Hard Reverse or features reverse files for PowerPC architecture Big-Endian

Tasks for reverse engineering are an essential part of any CTF, and NeoQUEST is no exception in this regard. In each task, we add a “zest”, which, on the one hand, somewhat complicates the participants to complete the task, and on the other, it allows us to deal with what we haven’t worked with yet.

If we talk about the "highlights", then the task of the online-stage NeoQUEST-2017 of the planet Endian "Crew Rescue" is practically a cupcake! Welcome to the cut, to the very jungle of the reverse: let's talk about the PowerPC Big-Endian architecture and a little about QEMU !

And we remind you that NeoQUEST 2017 will be held in Petersburg on June 29 : reports, workshops, contests, prizes, a great time and free entry when registering on the site - everything is for you! Read more about what will be included in the program "confrontation", read here and on the site!

Where to begin? From the legend!

So ... While the spaceships were plowing through the universe, the participants of NeoQUEST found themselves on the planet "Endian" and "discovered the ship of the last expedition, the one that was considered to be missing without a trace!". Already not bad! And it's nice to know that in space, too, use IP-addresses.
')
We read carefully the legend and get the following information:

1. IP address of the on-board computer 213.170.100.211
2. "Special" file 1_8139.rom
3. A PowerPC Big-Endian Binary 2_quest.cod_data

First of all, we drive this IP address into the address bar of the browser and drive it!


The name of the tab immediately gives the first hint. Somehow QEMU is used here. Mentally put a tick in order not to forget, register and load the file 1_8139.rom.


What is going on? A screenshot is displayed, apparently from the qemu virtual machine, in the screenshot - please enter the password. However, how to enter it? All that we can do is load a strange file, although ... SeaBIOS and Booting from ROM ... Those who worked with QEMU have probably already guessed what kind of file we are loading. But for the sake of purity of the experiment, let's try to set the file command on it.


Thus, it turns out that our 8139 file is a BIOS ROM Extension or PCI Expansion ROM.
If you try to load an arbitrary file, here is the output we will have:


It seems that the first 3 bytes are checked. Well, this is not a problem - we put the first three bytes, as they ask, iii ... Nothing! Same. How so? But the fact is that if the file is not in the format of PCI Expansion ROM, then qemu will simply not launch it. And judging by the assignment, there is also some kind of signature. We will understand further.

PCI Expansion ROM

What kind of animal is this? PCI Expansion ROM is a special piece of the initialization code of a logical PCI device, usually stored either in the BIOS or on a PCI device chip. One of the most common use cases is the implementation of the network boot (PXE) mechanism. If you want to see how this happens, we run qemu without parameters, and after the attempt to boot from CD / HDD fails, qemu will show you PXE.


We decided on the type of file, let's look at its structure.


Under x86, PCI 2 is allocated the first 2 bytes to the 0x55aa signature, the third byte indicates the size of the module (PCI ROM size = 3 bytes * 512), the fourth byte is already the executable code. In most PCI ROMs, if not all, this is the usual jump to the initialization code.

Oh yeah, I almost forgot: since this is quite an old technology, and it was used before the time of UEFI, then all the code is 16-bit Real Mode.

Next, bytes 0x18 indicate the offset of the PCIR structure, and 0x1A indicates the PnP structure. These structures are of an official nature and carry basic information about the PCI ROM module.
The attentive reader will notice that the vendor and id device just correspond to the reltek 8139 network card. It was her module that was taken as the basis.

Of these structures, PnP is of the greatest interest. It contains interesting fields such as checksum and bootstrap entry.

Bootstrap entry indicates the code to which control is transferred when you try to boot from this device. In this case, it looks like this:


And, as we see, it is very similar to our screenshot, it means that we are on the right track! Now all you need is for the NOP password verification procedure and try to feed the modified webcam file.

Do not forget that we have a checksum field in the PnP structure. How is cheksumma considered? It's simple - initially it is put in 0x00 and the sum of the bytes of the file is considered. Then the resulting amount is subtracted from 0x100. So we get the value we need. Why 0x100? Because cheksumma single-byte. The fact is that the sum of all bytes during the test should show 0x0. That is, if the sum of bytes showed us 0x10, the value of the checksum will be 0xF0.

It is clear that when the module is loaded, it runs in qemu. But nothing prevents us from trying to also use the qemu -option-rom command 1_8139.rom

If everything is done correctly (patch ROM and cheksumm right), then this ROM will simply return control to the BIOS. We try in webcam ... Success! Something new has appeared:


Read CRC? Another cheksumma? Well, at least the line hints that we are using the CRC (and therefore XOR) to verify the module. Find this value in the module.


Almost the very end of the file. We know the place, now it remains to understand the CRC signature algorithm. Or at least find a polynomial, and then you can go through the options. On assignment we are given some PowerPC Big-endian. No need to scare us with all sorts of PPC, we are so scared. Take IDA Pro, HEX-editor, and go!

The file size is quite large, so the decision "in the forehead" is hardly appropriate here. Let's try to search for the hooks that we have: the CRC algorithm and the message “CRC error”. To begin with, we will find error messages, here the utility strings will help us.


Fine! Everything is there, but why 2 times? We will understand! We look in the HEX-editor or in IDA.


We found the line, and at the same time the other error messages. And also - look carefully! - before each error message we have 2 bytes, and very similar. Well, 0xFFFF (or -1) puts everything in its place. This is an associative array of error messages. Create a structure in IDA Pro and get just such beauty:



Now, following the logic, all this code uses error codes. However, we have 2 hits - error code 0x1604 and 0xA04. Well, we will look both.

0x1604

We are looking for a 0x1604 mention in IDA:


Great, 2 hits. We look!


This code validates the CRC. For convenience, we immediately denote the function call at address 0x42944 as crc_1604 and remember that the function returns the value through the R3 register. The register R29, most likely, stores the recorded value of the CRC, and in the register R0 - the calculated value of the CRC. This becomes clear after viewing the function code crc_1604:


A small function, only it does not look like a CRC. There is no polynomial here, but the usual byte XOR is used! It immediately becomes clear that the code 0x1604 is for single-byte pseudo-CRC. And it is also clear that the calculated value is returned via R3 to the calling function, and, most likely, the CRC should be compared either with the previously recorded one, or the CRC should be zero. Here are the two most common integrity checks.
Well, it follows from this that we need the code 0xA04 - we look!

0xA04

Similarly, we are looking for a reference to 0x1604 in IDA:


Oh, just one function, we are lucky!


So what can be seen? The code 0xA04 is set only if the register r3 is not equal to zero. So, the function at 0x229c8 is our client!


Immediately pay attention to these parts of the code! And yes, it also uses the usual XOR, only 4 byte. If you analyze the function in detail, you can find some conditions that are imposed on the file being checked. But we do not need it, because we have the file format, and we need only a signature mechanism. We found it! Normal XOR 4 bytes.
Especially non-believers can show an approximate decompilation of this site (thanks to retdec.com ).


It remains only to write the CRC count and go for the key! We write the cherished lines of code a-la while (size--) {crc ^ = * input ++;} and replace the value at the end of the PCI ROM file. Do not forget to change cheksummu, iii ... We are the champions!

At the "confrontation" will also be interesting!

While doing this task, we bit into nostalgia and remembered the times when the MacBooks were on PowerPC, because not only Intel had a beautiful and diverse world!

Participants in the hackquest final competition on June 29 in St. Petersburg will have a wide variety of tasks in which, in addition to reverse, knowledge of steganography, cryptography, the ability to conduct OSINT , work with “horned green monsters” (this is, of course, about Android) and many much more!