encryption - page 2 - Feature Requests - CHDK Forum


  • 15 Replies

Offline hk

  • *
  • 5
Re: encryption
« Reply #10 on: 29 / June / 2009, 05:57:55 »
RaduP wrote:

> AFAIK, you also need a PRIVATE key, not just a public key to do the
> encryption. So the private key must be stored somewhere in plain text,
> either on the SD or in the camera itself (but then you'd need to flash
> some new firmware).

The private key is only necessary to decrypt the picture and this
private key never ever should be stored on any part of the camera.


Offline reyalp

  • ******
  • 14080
Re: encryption
« Reply #11 on: 29 / June / 2009, 17:17:51 »

I have clearly defined what I need:

1. On power up I need to read the content (16 byte) of a file stored on the
   SD card (the encryption key) and replace it by a new one.

2. When a picture is taken, I must be able to access the already jpg compressed
   picture data before it is written to the SD card. I must have write access
   to this data, but (in a first step) it is not necessary to change the size
   of the data.
This is implementation. What you need to do is define what goals your encryption system is supposed to accomplish.

But anyway, AFAIK no one has yet reverse engineered the stuff that deals with the jpeg buffer. Figuring out if and where you can modify that will require reverse engineering. Same goes for modifying the loading and display of jpegs in playback mode.

I haven seen the string "JpegAddress" in a firmware dump. DvlpSeqTask is probably another good place to start looking.
Don't forget what the H stands for.


Offline fudgey

  • *****
  • 1705
  • a570is
Re: encryption
« Reply #12 on: 29 / June / 2009, 18:33:15 »
It's probably a whole lot easier to just disable JPEG output (not implemented yet but I've been told it can be done) and encrypt a DNG instead of finding and encrypting the JPEG... And to forget anything related to review and play mode until that first part works.

Note that a full resolution full quality well exposed high detail JPEG is actually not hugely lot smaller than a DNG (for my camera, it's 5 MB vs 9 MB, less than double the size for this worst case JPEG).

Btw, I wouldn't be one bit surprised if the camera never had a full copy of the JPEG in RAM, and instead encodes (and writes to SD card) in chunks for obvious shooting speed gain... this could make things quite a bit more complicated.

Re: encryption
« Reply #13 on: 09 / July / 2009, 08:39:03 »
just disable JPEG output (not implemented yet but I've been told it can be done)
I've found in primary.bin (ixus70_sd1000 1.02a, start adress 0xFFC00000, disasm IDA 5.2) interesting strings:

RAM:FFE51529 aDevelopprocess DCB "DevelopProcess RAW -> YC.",0
RAM:FFE51545 aDevelopproce_0 DCB "DevelopProcess RAW -> JPG.",0
RAM:FFE51561 aUseJpeg_buffer DCB "Use JPEG_BUFFER_WIDE_ADDR. ",0
RAM:FFE51580 aErrorWaitevent DCB "Error WaitEvent DEVELOP_COMPLETED.",0
RAM:FFE515A5 aDevelopproce_1 DCB "DevelopProcess YC -> JPG.",0
RAM:FFE515C0 aStartdeveloppr DCB "StartDevelopProcess executed.",0

As I understand, function which follows next (FFE515E0), starts encoding process RAW->YC (Is somebody know something about YC?), YC->jpeg and RAW->jpeg. Am I right?


Offline reyalp

  • ******
  • 14080
Re: encryption
« Reply #14 on: 05 / May / 2011, 00:46:07 »
Old thread, but this stuff comes up every now and then and this seems like as good a place as any...
btw: http://www.canon.co.jp/imaging/osk/osk-e3/index.html
it should be possible doing something like this. information about this osk-e3 is very rare in the internet. i wonder why ;)
Not so rare any more http://www.elcomsoft.com/canon.html

via http://www.schneier.com/blog/archives/2011/05/nikon_image_aut.html mentioning that nikons equivalent has also been cracked.

CHDK gets a shoutout in the comments ;)

Don't forget what the H stands for.

Re: encryption
« Reply #15 on: 06 / May / 2011, 13:04:37 »

there is 3 different usages of cryptographic functions in Canon DSLR:

- image authentication : for integrity. to prove a picture is coming from a given camera and has not been modified.
these function are available on all DSLR except 600d / T3i and 1100d / T3.
only image signature is explained by Elcomsoft. http://www.elcomsoft.com/canon.html
this is done mostly in hardware by the "Kayser". Follow CRP_Hash* funtions.
- image encryption : for confidentiality. to avoid someone having access to the image content.
this is only available on 1D* camera with OSK kit.
to my knowledge, nobody understood how does it work.
- Fir / update file protection. AES is for confidentiality. MD5/SHA1/HMAC-SHA1 for signatures / integrity check, as partially explained here: http://magiclantern.wikia.com/wiki/Firmware_file. Magic Lantern people since 7d knows the signature, and since the 550d the encryption scheme. Look for 'cipher.bin' in stratospheric memory ;-) as already cited by 'memset' in this forum.

« Last Edit: 06 / May / 2011, 13:09:07 by lorenzo353 »


Related Topics