12587603 OS disassembly

[antus]

it seems to only be a 24 bit bus, so the top 8 address bits dont matter. FF8000 is literally the same address as FFFF8000. I have verified this with my own tools. Different compilers or code create different output but its functionally the same. Just another annoyance when your trying to reverse engineer. I dont know of an automatic way to deal with this, I would proceed with what you have and try to keep your head around it. If it was possible to find the locations for all of the opcodes that reference either FFxxxx or FFFFxxxx and patch one to the other in an automated way in the bin I think the bin would work the same, but it would make the disassembly cleaner. I have not solved this, but that is how I would do it if that was my goal. I reckon you could do this in ida in python, not sure what ghidra has as far as scripting and patching languages go. Or maybe you could export asm and write a tool that loads the asm and byte patches the bin outside of ghidra then load the new bin back in.

[RADustin]

it seems to only be a 24 bit bus, so the top 8 address bits dont matter. FF8000 is literally the same address as FFFF8000. I have verified this with my own tools. Different compilers or code create different output but its functionally the same. Just another annoyance when your trying to reverse engineer. I dont know of an automatic way to deal with this, I would proceed with what you have and try to keep your head around it. If it was possible to find the locations for all of the opcodes that reference either FFxxxx or FFFFxxxx and patch one to the other in an automated way in the bin I think the bin would work the same, but it would make the disassembly cleaner. I have not solved this, but that is how I would do it if that was my goal. I reckon you could do this in ida in python, not sure what ghidra has as far as scripting and patching languages go. Or maybe you could export asm and write a tool that loads the asm and byte patches the bin outside of ghidra then load the new bin back in.

I don't really see it being a problem, other than it's a little messy. Functionally I suppose it's all there. Appreciate the info.

I'm getting a hard error though at 0x506 based on a reference it's getting from 0x502. I set that whole region to data and rerun the analysis but it doesn't get any further. So I need to figure this part out.

Also the scripting in the dumpster dive info. Really no clue yet on how that is done so I need to look into that.

[antus]

looking at one of my projects from an earlier OS, 0x500 to about 0x54c are data (GM proprietary segment header), not code. You need to follow the boot code until you see it load data in to a register and then jump to the register. I dont know how well modern tools handle this but when I was doing it they couldnt follow that automatically and it took manual work and scripts to follow the code. disassembling all was not that effective.

[RADustin]

looking at one of my projects from an earlier OS, 0x500 to about 0x54c are data (GM proprietary segment header), not code. You need to follow the boot code until you see it load data in to a register and then jump to the register. I dont know how well modern tools handle this but when I was doing it they couldnt follow that automatically and it took manual work and scripts to follow the code. disassembling all was not that effective.

I see what you're saying. I'll take a look.

[antus]

Yeah its called an indirect jump. A disassembler needs to be able to see if a static address is loaded to a register and is then jumped too, but to know this it needs to know that the source is rom, not ram, and so the target address is not generated at runtime and of course it is possible in other hardware that it could be generated at runtime. So most disassemblers are not smart enough to handle this automatically. Your entry points are one of these from the boot sector, and a couple from the interrupt vectors at the start of the rom which are hardware triggered to handle inputs. If you can find and follow all of these you should be able to get most of the code. If you have or write a script that can handle the indirect jumps that will be better. When I did it I had a clumsy script that set every byte to code through the bin in ida from python. It was messy, but it was ok.... a loop, set code, next byte, repeat. it was easy to write and found the code but created lots of junk too. doing it properly would be a lot better.

[RADustin]

still working through making heads and tails of things but wanted to post this. Using the 'dumpster dive' CSV for P59 OS 7603 I parsed it into an agreeable format that the prewritten Ghidra script would run it.

The Ghidra script is 'ImportSymbolsScript.py'. Run it and it'll prompt to open a file, use the attached. This process will overlay the entire contents of the CSV into Ghidra and instantly make the code more human readable.

Many thanks to NSFW.