[Class A]

From my naive thinking, shouldn't encryption be built into the firmware boot loader or firmware updater which cannot be changed?

This makes sense, but it is also conceivable that the loader is part of the firmware and is first copied to a location in volatile memory before being executed from there. This would allow replacing the loader with firmware updates.

[falconeye]

This makes sense, but it is also conceivable that the loader is part of the firmware and is first copied to a location in volatile memory before being executed from there. This would allow replacing the loader with firmware updates.

Yes, but then the decrypter itself would have been decrypted as well And so are all future decryption keys.

Except ... wait a minute ... wasn't there this small chunk still awating decryption by tr13?

[tr13]

From my naive thinking, shouldn't encryption be built into the firmware boot loader or firmware updater which cannot be changed?

I already mentioned that most current firmwares are written in wrong way.
This means that part of firmware stays in RAM while ALL image is copied to flash chip.
It is very easy to change encryption. I don't want to advice Pentax, but it is not hard.

[tr13]

UPDATE.

I added new decryptor to my site.
Now it decrypts all sections of firmware for all known models (K20D/GX20/K7/K-m).
As is able to encrypt all back.

Interesting thing is that I don't see menu strings inside K7 firmware :-)

[Class A]

Interesting thing is that I don't see menu strings inside K7 firmware :-)

Unicode?
"more text"

[tr13]

Unicode?
"more text"

English two byte Unicode is perfectly visible.
I also don't see menu strings inside Km firmware (they look similar and are larger then GX20/K20D firmware).
Debug and other strings are ok, but no menu strings.
One option is that they made them bitmaps :-)

[Nass]

Hello - I'm not a hardcore programmer so can't help, but very interested in this project. Might I say that this is definitely the future - user contributions are the way forwatrd, look at the whole Ipod phenomenon. Small apps that can be bought to enhance your core ipod - imagine if that were possible in digital. Wow.

I tell you what I'd love to be able to do, make filters in photoshop and be able to upload them into my camera as ?PNGs?. For example you could make a heap of perfect ND filters quite easily this way, and store them somewhere for use as & when.

Anyhow I can do websites and php - not sure if that helps in the least but great stuff

[rparmar]

Great project!

Let me give you some reasons I want improved firmware.

1. To allow setting the back wheel in "M" mode to control ISO, so I can have the same controller setup no matter what lens I use. This is my number one beef.

2. Currently the auto-focus can lock before the Shake Reduction has clicked in. The beep (if engaged) indicates we are ready to shoot, but we are not! We need a custom function that allows beeps only if both AF and SR are locked. Or, that will disallow shutter release until this is the case.

3. To provide a switchable "catch-in-focus" that will work with AF lenses as well as manual focus lenses.

4. To provide an ability to add aperture information manually, so it gets printed in the EXIF to subsequent files. Or, allow this EXIF tag to be edited in camera.

[Das Boot]

I think the first and easiest update to the firmware could be direct access to WB, ISO, Shutter Settings, Color, and Flash Settings. Pretty much everything in the Fn menu, just a simple button combination like Bracket Button + Same Button in Fn menu and instant access. It would be easy for people to use and remember because the buttons would be the same as the Fn menu. Not to do away with the Fn menu, just an addition.

tr13 -
Is it just as easy to encode a new firmware or is there a mystical checksum on top of the encryption used that you know of.

(Update)- Never mind, just went to the website and saw your new post... Good job!

[nanok]

that's a huge first step. very nicely done. i'll be watching this (being the guy who fights class A for the rights to "oss advocate" around here )

i will especially keep an eye out for any requests for specific help from you. good luck!

[ratjadi]

This is absolutely great, congratulations so far!

I am not a hardcore programmer, but I would like to understand what have been done so far? Maybe you could give some resumee of the steps already done. Maybe from this starting point I could do something helpful, some isolated defined task.

I think I understand some basics, but I don't get the thing as a whole.
For example what can be done with this dll?
What does it mean that you have decrypted the firmware? You don't get source code from it, do you?
How could it look like when you change the firmware - codewise? Do you get to some point where you have the whole firmware as sourcecode and then change it, compile it and finally encrypt it? Or do you just bent some interrupts with a hex-editor?

It would be great if you provide some visible, tangible stuff, so that the average programmer can follow.

And good luck, I will follow this project for sure!

[Das Boot]

I think I understand some basics, but I don't get the thing as a whole.
For example what can be done with this dll?
What does it mean that you have decrypted the firmware? You don't get source code from it, do you?
How could it look like when you change the firmware - codewise? Do you get to some point where you have the whole firmware as sourcecode and then change it, compile it and finally encrypt it? Or do you just bent some interrupts with a hex-editor?

It would be great if you provide some visible, tangible stuff, so that the average programmer can follow.

The .dll was a possible tool to get the unencrypted firmware. It is not needed for that purpose now. It still could be useful in reversing the code in the future. As far as source code, this is as basic as it gets. With the memory maps and the start the folks got with K10D along with the white paper on the chipset things are off to a good start. Now the hard nose reverse engineering begins. The code is right here it's all a matter of figuring/sorting it out. There's nothing that says what ports or bits of ports do and/or what they are connected to. It's a matter of using the clues within the code to figuring that out. Telling if a port is a matrix of buttons or a bus can usually be determined by the way they are handled within the code. Telling what button is what can be a little more difficult.

Back to the .dll.... If everything works right, the planets align and a lucky break is given, the dll could be the quickest helper in figuring out a lot of the routines. For instance, while running Remote Assistant and a USB snooper, the communication protocol could be figured out and ultimately the commands sent to the camera to do a particular function. Armed with that knowledge, you could search the firmware for the jump tables corresponding to those commands. From there you can follow the code for each command and document it (shutter activation, WB, ISO... anything you can do in RA). You can also see what part of the code utilizes the jump table and follow it backwards all the way to the parser. A lot of information can be gained from just what little is given us... possibly. That could be the first round of attack on the code. It's going to take a good amount of time to figure out even the basic stuff, but as our knowledge of the code grows it ends up being kind of like a snowball effect and each hurdle/mystery gets smaller and easier to solve. It truly is exciting the kind of attention this is getting and the how far along the project has gotten. It would be funny if in the future that a used K20d would be more sought after for the mods you could do to it as opposed to a new K7 out of the box. It might wake up Hoya/Pentax and release firmware as open source for discontinued products (well maybe not - but maybe make them listen closer to its users). Anyways, enough ranting....

[ytterbium]

It seems that at 0x006D3890 in decrypted K-7's firmware is something like a bitmap data.
I've included simple plot of the data from that address.
Plotted data is 441600 bytes long (at least i plotted it as 8 bit bytes).
Since i have no idea of the dimensions (if it is bitmap at all - could be some look up table aswell) i choose dimensions to be 32*13800 so the gradients can be visible.
Note that this is not a colour image but rainbow colour map to 0..255 byte values. The line pattern hints it could be RGB bitmap with some colours being black (so every third, or forth if its RGBA for transparent menu items byte would be 0x00). But viewing it at different HxV dimensions reveals only ramp patterns.
Where do you expect menu item bitmaps to be located?

Interesting strings:
[Exposure OB]...[Dark OB]...[K Value (X128)]....[DFS Offset]....PB..B...C:\Main.jpg.C:\Sub.jpg..C:\Thumb.jpg....C:\Comp.raw.C:\Debug.txt....C:\Bayer1.raw...C:\Bayer2.raw...C:\Dark.raw.C:\PreBayer.raw.C:\PreDark.raw..C:\DevI%03d.jpg.
At 6CF030.

[kytutr]

Interesting strings:
[Exposure OB]...[Dark OB]...[K Value (X128)]....[DFS Offset]....PB..B...C:\Main.jpg.C:\Sub.jpg..C:\Thumb.jpg....C:\Comp.raw.C:\Debug.txt....C:\Bayer1.raw...C:\Bayer2.raw...C:\Dark.raw.C:\PreBayer.raw.C:\PreDark.raw..C:\DevI%03d.jpg.
At 6CF030.

It looks like entries from REALOS/FR file system. So maybe there's a chance to mount it and see more interesting files.

[tr13]

tr13 -
Is it just as easy to encode a new firmware or is there a mystical checksum on top of the encryption used that you know of.

(Update)- Never mind, just went to the website and saw your new post... Good job!

Yeah, we have checksum, but we also have loader code.
So, we could guess how it is calculated.