Menu

A few posts ago, we managed to disassemble the firmware from the CSL Dualcom site.

The entire listing is available here as a zip. There is a lot of blank space in the file which needs to be trimmed down, but for reference this file will be left as-is.

I have also put the code on github. It’s not ideal as you can’t use the web interface to show the code/diffs, but it is a good way of recording history as mistakes will be made.

The process of turning diassembly into something useful isn’t easy. I find the most useful things are to find very commonly called subroutines first, and work out what they do. If they aren’t obvious, skip them.

The raw listing doesn’t show us the frequency with which subroutines are called. Python, to the rescue again. We trim out the fluff from the file. 0x1000-0x2000 is the string table, which the disassmebler doesn’t know about and tries to turn into code. The processor has a mirrored address structure so everything in the range 0x00000. Everything above 0x1FFFF isn’t the code – it’s special function registers and a mirror area.

First thing to be aware of is that disassembly is not an exact science. Sometimes you will see an address CALLed but you can’t find it. This probably means that the disassembly is misaligned in that area – look a couple of adresses above and below. This is not the case here.

We can see immediately above 0xE1B2 there is a POP and RETB, the end of a subroutine.

To work out what a sub does, it helps to know what parameters are passed to it and how. If we look through for all the CALLs to 0xE1B2, we get an idea of what is going on:

1

2

3

03d31530dMOVB,#0DH

03d33e1 ONEBA

03d34fcb2e100 CALL!!0E1B2H

B is always set to a value over quite a wide range. It’s probably a number or a ASCII character.

A is set to either 0, 1, 2 or 3. This is likely some kind of option or enumeration.

Going back to the subroutine, we can see how this could work:

1

2

3

4

5

6

7

8

9

10

11

12

13

0e1b24c01CMPA,#1H

0e1b4df05 BNZ$0E1BBH

0e1b663MOVA,B

0e1b7ec01e100 BR!!0E101H// If A = 1, branch to 0xE101

0e1bb4c02CMPA,#2H

0e1bddf05 BNZ$0E1C4H

0e1bf63MOVA,B

0e1c0ec47e100 BR!!0E147H// If A = 2, branch to 0xE147

0e1c44c03CMPA,#3H

0e1c663MOVA,B

0e1c761f8SKNZ

0e1c9ec6ce100 BR!!0E16CH// If A = 3, branch to 0xE16C

0e1cdecdfe000 BR!!0E0DFH// If A = 0, branch to 0xE0DF

So we are branching to other addresses based on the parameter in A.

There’s one thing to note about this function. There is no immediate RET instruction there. These have to be dealt with in the code that is branched to.

Let’s look at 0xE101.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

0e10177MOVH,A

0e1028efaMOVA,PSW

0e1049803MOV[SP+3H],A

0e10667MOVA,H

0e107717bfaDI

0e10ac3 PUSH BC

0e10bdbb6e0 MOVW BC,!0E0B6H

0e10e48b8e4MOV0E4B8H[BC],A

0e111a2b6e0 INCW!0E0B6H

0e114afb6e0 MOVW AX,!0E0B6H

0e117440a04CMPW AX,#40AH

0e11adc04 BC$0E120H

0e11cf6 CLRW AX

0e11dbfb6e0 MOVW!0E0B6H,AX

0e1208f0401MOVA,!SSR02L

0e12331631eBTA.6H,$0E144H

0e126362201MOVW HL,#122H

0e12971a2SET1[HL].2H

0e12b71b2SET1[HL].3H

0e12ddbb4e0 MOVW BC,!0E0B4H

0e13049b8e4MOVA,0E4B8H[BC]

0e1339e44MOV SIO10,A

0e135a2b4e0 INCW!0E0B4H

0e138afb4e0 MOVW AX,!0E0B4H

0e13b440a04CMPW AX,#40AH

0e13edc04 BC$0E144H

0e140f6 CLRW AX

0e141bfb4e0 MOVW!0E0B4H,AX

0e144c2 POP BC

0e14561ecRETB

It’s pretty long and complex. But there is one really key piece of info in there – the special function register SSR02L. Looking to the 78K0R data sheet, this is “Serial status register 02”. It’s pretty likely this function concerns serial. It has a return at the end as well.

If we look 0xE16C, this has reference to SSR12L. Another serial port.

It’s quite likely that this function concerns either reading or writing to the various serial ports on the board. I’ve not looked at it in enough depth to know exactly what it is doing, so we’ll do the following:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

// B has char

// A has 0,1,2,3 - probably different serial ports

// Return is in the branches

:sub_Serial_UnknownA_e1b3

0e1b24c01CMPA,#1H

0e1b4df05 BNZ$0E1BBH

0e1b663MOVA,B

0e1b7ec01e100 BR!!0E101H// A = 1

0e1bb4c02CMPA,#2H

0e1bddf05 BNZ$0E1C4H

0e1bf63MOVA,B

0e1c0ec47e100 BR!!0E147H// A = 2

0e1c44c03CMPA,#3H

0e1c663MOVA,B

0e1c761f8SKNZ

0e1c9ec6ce100 BR!!0E16CH// A = 3

0e1cdecdfe000 BR!!0E0DFH// A = 0

What have I done here?

Called the sub :sub_Serial_UnknownA_e1b3. The : denotes that this is the actual sub. It is something to do with serial – the first unknown sub to do with serial. I have put the address on the end just to keep track of where it is.

Search and replace on !!0E1B2H with this new name. “sub_Serial_UnknownA_e1b3” now shows instead of the raw address – when I see it called I know it is something to do with serial.

Put some brief notes above the sub so I know what it is doing.

Indented branches so function is a little clearer

I’m now going to do similar for the other high-frequency subs. Again, I am building up a broad picture, not going into extreme depth at this stage.

I'm a security researcher and reverse engineer. By visiting this site, you must realise that any or all files on this site may be jam packed full of the finest exploits, tricks and other gubbins. You might also get geo-located and port-scanned for fun and profit.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
If I really want to track you, by tricking you into visiting this site, then it's going to be a lot more subtle than a browser cookie.