io_crypt - encrypt your photos while you shoot them

Started by g3gg0, February 02, 2014, 12:36:25 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

1%

I think it crashes from many writes so a burst of silent pics might do the same thing but didn't check.

Marsu42

Quote from: 1% on February 15, 2014, 07:23:43 PM
I think it crashes from many writes so a burst of silent pics might do the same thing but didn't check.

In that case, silent pix are *less* likely to crash than quick single normal pics as the lag on shutter lag on silent pics is longer.

1%


g3gg0

this is a module limitation.
if you look at the headers, then you will find #ifdefs for some models.
but from the module view you can only compile for one model.

so i would have to use numbers and check them according to model_name.
quite a lot work for some dirty workaround.
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

fixed that crashing issues finally :)
you can download the module in the main post.
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!

Marsu42

Quote from: g3gg0 on February 15, 2014, 11:33:47 PM
so i would have to use numbers and check them according to model_name.
quite a lot work for some dirty workaround.

I have the same problem, and I think some model-detection framework should go into the core for modules to use so not every author needs to add them again and again - like (model_is_60d() || model_is_6d()) that work like the #ifdef in the core... and can be just replaced when code code is refactored into modules.

As for silent shooting imho it's worth to do a check, photo journalist as one the intended groups for this modules are bound to use it to get inconspicuous that need to be safeguarded by encryption.

g3gg0

i already removed the restrictions.
all problems gone now, so no need to restrict to single image anymore.

about model stuff.
well, i recommend to use the values defined in propvalues.h along with property PROP_CAM_MODEL content.
to be done.
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

the most annoying thing is that canon relies on priority inversion, which is.. quite... "impressing" :)
i hope they documented that internally at least
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!

Marsu42

Quote from: g3gg0 on February 16, 2014, 02:14:21 AM
the most annoying thing is that canon relies on priority inversion, which is.. quite... "impressing" :)
i hope they documented that internally at least

Ugh? Are we simple mod authors supposed to understand what you're talking about :-p?

Feel free to document the priority/thread stuff for the rest of us, for example I don't understand at all when offloading some metering loop in my auto_iso module from the general shoot task to a dedicated thread is a good idea - either for being friendly to the rest of the ml tasks or to increase performance.

g3gg0

http://en.wikipedia.org/wiki/Priority_inversion
explained quite well there.

in this case the shooting threads need memory.
this memory is allocated by a manager which has a lower priority than the shooting threads.
so for the time the shooting threads were executed, the memory manager didnt get time for processing.
this was no problem, as the FIO_Write function waited for a semaphore released by interrupts and thus handed CPU over to other threads.

now i am (well, i was) blocking the shooting threads while they are writing.
blocking with executing real code, not by sleeping or waiting for a semaphore. (sleep also gives away CPU time to the next lower threads)

well, this caused the shooting thread to delay the FIO_Write() call a bit longer, which didnt hurt the task itself.
but i didnt give away cpu time in this call, but i used it to calculate stuff (encrypt).

this lead to the memory manager task, which unfortunately has a lower priority, not being executed fast enough.
some other high priority shooting tasks also didnt give away CPU time and so the memory manager starved.

in the current approach, i just put the encryption into a separate crypt thread, which has a "normal" priority.
so the shooting tasks give away their CPU time by waiting for a semaphore and the memory manager can run.
and all is fine.

funny, eh?
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%

lol, I had to look it up and I was going to post the wiki link :)

g3gg0

i just saw that in some cases the image is non-decryptable when using RSA. (encrypted_size: 0 when decrypting)
but thats no serious bug i guess. maybe just not handling the asynchronous RSA encryption 100% correct.
will check that tomorrow.
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: 1% on February 15, 2014, 12:20:35 AM
Then 650D must be wrong/still not decrypting.


    else if(streq(camera_model_short, "50D"))
    {
        trace_write(iocrypt_trace_ctx, "io_crypt: Detected 50");
        iodev_table = 0x1F208;
        iodev_ctx = 0x49A64;
        iodev_ctx_size = 0x18;
    }


Not sure on the CTX but images are taken and encrypted... just not decrypted.

according to https://bitbucket.org/hudson/magic-lantern/commits/e769afc111947416d7c9e45d72f353a08f01a04b
there must be smth wrong. can you provide me a RAM/ROM dump?
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

650D should have:
        iodev_table = 0x54060;
        iodev_ctx = 0x7C278;
        iodev_ctx_size = 0x20;

and this was already set correctly.
can you check with the latest version and describe what is happening when:
- shooting an image with encryption password
- decrypting on pc
- setting password as before and view image in camera (after reboot)

please do that with trace enabled and upload the traces (two, one for saving, one for playback)

maybe you have a ram dump also?
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!

eos

[650D; P; 16.feb nightly; iocrypt 16.feb 1:27]

The changes in menu are nice.
Series shooting works.

on pc:
cannot open decrypted pw (neither jpg nor cr2)
cannot decrypt rsa (jpg&raw)

1%


g3gg0

that looks totally fucked up. whats wrong there?
recursively opening files until file descritors run out?!
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%

nanomad's fio, file thing. I had to get rid of card_drive in the module.. so maybe there is a bug with that?

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%


1%


g3gg0

that was encrypting. looks sane.
how about decrypting in camera using playback?
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%

Yea, that part seems right. i'll do the log of it decrypting, where its busted.

Hmm.. saying its not decryptable:

http://paste2.org/d1mPw7D3

BTW, I'm trying: 

// iodev_ctx = 0x49A64;
iodev_ctx = 0x49F18;


Look at both in the firmware... I think the 18 is closer, I tried to xref vs 7D but the functions don't quite match. Neither decrypts.

g3gg0

yep, it looks like the direct access to file offset isnt the best choice for all models.
i could again decide for a footer that is written when closing the file.
that would ease up writing and make that sane.
(might be the best choice for making encrypting available on all models)

alternatively i could use a sidecar file, which could make things complicated.
(calling FIO routines from routines at a lower level)

but reading still requires random access.
the FIO_SeekFile calls iodev_SeekFile somewhere, but i dont have the "correct" handle type at this position.
well, for 5D3 i could easily do that, but for 7D its different again and for 650D even more.



well, now as i use different threads anyway, i could really use sidecar files.
but copying IMGxxx.JPG to PC is much easier than copying some sidecar files too, especially when using a reader.
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!

stoopkid

Any chance at getting a build for the 550D? I'd be happy to try testing it.