|
Forum: Pentax DSLR Discussion
08-18-2009, 03:01 AM
|
| |
Sorry, I'm somehow busy with other things right now and can't get into full-blown reversing mode.
One of the problems with the variables (both local and global) is that the opcode/operand type (ld/lduh/ldub) does not set the data size.
The current frame pattern is not handled properly:
st rp, @-r15
enter #0xC
stm1 (r8, r9, r10, r11)
addsp #0xF8
There is no logic in the module to handle the addsp. The compiler used for the K100D did not use addsp to adjust stack frames on enter like this.
But there are other problems too. And arguments passed via the stack are not handled at all.
|
|
Forum: Pentax DSLR Discussion
08-16-2009, 01:19 AM
|
| |
"Approximate" is the key word here. Don't know about the SDM lenses, but distance info returned from screw drive lenses is too inaccurate for use in open loop AF control, and that's the main reason for lack of real tracking servo AF and hyperfocal/DOF modes in Pentax cameras.
|
|
Forum: Pentax DSLR Discussion
08-15-2009, 01:15 PM
|
| |
That one was pretty obvious - a lot of printf() type calls with things like "MODSET.%d" near the reference. But there are few more interesting header fields.
I still wonder what the best way to compare notes is. Email/forum/blog/wiki?
|
|
Forum: Pentax DSLR Discussion
08-15-2009, 12:06 PM
|
| |
It seems that the file extension is stored in the firmware update file as 4-byte word at offset 0x10
The same (2-byte) value repeated twice is used as block terminator together with the A5 5A 5A A5 sequence - in the case of k2000 '01 e2 01 e2 a5 5a 5a a5' is found at:
Code:
000001f8 - end of header?
000ffff0
00fffff0 - end of DSP firmware
01000070 - end of CPU firmware header?
01037ff8
0103fbf0 |
|
Forum: Pentax DSLR Discussion
08-14-2009, 01:00 PM
|
| |
That was stated clearly in the K100D firmware but the string was removed in later models:
strings FWDC156B.BIN | grep -i fuji
6Softune REALOS/FR is Realtime OS for FR Family, based on micro-ITRON COPYRIGHT(C) FUJITSU LIMITED 1994-1999
BTW at first glance it seems that GX 20 v1.03 uses a lot more int 0x40 calls than 1.01 but that may be only subjective impression.
|
|
Forum: Pentax DSLR Discussion
08-14-2009, 01:09 AM
|
| |
| |
|
Forum: Pentax DSLR Discussion
08-13-2009, 04:24 PM
|
| |
That's exactly one of the forbidden post-delayed instructions, so you shound not really do that:
Instructions Prohibited in Delay Slots
The following instructions may not be used in delayed branching processing by the FR family CPU.
• LDI:32 #i32,Ri LDI:20 #i20,Ri
But we are getting into architectures here which was not the purpose of the post. The manual explains it pretty well with pipeline state diagrams and everything.
That was on purpose. The code would look like that if written by human and not by compiler. Instructions refer to different registers and the LD does not affect the flag register, so order does not really matter, but it's more logical this way.
|
|
Forum: Pentax DSLR Discussion
08-13-2009, 01:42 PM
|
| |
Ouch. You're right. That's why it did not make sense assigning the same sub for syscall and unhandled interrupts.
BTW 97D is undefined opcode in CM71-00101-4E so it's some later CPU in gx20
|
|
Forum: Pentax DSLR Discussion
08-13-2009, 01:33 PM
|
| |
Delayed branch/jump just means that the instruction following the call:D is executed before the jump for better pipeline utilization, and that's heavily used by the compiler reordering optimiser.
Code:
Trivial example:
ROM:105617C2 ldi:32 #sub_105D4E64, r12
ROM:105617C8 call:D @r12
ROM:105617CA ld @r8, r4
Effective order of execution:
ldi:32 #sub_105D4E64, r12
ld @r8, r4
call @r12
Not so trivial example with conditional jump:
ROM:10561822 cmp #1, r0
ROM:10561824 beq:D loc_1056182A
ROM:10561826 ldi:8 #1, r2
Effective order of execution:
ldi:8 #1, r2
cmp #1, r0
beq loc_1056182A
It's easy to miss the ldi:8 here.
Delayed instructions are subject to some restrictions that don't break the
pipeline - something like register-register and short immediate-register ops only.
It does not make sense writing
call:D @r12
ldi:32 #sub_105D51CA, r12
because the CPU has to fetch the 32-bit value and stall the pipeline anyway. Hope that it makes some sense ;)
|
|
Forum: Pentax DSLR Discussion
08-13-2009, 12:24 PM
|
| |
Quite possible. I was thinking about 256-enty interrupt table at 10003C00
That would make int 64 at 10003D00, but I'm not up to speed yet, so correct me if I'm wrong.
Not a problem. Just takes some time to notice the :D and its side effects at first. Sometimes a piece of code makes no sense at all until you see the :D and the following instruction. Hopefully ld cannot follow the corresponding @r call, so it does not confuse the analysis ;)
|
|
Forum: Pentax DSLR Discussion
08-13-2009, 11:25 AM
|
| |
The default handler (same as all unused IRQs?) seems like a debugging hook. It basically calls @r12 that it gets as argument, but performs some conditional action besides. And finishes with infinite loop instead of ret/reti. weird.
even call:D @r0 to make things more confusing with delayed instructions. It takes some time to get used to those RISC quirks like delayed branches.
|
|
Forum: Pentax DSLR Discussion
08-13-2009, 06:24 AM
|
| |
Took a look at K20D/GX20 firmware v1.03 today.
Two interesting observations comparing to K10/K100:
1. A lot of function calls are done like this:
ROM:10641EEC ldi:32 #sub_1004C81C, r12
ROM:10641EF2 extsh r4
ROM:10641EF4 int #0x40
with or without instructions between the ldi and int. This breaks the analysis and has to be implemented in the disassembler. That requires proper register tracking as the current approach works only on consecutive ld/jmp instructions.
According to the manual:
Vector numbers 9 to 13, 64 and 65 are used by emulators for debugging interrupts and therefore the corresponding numbers "INT#9" to "#13", "#64", "#65" should not be used in user programs.
2. There is new command in modset.txt - CRE_RECOVERY_FW that seems to "Create recovery firmware". Has anyone tried that?
|
|
Forum: Pentax DSLR Discussion
08-12-2009, 05:14 AM
|
| |
The flash is definitely parallel so not easy to reprogram. You have to rely on the boot loader (CPU firmware) for recovery if something goes wrong. The EEPROM is in fact area within the same flash chip - you can see the shutter counter increasing in different ROM dumps.
|
|
Forum: Pentax DSLR Discussion
08-12-2009, 04:48 AM
|
| |
Just tried it on the K10D. Save DSP firmware dump via modset.txt, rename it to kb421.bin and put the card back in the camera. Amazingly it says DETECTED DSP F/W FILE ... UPDATING even before switching the power on, but then red FIRMWARE DATA ERROR appears. If the file is named kb421b.bin it's determined to be BOTH F/W FILE and kb421c.bin is CPU F/W FILE. Something like that worked on the K100D so there has to be a way.
|
|
Forum: Pentax DSLR Discussion
08-12-2009, 04:08 AM
|
| |
That was 3 years ago and I don't remember all the details, but I think there was some standard checksum like crc32 that you could calculate using HexWorkshop. I also used modified firmware dump (kb393dsp.bin) instead of normal firmware file. The boot loader/flasher is simple self-contained piece of code, and relatively easy to reverse. I'll take a look at the annotated IDB files now and see if the checksum routine is commented somewhere.
Edit: Or maybe the loading of kb393dsp.bin bypassed the checksum. I started with something safe and simple like replacing one letter in a menu item. Will have to try again.
|
|
Forum: Pentax DSLR Discussion
08-12-2009, 03:28 AM
|
| |
Sorry about the stupid question, but did you press the shutter? All STORE* command generated files are relevant to each frame taken - from raw sensor dump to parameter listings.
|
|
Forum: Pentax DSLR Discussion
08-12-2009, 02:56 AM
|
| |
You can do that with raw2tiff and some scripting. From the help:
-H # size of input image file header in bytes (0 by default)
-w # width of input image in pixels
-l # length of input image in lines
-H is same as offset
It wold be better to make the tool aware of bitmap index tables, so you give it bitmap dimensions + table address and length and it extracts all images. Looks like 20 lines of perl to me.
BTW I've in fact tried to modify the K100D firmware to allow some FA functionality with A lenses (auto/selectable focus points) - that was the reason for generating those tif files.
The route I took was finding the AF point menu bitmaps, cross referencing that back to the subroutine that uses them, finding the global variable that holds focus point selection information and then trying to find the subroutines that refer to that and limit the choice depending on lens. Got some partial success after patching 7-8 conditional jumps - the menu items were no longer grayed and you could choose different focus modes with A lens, but the real check was left out and the camera still used only the central point.
The other approach - finding all references to the variable containing lens type was almost impossible. A lot of pointers to static and dynamic structures passed between subroutines, with some things being asynchronous - running in interrupt handlers or separate processes. Maybe very advanced disassembler can help here, but it has to be almost to the level of the x86 module.
|
|
Forum: Pentax DSLR Discussion
08-12-2009, 01:50 AM
|
| |
I was able to extract somehow useful bitmap information using raw2tiff. This command line utility (part of libtiff) lets you set different parameters of the raw data - format, x-resolution and so on. Result looks like this: http://zezo.org/144.png and http://zezo.org/288.png. You need image viewer that can handle 15000/30000 vertical pixel images (firefox works for me). Fonts and bitmaps are identifiable. Same can be done with different x resolutions and different things come to alignment. This is grayscale conversion, so it looks like 8-bit indexed pallete images.
|
|
Forum: Pentax DSLR Discussion
08-12-2009, 01:09 AM
|
| |
You are right about the numbers - they will allow single SD card to be used to service different models, but I was referring to another thing. In firmware files prior to K10D v1.30 file names appear like plain text and are easily identifiable with hex viewer or the 'strings' unix command line utility. That makes it very easy to guess their usage as the contained commands are near the file names so you don't even need to disassemble the file, just have to guess the syntax (well, finding the parser in the asm file and noticing that it searches for [ and ] helps the process ;).
strings FWDC162B.BIN looks like this:
C:\MODSET.TXT
C:\MODSET.TXT
DEBUG_MODE EN
DEBUG_MODE DIS
CFDOOR_OPEN EN
CFDOOR_OPEN DIS
...
and in the corresponding 1.30 section file names are 'encrypted':
fylgvmlk|nvdlg|)z~vmlk|nvdlg| lg)z~vmlk|nvdlg| m`z)elgzvjy|vo`{d|y)
DEBUG_MODE EN
DEBUG_MODE DIS
CFDOOR_OPEN EN
CFDOOR_OPEN DIS
...
But in the end the garbage in the first line still decodes to 'C:\MODSET.TXT'
|
|
Forum: Pentax DSLR Discussion
08-11-2009, 12:37 PM
|
| |
This works on *istDS, K100D and K10D. You either need the proper file extension or the command/syntax are different. I'll take a look tomorrow.
Definitely from the debug menu. I just finished reading the entire thread and was going to comment on that too.
|
|
Forum: Pentax DSLR Discussion
08-11-2009, 12:14 PM
|
| |
Thanks ;)
I forgot to introduce myself, so here it goes:
I've spent some time reversing pentax firmware few years ago - starting with optio 33 wr (Pentax Optio 33WR RAW mode and other secrets). Bought K100D later partially out of curiosity if I can make the debug commands work. They did, and I discovered the famous menu-info-menu-menu-info combo within the first day, but did not publish it at the time.
The only real benefit of this work so far has been the decoding of some EXIF tags and contributing to Phil Harvey's exiftool. So remember me when you see the Temperature and Battery Charge Level tags ;)
Now when we have dedicated project I may be able to contribute some more knowledge - the improved fr disassembler and the sysparam syntax from the posts above should be just the start. I contacted tr13 as soon as fellow pentaxian who was aware of my hobby sent me the link to his site and spent part of the day exchanging emails.
Best regards,
Cvetan
|
|
Forum: Pentax DSLR Discussion
08-11-2009, 08:58 AM
|
| |
Try 'modset.txt' and open card door during startup. That works on K10D v1.30 (and all previous versions). The file names are obfuscated in the firmware, but still decode to modset.txt and sysparam.txt
|
