600 Control Unit

[bdm310]

Picked back up on this project recently and decided to see if I could figure out the CU firmware and get a RAM dump. Many hours in and I'm learning that x86 real mode embedded applications are really really difficult to disassemble and my usual tools don't work well (Ghidra). I'm very slowly making progress but figured I'd start a discussion here as it seems that you've gotten quite a bit further on this than I have so far.

Two main questions so far -

1. I see a reference to turning on the CU with "Menu and Power buttons" in your python tool. The flow of the tool suggests that this should put the unit in a different mode, I'm assuming a ROM program/bootloader mode. Mine does not seem to do this. Not sure if I'm making the right conclusions here?
2. If you have anything in-work on reverse engineering the CUs or any helpful tips, I'm all ears.

[robots]

All CUs have ROM. I dont know which version of CU you have. There is one with graphical display and there is one with 2004 4line lcd.

• graphical units have 1MB of RAM and rom in PLCC socket
• character based units have less ram, and rom is soldered.
• I have dump of both (somewhere)

Graphical lcd emulates character lcd. There is font table and it basically acts same way wrt firmware.

There is one place in Port (inport outport address space) that determines the version of the CU. There are multiple versions, i dont know what the difference is (and its not the keyboard, keyboard is different thing)

Since some version firmware is the same. It will work with both variants of lcd. I have just dumps from graphical CUs.

The loader is in ROM, it is accessed by combo of keys. There are few portions of it not accessible without 80186e debugger. But its not problem.

With ghidra you start at address.. fffff0 (f000:fff0 in ghidra). Ghidra sucks at the segments, you need to do them manually.

f000:fff0 ea 04 00        JMPF       LAB_f000_ff04
                 f0 ff

Look at the op code ... ea 04 00 f0 ff. Segment is fff0, offset 0004. Hit G in ghidra type fff0:0004 and you are sent to:

                             LAB_f000_ff04                                   XREF[1]:     f000:fff0(j)  
       f000:ff04 ba a4 ff        MOV        DX,0xffa4
       f000:ff07 b8 00 f8        MOV        AX,0xf800
       f000:ff0a ef              OUT        DX,AX
       f000:ff0b ba a0 ff        MOV        DX,0xffa0
       f000:ff0e b8 00 00        MOV        AX,0x0
       f000:ff11 ef              OUT        DX,AX
       f000:ff12 ba a2 ff        MOV        DX,0xffa2
       f000:ff15 b8 0a f8        MOV        AX,0xf80a
       f000:ff18 ef              OUT        DX,AX
       f000:ff19 ba 94 ff        MOV        DX,0xff94
       f000:ff1c b8 c0 0f        MOV        AX,0xfc0
       f000:ff1f ef              OUT        DX,AX
       f000:ff20 ba 96 ff        MOV        DX,0xff96
       f000:ff23 b8 0a 10        MOV        AX,0x100a
       f000:ff26 ef              OUT        DX,AX
       f000:ff27 ba 9c ff        MOV        DX,0xff9c
       f000:ff2a b8 00 00        MOV        AX,0x0
       f000:ff2d ef              OUT        DX,AX
       f000:ff2e ba 9e ff        MOV        DX,0xff9e
       f000:ff31 b8 0a 20        MOV        AX,0x200a
       f000:ff34 ef              OUT        DX,AX
       f000:ff35 2e ff 2e        JMPF       CS:[0x0]=>LAB_f000_0000
                 00 00

Very special thing about ROM in CU. Its only HALF of the space it has allocated. So its mirrored on some. The very latest CUs have bigger rom i think

I am attaching 2 files. You should be able to import them to ghidra. I use 11.2.1 version. Gdm-cu is "the" cu firmware. CU_ROM_xxx is rom dump and analysis. I have tried to understand and name the functions by what i think they do - looking at manual, label tables, etc etc.

gdm.zip

[robots]

Uhh almost forgot .... there is very special operating system. I call it "proc". There is table of proc's (procedures/processes). (look for proc_0) These processes have function handler, flags, and "events" on what to do when something happens. They are linked together by these processes. For example Proc_0 will advance to proc_1, 125, 7c, 3c, 3eb - depending on content of 22d0 address.

So procs have type:
type 0 is ...
type 1 is ... i dont remember
type 2 is end of sequence, return to "initial" proc. (initial proc is told by flags)
type 3 is execute function and advance to referenced proc
type 4 is ... i dont remember :)
type 5 is switch ... so if you see 5004h that means there are 4 cases + default (1,125,7c,3c,3eb).

Look at proc_a its switch with 42h values (this is actually the "select application screen")

There is function called proc_proc which is the proc processor :) ... this is what schedules the next proc.

Interrupts can schedule new proc! This is how serial ports and devices are handled. (here only serial port)

[robots]

factory backup and factory restore just copies first few kB of ram beyond 1/2 of RAM, and restore copies it back :-D sorry to crash your dreams.
Closest there is to dump is Variable backup. This one will dump start of the ram to serial port. But only start. I have modified ROM that i can plug into the CU that will dump whole RAM. But its kinda hard, because its old tech, not all people have EPROM burners + the chips are no longer manufactured.

[bdm310]

That sure is silly. Last resort is of course burn a new EPROM with some code to dump RAM. Mine has a 27C256 in it, so easily doable.

I'm sure they weren't coding with vulnerabilities in mind, we'll see if it's possible to find an exploit.

Trimble must have a way to write the full RAM, right? I haven't done a very close look at your python tools to see if that's what they can do?

[robots]

I think trimble has the firmware, so they dont care about dump. They just upload new firmware and do the "setup" config. This is where you select size of RAM (yes you pay more for more ram, already present) select type of keyboard. (on stations you select type of servo, radio, edm)

[robots]

And yes, there is step-by-step script to upload full dump :) https://github.com/robots/gdm/blob/master/gdm600cu/upload.py

[robots]

If you are interested in the MATH! ... this is best viewed in very old 400station code. I have most of the math figured out.
400.zip

The proc numbers and sequences are the same across the geodimeter software. So you can look here and see what the math is, apply it to CU.

[robots]

The math is with 6 byte numbers. see gdm_num.py for details.

[Middim]

Just wondering if this means it would be possible to upload the program file to the CU?
I still have my CU which I had replaced the batteries on, but of course it just says "Program Lost!" and "Version 668-01.01 Load Program!".
I'm still able to use my 600 since I have software for the computer, but it sure would be nice if it's possible to re-upload the program and have the CU working as well.

[bdm310]

If you have a program file to upload, there are tools in this repo to do so. There currently exist no tools (outside of @robots 's custom flash chip) to back up a CU though, so you're out of luck if you don't have a program already.