[DONE] Optional Image Encryption

Started by Se7eN, January 13, 2014, 09:25:15 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Se7eN

So while I am fairly new to magic lantern (registered to post this but have been using ML for well over a year) i did take the time to search to see if anyone had suggested something similar before (turns out they had: http://www.magiclantern.fm/forum/index.php?topic=9541.msg91565#msg91565).

now all that being said, it seemed to me that it got somewhat brief and negative responses. i find that to be slightly disappointing as there is a large user base here who would benefit from having some method to put at least the most basic of encryption on their photos.

I guess I'll give some background on why I find this to be so important. I live in Washington, USA, a place that lies under the 9th U.S. Circuit Court of Appeals' jurisdiction, a recent ruling  in Cotterman v. United States (http://www.scotusblog.com/case-files/cases/cotterman-v-united-states/) says that unless I am suspected of a crime in which access to the device in question would furnish proof of said crime (read: reasonable suspicion) that the authorities have no right to either 1) compel me to decrypt the device 2) forcefully decrypt said device.  not everyone has these protections, but as of today (January 13th 2014) the Supreme Court of the United States has denied their Petition for Certiorari, meaning this case will never be heard by that court, cementing this into legal precedent. that being said as someone who regularly takes his camera places that are off limits, to photograph things that would later be incriminating, the ability to encrypt my photos would be extremely useful to my continued freedom.

I currently use ML on a 600D and love it, I'd just also like to have the option to encrypt my photos, perhaps using a unique password selected via the front scroll wheel or via the back arrow keys (although the first method would ensure compatibility across all camera's)

let me know what you think or if my limited coding abilities, use of Google, or generally snarky attitude could possibly be of any help.

-Se7eN

g3gg0

Didn't notice the other thread. Love that idea.
reporter support for not-so-friendly countries.

will think about it :)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Se7eN

Quote from: g3gg0 on January 14, 2014, 01:55:15 AM
Didn't notice the other thread. Love that idea.
reporter support for not-so-friendly countries.

will think about it :)

Thanks! that's all I can ask for, let me know if there is anyway I might be able to help.

-Se7eN

g3gg0

already had success with a simple hack, XORing the CR2 files with a fixed pattern and it worked ;)
- start camera
- enable hack
- shoot: saves the CR2
- repower
- try to view images, none worked
- repower
- enable hack
- try to view images, worked

but it was very hackish, trying to make it more portable and *a bit stable*
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Se7eN

Quote from: g3gg0 on January 14, 2014, 11:24:40 PM
already had success with a simple hack, XORing the CR2 files with a fixed pattern and it worked ;)
- start camera
- enable hack
- shoot: saves the CR2
- repower
- try to view images, none worked
- repower
- enable hack
- try to view images, worked

but it was very hackish, trying to make it more portable and *a bit stable*
Awesome! I wasn't expecting anything nearly that quick, Thanks!

-Se7eN

g3gg0

encryption is only one part that has to be done.

scenario 1:
lets assume the photographer is a reporter in some unstable country and gets caught shooting photos.
his SD/CF gets removed and being checked in-depth for photos on some computer.
full CR2/JPG/MOV encryption will successfully prevent the footage from being revealed.

scenario 2:
he is forced to show the images on his camera.
when viewing the shots, the camera ask for a password (using IME interface) or just displays "Image could not get displayed".
not a good idea. in the worst case he is getting tortured until he gives out the password or "fixes" the issue.

scenario 3:
some on-demand password dialog could be useful for other scenarios where there will be no punishment to fear.
e.g. on a set or where losing the footage would cause financial loss and thus needs to be encrypted.


to make the images not only non-readable, but also deniable as it would be the best in scenario 2, it should
open some template file (e.g. a flower) instead whenever an encrypted image is tried to be displayed.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Se7eN

the easiest workaround i can think of would be to simply let the user select a "safe" photo to be displayed from the available photos already on the SD card.

on a side note, while I may be willing to be charged with contempt of court to protect my images, I've yet to shoot anything that I'd be willing to let myself be tortured over. However, I would be fairly surprised if there wasn't someone out there somewhere who would be willing to go to that length to protect their images. there's also the chance that revealing the photos carries worse consequences than being tortured, indefinite incarceration is an example that comes to mind.

maybe hiding the password prompt as an action (button press maybe?) you have to perform while viewing one of the "safe" photos. kinda like pressing the delete button to enter the ML menu, except you'd press something else (white balance perhaps? ISO?).

-Se7eN

blade

I love the idea, however if the files are present, but not readable there is no plausible deniability. Something like saving in a true chript file would solve this issue.
eos400D :: eos650D  :: Sigma 18-200 :: Canon 100mm macro

RenatoPhoto

http://www.pululahuahostal.com  |  EF 300 f/4, EF 100-400 L, EF 180 L, EF-S 10-22, Samyang 14mm, Sigma 28mm EX DG, Sigma 8mm 1:3.5 EX DG, EF 50mm 1:1.8 II, EF 1.4X II, Kenko C-AF 2X

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

g3gg0

Quote from: blade on January 15, 2014, 07:46:47 PM
I love the idea, however if the files are present, but not readable there is no plausible deniability. Something like saving in a true chript file would solve this issue.

this:

Quote from: g3gg0 on January 15, 2014, 12:24:04 AM
to make the images not only non-readable, but also deniable as it would be the best in scenario 2, it should
open some template file (e.g. a flower) instead whenever an encrypted image is tried to be displayed.

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Se7eN

Quote from: blade on January 15, 2014, 07:46:47 PM
I love the idea, however if the files are present, but not readable there is no plausible deniability. Something like saving in a true chript file would solve this issue.

that's why i like g3gg0's idea of simply displaying a "safe" photo, everything works it's just all a little off. they may wonder why there's 100 copies of the exact same photo, but a simple I liked the way it looked, or "WTF?! you broke it!" seems like a simple enough way to get past that, assuming the password prompt is something that isn't easily stumbled upon. once they start getting prompted for a password then the "fun" begins.

all in all I don't think we're trying to make it so these photos are permanently inaccessible, just obfuscated behind some token encryption. basically allowing you to pretend that its all just the same photo, or a corrupted card.

Jolly Roger

Quote from: g3gg0 on January 15, 2014, 12:24:04 AM
to make the images not only non-readable, but also deniable as it would be the best in scenario 2, it should
open some template file (e.g. a flower) instead whenever an encrypted image is tried to be displayed.

So-called steganography (http://en.wikipedia.org/wiki/Steganography), I remember software like "camouflage" ten years ago..

Maybe some opensource solution could be of any help? That's Java: http://sourceforge.net/projects/openstego/

RenatoPhoto

Quote from: g3gg0 on January 15, 2014, 08:09:22 PM
???
If you had a wifi card connected to a nearby wifi area, you can make the pictures disappear. 
http://www.pululahuahostal.com  |  EF 300 f/4, EF 100-400 L, EF 180 L, EF-S 10-22, Samyang 14mm, Sigma 28mm EX DG, Sigma 8mm 1:3.5 EX DG, EF 50mm 1:1.8 II, EF 1.4X II, Kenko C-AF 2X

Michael Zöller

neoluxx.de
EOS 5D Mark II | EOS 600D | EF 24-70mm f/2.8 | Tascam DR-40

wolf

Using Ruberhose as a group would make every card in a Canon and every user suspicious of holding some secret photos.

Se7eN

Quote from: wolf on January 15, 2014, 09:27:44 PM
Using Ruberhose as a group would make every card in a Canon and every user suspicious of holding some secret photos.
Quote from: Michael Zöller on January 15, 2014, 08:58:25 PM
https://en.wikipedia.org/wiki/Rubberhose_%28file_system%29

hadn't heard of that before, love the idea, i just don't know that it'd be applicable here, would our camera's support such a file system? if so, talk about ideal the camera would simply appear empty until you entered the correct password/s.

for those people who actually know magic lantern is a thing and that it could be capable of implementing rubber hose, likely a somewhat small group. while i understand not everyone lives somewhere that pretends it holds people innocent until proven guilty, it'd be really hard to prove there was anything on that drive to begin with, you could simply claim you hadn't used that camera, never got around to it. I mean then the beatings could begin, but that seems to be the exact point of implementing rubberhose to begin with.

-Se7eN

Michael Zöller

Quote from: wolf on January 15, 2014, 09:27:44 PM
Using Ruberhose as a group would make every card in a Canon and every user suspicious of holding some secret photos.
I don't think so. In fact I believe that the use of crypto does not imply wrongdoing at all. That's one aspect of what plausible deniability is about. One could even hand out one or two "safe" keys and still there would be no way for someone apart from the user to know if there were any more pictures inside the encrypted area.

But I didn't post the link because I wanted to imply my support for implementing a specific form of encryption or plausible deniability scheme. I just felt that quite a few ideas were raised here that have been discussed before and that rubberhose is a good starting point to consider the pros and cons of all the options.

Also, a good thing about Magic Lantern's module system is that developers can decide if they want to implement something, just as users can decide if they want to use or even install a particular model or not :)
neoluxx.de
EOS 5D Mark II | EOS 600D | EF 24-70mm f/2.8 | Tascam DR-40

1%

What about moving the CR2 into some encrypted loop file system in the ML directories. They wouldn't be able to tell an ML font file or a canon CTG file from this and you can't tell that there are photos on the card.

If someone already knows about ML encryption then none of these techniques would really save you as they would be able to look up and/or test it themselves. Would work for those who don't tho.

g3gg0

Quote from: 1% on January 15, 2014, 10:40:26 PM
If someone already knows about ML encryption then none of these techniques would really save you as they would be able to look up and/or test it themselves. Would work for those who don't tho.

i bet a few bucks that the common [insert any country] police officer does not know anything about MLs encryption and hiding feature :)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

wolf

Quote from: Michael Zöller on January 15, 2014, 09:58:13 PM
I don't think so. In fact I believe that the use of crypto does not imply wrongdoing at all.
Same here.
So why hiding the crypted files then?

g3gg0

Quote from: wolf on January 15, 2014, 10:58:39 PM
Same here.
So why hiding the crypted files then?

this

Quote from: g3gg0 on January 15, 2014, 12:24:04 AM
scenario 2:
he is forced to show the images on his camera.
when viewing the shots, the camera ask for a password (using IME interface) or just displays "Image could not get displayed".
not a good idea. in the worst case he is getting tortured until he gives out the password or "fixes" the issue.

i bet when you get a gun pointed right onto your head, you will give out the key.
well, this is a drastic example. but there are coutries where you have to be afraid of some kind of punishment.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

wolf

Quote from: g3gg0 on January 15, 2014, 11:03:00 PM
i bet when you get a gun pointed right onto your head, you will give out the key.
well, this is a drastic example. but there are coutries where you have to be afraid of some kind of punishment.

And what if is known that ML can hide images...

Michael Zöller

I'll try to explain. I'm by no means an expert on these things though, but the basic idea is this:

A user would activate the crypto module and it creates, say, a 1GB file right away. Then the user could create an arbitrary amount of "partitions" in the file. It could be only one, or it could be many. It could even be none at all. There is no way to say how many there are except if you know the password(s). Now, even in case someone knows what the crypto module is and exactly what it does (by looking at the magic lantern source code), there is no way to *know*. Not the amount of partitions, not the amount of images, not even if there is anything at all in there.

So for most situations in most civilized states it is quite a comfortable position for a journalist. On the other hand this concept has been criticized for exactly that property because, one could find oneself in the very bad situation of not ever being able to prove that one has given all the passwords. But if one seriously has to consider those kinds of scenarios... well then there are only bad choices and trusting in a hobby project is probably not thing one should do... :)
neoluxx.de
EOS 5D Mark II | EOS 600D | EF 24-70mm f/2.8 | Tascam DR-40

g3gg0

Quote from: wolf on January 15, 2014, 11:19:39 PM
And what if is known that ML can hide images...

this ;)

Quote from: g3gg0 on January 15, 2014, 10:55:07 PM
i bet a few bucks that the common [insert any country] police officer does not know anything about MLs encryption and hiding feature :)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Se7eN

Quote from: g3gg0 on January 15, 2014, 11:03:00 PM
this

i bet when you get a gun pointed right onto your head, you will give out the key.
well, this is a drastic example. but there are coutries where you have to be afraid of some kind of punishment.

if you ever find yourself with images on your card that someone is willing to shoot you over, it's then somewhat likely that if they see the photos they'll still shoot you, or perhaps just imprison you forever.

1%

Yea its not likely they would know. If you're up against serious people maybe. NSA/MI5/FBI might know but Thuggee McThug in Egypt won't know and neither would random policeman.

Password prompts, large numbers of unreadable files and suspiciously similar preview images might arouse suspicion from less tech savy tho. All in all its a good idea in general.

g3gg0

ok the first EXPERIMENTAL version is here
beware that this will destroy any footage you shoot and could even kill your camera etc.
business as usual.... dont cry :)

supported models:
- 600D [not tested]
- 7D [tested]
- 5D3 [CR2 tested]

how it works:
- enable modules ime_base, ime_rot, trace and io_crypt
- on startup you get an IME dialog that asks for your password
- enter it using the wheel/SET and press Q to jump to OK and press SET
- any file created (JPG, CR2, MOV) will get encrypted (BUT MOV PLAYBACK WILL CRASH!!)
- any of these files being read, will get decrypted using your password

hints:
- if the password doesnt match, you get an error message that the image could not be shown
- if decoding was successful, a few files usually get cached - even changing the pass will still show you a decoded image
- you can set another password from the debug menu -> "Enter crypt password"
- image reading/writing will be noticeable slower
- currently uploading a youtube video



currently there is no PC-decrypter, its just an in-camera experiment, so dont complain please.
also the encryption method is not final and will change, so you can not decrypt these images some time later...
so only use it for tests!
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Michael Zöller

neoluxx.de
EOS 5D Mark II | EOS 600D | EF 24-70mm f/2.8 | Tascam DR-40

Se7eN

Quote from: g3gg0 on January 16, 2014, 02:04:48 AM
ok the first EXPERIMENTAL version is here
beware that this will destroy any footage you shoot and could even kill your camera etc.
business as usual.... dont cry :)

supported models:
- 600D [not tested]
- 7D [not tested]
- 5D3 [CR2 tested]

how it works:
- enable modules ime_base, ime_rot, trace and io_crypt
- on startup you get an IME dialog that asks for your password
- enter it using the wheel/SET and press Q to jump to OK and press SET
- any file created (JPG, CR2, MOV) will get encrypted (BUT MOV PLAYBACK WILL CRASH!!)
- any of these files being read, will get decrypted using your password

hints:
- if the password doesnt match, you get an error message that the image could not be shown
- if decoding was successful, a few files usually get cached - even changing the pass will still show you a decoded image
- you can set another password from the debug menu -> "Enter crypt password"
- image reading/writing will be noticeable slower
- currently uploading a youtube video



currently there is no PC-decrypter, its just an in-camera experiment, so dont complain please.
also the encryption method is not final and will change, so you can not decrypt these images some time later...
so only use it for tests!

This is amazing! thanks for all your hard work g3gg0!

-Se7eN

Alex135

While I am not an active participant on the forums most of the time, I am a regular reader and follower of the development of ML and use ML regularly. (Almost religiously ;-) )
G3gg0, you have done an outstanding job on this. I have not tested it myself but from the video it already shows a lot of practical application uses. I never thought about on-camera encryption and locking out of images, but this is fantastic. A secondary partition or saving the files somewhere in a hidden directory in the ML folder or similar that looks like misc files from the camera's OS would do even better if the card was taken out of the camera to be searched. Sure there would be some large files in weird places, but nobody would be able to open them and likely as not nobody would care. Just a thought on if it is practical or not.

A standard format of encrypted CR2 files or JPEG would be good to have documented in a format other than what is easily recognized by most. I am thinking similar to the ML DNG format that is being implemented for RAW recording.  (Conceptually ofcourse. A documented standard "encrypted.*ML crypt file extension here*" type of file. )

As a photographer/videographer that currently works for an organization that works in restricted access countries I can safely say this would be of huge use to myself. Much easier than using a live linux USB distros to move data onto hidden encrypted hard disk partitions... still would be done but makes on-camera files much safer.

Keep up the good work guys.

g3gg0

thanks :)

but i need testing and feedback.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

blade

This may be a big thing for a lot of people. I myself do some ubex, and hiding some foto's may be usefull.  However this would be a killer option for e.g. journalists etc. I attempted a test, however, as stated it does not work a 650D.

I will keep up to date  on this tread and test a version if it is available for my camera.

eos400D :: eos650D  :: Sigma 18-200 :: Canon 100mm macro

fbaux

EOS 100D.101 (2018-02-27) + Canon EF-S 18-135mm f/4-5.6 IS + Canon EF-S 55-250 f/4.0-5.6 IS II + Eye-fi card

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

1%

On 7D.

Module on, enter password -> can see pics taken, can't see unencrypted pics
module off -> can't see encrypted pics, can see normal ones

Also get an underflow error from the memory back end.

g3gg0

Quote from: 1% on January 19, 2014, 08:23:15 AM
Module on, enter password -> can see pics taken, can't see unencrypted pics
module off -> can't see encrypted pics, can see normal ones

thanks for testing. thats how it works currently.
no autodetection if a file is encrypted or not.
if a file is crypted, it just contains some garbage with a (repeating) 64 bit xor crypt key that changes every 4k.

i am currently experimenting with RSA and plan to generate the key not from a passphrase, but from random numbers.
then i have to save that key into a RSA encrypted block.

this means:
- no password to be entered
- every picture taken is encrypted using a random cipher key (still the symmetric cipher as before, based on 64 bit, 4 tap LFSR and XOR)
- every file has a sidecar file that gets encrypted using the "public" RSA key
- this sidecar file contains the file's symmetric, random cipher key
- to reveal the symmetric cipher key, you have to use the "private" RSA key which should be on your computer at home only

as this means you can not decrypt the file in camera (you cannot review the files anymore) i plan to also add modes that allow you both being used in parallel.
maybe caching the key until camera gets restarted, or a function to save the keys protected with a password if you want to review it later.

mode a) "paranoid": all gets encrypted using RSA+LFSR-XOR in realtime. if you take a shot, you cannot view them in the camera anymore.
mode b) "relaxed": like paranoid, but the decryption keys stay cached until you poweroff the camera
mode c) "normal": all gets encrypted using LFSR-XOR in realtime. you have to enter a password on startup.
mode d) "casual": files are not encrypted. with a menu entry called "encrypt all files", you can encrypt the files


Quote from: 1% on January 19, 2014, 08:23:15 AM
Also get an underflow error from the memory back end.

uhm any idea where it comes from?
whats the message?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Alex135

Quote from: g3gg0 on January 17, 2014, 04:36:07 PM
thanks :)

but i need testing and feedback.

It seems as if nightlies are now being updated again for the 60D so I will test it out after work today and post the results.

g3gg0

it will only work for 600D, 7D and 5D3
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Alex135

Ah ok. Is that due to system specs or just not enough development done yet for the 60D?

g3gg0

i did not dig into the 60D binary yet, where to add the hook poins.
will tonight look into it if its the same and then add the addresses.
(per model we need 3 values. two memory addresses and one size)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Alex135

Quote from: g3gg0 on January 20, 2014, 03:04:52 PM
i did not dig into the 60D binary yet, where to add the hook poins.
will tonight look into it if its the same and then add the addresses.
(per model we need 3 values. two memory addresses and one size)

Ah, alright, that makes sense. I don't know much about the specifics of the ML coding so forgive my ignorance. Either way I will await your update and be sure to test it out once it is up.

One of these days I will find the time to dig around in the ML code.

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

larrycafe

glad to see progress in this thread, I just don't know why I am not getting any positive comment in my previous post. thanks g3gg0, looking forward to see it going to 60D.

rubixcom

This is such a great feature. Can't wait to try it.  ;D

My 2 cents with regards to deniable encryption; storing sensitive/secret images inside least significant bits of raw sensor data part of a CR2 file seems like the best option to me.

So the scenario might be:
1) Photographer fills his card with CR2 images.
2) He/she enables "stealth mode" and provides a password.
3) Any photos taken from that point are shot as JPEGs only but are not actually saved as new files, instead they are stored within least significant bits of sensor data inside existing CR2 files. Which CR2 files are modified could be determined by the encryption algorithm or selected by the photographer. Image data would also have to be encrypted (or at last stripped of common headers/identifiers) before being stored so that the noise would appear random.
4) If the camera or memory card is taken away and inspected, all CR2 images simply appear to contain an amount of random noise as you would expect in a CR2 file.
5) Photographer gets home and copies the files to his PC where he uses a separate application to extract the images.

Since CR2 files are huge, it might even be possible to store a few different low res JPEGs inside to allow the photographer to reveal 1 or 2 sacrificial passwords if the interrogators become suspicious that stenography is used.

Also, if not possible to do this in real time, perhaps a script to hide secret images could be developed and run adhock from the ML menu.

And while on the subject of security; how about another script to fill unused space on the card with random noise so that deleted pictures cannot be extracted later with photo recovery software.

Thanks to all hard working devs,
Alfred

g3gg0

Quote from: rubixcom on January 23, 2014, 08:26:58 AM
My 2 cents with regards to deniable encryption; storing sensitive/secret images inside least significant bits of raw sensor data part of a CR2 file seems like the best option to me.

okay this is then cryptography + steganography.
quite advanced, but anyone is invited to help with the development to make it happen ;)
its not *my* project - its an open source project and i try to give all the chance to help with improving/adding such features.

so anyone - provide me a "uint32_t cr2_inject(char *cr2_filename, char *jpg_name)" and i will embed it ;)

Quote from: rubixcom on January 23, 2014, 08:26:58 AM
And while on the subject of security; how about another script to fill unused space on the card with random noise so that deleted pictures cannot be extracted later with photo recovery software.

already considered that - this is especially important for the mode c) "casual" which alows you to call "encrypt all files now" mode that will run for an hour or so.
in this case all images already were written plain to the memory card and could potentionally be restorable using simple tools. (photorec)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

rubixcom

Quote from: g3gg0 on January 23, 2014, 11:50:35 AM
so anyone - provide me a "uint32_t cr2_inject(char *cr2_filename, char *jpg_name)" and i will embed it ;)

Happy to give it a go :). But, being quite unfamiliar with CR2 file structure, ML source code and having not touched C++ in 13 years, it might take me some time.

I am guessing that to implement this properly, you'd need to:
1) Extract only the Huffman compressed DCT data from the source JPEG. The reason for this is to reduce the chance of anyone brute forcing the password until they detect any common JPEG structures or image sizes within the decrypted data. The obvious downside of stripping these headers would be that image parameters such as image size, colour format and etc would not be stored. The user would have to supply those while extracting the images. Also, a non-easily identifiable method of storing the Huffman tables would also have be devised.
2) Encrypt this data using the password supplied.
3) Extract raw sensor data from target CR2 as a bitmap (I image that there should be code for this at dcraw)
4) Store encrypted data inside the least significant bits of the pixels from the bitmap image decoded from the CR2 raw sensor data. The pixels that are modified would have to be dispersed throughout the image in a random fashion based on a part of the password. If sequential pixels are modified instead, an attacker may notice an increased amount of noise in the certain areas of the image.
5) Re-compress and save the CR2 file (I imagine ML would have some utilities for this) ensuring that the created/last updated timestamps are not updated.

The user must also be forced to give at least a 10 character password otherwise the whole thing is still quite vulnerable to brute force attacks.

This would need to be done properly as people tend to (perhaps foolishly) put a great deal of faith in encryption.

Thanks,
Alfred

g3gg0

i would not use C++ for that.
could be possible with modules, but never tried. ;)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!