Non-ldr-firmware?

[Wizkas0]

Hey sualk! Sorry for using this as a forum for questions, but I couldn't find an email or something like that...

I am analysing firmware from a device that uses a ADSP-BF536 processor, using your plugin. Your dissassembler finds a ton of operations, but the problem is that the control flow doesn't really make sense compared to what I know about the program, and in the decompiler I get a lot of "WARNING: Could not recover jumptable at..."

One thing that could be contributing to the problem is that the firmware file is not able to be loaded as a .ldr file, neither by your extension nor by tool i found that is supposed to be able to read ldr-files. It exists in the device on a flashdrive as a file with the file-extension .BIN, and does not appear to have to correct headers for a .dxe file nor a .ldr file, so it is a mystery to me how the firmware is loaded.

Do you have any ideas of what I could do to get a better result out of ghidra, or any thoughts about what kind of file this might be?

[sualk]

You need to know how the file gets loaded to memory. If the bin file is a raw image then it would be enough to know the location to which the file gets loaded. If the file contains additional information for some kind of loader then you need to know the format and load the file accordingly.

[Wizkas0]

Thank you four answering!

Oh, okay! I do know the location to where it gets loaded actually, I have a dump of the units ram, which contains the firmware file. Even when analysing the entire ram, the control flow doesn't quite add up, and I get those same warnings. It might just be my inexperience, though.

---

Från: sualk @.> Skickat: den 16 oktober 2022 17:46 Till: sualk/ghidra-blackfin @.> Kopia: Kalle Meurman @.>; Author @.> Ämne: Re: [sualk/ghidra-blackfin] Non-ldr-firmware? (Issue #3)

You need to know how the file gets loaded to memory. If the bin file is a raw image then it would be enough to know the location to which the file gets loaded. If the file contains additional information for some kind of loader then you need to know the format and load the file accordingly.

— Reply to this email directly, view it on GitHubhttps://github.com/sualk/ghidra-blackfin/issues/3#issuecomment-1279995325, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASUUYRNRTS5OIR5ZVZILOSLWDQPLRANCNFSM6AAAAAARFK3J2M. You are receiving this because you authored the thread.Message ID: @.***>

[sualk]

So you loaded the binary to the correct location. Then jumps, calls etc. to absolute addresses should be fine and should not influence the control flow.

But maybe your binary uses a lot of parallel instructions? If that is the case you might experience the issue mentioned in the readme, that registers get overwritten due to not handling the parallel execution correctly. I had a binary where this was a big problem and also messed up the control flow in a lot of places.

[Wizkas0]

Right, you mentioned those in he readme. I'm gonna have to study the instructions carefully if there are parallel instructions, then, try to make sense of it.

I think I figured out part of the problem at least, though. I'm trying to identify a function based on strings that I know the function prints, however, ghidra doesn't seem to think that those strings are referenced anywhere in the binary. When examining the stack/ heap however, the copies of the strings that have been put on there are referenced. I think that the strings must be in some array structure and are not referenced directly, but based on some offset from base of that array. So maybe the controlflow actually makes sense, but I've been looking at it the wrong way.

---

Från: sualk @.> Skickat: den 17 oktober 2022 20:17 Till: sualk/ghidra-blackfin @.> Kopia: Kalle Meurman @.>; Author @.> Ämne: Re: [sualk/ghidra-blackfin] Non-ldr-firmware? (Issue #3)

So you loaded the binary to the correct location. Then jumps, calls etc. to absolute addresses should be fine and should not influence the control flow.

But maybe your binary uses a lot of parallel instructions? If that is the case you might experience the issue mentioned in the readme, that registers get overwritten due to not handling the parallel execution correctly. I had a binary where this was a big problem and also messed up the control flow in a lot of places.

— Reply to this email directly, view it on GitHubhttps://github.com/sualk/ghidra-blackfin/issues/3#issuecomment-1281289402, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASUUYRLOFVP4CHMRDBJ6BRDWDWJ4ZANCNFSM6AAAAAARFK3J2M. You are receiving this because you authored the thread.Message ID: @.***>

[13HansSeppaufpepp12]

gh repo clone sualk/ghidra-blackfin