CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: Vegetothe1st on 10 / February / 2014, 14:04:50
-
Hi everyone,
I'm looking to do a security-related project using CHDK and wanted to get some tips and pointers before beginning. I haven't dug into the firmware at all yet, so pointers on which files would be important to look at would be appreciated.
I'd like to modify the firmware to do the following (more detail below):
1. Prevent a user from taking a picture when a certain object is in the frame (company logo, etc...)
2. Embed additional information inside the photo itself in a non-obvious way (i.e. encode it into the image)
3. Detect a particular user's face in an image
For the first point, the idea is to prevent a user from taking an image if they're taking a photo of some particular object (a person with a specific badge on, documents with watermarks, etc...). Ideally this detection could be performed before the user pressed the capture button and prevent the photo from ever being taken. I'm open to suggestions on object detection algorithms to use, I plan on starting by detecting a simple mono-colored shape and advancing from there.
The second point is a bit simpler and can be done after image capture. The idea is to use steganography to encode additional information into the photo, such as the time and date it was taken. There should be some simple methods to do this, but I'll need to modify the image before it's saved to the SD card.
Finally, the third point is easily the most difficult (and just a stretch goal). I'm wondering if it's possible to detect a particular user's face in an image and mask that person's face. I would probably start with masking all faces, but ideally it would only mask the face of a specific person. I know Canon cameras with DIGIC 3 processors and above have face detection built into them, can this feature be accessed and leveraged for this goal? Also, is the goal possible on DIGIC 2 cameras that don't have built-in face detection?
Any thoughts, tips, etc... on directions to approach these goals from would be greatly appreciated!
-
Also, if this isn't the right forum to post this in then please let me know! I looked around and thought this was the best place. ::)
-
Interesting idea; but I think you will face some challenges trying to do this with a Canon P&S camera.
Here are some of my initial thoughts.
CHDK does not modify the camera firmware, it loads every time the camera is started from special files on the SD card.
Unlocking the SD card, or formatting it in the camera will remove CHDK and all your security options will be gone.
Your second goal, to embed data in the image, would be the easiest - CHDK has access to the raw captured data before the camera converts it to a JPEG. You could fairly easily modify the captured data to embed a watermark. Remember you are working with raw sensor data (in a Bayer format) not RGB pixels.
For the other two you would probably need to work with the live view data shown in the LCD. This has much lower resolution than the sensor is capable of (720x240 for most cameras) and is in YUV format. Being able to detect a logo or particular person, at different angles, positions and lighting at such a low resolution could be a challenge.
There is also not a lot of CPU power available. I don't know what the state of the art in recognition algorithms is like these days; but I imagine it still needs a fair bit of horsepower.
Phil.
-
3. Detect a particular user's face in an image
How many faces in your library? Some cameras has built in function to recognize particular user's face, camera shows their names on LCD.
-
Interesting idea; but I think you will face some challenges trying to do this with a Canon P&S camera.
Here are some of my initial thoughts.
CHDK does not modify the camera firmware, it loads every time the camera is started from special files on the SD card.
Unlocking the SD card, or formatting it in the camera will remove CHDK and all your security options will be gone.
Your second goal, to embed data in the image, would be the easiest - CHDK has access to the raw captured data before the camera converts it to a JPEG. You could fairly easily modify the captured data to embed a watermark. Remember you are working with raw sensor data (in a Bayer format) not RGB pixels.
For the other two you would probably need to work with the live view data shown in the LCD. This has much lower resolution than the sensor is capable of (720x240 for most cameras) and is in YUV format. Being able to detect a logo or particular person, at different angles, positions and lighting at such a low resolution could be a challenge.
There is also not a lot of CPU power available. I don't know what the state of the art in recognition algorithms is like these days; but I imagine it still needs a fair bit of horsepower.
Phil.
Hey Phil,
Thanks for your quick response! You're of course right that replacing the SD card would remove the security features, this project is more just to see what's possible with CHDK. I'll keep using the live view data in mind, I'm not sure there is another way to prevent image capture for the first point without using this data. The third point could be done with the higher resolution image (the image should just be saved with the face obscured rather than obscure it in real-time), but I'll need to figure out how face detection is done in these cameras.
-
3. Detect a particular user's face in an image
How many faces in your library? Some cameras has built in function to recognize particular user's face, camera shows their names on LCD.
I'd just start with my own for now, it would be great if I had access to the functionality you mentioned or a way to code it into a camera that didn't have it. I'm not sure if it's a new feature that was included in the later processors because of an increase in processing power or just a new feature that happened to be developed at the time.
-
I'd just start with my own for now, it would be great if I had access to the functionality you mentioned or a way to code it into a camera that didn't have it. I'm not sure if it's a new feature that was included in the later processors because of an increase in processing power or just a new feature that happened to be developed at the time.
I suspect it depends on hardware (Likely the Digic DSP rather than just raw CPU speed) but it's kind of irrelevant, because it would be impractical to try to port Canon firmware features like this anyway.
I did some very preliminary investigation of the face detect code in http://chdk.setepontos.com/index.php?topic=8243.msg86889#msg86889 (http://chdk.setepontos.com/index.php?topic=8243.msg86889#msg86889) - This isn't directly applicable to your project, but might give you some starting places to look in the firmware code.
Regarding #2, as phil says modifying the raw data is relatively easy, but keep in mind that unless you are saving raw or DNG the resulting data will be encoded with lossy jpeg compression.
-
It seems that the camera I'll be using is the Canon PowerShot A2500. As far as I can tell it has a CHDK port that supposedly works (firmware is available on the downloads page and the porting thread has a decent amount of activity). This camera has a DIGIC 4 processor, so face detection should be a go. :)
A2500 Porting Thread: http://chdk.setepontos.com/index.php?topic=10626.0 (http://chdk.setepontos.com/index.php?topic=10626.0)
-
Started digging into this a bit after finally getting all the hardware, I'm having trouble starting however. I planned on doing the Stego portion first as it seems the simplest, but I'm having trouble understanding the order in which code is run. It seems that main.c loops forever in its core_spytask() function waiting for the raw_data_available variable to be set so it can process the data. This variable is set in /platform/generic/capt_seq.c, apparently when a capture is in the process of occurring; raw.c then processes and saves the data.
However, this doesn't seem to reference writing JPEG images at all. The code related to JPEGs seems to be contained in remotecap.c and /platform/generic/filewrite.c. raw.c does make one reference to remotecap_get_target(), but it's unclear to me how remotecap.c is ever aware the camera wants to save JPEG images.
I believe that modifying the raw image in raw.c to embed time/date information should be straightforward enough, but this will likely be lost (I believe) when the image is transformed into a JPEG via the functionality in filewrite.c. Ideally I could wait until this process had been done and then embed time/date information (so the information remains decipherable), but I can't figure out where this finalized JPEG would be available to modify. I'd prefer to embed the image in the JPEG rather than the RAW image because JPEGs are the more common image type.
Any pointers are appreciated as always. :)
-
Started digging into this a bit after finally getting all the hardware, I'm having trouble starting however. I planned on doing the Stego portion first as it seems the simplest, but I'm having trouble understanding the order in which code is run. It seems that main.c loops forever in its core_spytask() function waiting for the raw_data_available variable to be set so it can process the data. This variable is set in /platform/generic/capt_seq.c, apparently when a capture is in the process of occurring; raw.c then processes and saves the data.
However, this doesn't seem to reference writing JPEG images at all.
JPEGs are made and saved by Canon firmware tasks, not by CHDK. (Note that I haven't tried to spot mistakes - if any - in the above)
If you need to access the JPEG data before it's saved, you'll need one of the filewritetask hooks. filewrite_main_hook() in platform/generic/filewrite.c is the first CHDK function that gets called in the JPEG saving process. This hook is only called once for each JPEG file on DryOS < r50 cameras. Later DryOS cameras save large JPEG files in multiple passes, you often won't see all parts of the file at once. The JPEG file data itself is broken into one or more chunks. On DryOS >= r50 the EXIF part of big JPEGs is the last chunk, it gets written to the beginning of the file. For smaller files and for earlier cameras, the EXIF is the first chunk.
I believe that modifying the raw image in raw.c to embed time/date information should be straightforward enough, but this will likely be lost (I believe) when the image is transformed into a JPEG via the functionality in filewrite.c.
If the CHDK raw hook is placed correctly, changes to the raw data will make it into the JPEG (you can try this easily, modify smaller parts of the raw buffer and check the resulting JPEGs). There's one thing we know about which carries information about the original image: "i-contrast" - it stores some image data elsewhere and applies it after our raw hook.
-
Thanks for the reply srsa_4c!
That's a bit unfortunate that CHDK doesn't have direct access to the JPEG creation/saving process. I'll see if I can use any of the hooks in filewrite.c, but I'm still not entirely clear on how they work. It seems the camera I'm using (A2500) has DryOS v2.3 (revision 52), so it might be saving the JPEG in multiple passes. Odd that the JPEG chunks are passed in different orders based on the file size.
I'll also try directly modifying the RAW image and seeing what makes it into the JPEG. My concern there is that much of the RAW data is lost when converting to a JPEG, so any information I embed will likely be lost as well.
Currently I'm writing a separate C program to get the framework laid out for the steganography, then I'll try and implement it into CHDK.
-
I'll also try directly modifying the RAW image and seeing what makes it into the JPEG. My concern there is that much of the RAW data is lost when converting to a JPEG, so any information I embed will likely be lost as well.
If you want to modify the image data in filewrite, that will be very difficult since it's already jpeg compressed.
-
I'll also try directly modifying the RAW image and seeing what makes it into the JPEG. My concern there is that much of the RAW data is lost when converting to a JPEG, so any information I embed will likely be lost as well.
If you want to modify the image data in filewrite, that will be very difficult since it's already jpeg compressed.
Does it matter that it's already JPEG compressed? Given that I want to embed time/date information in the photo (i.e. by modifying the LSB to contain the data), it seems that doing this on already compressed data would be preferable. Then my work won't be lost to compression, correct?
Is it possible to actually modify the image data in filewrite.c? It seems like it might be by modifying the values pointed to by the addr pointer in various chunks, but I'm not sure how you could get reliable position information for later decoding of the embedded information.
My current strategy is to start from the end of the JPEG image and work backwards (skipping the 0xFF 0xD9 bytes at the end of the image), to ensure that I don't overwrite any header information at the start of the file. I'm noticing that I need to watch out for other markers in the data however, such as (0xFF 0x00), which attempts to mark 0xFF as a non-marker byte.
-
Does it matter that it's already JPEG compressed? Given that I want to embed time/date information in the photo (i.e. by modifying the LSB to contain the data), it seems that doing this on already compressed data would be preferable. Then my work won't be lost to compression, correct?
If you fiddle with random bits in the compressed data, I would expect it to stop being a valid jpeg. Maybe that's ok in your application.
Is it possible to actually modify the image data in filewrite.c? It seems like it might be by modifying the values pointed to by the addr pointer in various chunks, but I'm not sure how you could get reliable position information for later decoding of the embedded information.
Filewrite gives you enough information to know the position within the file and the size of the chunk you are working with.
-
Does it matter that it's already JPEG compressed? Given that I want to embed time/date information in the photo (i.e. by modifying the LSB to contain the data), it seems that doing this on already compressed data would be preferable. Then my work won't be lost to compression, correct?
If you fiddle with random bits in the compressed data, I would expect it to stop being a valid jpeg. Maybe that's ok in your application.
Is it possible to actually modify the image data in filewrite.c? It seems like it might be by modifying the values pointed to by the addr pointer in various chunks, but I'm not sure how you could get reliable position information for later decoding of the embedded information.
Filewrite gives you enough information to know the position within the file and the size of the chunk you are working with.
How the data is presented in filewrite.c is the same as how it's seen when you open the JPEG in a hex editor, correct? I was going to try and create some logging files later today to ensure this was the case. If true, then I should be able to modify the bytes as long as I'm careful to avoid messing with the JPEG markers. I've noticed that overwriting any of these does make it an invalid JPEG and it can't be opened by an image viewer. I would like it to stay openable. :)
Ideally I'd want to modify only the data in the last chunk (assuming it's not the Exif headers as was mentioned before), so that when decoding the message in the JPEG I know I can just start from the end and work backwards. Encoding elsewhere in the image (say in the third chunk rather than the last) may give me an offset from the start of the JPEG, but I wouldn't have any way of knowing this offset when trying to decode.
Do you know if there are any minimum chunk sizes? Could be an issue if I'm waiting to see the last chunk and it only turns out to be a few bytes when I need a lot more.
-
Does it matter that it's already JPEG compressed? Given that I want to embed time/date information in the photo (i.e. by modifying the LSB to contain the data), it seems that doing this on already compressed data would be preferable. Then my work won't be lost to compression, correct?
If you fiddle with random bits in the compressed data, I would expect it to stop being a valid jpeg. Maybe that's ok in your application.
Is it possible to actually modify the image data in filewrite.c? It seems like it might be by modifying the values pointed to by the addr pointer in various chunks, but I'm not sure how you could get reliable position information for later decoding of the embedded information.
Filewrite gives you enough information to know the position within the file and the size of the chunk you are working with.
How the data is presented in filewrite.c is the same as how it's seen when you open the JPEG in a hex editor, correct? I was going to try and create some logging files later today to ensure this was the case. If true, then I should be able to modify the bytes as long as I'm careful to avoid messing with the JPEG markers. I've noticed that overwriting any of these does make it an invalid JPEG and it can't be opened by an image viewer. I would like it to stay openable. :)
Ideally I'd want to modify only the data in the last chunk (assuming it's not the Exif headers as was mentioned before), so that when decoding the message in the JPEG I know I can just start from the end and work backwards. Encoding elsewhere in the image (say in the third chunk rather than the last) may give me an offset from the start of the JPEG, but I wouldn't have any way of knowing this offset when trying to decode.
Do you know if there are any minimum chunk sizes? Could be an issue if I'm waiting to see the last chunk and it only turns out to be a few bytes when I need a lot more.
I thought you wanted to add the data as a hidden watermark to the image pixel data?
If this is the case then you won't be able to do this by modifying the JPEG file data. The RAW image data is converted to YCbCr colour space (often with 4:1:1 encoding), split into 8x8 pixel chunks each of which undergoes a discrete cosine transform (DCT) from which the least visible information is discarded. The data is then compressed again using a lossless huffman encoding compression.
If you change the LSB of this JPEG compressed data it will most likely invalidate the data stream and the decompression of the image will fail when you try and view it.
In order to modify the LSB of a single pixel you would have to uncompress the JPEG data, make the change and then recompress it, while keeping the file size identical unless you also update the file headers.
Phil.
-
After some testing, it appears I can see all of the JPEG data using jpeg_chunks->address; apparently the data all seems to fit in a single chunk every time. Now I need to try modifying some of it.
Addressing the concerns above, I've been messing around with modifying the LSBs to encode the data and it is very easy to mess the JPEG up such that it becomes a corrupted image. It's definitely possible to change a few bytes and have the image be perfectly valid though, at least from my testing on standalone JPEG images that I've loaded and changed. I've yet to try modifying the data seen in the filewrite_main_hook, but it looks to be the same as the data I've already been messing with (starts with FFD8, ends with FFD9 as JPEGs should).
I'm just trying to encode date/time information into the image at the moment (if I said watermarking this is what I meant). This is doable by converting the information to a binary representation and then changing the LSB of a byte in the image to the value of a single bit in the message. This means I need to change 1 byte in the image for every bit in my message.
-----
On a different note, I'm noticing that occasionally during my testing the camera just turns off after taking a picture. I'm doing some long-running tasks for testing (converting the binary data to hex and printing it to a file), is this causing the camera to think it failed to take a picture and shut off? The LiveView shows the image and then proceeds back to live tracking, but the camera just shuts off after a few seconds of processing. Preventable by only printing a few thousand hex bytes rather than the whole image, so I'm assuming this is the case.
-
And directly modifying the bytes being pointed to works! :D
Time to finalize the steganography algorithm and get it implemented.
Slightly off the topic of CHDK, but does anybody know of any easy-to-use encryption libraries that I could integrate with CHDK? Might as well encrypt the embedded information as well. I tried getting both NaCl and Sodium to work, but wasn't able to; NaCl refused to compile at all, and I couldn't link a test program against Sodium for some reason despite the libraries being in /usr/local/lib. The latter issue might be a problem with my Ubuntu configuration, I can't seem to link against any libraries in that folder.
-
It's definitely possible to change a few bytes and have the image be perfectly valid though, at least from my testing on standalone JPEG images that I've loaded and changed.
Like Phil, I'm having trouble seeing why this would be true in the general case. Unless you've actually worked out how it affects compressed data and determined the result will always be valid, just having a few examples that aren't completely broken doesn't mean much.
On a different note, I'm noticing that occasionally during my testing the camera just turns off after taking a picture.
A first step would be to get a romlog: http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
Slightly off the topic of CHDK, but does anybody know of any easy-to-use encryption libraries that I could integrate with CHDK?
I don't know of any specifically, but given that CHDK doesn't have access to a full ANSI C library your best bet will be something light with minimal dependencies.
-
Like Phil, I'm having trouble seeing why this would be true in the general case. Unless you've actually worked out how it affects compressed data and determined the result will always be valid, just having a few examples that aren't completely broken doesn't mean much.
I'll hopefully know if my method will work tomorrow or Friday, I'll keep updating the thread. I'm not sure why it wouldn't work, the data present in filewrite_main_hook() is seemingly the exact same data that you would get when opening the JPEG in a hex editor. Again, I just need to ensure that I avoid modifying header information and other significant byte sequences (such as FF00 sequences that indicate the FF byte isn't a header).
A first step would be to get a romlog: http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
Thanks for that, I probably should have looked at the Debugging article more closely. I'll try and use these the next time the camera bugs out on me.
I don't know of any specifically, but given that CHDK doesn't have access to a full ANSI C library your best bet will be something light with minimal dependencies.
Good point, I'll need to make sure any solution I choose is pretty lightweight. I'll keep looking around, ideally I want an asymmetric algorithm so I could hard code the public key in the firmware and keep the other key private.
It might be possible just to write my own functions to implement RSA, it just never seems to be a good idea to try and do encryption yourself though when well-tested solutions exist.
-
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.
-
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.
-
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.
-
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.
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.
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.
-
Thanks again for the information srs_4c. :)
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.
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/. (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.
-
I'm going to try modification of the DCT quantization tables as outlined here: http://www.guillermito2.net/stegano/jsteg/. (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.
-
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)
-
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.
-
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.
-
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.
-
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!
-
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.
-
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!