I’m porting a driver over to ARM64, that driver relays crucially on some un-exported kernel symbols,
it currently finds in exported functions the required addresses, in x86/x64 that’s quite nice.
Ho weever the ARM64 ISA seams to be quite a terrible mess in comparison, no way to find there anything “by hand”, so to say.
Hence I need a ARM64 disassembler engine that I could use to find what I need,
could anyone here recommend me a reliable lightweight and free ARM64 disassembler engine which I could use?
It is inaccurate to say that the ARM64 instruction set is “a terrible mess.” The simple fact is that the x86/x64 instruction set is a terrible mess, with special-purpose instructions of various lengths with hidden dedicated registers and a virtually random machine code, with prefix bytes that interact in unexpected ways. It is the unorthogonal nature of the instruction set that makes it easier to find specific sequences. The ARM architecture, on the other hand, is simple and logical. It just so happens that the simplicity makes it harder to decompile, which is what you need.
Whether that’s good or bad depends on which side of the world you’re on.
well, it is also wrong to say that the ARM instruction set is more logical or that that’s the reason it is harder to identify a specific sequence or decompile. ARM is a RISC architecture while x86 and x64 are CISC design. That’s a fundamental difference
Baroque instruction sets like x64 have disadvantages to be sure, but there are some advantages. They are easier to extend and can be harder to disassemble given the profusion of possible code bytes sequences that a compiler or optimizer can choose from. Consider the REP NOP sequence - who in the 1980’s would have thought that that would become important? And also the many new prefix codes that are ignored by older CPU models but control things like transactional memory on newer ones. And how many different ways are there to encode a loop that searches for substrings? many
Setting all of those issues aside, the OP’s problem is that he is trying to find some function entry points by looking for certain code bytes near its start. Probably by looking for code that does something about parameters. That’s harder to do on any RISC architecture, but it is not something that can reliably be done on any kind of architecture. It can break with a simple Windows update and when it does, it can result in calling into arbitrary KM code.
Well fair enough ARM has its advantages just that as you wrote for disassembling and alike is a pain.
I am aware of the potential risks although historically to my knowledge the safeguards in place worked and when something changes the driver just failed to load with an appropriate error message.
So the question at hand is with what to disassemble arm64 code in the kernel?
Absolutely right… IDA-Pro is, basically, the “standard” – but, it’s far from free (and the guy who owns the company has not exactly been “collaborative” in the past).
And, FWIW, I’ve heard some bad stories about Ghidra. I mean, aside from the whole Log4J fiasco.