#1
|
|||
|
|||
Cortex M4 Firmware
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 |
#2
|
|||
|
|||
I'd like to try to help you, but my privileges do not let me download the file... :-(
|
The Following User Says Thank You to wild For This Useful Post: | ||
eychei (04-07-2018) |
#3
|
|||
|
|||
Here is a link to the file.
https://www.file-upload.net/download-13069610/15.zip.html -e |
#4
|
|||
|
|||
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: Code:
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 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. |
The Following User Says Thank You to wild For This Useful Post: | ||
eychei (04-07-2018) |
#5
|
|||
|
|||
Thank you.
I couldnt find the vector table. Now I have it. I will try the offset you mentioned and come back here. -e |
#6
|
|||
|
|||
@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 Last edited by eychei; 04-07-2018 at 15:11. |
#7
|
||||
|
||||
From what I see,
it is not the plain binary file... You need parse it... Code:
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 Last edited by UniSoft; 04-07-2018 at 21:17. |
The Following User Says Thank You to UniSoft For This Useful Post: | ||
eychei (04-07-2018) |
#8
|
|||
|
|||
@unisoft
I can not download the file you uploaded. Can you give a mirror? thx -e |
#10
|
|||
|
|||
thanks for the image.
I am still stuck. Attached i am sending the cleaned firmware. Can you have a look? -e |
#11
|
||||
|
||||
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 Last edited by UniSoft; 04-08-2018 at 02:09. |
The Following User Says Thank You to UniSoft For This Useful Post: | ||
eychei (04-08-2018) |
#12
|
|||
|
|||
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 |
#13
|
||||
|
||||
This somewhat helps with reverse engineering.
IDA creates cross-references. for example jump to: RAM:1FFFE1C8 you will see all references to this variable. 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 Code:
typedef struct { uint16_t addr; // <<<<<<<<<<<<< from here uint16_t length; uint32_t chksum; uint8_t data[0x60]; } chunk_t; |
#14
|
|||
|
|||
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!!! |
#15
|
||||
|
||||
nowhere... I make it...
Just look on bin file and see that it was splited in parts... Have no idea... never work with NXP |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Edit firmware .bin | alberto280 | General Discussion | 8 | 08-22-2020 23:06 |