io_crypt - encrypt your photos while you shoot them

[1%]

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

[Marsu42]

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%]

Try the older module and see what it does.

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

[g3gg0]

fixed that crashing issues finally
you can download the module in the main post.

[Marsu42]

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.

[g3gg0]

the most annoying thing is that canon relies on priority inversion, which is.. quite... "impressing"
i hope they documented that internally at least

[Marsu42]

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?

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

[g3gg0]

Then 650D must be wrong/still not decrypting.

Code: [Select]

    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?

[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?

[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%]

I added a log to that commit and uploaded the rom to upload.g3gg0.de

[g3gg0]

that looks totally fucked up. whats wrong there?
recursively opening files until file descritors run out?!

[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]

can you locally roll back and try?

[1%]

I will try that now and make another log.

[1%]

Here is another:

http://paste2.org/cksdZGU6

[g3gg0]

that was encrypting. looks sane.
how about decrypting in camera using playback?

[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: 

Code: [Select]

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

[stoopkid]

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