Ghidra

[maidenone]

previous work on RV32 and RV64
https://delaat.net/rp/2019-2020/p49/report.pdf

https://reverseengineering.stackexchange.com/questions/22558/reversing-a-key-gen-firmware-for-risc-v

Ghidra release do not support Risc-V but if you install from source it does.

[gamelaster]

I already tried nightly Ghidra (there are some repos with prebuilt windows binaries), sadly,
I wasn't able to configure Ghidra to correctly disassemble the blobs (yet)

[micahswitzer]

I was able to get a nightly build partially working. The batch import didn't work properly, and it also doesn't support a few kinds of relocations needed, but I was able to load a few object files manually.

There's a fork of Ghidra that has a few more updates to the RISCV module, but I haven't had the chance to check it out yet: https://github.com/mumbel/ghidra/tree/riscv

[stschake]

I've used the out-of-tree version here: https://github.com/mumbel/ghidra_riscv

Seems to work okay, even if it doesn't have the exact ISA. In general, I'd recommend just giving Ghidra an ELF from the build instead of trying to get it to digest the raw object files.

This is the built processor, extract to $GHIDRA_DIR -> Ghidra -> Processors:
ghidra_9.1.2_PUBLIC_20201029_ghidra_riscv.zip

[micahswitzer]

Ah okay, I didn't realize that version existed. That's much cleaner.

I guess the reason I'd prefer reversing straight from the objects is so that we can more easily isolate the behavior of each API function. Maybe the goal is not so much to duplicate their API in C as it is to identify how to interact with the radios? I guess I'd like to see a clear goal established when it comes to the RE work.

[gamelaster]

@micahswitzer This is very good question. Although, I think the most easiest way of testing the setup if our RE'ed implementation works, is just reimplement their API.

[maidenone]

I got 3 BL602 boards on its way to me, i will make them remotely available if there are things we want to execute on real hardware. I also got a SDR that i can hook up to look at what happens in the spectrum when we poke at registers.

[gamelaster]

@maidenone well, how you want to deal with flashing? AFAIK, the flash tools are closed-sourced.

[maidenone]

have not thought about that. but given that it is a SiFive E25 core that uses JTAG, making OpenOCD talk with it should not be that hard?

I have poked around with OpenOCD and BMP code before to add new targets.

[WildCryptoFox]

My understanding of ghidra's decompiler is that it is written in C++ and doesn't depend on Java at all; but the linked repo appears to use Java..? I don't (yet) have Ghidra, nor Java, could someone present some decompilation samples over the objects in this repository?

Yesterday, I experimented with adding RISC-V support to r2dec. The output is a naive translation of assembly to a pseudo-c; arguably not much better than the assembly itself. The result could be greatly improved with post-processing but r2dec isn't really designed for data-flow transformations, so this would be limited to trivial cases.

This might be enough but I'd rather invest time in a new decompiler, which can use deep data-flow analysis to simplify the result. I'd start with RVSDG, an optimization-friendly data-flow intermediate representation in SSA-form without the total order of control-flow graphs. Such a decompiler could naturally be repurposed as an optimizing recompiler.

Would anyone be interested in either working on improving an existing decompiler or working towards a new one?

[micahswitzer]

Yes, the decompiler itself is written in C++. However, the processor specifications are written in a DSL called Pcode, and the code that tells Ghidra how to load platform specific relocations and DWARF information is written in Java.

So yes, you can run the decompiler without Java (I believe radare can do that), but it's much more useful if you use it within the context of Ghidra with all of the tools that Ghidra has to offer.

That being said, the RISCV module for Ghidra is not quite production ready. In my incredibly brief testing, I noted that most of the non-trivial relocation types were not implemented. I also read that there were some other issues with the pcode that caused Ghidra to misinterpret the meaning of the assembly (not the disassembly itself). I'm relatively new to the RISC-V ISA, but I'd be willing to see if I could at least implement the missing relocations which would greatly improve the usability of Ghidra for this project.

I'm also willing to lend another set of eyes on such an effort should someone else with more experience want to tackle this issue with another RE platform.

[stschake]

I might be misunderstanding, but since the ELF here is built purely so the code can be pulled out of it for a raw flash image, it won't have any relocations - there isn't any code in the ROM that could load them anyway. So while the Ghidra RISCV processor doesn't support a lot of them, that doesn't matter if you load the ELF into it?

[micahswitzer]

You are correct that there will be no relocations in the final binary loaded into ROM. However, since the library code references other internal functions and data structures, relocations are necessary to allow for flexibility during the final linking step.

I think you may be suggesting that we could simply compile and link a sample application which we could then RE since it would no longer have any relocations. If so, issue #6 suggests the same thing.

[Yangff]

Yes, the decompiler itself is written in C++. However, the processor specifications are written in a DSL called Pcode, and the code that tells Ghidra how to load platform specific relocations and DWARF information is written in Java.

So yes, you can run the decompiler without Java (I believe radare can do that), but it's much more useful if you use it within the context of Ghidra with all of the tools that Ghidra has to offer.

That being said, the RISCV module for Ghidra is not quite production ready. In my incredibly brief testing, I noted that most of the non-trivial relocation types were not implemented. I also read that there were some other issues with the pcode that caused Ghidra to misinterpret the meaning of the assembly (not the disassembly itself). I'm relatively new to the RISC-V ISA, but I'd be willing to see if I could at least implement the missing relocations which would greatly improve the usability of Ghidra for this project.

I'm also willing to lend another set of eyes on such an effort should someone else with more experience want to tackle this issue with another RE platform.

yes, plaease use the elf I pushed to the blobs. (or, if you want, compile them like @micahswitzer said ) They should also contain all the symbols and in my case, ghidra with risc-v plugin load them mostly good. Only problem is the floating point, which I think we can do it manually.

However, it seems that the decompile result contains some problem. as far as I can read, some memory r/w are missing.. i can see them in the assembly, but they disappear in decompile.

[WildCryptoFox]

Reko, a capstone-based decompiler, might be a candidate. Unfortunately it doesn't seem to understand at least RISC-V ELF relocations. I don't know how much work is needed.

[mumbel]

if you come across any disassembly/instruction issues (I just fixed a bug in c.fsw and c.fswsp) or if you come across any ELF unimplemented relocations (I didn't notice any yet) feel free to file an issue on either of my repos. If its a bigger non-RISCV issue, i'd go ahead and file with ghidra's issues. There is an open bug being looked at if you come across a subtract popup.

edit: this was done in my side time, and I haven't used this module extensively so there are likely bugs, if anything looks off, comments are welcome, and hopefully 9.2 will be out soon so you don't have to build ghidra, but would for sure at least use my RISCV/data/languages/ which is compiled by ghidra at runtime based on if the timestamp for the .sla file is out of date/doesn't exist yet.