NOISSUE - Ghidra Reverse Engineering

[debugthings]

@logicog I started looking at this repo a month ago because it is well ahead of where I was when I started looking at how to alter the firmware.

I have a number of tools, bits and bobs around creating better decompilation of the firmware. Here is the repo https://github.com/debugthings/ghidra_8051tools

[logicog]

Please do! We need all the bit and pieces we can gather to put this together. The learning curve to get here was extreme.
At present I am adding the uIP TCP/IP stack. I am mostly through, i.e. the porting to 8051 is done and I see packets, but need to fix some ARP stuff, because I don't want to check in anything that removes functionality. And then I really would need some ideas where this should go. If this is to be a complete replacement firmware, then there needs to be a web-server, possibly with SSL. That will be very nasty to implement. Squeezing uIP into the little RAM there is, was already very hard.

[logicog]

Wow this is very advanced! Could you add some documentation, on how to integrate with Ghidra? The way you took was very different from what I did. I went directly for the interaction with the SFRs, knowing how the Network-ASIC would look like from work on the RTL93xx chips. So my Ghidra-Skills don't go much beyond finding the SFR-code. I have an image now though, that will print for every action in the web-interface on the serial console the corresponding Register-read/writes, PHY-rw and SerDes r/w. With that, one can implement stuff features mirroring in a couple of hours. It is basically click stuff in the web and look what is being written to the ASIC, possibly read the datasheet for the RTL8366/9 for some background.

[debugthings]

Agreed on the stack. What I can tell from this is they have a modified version of lwIP and a custom set of software for spanning tree implementation.

I've added some other things to the repo along with my workspace. It might break because I changed the processor spec to workaround a few things that were annoying me about the ABI and how the compiler and Ghidra interacted with register banking, I'll add some documentation on how to get it working.

Caveat, I need to start from a fresh instance of Ghidra and figure out all I did in a succinct way

[logicog]

Are you sure about IwIP? That is more complex than uIP and I had quite some trouble getting that to compile under sdcc. But then I guess they are using the Keil compiler (is that correct?), which seems to produce much better code. With sdcc I am not sure IwIP will compile without a lot of optimization by hand, if at all.

[debugthings]

I'm going to walk it back and state they are using a TCP/IP stack based on lwIP. Strings in the code show directory listings such as these which mirror the ipv4 directory.

https://github.com/lwip-tcpip/lwip/tree/master/src/core/ipv4

LOC	VAL	REP	TYP	LEN
BANK02::cc1d	....\common\src\app\web\httpd.c	"..\..\common\src\app\web\httpd.c"	ds	14
BANK08::9cb6	....\common\src\app\web\httpd.c	"..\..\common\src\app\web\httpd.c"	ds	14
BANK01::e9da	....\common\src\app\web\web_api.c	"..\..\common\src\app\web\web_api.c"	ds	4
BANK04::d508	....\common\src\app\web\web_api.c	"..\..\common\src\app\web\web_api.c"	ds	4
BANK01::c928	....\common\src\lwps\etharp.c	"..\..\common\src\lwps\etharp.c"	ds	12
BANK04::66fb	....\common\src\lwps\etharp.c	"..\..\common\src\lwps\etharp.c"	ds	12
BANK02::cff9	....\common\src\lwps\icmp.c	"..\..\common\src\lwps\icmp.c"	ds	2
BANK06::c888	....\common\src\lwps\icmp.c	"..\..\common\src\lwps\icmp.c"	ds	2
BANK06::7308	....\common\src\lwps\igmp_group_db.c	"..\..\common\src\lwps\igmp_group_db.c"	ds	0
BANK06::5a4f	....\common\src\lwps\igmp_snooping.c	"..\..\common\src\lwps\igmp_snooping.c"	ds	0
BANK21::a86e	....\common\src\lwps\lacp_fsm.c	"..\..\common\src\lwps\lacp_fsm.c"	ds	1
BANK01::b4bc	....\common\src\lwps\lwps_api.c	"..\..\common\src\lwps\lwps_api.c"	ds	56
BANK04::6273	....\common\src\lwps\lwps_api.c	"..\..\common\src\lwps\lwps_api.c"	ds	66
BANK20::a546	....\common\src\lwps\rstp.c	"..\..\common\src\lwps\rstp.c"	ds	6
BANK01::b910	....\common\src\lwps\tcp.c	"..\..\common\src\lwps\tcp.c"	ds	14
BANK04::4085	....\common\src\lwps\tcp.c	"..\..\common\src\lwps\tcp.c"	ds	16
BANK01::ba16	....\common\src\lwps\udp.c	"..\..\common\src\lwps\udp.c"	ds	10
BANK04::6105	....\common\src\lwps\udp.c	"..\..\common\src\lwps\udp.c"	ds	18
BANK09::937b	..\src\api\rtk_switch.c	"..\src\api\rtk_switch.c"	ds	4
BANK06::c91f	..\src\init.c	"..\src\init.c"	ds	26
CODE:3953	..\src\sal\salacl.c	"..\src\sal\salacl.c"	ds	3
BANK08::c3c8	..\src\sal\salqos.c	"..\src\sal\salqos.c"	ds	2
BANK08::9e91	..\src\sal\saltrunk.c	"..\src\sal\saltrunk.c"	ds	2
BANK08::c423	..\src\sal\salvlan.c	"..\src\sal\salvlan.c"	ds	2
BANK21::407d	..\src\web\web_file.c	"..\src\web\web_file.c"	ds	2
BANK04::841f	..\src\web\web_image.c	"..\src\web\web_image.c"	ds	2
BANK01::c631	src\web\web_file.c	"src\web\web_file.c"	ds	2

[logicog]

That's a very convincing argument. This is probably based on a very old version without much of the newer code in lwIP such as TLS or IPv6, tough. At least they don't offer that. The RTL8366 for which their SDK seems to have been written initially is from latest 2005, around the time lwIP was also initially written. lwIP is more performant than uIP, but also more complex, which means more problematic for stack use, the limiting factor for the 8051. I will stick to uIP for now, the TCP/IP stack can be switched later again.
Evidently, any free firmware alternative would need to be able to be configured through the network and be installed through their web-interface, in order to be attractive for more than hackers. For that, my biggest questions regarding the boot process are:

• How is the checksum for the image calculated? The algorithm does not seem to be obfuscated, and is probably something silly such as CRC32, but I can't figure it out by looking at it. Any free image uploaded through the web-interface will need to have a correct checksum.
• There appears to be some switching of the code base address in the flash when the bootloader switches to the actual image. At least there is a duplicate set of ISRs, in fact all basic code such as add32, and those would need to be in bank 0. Any idea?

BTW: SAL stands for Software Abstraction Layer. HAL would be Hardware Abstraction Layer and DAL is data abstraction layer, because their SDK is for several different generations of chips.
Oh. And this here seems to be really nice fodder for ghidra, because they left the debug symbols in (it is a gcc-built amd64 kernel module):
https://github.com/BeeconMini/openwrt_v23.05.4/blob/master/package/kernel/rtl8373/src/rtl8373.ko. It allows to give meaning to what the functions do because of speaking names.

[debugthings]

There appears to be some switching of the code base address in the flash when the bootloader switches to the actual image. At least there is a duplicate set of ISRs, in fact all basic code such as add32, and those would need to be in bank 0. Any idea?

Yes, there is switching all over this codebase. There is a whole set of startup routines that would need to be analyzed. What I've seen is the data handling methods all exist in BANK0.

How is the checksum for the image calculated? The algorithm does not seem to be obfuscated, and is probably something silly such as CRC32, but I can't figure it out by looking at it. Any free image uploaded through the web-interface will need to have a correct checksum.

I found where they validate the rt_header->magicnumber and reversed the object. Here is the initial info for the header checksum. I have also found where it validates the paylod and I 'll do some analysis against the that soon.

In the SWTG118AS-v2 image from here in BANK3:5000 or file offset 0x1D000 there is a grouping of bytes that has the following data 12 34 56 78 00 0E 18 A0 00 00 04 C6 04 1D C2 60 33 22 55 FF

This translates to a c header like the one below. The algorithm I found calculates the header_chksum by adding all of the bytes in order of the structure. ie, 0x12 + 0x34 + ... + 0xFF = 0x4C6

I am looking to see if there is any special handling of the payload_chksum. But I suspect it's likely a CRC32 of some section. However you can easily fake it by

struct rt_header {
    dword magic_number = 0x12345678;
    dword length  = 0x000E18A0;
    dword header_chksm = 000004C6;
    dword payload_cksum= 0x041DC260;
    dword reserved = 0x332255FF;
};

[logicog]

Yes, there is switching all over this codebase. There is a whole set of startup routines that would need to be analyzed. What I've seen is the data handling methods all exist in BANK0.

I don't mean switching of banks, I mean switching of the base of the code in the flash itself. There is another Interrupt vector table at 0x1000 (the equivalent of what is at 0x0000) with a new set of ISRs and a new boot vector. This is activated when the bootloader switches to the full kernel. The flash memory area that is being checksummed starts there. What I don't understand is, how this memory address is set up as the new base address for the Interrupt vector table. Of course, maybe it isn't and the code continues to use the table at 0x0000. But that would lead to a strange mixture of the initital boot code and the updated image code.

I am looking to see if there is any special handling of the payload_chksum. But I suspect it's likely a CRC32 of some section. However you can easily fake it by

Does that mean that an image with that header will always be accepted, even if the checksum is incorrect?
BTW: did you get the email I sent to the outlook email address you use in your commits?

[namidairo]

Oh. And this here seems to be really nice fodder for ghidra, because they left the debug symbols in (it is a gcc-built amd64 kernel module):
https://github.com/BeeconMini/openwrt_v23.05.4/blob/master/package/kernel/rtl8373/src/rtl8373.ko. It allows to give meaning to what the functions do because of speaking names.

I'll take this chance to note that you may also wish to extract the 8372n kernel module from the firmware image of the TP-Link TL-7DR7260, which appears to have a great deal of the managed functions that aren't implemented in the BeeconMini module.

Should be a good reference for some of the things that may seem a little esoteric from just looking at register read/writes being dumped to serial out.

Edit: A similar prebuilt driver is available from asuswrt-merlin.ng, for those who can't access the TP-Link image. https://github.com/RMerl/asuswrt-merlin.ng/blob/main/release/src-rt-5.04behnd.4916/router-sysdep.rt-be92u/hnd_extra/prebuilt/rtl8372.o

[zuernerd]

The checksum for payload is also just a sum algorithm. You can see here how it is calculated: https://github.com/up-n-atom/SWTG118AS/blob/main/tools/calcsum.py

[logicog]

Thanks @zuernerd for pointing this out! This had not been clear to me for some time. We are working on building valid update images now, see PR #20 . So far, the image passes the calcsum.py test and the switch also accepts it as valid, but then it does not get permanently installed by the switch on the flash-rom. More hacking needed...