Forgot Password
Pentax Camera Forums Home
 

Reply
Show Printable Version Search this Thread
09-04-2014, 12:48 PM   #331
Veteran Member
patarok's Avatar

Join Date: Jul 2013
Posts: 351
I just wanted to say a big "Thank You Shodan!" for the Wiki!!!

09-06-2014, 05:02 PM   #332
New Member




Join Date: Aug 2014
Posts: 9
Is this still being actively developed? I'm a coder and I'd like to contribute, but I cannot afford to accidentally brick my K30. I see that you've made some progress in loading binaries, but I'm still concerned about the safety of the progress. Is there any ETA on a "developer friendly" release? I can deal with crashes and bugs, but I'd like to be confident that my camera won't spontaneously brick (i.e. being able to revert to the stock firmware).

I see that the git hasn't been updated in a month, so I'm curious if it's still being worked on.
09-08-2014, 03:50 AM   #333
Senior Member




Join Date: Jun 2014
Posts: 147
I asked that same question a while ago. Shodan commits only ready stuff. [1]

I don't have K30 but I think you are able to execute scripts from SD card. If I had, I would be making memory dumps and reverse engineering the firmware all my spare time.

So the brickin stage is only when you are updating modified firmware.

[1] https://www.pentaxforums.com/forums/6-pentax-dslr-discussion/250555-resurrect...ml#post2853985
09-08-2014, 09:45 AM - 3 Likes   #334
Forum Member
Shodan's Avatar

Join Date: Feb 2014
Posts: 92
Original Poster
I've never bricked my camera and I do a tons of really stupid stuff to it. The current release is the developer friendly version. I run it on both my devices and have never had issues with normal operation.

Is it possible to brick it, potentially yes!

I spend about 3 hours a week RE'ing the firmware and although it looks like nothing is happening it's because i'm trying really hard to only release stuff that is well documented.
I'm after comprehensive understanding of how the whole thing fits together that way making other models compatible should be quite easy.

09-21-2014, 01:07 PM   #335
New Member




Join Date: Sep 2014
Posts: 7
Just by staring at the xor.key it looks like some 0x80 bytes buffer at the beginning coming from "somewhere". Then every 0x80 bytes you just substract 0x80 from each 32bit int in the whole block to get the next block for the next part of the fw. this seems to at least work at the beginning.
Can you give me the location of the firmware decryption function? I'm curious how the whole thing works in detail :-)
09-22-2014, 05:15 AM   #336
Forum Member
Shodan's Avatar

Join Date: Feb 2014
Posts: 92
Original Poster
On the K30 1.05 binary you can find it at 0xA01A0C38, i've decompiled it for you although this isn't guaranteed to be correct.
I've also attached a bit of C/ASM which if run on a little endian ARM machine (such as my raspberry pi) will decrypt the image.

Take a look at it, shouldn't be too hard to produce a nice algorithm.
Attached Files
File Type: txt decompilation.txt (2.2 KB, 90 views)
File Type: txt code.txt (5.3 KB, 89 views)
File Type: txt main.txt (1.7 KB, 84 views)
09-22-2014, 11:36 AM   #337
New Member




Join Date: Sep 2014
Posts: 7
QuoteOriginally posted by Shodan Quote
On the K30 1.05 binary you can find it at 0xA01A0C38, i've decompiled it for you although this isn't guaranteed to be correct.
I've also attached a bit of C/ASM which if run on a little endian ARM machine (such as my raspberry pi) will decrypt the image.

Take a look at it, shouldn't be too hard to produce a nice algorithm.

Awesome, thanks! I'm not a big fan on the Hex-Rays ARM decompiler, it gets so much stuff only semi-correct and makes me spend more time when it comes to actually reversing some function. It's an awesome tool to get a general overview though, and the x86 version is just lovely. (Possibly because I hate x86 assembly with a passion.)

Anyway, here's my tool which should correctly deobfuscate the whole FW without needing any static keyfiles. I'm a little bit sad I didn't figure this out by just staring at the 0x80 block though. It's such a simple algorithm.

#9585320 - Pastie

I'm rather sure all other cameras use the same one but just have a slightly different file format. The suspicious IV is present in firmware updates for my K-5 as well just at the very beginning and I can just decrypt the whole file as well by ignoring that 0xf00 crap.

I think those first 0xf00 bytes seem to do some kind of setup stuff that's only required since they moved to ARM? Maybe the ARM directly goes booting from there whereas the old FR maybe had some different ROM and booted from a later offset? What a pity that I only have this k-5, this was just starting to get fun
09-22-2014, 06:45 PM   #338
Pentaxian




Join Date: Jun 2009
Location: GMT +10
Photos: Albums
Posts: 10,720
QuoteOriginally posted by svenpeter Quote
What a pity that I only have this k-5, this was just starting to get fun
FWIW, the pktriggercord (a Pentax tethering app) source code may reveal some useful information about K-5 and other Pentax model interfaces. K-3 still seems to be a problem for them though.

09-23-2014, 07:30 AM   #339
Veteran Member




Join Date: Feb 2009
Photos: Albums
Posts: 455
srry to butt in but
i have a pentax experimental camera with no labelling as to which model it is, Its firmware reads as PENTAX K-M, VER: 0.10 (Not 1.0), on opening the the camera i found it to be having a K-x mainboard ( i think i have a pentax K-x with K-m firmware, ) , it does not take either of these modset: Km : MODSET.464, Kx: MODSET.492.
I see that version check reading can be changed, update reads version check to permit an update, can someone help me how to make the version read as PENTAX K-X, VER: 1.00 or
how do i take pentax k-x firmware and make it read PENTAX K-M, VER: 0.10
i have IDA pro free but cant understand how to use it.
if i create a .cue will i be able to read the firmware which is a bin file.

thanks in advance


Read more at: https://www.pentaxforums.com/forums/6-pentax-dslr-discussion/67897-pentax-fir...#ixzz3E9IIwY8s

---------- Post added 09-23-2014 at 08:16 PM ----------

QuoteOriginally posted by RayeR Quote
It doesn't matter, you can easily upgrade or downgrade to any available version. I bought K-30 with 1.04, then updated to 1.05 and 1.06 and back to hacked 1.05. BTW user lens FF/BF settings seems to be preserved during updates, no need to set it again...
pls let me know how did u do this
09-23-2014, 12:31 PM - 2 Likes   #340
New Member




Join Date: Sep 2014
Posts: 7
This is too much fun to give up just because I have the wrong camera :-)

I've fixed up the deobfuscator and added support for the k-5 firmware: https://github.com/svenpeter42/pfwtool
And here's my notes from my train ride:

The FW starts at offset 0x0 and does the usual magic early hw init pokes, I'm rather sure both icache and dcache and the MMU are off at this point.
At a000_08a0 it calls functions from a table located at a000_0930 with (r0, r1, r2, function ptr).
The very first entry copies the reset vectors from a000_0a20 to offset zero, then it copies some helper function i think from a000_0d6c to 0100_0000. The reset vector is a000_0000 fwiw. The reset vector, prefetch abort, etc. all line up nicely with what you'd expect from such a CPU.

I think this is done to overwrite the old reset vectors that are still in memory from the boot ROM (let's call that one boot0), which has to exist. (How else would it start running code from a000_0000 but later use reset vectors at 0? It's possible that boot0 is still mapped at this point and one of the magic STRs at the beginning disable it.)

My first step on projects like this usually is to look for a recovery mode and if that doesn't exist write one myself so that I only brick some HW when I do something stupid in that really small recovery code.
I've seen no evidence of any kind of recovery in the updatable part of the FW - This is to be expected though: if there is a recovery mode it'll be in boot0.
If boot0 cannot be dumped and/or doesn't have recovery functions we could still replace the FW itself given that a000_0000 is RAM and my gut feeling tells me that it indeed is RAM.
Another advantage is that we do not need code running the background if we can boot the FW from the SD slot instead (threading on embedded systems is usually messed up and just works by pure chance so you don't wanna touch that.) We also don't know what kind of storage is used for the FW, do we? It could be some kind of memory that's only rated for a few hundred overwrite cycles which we'll easily hit.

@Shodan: Have you seen any evidence in memory dumps of some ARM code still just sitting around? Maybe we're lucky and boot0 is still mapped somewhere. I'd otherwise like to do a memory dump at the very early beginning of the FW which sadly is just a little bit risky ;-)
Do you hang out on some IRC network? Taling over forums is so annoying...

Does anyone have any of the ARM-based Pentax cameras with some damage in the mechanical parts? (Broken shutter, etc.) I'd love to take one apart and hunt for JTAG and/or a UART port. Makes debugging so much easier and I could go and hunt boot0 with early memory dumps.


edit:
Interestingly, the K-3 appears to use the ARM processor in little endian mode. Haven't made a lot of progress on the fw otherwise, but it looks like the update routines all happen very early after bootup and are seperate from the "real" OS which could be abused as a very very limited recovery mode for first experiments. Still not sure if the stuff at a000_0000 actually is RAM or some kind of flash or something?

The K-5 update code smells like some NOR flashing code which means there's no easy possibility of loading a different FW from SD card there but the newer ARM models might've changed that.

Last edited by svenpeter; 09-26-2014 at 01:46 PM.
09-28-2014, 03:36 PM   #341
Forum Member
Shodan's Avatar

Join Date: Feb 2014
Posts: 92
Original Poster
QuoteQuote:
Awesome, thanks! I'm not a big fan on the Hex-Rays ARM decompiler, it gets so much stuff only semi-correct and makes me spend more time when it comes to actually reversing some function. It's an awesome tool to get a general overview though, and the x86 version is just lovely. (Possibly because I hate x86 assembly with a passion.)
Agreed but when you have a 10meg binary it helps a lot.

QuoteQuote:
Anyway, here's my tool which should correctly deobfuscate the whole FW without needing any static keyfiles. I'm a little bit sad I didn't figure this out by just staring at the 0x80 block though. It's such a simple algorithm.
Nice! Save a 10meg key file.

QuoteQuote:
I'm rather sure all other cameras use the same one but just have a slightly different file format. The suspicious IV is present in firmware updates for my K-5 as well just at the very beginning and I can just decrypt the whole file as well by ignoring that 0xf00 crap.

I think those first 0xf00 bytes seem to do some kind of setup stuff that's only required since they moved to ARM? Maybe the ARM directly goes booting from there whereas the old FR maybe had some different ROM and booted from a later offset? What a pity that I only have this k-5, this was just starting to get fun
Agreed, the original decryption tool worked in a very similar way (although broken on the K30). I think the IV was taken out of the first 0xf00 of the binary.
The first 0xf00 isn't flashed, or at least I can't find it on the RAM dump I have. The firmware is pretty much identical from 0xf00. The first 0xf00 in the RAM dump I have contains the start up routines.

QuoteQuote:
My first step on projects like this usually is to look for a recovery mode and if that doesn't exist write one myself so that I only brick some HW when I do something stupid in that really small recovery code.
Haven't found it on the K30, that's my I wrote my loaded which shoves code into RAM and executes it.

QuoteQuote:
If boot0 cannot be dumped and/or doesn't have recovery functions we could still replace the FW itself given that a000_0000 is RAM and my gut feeling tells me that it indeed is RAM.
It is, check the ARM spec 0xA0000000 is main RAM. I've jumped about 150 meg of it so far on the K30 - there's tons more.

QuoteQuote:
@Shodan: Have you seen any evidence in memory dumps of some ARM code still just sitting around? Maybe we're lucky and boot0 is still mapped somewhere. I'd otherwise like to do a memory dump at the very early beginning of the FW which sadly is just a little bit risky ;-)
No. My RE is now on memory dumps which look a lot like the FW image but with the first 0xf00 different. There are three distinct code blobs, DSP, GUI and debug. I've tried a dump of 10kb at 0x0 and the device crashed. According to the specs the reset vector should be there, maybe I should start dumping a lot less.

QuoteQuote:
Does anyone have any of the ARM-based Pentax cameras with some damage in the mechanical parts? (Broken shutter, etc.) I'd love to take one apart and hunt for JTAG and/or a UART port. Makes debugging so much easier and I could go and hunt boot0 with early memory dumps.
I had a lead on one but the forum user who had it has gone cold. Desperately want to JTAG!

QuoteQuote:
Do you hang out on some IRC network? Taling over forums is so annoying...
Yep I do. PM me we should probably talk. I could give you an IDC export of my DB, might speed things along a bit for you.

---------- Post added 09-28-14 at 11:37 PM ----------

Also anyone in Kuala Lumpur third week of October. I'll be talking about hacking the K30.
09-28-2014, 07:44 PM   #342
Veteran Member
mtux's Avatar

Join Date: Apr 2013
Location: Kuala Lumpur, Malaysia
Photos: Gallery | Albums
Posts: 2,388
QuoteOriginally posted by Shodan Quote
Also anyone in Kuala Lumpur third week of October. I'll be talking about hacking the K30.
Where?
09-28-2014, 11:43 PM   #343
Pentaxian




Join Date: Jan 2012
Location: Slovenia
Photos: Gallery
Posts: 2,164
ICSIPA?
Are these things streamed or at least recorded?
09-29-2014, 12:42 AM   #344
New Member




Join Date: Sep 2014
Posts: 7
I think there's a debug-over-usb mode hidden inside at least my K-5's firmware. By sending some custom SCSI commands you seem to be able to do *lot* of stuff lke e.g. reading from and writing to memory!
That would make for some nice on-the-fly patching with minimal brick risk if this is present in the K-30 fw as well. I"ll go hunt that this weekend!

@Shodan: Sent you a PM.

//edit:
If you want to have the (mostly boring) vectors run the following idapython script after you create a segmet from 0 to 0x400 or so:
for ea in range(0x34c):
PatchByte(ea, Byte(ea + 0xa0000a20))

Last edited by svenpeter; 09-29-2014 at 08:25 AM.
10-10-2014, 01:24 PM   #345
New Member




Join Date: Oct 2013
Posts: 24
I haven't read the whole thread, but are there any chances that some of you can achieve some video improvements on the K-3 like changing the codec or upping the bitrate?
Reply

Bookmarks
  • Submit Thread to Facebook Facebook
  • Submit Thread to Twitter Twitter
  • Submit Thread to Digg Digg
Tags - Make this thread easier to find by adding keywords to it!
bit, camera, card, chdk, code, data, debug, dslr, file, firmware, flash, fp, gps, instruction, k-30, k-50, k30, love, magic, module, notes, pentax, photography, pin, pins, sd, text
Thread Tools Search this Thread
Search this Thread:

Advanced Search


Similar Threads
Thread Thread Starter Forum Replies Last Post
NY area SDM Hacking dappercorpmonkey Troubleshooting and Beginner Help 11 07-26-2013 04:15 PM
Nature Resurrecting some old images - Angry Birds! Julie Post Your Photos! 4 03-07-2013 10:41 AM
k-5 firmware hacking anyone? secateurs Pentax K-5 33 10-05-2012 03:05 PM
Hacking lens' memory plis Visitors' Center 6 11-28-2011 10:58 PM
Resurrecting a MX and Super ME LiMPiNg Pentax Film SLR Discussion 4 09-27-2011 02:55 PM



All times are GMT -7. The time now is 09:46 AM. | See also: NikonForums.com, CanonForums.com part of our network of photo forums!
  • Red (Default)
  • Green
  • Gray
  • Dark
  • Dark Yellow
  • Dark Blue
  • Old Red
  • Old Green
  • Old Gray
  • Dial-Up Style
Hello! It's great to see you back on the forum! Have you considered joining the community?
register
Creating a FREE ACCOUNT takes under a minute, removes ads, and lets you post! [Dismiss]
Top