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.

[AngelMarc]

I've been working on those TBL instructions for the last couple days and I think it's basically working.
To try it, extract the files in the attached .zip file into your Ghidra\Processors\68000\data\languages directory.

https://github.com/NationalSecurityAgen ... ssues/1244

Any comments on hex sequence F82E?
I have at least 4 references to that immediately surrounded by seemingly properly decompiled code.
Example

Code: Select all

        00079c70 67 1e           beq.b      LAB_00079c90
        00079c72 3d 78 a1        move.w     (DAT_ffffa104).w,(local_e,A6)                    = ??
                 04 ff f6
        00079c78 3d 78 a0        move.w     (DAT_ffffa0ca).w,(local_c,A6)                    = ??
                 ca ff f8
        00079c7e 36 39 00        move.w     (DAT_0000875e).l,D3w                             = 001Ah
                 00 87 5e
        00079c84 f8              ??         F8h
        00079c85 2e              ??         2Eh    .
        00079c86 31 40 ff f6     move.w     D0w,(-0xa,A0)
        00079c8a 31 c3 a1 04     move.w     D3w,(DAT_ffffa104).w                             = ??
        00079c8e 60 06           bra.b      LAB_00079c96
                             LAB_00079c90                                    XREF[1]:     00079c70(j)  
        00079c90 31 f8 a0        move.w     (DAT_ffffa0ca).w,(DAT_ffffa104).w                = ??
                 ca a1 04
                             LAB_00079c96                                    XREF[1]:     00079c8e(j)  
        00079c96 34 78 a1 04     movea.w    (DAT_ffffa104).w,A2                              = ??
        00079c9a 31 ca a0 c6     move.w     A2w,(DAT_ffffa0c6).w                             = ??
        00079c9e 31 ca a0 e4     move.w     A2w,(DAT_ffffa0e4).w                             = ??
        00079ca2 31 ca a0 c8     move.w     A2w,(DAT_ffffa0c8).w                             = ??
        00079ca6 31 ca a0 c4     move.w     A2w,(DAT_ffffa0c4).w                             = ??
        00079caa 31 ca a0 c2     move.w     A2w,(DAT_ffffa0c2).w                             = ??
        00079cae 11 fc 00        move.b     #0x1,(DAT_ffffa123).w                            = ??
                 01 a1 23
        00079cb4 60 00 05 7a     bra.w      LAB_0007a230

not exactly sure of this answer but I tried ida with the 688332 we normally use and got the same results. So I tried some other similar processors and eventually used the ida MC68xxx universal emulator that includes all opcodes from all variants of the CPU32 and it gave me this:

Code: Select all

ROM:00079C6C                                         loc_79C6C:                              ; CODE XREF: ROM:00079C0A↑j
ROM:00079C6C                                                                                 ; ROM:00079C12↑j ...
ROM:00079C6C 4A38 A123                                               tst.b   ($FFFFA123).w
ROM:00079C70 671E                                                    beq.s   loc_79C90
ROM:00079C72 3D78 A104 FFF6                                          move.w  ($FFFFA104).w,-$A(a6)
ROM:00079C78 3D78 A0CA FFF8                                          move.w  ($FFFFA0CA).w,-8(a6)
ROM:00079C7E 3639 0000 875E                                          move.w  (word_875E).l,d3
ROM:00079C84 F82E 3140 FFF6                                          tblu.w  -$A(a6),d3
ROM:00079C8A 31C3 A104                                               move.w  d3,($FFFFA104).w
ROM:00079C8E 6006                                                    bra.s   loc_79C96

From https://support.dce.felk.cvut.cz/nms/fi ... /c4cpu.pdf (which then goes on to describe the opcodes if you were to look in to defining them in ghidra).
I am going to guess either these are put in this CPU as GM customizations for their version of the chip, or the P59 has a slightly newer processor than the P01 which adds the extra instructions we know that NSFW helped define in ghira as well as these.

Code: Select all

The CPU32 instruction set is summarized in Table 4-2. The instruction set of the
CPU32 is very similar to that of the MC68020. Two new instructions have been added
to facilitate controller applications: low-power stop (LPSTOP) and table lookup and
interpolate (TBLS, TBLSN, TBLU, TBLUN).