Cortex M4 Firmware

[eychei]

Hi everyone,

I am trying to disassemble a Kinetis K10 Firmware update file.
I have the following:

- Processor is a Kinetis K10 MK10DZ (Arm-Cortex M4)
- little endian
- 32 Bit
- no encryption / Strings are visible

Memory map is like this:
FLASH 0x00000000 - 0x0003FFFF

When loading the file into IDA it doesnt make any sense.
I think the update file does have his own structure.
Normally the init vectors should be at 0x0 but this is not true for this firmware update file.

Maybe someone can help me out with this.

-e

[wild]

I'd like to try to help you, but my privileges do not let me download the file... :-(

[eychei]

Here is a link to the file.

https://www.file-upload.net/download-13069610/15.zip.html

-e

[wild]

Please take care that I have never used your processor!
According to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABIFJFG.html (it is the same for all Cortex Mx families) the first two 32bit words of the vector table are:
0x0000: Initial Stack Pointer value: points to a RAM area
0x0004: Reset vector: points to the code you have to start to run.
so, if I take a look at the binary dump of the file you uploaded:

000000 - 10 00 7F 01 00 48 60 00 F4 F1 FF FF 00 00 00 20 
000010 - 99 72 00 00 CD 72 00 00 21 74 00 00 21 74 00 00 
000020 - 21 74 00 00 21 74 00 00 21 74 00 00 21 74 00 00

beacuse the values ar written in little endiand format,
it seems your stack pointer points to 0x017F0010 and
the reset vector (code execution) starts at 0x00604800

It seems that your code is not loaded at the start of the flash, but in some other pages, so in IDA you have to tell that your code has an offset value different from 0.
It can help to take a look at the other vectors in the table to get some ideas in which part of your memory your code is loaded...
Now it is very late (02:30am) so I can't dig deeper.
If required, tomorrow I will check in more details in which memory page of your microcontroller this piece of SW is loaded.
Please let me know.

P.S.: I suggest you to take a look at the memory map of your micro.

[eychei]

Thank you.
I couldnt find the vector table. Now I have it.
I will try the offset you mentioned and come back here.

-e

[eychei]

@wild

I used the reset vector in IDA as follows:

ROM Start address : 0x00604800
Loading address: 0x00604800

I am new to this so bear with me a little.

How do i find out where the reset vector is pointing in my file.
I do get it that I need to now in which memory space this file is loaded and thus can find the offset which is first executed. I am looking further, but would need some assistance.

Just one other question:
Why is my sp value higher than my reset vector address?
The memory map shows that the sp value is in the flash memory
0x0000_0000–0x07FF_FFFF Program flash and read-only data
Where do I see how the flash memory is mapped?

-e

[UniSoft]

Originally Posted by eychei

Maybe someone can help me out with this.

From what I see,
it is not the plain binary file...
You need parse it...

typedef struct
{
    uint16_t addr; // ??? looks like address, maybe offset
    uint16_t length; // how many bytes in data
    uint32_t chksum; // 0xffffffff - sum(of all data bytes)
    uint8_t data[0x60]; 
} chunk_t;

typedef struct
{
    uint32_t unkn; // 
    chunk_t chunks[1]; // array of chunk_t blocks
} yourfile_t

[eychei]

@unisoft

I can not download the file you uploaded. Can you give a mirror?

thx

-e

[UniSoft]

http://i63.tinypic.com/rqw784.png

[eychei]

thanks for the image.

I am still stuck. Attached i am sending the cleaned firmware.
Can you have a look?


-e

[UniSoft]

Originally Posted by eychei

I am still stuck.
Can you have a look?

remove first dword: 10 00 7F 01
run IDA drag and drop bin file on ida window
select Processor type: ARM Little-endian [ARM], click Set, then OK

in next window setup memory map:
RAM
check "Create RAM section"
RAM start address: 0x1fff8000
RAM size: 0x18000
ROM
ROM start address: 0x4800
Loading address: 0x4800
Click OK

After load, click "Alt + G", change flag T to 1 (thumb mode)
now first dword is a stack pointer: in your case 0x20000000
second dword is entry point, go that (address-1) and press C (Code), or P (Procedure)

here is IDA 7.0 idb
https://www.file-upload.net/download-13070917/BinCleanIDB.zip.html

[eychei]

thx UniSoft.
Checking the file right now.
Can i ask why you created a ram section? This is completly empty.
How did you find the rom start address?

-e

[UniSoft]

Originally Posted by eychei

why you created a ram section?

This somewhat helps with reverse engineering.
IDA creates cross-references.
for example jump to: RAM:1FFFE1C8
you will see all references to this variable.

Originally Posted by eychei

How did you find the rom start address?

This is not the ROM start address.
This is the start address of the firmware.
The starting address of the ROM is 0x00000000.
And the first 0x00004800 bytes are very likely occupied by a custom bootloader.

where from I got 0x00004800

typedef struct
{
    uint16_t addr; // <<<<<<<<<<<<< from here
    uint16_t length;
    uint32_t chksum;
    uint8_t data[0x60]; 
} chunk_t;

[wild]

I'm just curious.
I have worked on problem like this only on STM32: the analysis of the ST-Link and J-Link Firmware and the software which make the firmware upgrade (DFU like).
In those software (Segger JlinkARM.DLL, STLinkReflash, ...) the firmware is stored without any info "attached" (the flash starting address and blob size are stored in a different structure), since my error interpreting the eychei's BIN file*.
Questions:
- where did you get the 'chunk_t' info?
- is it the standard way of the (I presume) NXP DFU utility?

*) when I wrote my first answer I had no time to look at the memory map of the K10 processors [eychei: take a look at the map, it directly answers your question] especially because I didn't find any reference to MK10DZ processors!!!

[UniSoft]

Originally Posted by wild

- where did you get the 'chunk_t' info?

nowhere... I make it...
Just look on bin file and see that it was splited in parts...

Originally Posted by wild

- is it the standard way of the (I presume) NXP DFU utility?

Have no idea... never work with NXP