Advice Requested - CHDK Security Project - Object Detection and Steganography - page 3 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 [3] 4   Go Down

Advice Requested - CHDK Security Project - Object Detection and Steganography

  • 33 Replies
  • 18466 Views
*

Offline Vegetothe1st

  • *
  • 19
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #20 on: 07 / March / 2014, 15:41:56 »
Advertisements
I've been trying to integrate an encryption  library called "libsodium" (https://github.com/jedisct1/libsodium) into CHDK and have run into some issues. I managed to cross-compile the library with arm-elf-gcc, but I'm unsure how exactly to modify the Makefiles to properly link the library against the project. So far I've made a modification to /core/Makefile to include the library in the list of dependences for main.elf, but I believe I need to do more than that; the Makefile structure is just confusing to me not having worked with such a large project in the past.

I put all of the necessary headers in /include, and put the library in /lib/sodium as libsodium.a. There were some missing header files that CHDK didn't have that libsodium required, so I tried to copy them over from my local include directory; this might not be something that should be done, but it allowed the project to compile.

Interestingly enough, I was able to call functions from the library in /platform/generic/filewrite.c after including the appropriate headers, but they seem to either crash the camera outright or cause the camera to misbehave (power button stops working, etc...). Any idea which Makefiles I should be modifying to correctly link this library against the project? Or do the missing headers just kill it altogether?

I've also attached one of the ROMLOGs from the crashes. They're all the same, something going wrong in FaceDetect. Not entirely sure how to decipher it however.
« Last Edit: 07 / March / 2014, 16:33:43 by Vegetothe1st »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #21 on: 07 / March / 2014, 16:36:36 »
Quote from: Vegetothe1st on 07 / March / 2014, 15:41:56
I've been trying to integrate an encryption  library called "libsodium" (https://github.com/jedisct1/libsodium) into CHDK and have run into some issues. I managed to cross-compile the library with arm-elf-gcc, but I'm unsure how exactly to modify the Makefiles to properly link the library against the project. So far I've made a modification to /core/Makefile to include the library in the list of dependences for main.elf, but I believe I need to do more than that; the Makefile structure is just confusing to me not having worked with such a large project in the past.

I put all of the necessary headers in /include, and put the library in /lib/sodium as libsodium.a. There were some missing header files that CHDK didn't have that libsodium required, so I tried to copy them over from my local include directory; this might not be something that should be done, but it allowed the project to compile.

Interestingly enough, I was able to call functions from the library in /platform/generic/filewrite.c after including the appropriate headers, but they seem to either crash the camera outright or cause the camera to misbehave (power button stops working, etc...). Any idea which Makefiles I should be modifying to correctly link this library against the project? Or do the missing headers just kill it altogether?

If you can call the library functions from other CHDK code then it is linked in - otherwise you would get linker errors during the build.

Copying header files is probably not a good idea unless you can find arm-elf-gcc versions; but it would depend on what header files they were.

If the camera crashes it should generate a ROMLOG, if you save this you can then trace the code in the main.bin.dump file generated by the build to see where it is crashing.

Posting the code might help.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline Vegetothe1st

  • *
  • 19
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #22 on: 08 / March / 2014, 04:20:37 »
It took me a bit longer than expected, but I got the message embedding code working with the firmware (minus encryption). However, I'm occasionally encountering some problems that I'll detail below:

1. Unidentified Image on camera image viewer. The camera shows a thumbnail of the image but won't display it across the entire screen, instead claiming that it is an "Unidentified Image". Any particular reason this would occur? There don't appear to be any visible distortions in the image, and my computer's image viewer is able to display them fine. I tried uploading JPEGs from the web to the camera and it was able to display them correctly, so it must have something to do with how I'm modifying the photos.

2. Multi-part photos. I thought I had this covered by always using the last chunk in the fwt_data_struct, but it seems that some photos call filewrite_main_hook multiple times and only save a single photo. For the photos that do this, the jpeg_file_offset changes frequently (typically starts at a high positive value, drops to -1, and then hits 0 before stopping). These images occasionally come out distorted.
« Last Edit: 08 / March / 2014, 04:39:36 by Vegetothe1st »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #23 on: 08 / March / 2014, 09:40:14 »
Quote from: Vegetothe1st on 08 / March / 2014, 04:20:37
1. Unidentified Image on camera image viewer. The camera shows a thumbnail of the image but won't display it across the entire screen, instead claiming that it is an "Unidentified Image". Any particular reason this would occur?
Since you're not touching the Exif block, the camera can successfully decompress its small embedded thumbnail - that's what you're seeing.
Quote
There don't appear to be any visible distortions in the image, and my computer's image viewer is able to display them fine. I tried uploading JPEGs from the web to the camera and it was able to display them correctly, so it must have something to do with how I'm modifying the photos.
You've been warned above that modifying random bits of the compressed data can easily make the JPEG stream invalid. The PC software can probably compensate for most of these errors. The camera, however, uses the DSP part of the DIGIC processor to decompress/compress JPEG data. It obviously only has to be able to decode what's in its specification (JPEG data made by Canon cameras). Your modifications to the JPEG probably trigger an exception in the DSP, which results in the error message.

Quote
2. Multi-part photos. I thought I had this covered by always using the last chunk in the fwt_data_struct, but it seems that some photos call filewrite_main_hook multiple times and only save a single photo. For the photos that do this, the jpeg_file_offset changes frequently (typically starts at a high positive value, drops to -1, and then hits 0 before stopping). These images occasionally come out distorted.
The high positive value is IMHO the start of the main JPEG data, the 0 offset means the Exif chunk which has to be located at the start of the file.
Logged
*

Offline Vegetothe1st

  • *
  • 19
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #24 on: 08 / March / 2014, 14:49:13 »
Thanks again for the information srs_4c. :)

Quote
Since you're not touching the Exif block, the camera can successfully decompress its small embedded thumbnail - that's what you're seeing.

That makes sense, I forgot that embedded thumbnail was included in the Exif data.

Quote
You've been warned above that modifying random bits of the compressed data can easily make the JPEG stream invalid. The PC software can probably compensate for most of these errors. The camera, however, uses the DSP part of the DIGIC processor to decompress/compress JPEG data. It obviously only has to be able to decode what's in its specification (JPEG data made by Canon cameras). Your modifications to the JPEG probably trigger an exception in the DSP, which results in the error message.

I probably should have taken this warning more to heart, I didn't realize that modifying the value only slightly would cause such distortions in the image. I wasn't seeing these distortions on images taken by the camera because they are fairly high resolution (though I can see them if I zoom in close which I found out this morning). On lower resolution images, the distortion is quite visible at standard zoom in an image viewer.

I'm going to try modification of the DCT quantization tables as outlined here: http://www.guillermito2.net/stegano/jsteg/. We'll see if that fairs any better. I'm not sure if this works without re-encoding of the image, it isn't entirely made clear... It seems you'd need to re-encode it using the updated table.
« Last Edit: 08 / March / 2014, 15:06:14 by Vegetothe1st »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #25 on: 08 / March / 2014, 16:25:55 »
Quote from: Vegetothe1st on 08 / March / 2014, 14:49:13
I'm going to try modification of the DCT quantization tables as outlined here: http://www.guillermito2.net/stegano/jsteg/. We'll see if that fairs any better. I'm not sure if this works without re-encoding of the image, it isn't entirely made clear... It seems you'd need to re-encode it using the updated table.

The 8x8 DCT blocks are compressed with a lossless compression - if you modify the LSB of the compressed data you will break the compression (and the file).

To modify the DCT data you would need to de-compress each block, change the LSB of one or more values, then recompress it. To do this without changing the compressed size and without changing the huffman tree data stored in the file header would be next to impossible. If you change either of these then you will have to re-write the file header as well.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline Vegetothe1st

  • *
  • 19
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #26 on: 09 / March / 2014, 06:13:24 »
Modifying the quantization tables prefaced by the (0xFF, 0xDB) marker does seem to be working. They're very limited in size, but I'm able to encode the date/time in them without an issue. These do slightly change the way the image is rendered in a viewer (I've attached a sample image where this can be seen in the black circle), but otherwise the image seems fine. The camera even recognizes it which is great. :)

I still need to implement this on the camera itself (it's currently just a C program that uses existing images), but I'm hopeful it will still work.

In the attached images you should be able to see a difference in how some of the areas of the picture are rendered. What I thought was most noticeable was the black circle in the upper left corner, but the words on the piece of paper change a bit as well. This is a bit of a lower resolution image, I wasn't honestly able to tell a difference between the images taken by the camera just by looking at them.

Each of the images shares the same Exif data minus the file modification time; is this time rewritten once the file is closed for writing?

The images are of my old toothpick bridge from my high school Physics class if anybody was curious.  8)
« Last Edit: 09 / March / 2014, 06:37:11 by Vegetothe1st »
Logged
*

Offline Vegetothe1st

  • *
  • 19
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #27 on: 09 / March / 2014, 06:22:03 »
Also, a picture of my previous method of just changing the image data from the end of the image back towards the start. Obviously not good for lower resolution images, but it's somewhat difficult to notice in the resolution the camera takes images at.
Logged
*

Offline Vegetothe1st

  • *
  • 19
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #28 on: 10 / March / 2014, 11:18:25 »
I've implemented it on the camera and it seems to be working. Here are some sample images with a message encoded in them. They seem to be valid JPEG files from what I can tell.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Advice Requested - CHDK Security Project - Object Detection and Steganography
« Reply #29 on: 10 / March / 2014, 14:51:35 »
Quote from: Vegetothe1st on 09 / March / 2014, 06:13:24
Modifying the quantization tables prefaced by the (0xFF, 0xDB) marker does seem to be working. They're very limited in size, but I'm able to encode the date/time in them without an issue. These do slightly change the way the image is rendered in a viewer (I've attached a sample image where this can be seen in the black circle), but otherwise the image seems fine. The camera even recognizes it which is great. :)

I'm glad you seem to have found a solution to your problem; but I would like to point out one thing.

In your original post, one of your goals was (emphasis added):
    2. Embed additional information inside the photo itself in a non-obvious way (i.e. encode it into the image)

AFAIK, Canon uses a fixed set of quantization tables for any given camera. Examination of the quantization table is a forensic method used to identify the source of an image or if the image has been modified (editing programs will often change the table when resaving a jpeg).

Depending on your actual security requirement, modifying the quantization table may not be sufficient, as it would be both easily detectable (compare to known Canon tables), and easily removable (restore default Canon table).

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
Pages: 1 2 [3] 4   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal