Symbol visibility in debugger

[chicane]

Hi,

I'm doing some reverse engineering of game code, and trying to make my life easier by manually building up a file of symbols (as per the specified ASCII symbol file format) containing significant code and data addresses that I can import into the Hatari debugger. However, I'm not quite getting the results I expect.

For example, I've created a symbols file with the following content and loaded it with the command "symbols symbols.txt":

Code: Select all

7657e T doneaaa
7c586 D apitstop

If I disassemble the code at address 7675e, I see a label in the debugger disassembly, which is what I want:

Code: Select all

doneaaa:
$0007657e : 4a79 0007 c586                     tst.w     $7c586

However, what I'd also expect to see is the address within the tst.w instruction being converted to say "apitstop" rather than "$7c586".

Am I misunderstanding what Hatari should be doing in this scenario? I've read that the "symbols" command can take "TEXT DATA BSS" parameters, but I'm not sure I understand what values I would specify or whether they would even be relevant in this instance.

Thanks.

[ThorstenOtto]

I think that is just a missing feature in the disassembler. But you can use the symbol name for example to set watch points.

Edit: instead of doing that in Hatari, you could also try out TTdigger (provided you have some program to load there, if the game directly loads some sectors from floppy you are lost)

[chicane]

I think that is just a missing feature in the disassembler. But you can use the symbol name for example to set watch points.

Edit: instead of doing that in Hatari, you could also try out TTdigger (provided you have some program to load there, if the game directly loads some sectors from floppy you are lost)

Thanks for clarifying. That's a bit of a shame but as you say, there are alternative ways

[ThorstenOtto]

For reverse engineering, TTdigger is a much better tool than some disassembly output. It has some quirks, and the GUI is a bit unusual, but it is quite powerful.

[chicane]

For reverse engineering, TTdigger is a much better tool than some disassembly output. It has some quirks, and the GUI is a bit unusual, but it is quite powerful.

Thanks. There's also Ghidra if one is willing to venture outside the world of Atari-native apps

[ThorstenOtto]

Ghidra is very powerful, but will only help with c-compiled code. And it won't work very well with code compiled by Pure-C, because it does not recognize the function parameters passed in registers.

[czietz]

Ghidra is very powerful, but will only help with c-compiled code.

No. I also find the disassembler extremely powerful.

And it won't work very well with code compiled by Pure-C, because it does not recognize the function parameters passed in registers.

With additional effort, you can teach Ghidra that calling convention, if you insist on using the decompiler. See this (nonsensical) example I built in PureC:

ghidra_purec.PNG

[ThorstenOtto]

With additional effort, you can teach Ghidra that calling convention, if you insist on using the decompiler. See this (nonsensical) example I built in PureC:

Nice. How did you do that? And does it also distinguish pointers from integral types?

[czietz]

Nice. How did you do that? And does it also distinguish pointers from integral types?

As I said, this requires additional effort. You need to edit the function signatures to specify the parameters and how they are passed. (Then again, this is also sometimes required even for compilers / calling conventions where arguments are passed on the stack.)

Generally, when reverse-engineering, there are just a handful of functions that are so interesting to me that I bother fixing the signature. Furthermore, I have an (albeit incomplete) Function ID database that helps identifying Pure C standard library functions.