Advice Requested - CHDK Security Project - Object Detection and Steganography - page 4 - General Discussion and Assistance - CHDK Forum

Advice Requested - CHDK Security Project - Object Detection and Steganography

  • 33 Replies
  • 7770 Views
Advertisements
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.

For now I think this method is fine, but you do have a good point. Looking at a few non-modified photos the tables do all seem to be the same. You could definitely tell the image had been modified at least by an image editing program if I choose to use this method. I'm happy for now that the modifications are not immediately noticeable to the average user, I'm not sure I have enough time or energy to attempt to defend against programmatic detection methods.

The project is being done for a graduate course and it's more about learning how these things would be done than providing full-proof protection against detection schemes. I'll include that bit of information in my presentation however as a downside to this approach.

Sorry to revive an oldish thread, but I'm working with Vegetothe1st on this project. Right now, I'm focusing on disabling image capture when a picture is taken. So far, by hooking into the file hooks and using filewrite_set_discard_jpeg(), I've been able to disable images being saved to the SD card. Unfortunately, the camera thinks the image is saved, and going to the playback mode creates "unidentified" images that don't really exist on the memory card, but take up slots in the image review (until the camera is restarted). I tried decrementing the file_counter_var, but decrementing it directly did not have any obvious effects? Do any of you have any suggestions? It's a cosmetic thing, so if you don't have any suggestions, no worries, but I am hoping to take care of this. A forum search did not turn up a whole lot.

Thanks!

*

Offline reyalp

  • ******
  • 12208
Sorry to revive an oldish thread, but I'm working with Vegetothe1st on this project. Right now, I'm focusing on disabling image capture when a picture is taken. So far, by hooking into the file hooks and using filewrite_set_discard_jpeg(), I've been able to disable images being saved to the SD card. Unfortunately, the camera thinks the image is saved, and going to the playback mode creates "unidentified" images that don't really exist on the memory card, but take up slots in the image review (until the camera is restarted).
Unfortunately, we don't know how to avoid this. The camera likely maintains the list of images at some higher level than the filewrite stuff.
Don't forget what the H stands for.

Unfortunately, we don't know how to avoid this. The camera likely maintains the list of images at some higher level than the filewrite stuff.

That's what I suspected, but I figured it was at least worth asking. Thanks for the quick reply!


 

Related Topics