PNG Merge - Revision history

PhilippeTeuwen: /* Challenge 3 */

2015-01-19T23:29:55Z

Challenge 3

← Older revision		Revision as of 23:29, 19 January 2015
Line 351:		Line 351:
	<br>Here is such example, all you have to reveal the indexed image is to patch the color byte from 0 to 3 and the IHDR CRC.		<br>Here is such example, all you have to reveal the indexed image is to patch the color byte from 0 to 3 and the IHDR CRC.
	<br><br>[[Image:Manul_laphroaig.png\|link=http://wiki.yobi.be/images/d/d1/Manul_laphroaig.png]]		<br><br>[[Image:Manul_laphroaig.png\|link=http://wiki.yobi.be/images/d/d1/Manul_laphroaig.png]]
	<br><br>The palette, magnified:		<br><br>The 8-color palette, magnified:
	<br>[[Image:Pal_8c2_x10.png]]		<br>[[Image:Pal_8c2_x10.png]]

PhilippeTeuwen: /* Challenge 3 */

2015-01-19T23:21:39Z

Challenge 3

← Older revision		Revision as of 23:21, 19 January 2015
Line 351:		Line 351:
	<br>Here is such example, all you have to reveal the indexed image is to patch the color byte from 0 to 3 and the IHDR CRC.		<br>Here is such example, all you have to reveal the indexed image is to patch the color byte from 0 to 3 and the IHDR CRC.
	<br><br>[[Image:Manul_laphroaig.png\|link=http://wiki.yobi.be/images/d/d1/Manul_laphroaig.png]]		<br><br>[[Image:Manul_laphroaig.png\|link=http://wiki.yobi.be/images/d/d1/Manul_laphroaig.png]]
			<br><br>The palette, magnified:
			<br>[[Image:Pal_8c2_x10.png]]

	==PNG fix CRC==		==PNG fix CRC==

PhilippeTeuwen: /* Challenge 2 */

2015-01-19T23:00:36Z

Challenge 2

← Older revision		Revision as of 23:00, 19 January 2015
Line 345:		Line 345:
	<br>[[Image:Incincinception.png\|link=http://wiki.yobi.be/images/d/df/Incincinception.png]]		<br>[[Image:Incincinception.png\|link=http://wiki.yobi.be/images/d/df/Incincinception.png]]
	<!-- http://datamatrix.kaywa.com/img.php?s=1&d=xxxxxxx -->		<!-- http://datamatrix.kaywa.com/img.php?s=1&d=xxxxxxx -->
			===Challenge 3===
			Actually there is a trick to minimize the patches to apply while maintaining a perfect compatibility with the standard:
			<br>Instead of starting from a RGB image, let's start from a 8-bit Greyscale image.
			<br>So one pixel from the greyscale image will correspond to one pixel of the indexed image, no more need for patching image size or dealing with scanline filter bytes!
			<br>Here is such example, all you have to reveal the indexed image is to patch the color byte from 0 to 3 and the IHDR CRC.
			<br><br>[[Image:Manul_laphroaig.png\|link=http://wiki.yobi.be/images/d/d1/Manul_laphroaig.png]]

	==PNG fix CRC==		==PNG fix CRC==

PhilippeTeuwen: /* Pixel mapping */

2015-01-19T17:27:08Z

Pixel mapping

← Older revision		Revision as of 17:27, 19 January 2015
Line 327:		Line 327:
	* RGB pixel(261,21): (1+3'''261''')+('''21'''(1+3*400))=26005		* RGB pixel(261,21): (1+3'''261''')+('''21'''(1+3*400))=26005
	* indexed pixel (340,64): (1+'''340''')+('''64'''*(1+400))=26005		* indexed pixel (340,64): (1+'''340''')+('''64'''*(1+400))=26005
			This schema by Ange helps understanding both IDAT values interpretations:
			<br>[[Image:MergeRGBillustrated_cropped.png\|500px]]

	===Challenge===		===Challenge===

PhilippeTeuwen: /* Steganalysis-resistant */

2015-01-19T17:24:41Z

Steganalysis-resistant

← Older revision		Revision as of 17:24, 19 January 2015
Line 317:		Line 317:
	<br><br>[[Image:Pngmerge-stegano.png]]		<br><br>[[Image:Pngmerge-stegano.png]]
	<br><br>While for the image on the right, nothing can be seen in the LSB (except for some scanline filter bytes that happen to be present on top of a uniform area near the top left corner).		<br><br>While for the image on the right, nothing can be seen in the LSB (except for some scanline filter bytes that happen to be present on top of a uniform area near the top left corner).
		⚫	<br><br>I cannot share @reversity 's original hand-crafted PoC but it was not steganalysis-resistant, here a crop of the top left:
⚫	~~<br><br>This~~ steganalysis helps also to understand how RBG pixels are mapped to the indexed image pixels.
		⚫	<br>[[Image:Reversity-stegano.png]]
			===Pixel mapping===
		⚫	The steganalysis seen in previous section helps also to understand how RBG pixels are mapped to the indexed image pixels.
	<br>Each RGB pixel will "produce" 3 indexed pixels so if the indexed image is of the same size as the RGB one, it will actually occupy only 1/3 of the RGB IDAT.		<br>Each RGB pixel will "produce" 3 indexed pixels so if the indexed image is of the same size as the RGB one, it will actually occupy only 1/3 of the RGB IDAT.
	<br>Let's look at e.g. pixel (261,21) on the RGB image:		<br>Let's look at e.g. pixel (261,21) on the RGB image:
Line 324:		Line 327:
	* RGB pixel(261,21): (1+3'''261''')+('''21'''(1+3*400))=26005		* RGB pixel(261,21): (1+3'''261''')+('''21'''(1+3*400))=26005
	* indexed pixel (340,64): (1+'''340''')+('''64'''*(1+400))=26005		* indexed pixel (340,64): (1+'''340''')+('''64'''*(1+400))=26005

⚫	<br><br>I cannot share @reversity 's original hand-crafted PoC but it was not steganalysis-resistant, here a crop of the top left:
⚫	<br>[[Image:Reversity-stegano.png]]

	===Challenge===		===Challenge===

PhilippeTeuwen: /* Steganalysis-resistant */

2015-01-19T17:22:54Z

Steganalysis-resistant

← Older revision		Revision as of 17:22, 19 January 2015
Line 317:		Line 317:
	<br><br>[[Image:Pngmerge-stegano.png]]		<br><br>[[Image:Pngmerge-stegano.png]]
	<br><br>While for the image on the right, nothing can be seen in the LSB (except for some scanline filter bytes that happen to be present on top of a uniform area near the top left corner).		<br><br>While for the image on the right, nothing can be seen in the LSB (except for some scanline filter bytes that happen to be present on top of a uniform area near the top left corner).
			<br><br>This steganalysis helps also to understand how RBG pixels are mapped to the indexed image pixels.
			<br>Each RGB pixel will "produce" 3 indexed pixels so if the indexed image is of the same size as the RGB one, it will actually occupy only 1/3 of the RGB IDAT.
			<br>Let's look at e.g. pixel (261,21) on the RGB image:
			<br>[[Image:tabasco_stegano.png]]
			<br>It maps to pixel (340,64) on the indexed image because both share the same data in the IDAT bytestream (not forgetting the 1 filter byte at start of each scanline):
			* RGB pixel(261,21): (1+3'''261''')+('''21'''(1+3*400))=26005
			* indexed pixel (340,64): (1+'''340''')+('''64'''*(1+400))=26005

	<br><br>I cannot share @reversity 's original hand-crafted PoC but it was not steganalysis-resistant, here a crop of the top left:		<br><br>I cannot share @reversity 's original hand-crafted PoC but it was not steganalysis-resistant, here a crop of the top left:
	<br>[[Image:Reversity-stegano.png]]		<br>[[Image:Reversity-stegano.png]]

PhilippeTeuwen: /* Literate programming */

2015-01-19T16:56:12Z

Literate programming

← Older revision		Revision as of 16:56, 19 January 2015
Line 17:		Line 17:

	==Literate programming==		==Literate programming==
	~~This~~ ~~code,~~ ~~also~~ available on ~~Github~~ ~~'''TODO'''~~ can do the job:		[{{#filelink: mergeRGBi.py}} mergeRGBi.py (available for download here)] can do the job:
	{{#fileanchor: mergeRGBi.py}}		{{#fileanchor: mergeRGBi.py}}
	<source lang=python>		<source lang=python>

PhilippeTeuwen: /* Steganalysis-resistant */

2015-01-18T15:59:29Z

Steganalysis-resistant

← Older revision		Revision as of 15:59, 18 January 2015
Line 317:		Line 317:
	<br><br>[[Image:Pngmerge-stegano.png]]		<br><br>[[Image:Pngmerge-stegano.png]]
	<br><br>While for the image on the right, nothing can be seen in the LSB (except for some scanline filter bytes that happen to be present on top of a uniform area near the top left corner).		<br><br>While for the image on the right, nothing can be seen in the LSB (except for some scanline filter bytes that happen to be present on top of a uniform area near the top left corner).
	<br><br>I cannot share @reversity 's original hand-crafted PoC but it was not steganalysis-resistant:		<br><br>I cannot share @reversity 's original hand-crafted PoC but it was not steganalysis-resistant, here a crop of the top left:
	<br>[[Image:Reversity-stegano.png]]		<br>[[Image:Reversity-stegano.png]]

PhilippeTeuwen: /* Going further? */

2015-01-18T15:57:35Z

Going further?

← Older revision		Revision as of 15:57, 18 January 2015
Line 370:		Line 370:
	<br>But the method would have to be integrated without destroying our careful rgb values<>indexes correspondences...		<br>But the method would have to be integrated without destroying our careful rgb values<>indexes correspondences...

	Actually histogram is useful to detect that some manipulation was done on part of the image, e.g. taking again the example given as introduction, we know the indexed image is embedded in the first 1/3 of the image. Let's compare its histogram with the ~~second~~ 2/3:		Actually histogram is useful to detect that some manipulation was done on part of the image, e.g. taking again the example given as introduction, we know the indexed image is embedded in the first 1/3 of the image. Let's compare its histogram with the lower 2/3:
	<br>[[Image:Tabasco_what_histo.png]]		<br>[[Image:Tabasco_what_histo.png]]

PhilippeTeuwen: /* Going further? */

2015-01-18T14:48:01Z

Going further?

← Older revision		Revision as of 14:48, 18 January 2015
Line 370:		Line 370:
	<br>But the method would have to be integrated without destroying our careful rgb values<>indexes correspondences...		<br>But the method would have to be integrated without destroying our careful rgb values<>indexes correspondences...

	Actually histogram is useful to detect that some manipulation was done on part of the image, e.g.		Actually histogram is useful to detect that some manipulation was done on part of the image, e.g. taking again the example given as introduction, we know the indexed image is embedded in the first 1/3 of the image. Let's compare its histogram with the second 2/3:
			<br>[[Image:Tabasco_what_histo.png]]