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).
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.
