Reverse Engineering PowerPC - Dual Processor Firmware - Page 1
Forum section: electronics / general

author: canadaboy25
author_rank: Regular Contributor
timestamp: February 26, 2024, 03:58:34 am
content: Once in a while I like to do a bit of reverse engineering on random devices that I have to learn how they work, repair them, or look for hidden features.Thanks to the help of members on this forum, I was able to modify the firmware of a smart TV to bypass the LED backlight check. The TV is still working now.I've also entirely reversed the firmware for a laser level receiver running a PIC MCU and the firmware of an HC-12 wireless transceiver running a small ST MCU. Both of these devices had some pretty neat hidden features that were able to be activated by undocumented button presses or commands.Recently, I had an old agricultural smart GPS receiver fail. The receiver has all the processing circuitry built in and has its own firmware. The processing part of the receiver still seems to work as I can connect to it through the configuration utility, change settings, and update the firmware. However, it does not find any satellites anymore. It was manufactured in 2008 and is now obsolete so I have replaced it with a much more modern unit. Since the main processor still seems to work, I figured I'd dive into it to see if I could find some hidden features or at least learn something along the way.Opening up the unit, I can see it is run by a XPC823ECZT66BA PowerPC processor. It seems this chip has a MPC823e core. Also on the board is a S29JL064H70TF100 flash chip. I assume this flash chip contains the firmware. I removed the flash chip from the board, rigged it up to an FPGA, and dumped the firmware.The firmware image I dumped has 3 distinct sections. I've attached screenshots of binvis showing each section.- The first section is a small chunk of PPC instructions- The second section is zlib compressed data. Decompressing it results in more PPC instructions. I assume the first section is code that will decompress this data and load it into RAM, then execute.- The last section prompts my questions belowI cannot understand what this chunk of data represents. Binwalk does not give any results for it, and it is quite large (exactly 50% of the flash memory). The start address of this section of the flash is 0x400000. Below is a snippet of "strings" output on the file:NV040003.AAANV040001.BBBNV640001.BBBEEVBLOGEEVEEV-BLOGEEV-BLOGEEVBGEEVBLOGEEVEEV-BLOGEEV-BLOGEEVBGNV180001.AAANV180002.AAANV120001.AAANV120002.AAANV0E0001.AAANV0E0002.AAANV100001.AAAMy serial number/Unique ID shows up in this data several times. I replaced the occurrences of it with "EEVBLOGEEV", "EEV-BLOG", and "EEVBG". I've also attached a copy of this chunk of the firmware as a binary file with .txt extension.There are also many occurrences of what appears to be file names (??) repeated throughout this chunk.This is where I am stuck. I have searched through the MPC823e reference manual and am having trouble understanding the architecture. It states that the chip is a dual processor design, with a PPC core, and a communication processor unit as well. If there are two processors, where would the firmware for the other processor be located? Is this chunk the firmware for the second processor? I cannot see anything else on the board that looks like a memory chip.My experience is with much smaller, simpler MCUs, so this is a bit outside of my realm of knowledge. However, I'm eager to learn more about it. If anyone has any ideas what this data could be, or ideas on steps to take to figure it out, I'd appreciate it.

author: amyk
author_rank: Super Contributor
timestamp: February 26, 2024, 04:50:29 am
content: Looks like some sort of filesystem.

author: macboy
author_rank: Super Contributor
timestamp: February 27, 2024, 03:16:50 pm
content: Quote from: canadaboy25 on February 26, 2024, 03:58:34 amThis isn't a dual core CPU, but rather a CPU with a special type of co-processor, essentially a DSP. Typically, some task on running on the CPU will guide the execution of the coprocessor. It will put some data into memory (sometimes special fast shared memory) and tell the coprocessor to perform some computationally intensive work on that data, while the CPU is free to do other things. Given this is a GPS receiver, I'd wager that the complex geo-location calculations are done on the coprocessor.Nothing in the reference manual will tell you anything about this FLASH layout. This is a 32-bit PowerPC CPU. Most of these, when taken out of reset, will fetch and execute the instruction at memory address 0xFFF00100. That is all that you know. That memory address is ~ 1 MB below the top of memory.Typically, the system is designed so that there is some memory (ROM or FLASH) mapped to this address at reset, containing the rominit: a very small chunk of code to do minimal init of the CPU, RAM, maybe some other busses, in order to be able to load and execute a proper bootloader. The bootloader is more complex and can access the FLASH memory and filesystems in it, often can bring up ethernet for tftp/bootp network booting, etc. It will boot kernel (e.g. for Linux) or a elf or other monolithic image (e.g. for VxWorks). That kernel or image will then continue to init other hardware and start tasking. Note that loading a kernel or image may (and often does) include decompression. Obviously that's the one-paragraph short form of embedded booting on PPC, there is a lot more to it.I agree with amyk that the second half of the flash likely contains a file system. It will not be FAT or ext based, so look into FLASH file systems. Maybe Squashfs and/or JFFS2 as used in many small embedded linux systems (routers, NAS, etc.).One of the most basic things you should try to do is to find the serial console connection. Probably >90% of embedded systems will have one, but usually not externally accessible. It is very often on a 3 or 4 (or more) pin 0.1" header, which is itself often not populated, so you will only see bare pads or holes. A larger header, like 10 to 14 pins is likely JTAG. Probe with an oscilloscope the various possible pins for a few seconds after power up. You should eventually find a pin with a UART serial bit stream (commonly 115kbps, sometimes 9600 bps, occasionally other speeds).This can tell youso very muchabout the system: the bootloader used, the operating system, RAM, FLASH, memory map, and other hardware details, etc. Very often the bootloader will have a way to break the boot process by sending a specific keystroke at a specific time, and will drop into a primative shell (this is sometimes also called a monitor). The U-boot bootloader is common today, but given the vintage of that hardware, it is much less likely. It may be a custom job too. If you can drop into this shell, you can often do things like display a memory map, read and write memory, but most importantly, manipulate FLASH. There are usually utilities do display partitions, erase and write, and *maybe* to list files on a FLASH file system. Very often the operating system will also dump much information to the console as it boots, giving even more insight into the hardware and software environment. You may even get a usable shell after the O/S boots, which can be very powerful.

author: TomS_
author_rank: Frequent Contributor
timestamp: March 10, 2024, 12:52:17 pm
content: The firmware for the communications processor is internal to the CPU. You can't access it, or maybe there's a special/undocumented process to access it. But really you don't need to know much about it.All of the built in peripherals have configuration registers located within the internal dual port RAM, and the CP reads and writes these as required to operate the peripherals. The registers are all documented in the datasheet for the processor so it's very easy to figure out what is being done with them.These processors seem to be somewhat related to the earlier 68K/CPU32 based QUICC processors - they seem very similar in my experience, just replacing the CPU core with a PPC core to become the PowerQUICC line, and I guess some new/upgraded peripherals. On the earlier QUICC devices you could sometimes load small firmware blobs to add functionality, but these had to come from Motorola as I don't believe the tools to create them were available publicly.