2


I'm trying reverse engineer the firmware, apparently bare metal, of an industrial controller. The device is based on a Coldfire controller, to be more precise, the MCF5282. To track its behavior, I want to use Qemu in its M68k fashion which is supporting already the MCF5206 and the MCF5208. The Coldfire implementation of Qemu lacks in many places, and it seems targeted to run Linux after the bootloader has left the hardware in a particular state. To run my firmware, I had to patch it removing all the hardware initialization, and write a new Qemu file for the CPU I wanted to target, the MCF5282.

So far, It seems that my code is working, and the CPU is initialized as the initialization code I have skipped would have done. When I start my emulation, strangeness begins, and there I ask for your help for understanding what is going on. When I run

qemu-system-m68k -nographic -cpu m5282 -kernel Firmware.bin.qemuPatched \
-serial telnet:127.0.0.1:4444,server,nowait \
-serial telnet:127.0.0.1:4445,server,nowait \
-serial telnet:127.0.0.1:4446,server,nowait \
-d in_asm -D execution.log

I expected all the instruction of the target CPU to be logged, and that's it is what's happened, at least until it reaches a branch instruction.
That time forward, no more instructions are logged, though the emulation is continuing.

I can say that emulation is continuing because if I add to the logged properties the target machine status, I see that the CPU state is changing after the that last instruction is logged and the PC is changing also.
The strangeness does not stop here, and if I follow the PC values, I see that CPU is executing instructions in the firmware address space in an unexpected way, to make a long story short, it seems it is sampling the real flow without writing every single step.

Does someone recognize in it the expected behavior?

Also, at least one time, I found a call to a function (jsr) where the flow logged seems to indicate that function is not executed. It just logs the next instruction, but looking at the CPU state it's clear that function has been executed. Is Qemu which is malfunctioning, or it's just me who can not understand what is going on?

----------------
IN:
0x00004da6:  movel %fp@(8),%d6

D0 = 00000064   A0 = 00082748   F0 = 7fff ffffffffffffffff  (         nan)
D1 = 00000028   A1 = 00084778   F1 = 7fff ffffffffffffffff  (         nan)
D2 = 00000025   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
D6 = 00000000   A6 = 0008fe44   F6 = 7fff ffffffffffffffff  (         nan)
D7 = 00000000   A7 = 0008fe34   F7 = 7fff ffffffffffffffff  (         nan)
PC = 00004da6   SR = 2004 T:0 I:0 SI --Z--
FPSR = 00000000 ----
                                FPCR =     0000 X RN
  A7(MSP) = 00000000 ->A7(USP) = 0008fe30   A7(ISP) = 00000000
VBR = 0x00000000
SFC = 0 DFC 0
SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
MMUSR 00000000, fault at 00000000
----------------
IN:
0x00004daa:  jsr 0x4ca0

D0 = 00000064   A0 = 00082748   F0 = 7fff ffffffffffffffff  (         nan)
D1 = 00000028   A1 = 00084778   F1 = 7fff ffffffffffffffff  (         nan)
D2 = 00000025   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
D6 = 00000064   A6 = 0008fe44   F6 = 7fff ffffffffffffffff  (         nan)
D7 = 00000000   A7 = 0008fe34   F7 = 7fff ffffffffffffffff  (         nan)
PC = 00004daa   SR = 2000 T:0 I:0 SI -----
FPSR = 00000000 ----
                                FPCR =     0000 X RN
  A7(MSP) = 00000000 ->A7(USP) = 0008fe30   A7(ISP) = 00000000
VBR = 0x00000000
SFC = 0 DFC 0
SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
MMUSR 00000000, fault at 00000000
----------------
IN:
0x00004db0:  movew %d0,%d7

D0 = 00000002   A0 = 000822c8   F0 = 7fff ffffffffffffffff  (         nan)
D1 = 00000020   A1 = 00084778   F1 = 7fff ffffffffffffffff  (         nan)
D2 = 0000007f   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
D6 = 00000064   A6 = 0008fe44   F6 = 7fff ffffffffffffffff  (         nan)
D7 = 00000000   A7 = 0008fe34   F7 = 7fff ffffffffffffffff  (         nan)
PC = 00004db0   SR = 2000 T:0 I:0 SI -----
FPSR = 00000000 ----
                                FPCR =     0000 X RN
  A7(MSP) = 00000000 ->A7(USP) = 0008fe30   A7(ISP) = 00000000
VBR = 0x00000000
SFC = 0 DFC 0
SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
MMUSR 00000000, fault at 00000000
2
  • Is there a reason are you asking this here instead of QEMU's support channels (mailing list, bug tracker etc.)?
    – Igor Skochinsky
    Commented Jan 30, 2019 at 13:18
  • Maybe because I expected in here I would have more chances of receiving an answer, or perhaps just because I saw that M68k is not the Qemu folks hot topic and therefore, as happened in the past, I wouldn't receive any answer. After all, I'm not even sure it isn't the expected behavior. But I'll try to follow your suggestion. Yours is also a good suggestion, but if someone has experience in this kind of issues and wants to share in this thread with me, I would appreciate a lot.
    – Alessandro
    Commented Jan 30, 2019 at 15:22

1 Answer 1

1

I got the explanation by another source, and It seems to me to be appropriate post here the answer I received.

It is weird, in my eyes I mean, but it is expected behavior, and make also sense with the necessary explanation.
The nature of Qemu, a JIT translator, implies that all code of the target CPU is translated into the code of the host CPU.
When My code branches to a code part which has been already translated, it just do not translate it again. For that reason, I don't see the istructions in the code log but I see the CPU state changing.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.