MicroHacker Forum

Posted: **30 Dec 2019, 22:25**

Go4IT wrote: ↑15 Dec 2019, 10:27 Try this settings https://mk4-wiki.denkdose.de/artikel/ip ... isassemble

Go4it this link is old I think it should be
https://mk4-wiki.denkdose.de/en/artikel ... isassemble

Posted: **31 Dec 2019, 00:17**

Yeah, you're right

Posted: **13 Jan 2020, 17:33**

ida-ipc-flash extended.png

ida-ipc-flash extended2.png

tring to see how the extended flash is structured i understand some just need the Arm commads
ill have a look through the data sheet, but any pointers

Posted: **13 Jan 2020, 18:44**

Sorry bones, you disassembled nonsense, caused from wrong settings. Try this one: https://mk4-wiki.denkdose.de/en/artikel ... to_ida-pro
The first bytes from an MCU (not CPU! That's only a part of an MCU) are most often a vector table, containing jumps on behalf of interrupts to different locations. After loading the image with the right settings, go to address 0x0000 and press "c", as this will disassemble a huge part oft the image. The rest is "hand work" to do, because IDA does not detect calls to those locations.

Posted: **13 Jan 2020, 19:36**

Go4IT wrote: ↑13 Jan 2020, 18:44 Sorry bones, you disassembled nonsense,

just my stupidity

Posted: **13 Jan 2020, 21:34**

Stevebe wrote: ↑13 Jan 2020, 19:36
Go4IT wrote: ↑13 Jan 2020, 18:44 Sorry bones, you disassembled nonsense,
just my stupidity

Oh boy, you don't got me wrong, didn't you!?

What i mean is that if you use the wrong settings, all that come out of the disassembler makes no sense.

If you put in the params i pointed you in my link and disassemble ("c") the first 8 DWORDs it should look like this:

13-01-_2020_22-30-18.png

You see the branch operations, each one 4 byte long (=DWORD). Following the RESET-Vector at 0x0000 it branches to the named location "loc_1018" which IDA creates on the fly for the address offset 0x0000 01018. Simply double-click the name and you get here:

13-01-_2020_22-36-31.png

The first operations setup the stackpointer (place for variables) and the program execution mode (CPSR):

Code: Select all

ROM:00001018 loc_1018                                ; CODE XREF: ROM:00000000↑j
ROM:00001018                 LDR     R0, =0x4000BEFC
ROM:0000101C                 MSR     CPSR_c, #0xD2
ROM:00001020                 SUB     SP, R0, #0x100
ROM:00001024                 MSR     CPSR_c, #0x5F ; '_'
ROM:00001028                 B       loc_3DF8
ROM:00001028 ; ---------------------------------------------------------------------------
ROM:0000102C dword_102C      DCD 0x4000BEFC          ; DATA XREF: ROM:loc_1018↑r
ROM:00001030 ; ---------------------------------------------------------------------------

As you see "LDR" means "load register", in this case "R0", one of 16 32-Bit registers of an ARM CPU. As each operation in ARM Mode is exactly 4 bytes long (1 DWORD) it is not possible to load a 32 Bit value directly. Instead the value itself is placed "nearby" the load operator an only an offset from the current PC (program counter, which is the execution pointer of the CPU) refers to the memory location where the 32-Bit value is placed. You see this by IDA using the ASM macro "=" which denotes this kind of operation. Because IDA knows where the bytes are located, it can create a named location for it ("dword_102C" above) and also can show the value loaded directly after the equal sign. Helpfull, isn't it?

You also find a data reference given at the dword location. It points upwards (arrow) which means the command using it is located before this. It also gives the segment "ROM" and the location "loc_1018". There are some context-functions (right mouse) which help you go to the used locations.

"MSR" means that the value is written to a register of the Co-Processor (CP15). Here it is 0xD2 which set's the MPU to Supervisor mode.

The next one, "SUB" is funny, it primarily loads the stackpointer "SP" with a value of R0 - 0x100, which is 0x4000BDFC. So from this memory location downwards the variables (implicitly used by branch operations or by push/pop operations, depending in the standard calling convention used) are stored. As we know that MAC's SDRAM is located from 0x4000 0000 up to 0x4000 BFFF, we now know where the stack is located

This operation needs a special privilege, which was set before by the CPSR command. The following instruction permits changes of the stackpointer register by setting a lower privilege. Any attempt to do so would raise an internal error and abort the program (reset vector).

In the last instruction it branches forward to 0x3DF8, where it continue execution.

Posted: **13 Jan 2020, 21:44**

Go4IT wrote: ↑13 Jan 2020, 21:34
Stevebe wrote: ↑13 Jan 2020, 19:36
Go4IT wrote: ↑13 Jan 2020, 18:44 Sorry bones, you disassembled nonsense,
just my stupidity
Oh boy, you don't got me wrong, aren't you!? What i mean is that if you use the wrong settings, all that come out of the disassembler makes no sense.
13-01-_2020_22-30-18.png

I am stupid a read the data from your example wrong, this is what happens with dyslexia lo lo i try again

Posted: **31 Oct 2021, 09:43**

Strings in the firmware seems to be coded as 1-Byte Pascal-Strings, means, they start with the number of bytes following.
Here are all english strings of the service menu:

Code: Select all

ROM:000784E0 aTest           DCB 4,"TEST"
ROM:000784E5 aGaugeSweep     DCB 11,"Gauge sweep"
ROM:000784F1 aLedTest        DCB 8,"LED test"
ROM:000784FA aRomLevel       DCB 9,"ROM level"
ROM:00078504 aNvmTargetRom   DCB 14,"NVM target ROM"
ROM:00078513 aNvmEepromLvl   DCB 14,"NVM EEPROM lvl"
ROM:00078522 aManufacture    DCB 11,"Manufacture"
ROM:0007852E aHours          DCB 5,"hours"
ROM:00078534 aDtc            DCB 3,"DTC"
ROM:00078538 aRoadSpeed      DCB 10,"Road speed"
ROM:00078543 aMph            DCB 3,"mph"
ROM:00078547 aKmH            DCB 4,"km/h"
ROM:0007854C aSpeedoGauge    DCB 12,"Speedo gauge"
ROM:00078559 aTachoGauge     DCB 11,"Tacho gauge"
ROM:00078565 aEngineSpeed    DCB 12,"Engine speed"
ROM:00078572 aOdometer       DCB 8,"Odometer"
ROM:0007857B aKm             DCB 2,"km"
ROM:0007857E aOdoRollCount   DCB 14,"ODO roll count"
ROM:0007858D aFuelPercent    DCB 12,"Fuel percent"
ROM:0007859A aFuelGauge      DCB 10,"Fuel gauge"
ROM:000785A5 aFuelADInput    DCB 14,"Fuel A/D input"
ROM:000785B4 aFuelFlow       DCB 9,"Fuel flow"
ROM:000785BE aTempGauge      DCB 11,"Temp. gauge"
ROM:000785CA aEngineTemp     DCB 12,"Engine temp."
ROM:000785D7 aC_0            DCB 1,"C"
ROM:000785D9 aBattery        DCB 7,"Battery"
ROM:000785E1 aADInput        DCB 9,"A/D Input"
ROM:000785EB aPort           DCB 4,"Port"
ROM:000785F0 aDistToEmpty    DCB 14,"Dist. to empty"
ROM:000785FF aRafe           DCB 4,"RAFE"
ROM:00078604 aL100km         DCB 7,"l/100km"
ROM:0007860C aStart          DCB 5,"start"

Posted: **31 Oct 2021, 11:01**

Sometimes i find instructions which looks far too complicated for the simple task they are doing, e.g.:

Code: Select all

ROM:000039FE                 LDRB    R1, [R0,#2]     ; Load current value of I2C Bus Control Register (IBCR)
ROM:00003A00                 LSLS    R1, R1, #25     ; Shift left value of R1 by 25 positions and store the result back into R1
ROM:00003A02                 LSRS    R1, R1, #25     ; Shift right the same value by 25 positions
ROM:00003A04                 STRB    R1, [R0,#2]     ; The shift above only forces Bit 7 to be 0 and so to enable the I2C module

First, the code loads the current value of the I2C control register, which is only a single Byte (8 Bits). This value get's shifted to the left by 25 positions. This shift operation (LSLS ...) set's 0 to every bit shifted into the 32 Bit register from the right. So a sample value of
00000000 00000000 00000000 10110111
gets to
01101110 00000000 00000000 00000000
after the shift left (note the first "1" of the last byte was shifted out!). Then it shifts the value back to the right (LSRS ...)
00000000 00000000 00000000 00110111
and finally stores it back into the IBCR (STRB ...)

All what these instructions are doing is enabling the I2C interface by setting Bit 7 of IBCR register to "0". Looks pretty cumbersume, doesn't it?

But this is what compilers created out of some C oder C++ code.

MicroHacker Forum

Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)

Re: Disassemble MAC7116 software (Ford IPC)