Gremlins and ELF magic: what if the ELF file is a container?

We, the children of the 90s, love to add something old school to NeoQUEST . This year, we remembered the gremlins , and we added them to the legend of one of the tasks of the “Face-to-face” competition NeoQUEST-2017.

However, under the outwardly funny legend, there is quite a real practical task: what if the usual ELF files are not just executable files, but containers, which we will have to open? To do this, you will have to experience rather extensive objcopy capabilities and refresh the organization of the ELF file.

To calculate suspicious sections, it is necessary to present the sectional and segmental composition of a typical ELF. In addition, of course, experience will also come in handy - for example, communicating with the firmware of embedded systems may well suggest suitable ideas!
')
Think 100% ready? We are sure that the gremlins will be able to surprise you with hidden archives, corrupted tables of symbols, as well as with audio files that will sound only in the hands of a skilled master! Under the cut - the source code for the task and the passage, so that every reader Habra could personally try to complete the task!

Initial data to the task

The legend to the task looked like this:

Upon arrival, we found that on the basis of utter chaos and devastation. All this arranged a couple of local Aborigines, very similar to the gremlins from the famous earth film. One of them was clearly the main one in this small gang, bigger, more arrogant and talkative:
- Hehehehehehe, we had ate your message! Had ate this stupid gremlin! And will eat you!
The second, smaller and more modest, kept behind his comrade and shouted from time to time:
- The Gremlins Are Coming!

It seems that these scabs not only caused chaos and destruction, damaged the message left to us, but also devoured their comrade ...

The source data is three files: greik , straip and message .

Based on the legend, we understand that the most important file is a message, and you need to listen to it. But, of course, it does not work (otherwise what is the meaning of the task?). If you run it, we get the following information:

Sorry, but I'm lost my prepare section ...

To fix our message, you need to "gut" two gremlins, which are all
"Gnawed", including, and his friend. Run each file. After ./greik we will see:

The Gremlins Are Coming! (original quote from the movie, by the way!)

After ./straip:

Hehehehehehe, we had ate your message! Had ate this stupid gremlin! And will eat you!

That is, everything that is described in the legend. Once these gremlins have eaten everything they need to complete the quest, you need to see what's inside! Apply the readelf utility to both files. We will be interested only in sections of the file and information about them, so you need to use the -SW flags. As a result, we get for straip:


Pay attention to section 28, stomach (stomach!). Let's take her. For this you can
use either the dd utility , calculating all necessary offsets, or the objcopy utility as follows:

objcopy -O binary --only-section=.stomach --set-section-flags .stomach=alloc straip stomach 

We will perform similar actions for the greik file. Issuing readelf -SW:


Dumping sections 28 and 29 (.first_stuff and .second_stuff):

 objcopy -O binary --only-section=.first_stuff --set-section-flags .first_stuff=alloc greik first_stuff objcopy -O binary --only-section=.second_stuff --set-section-flags .second_stuff=alloc greik second_stuff 

Let's see what we have here have removed. To do this, use the file utility for each of the extracted files. As a result, we get:

stomach: zip archived at least v2.0 to extract
first_stuff: data
second_stuff: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

Unzip the stomach and, using the file utility, see what kind of files we received:

sec1: data
piece2: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
key1: ASCII text

Hurray, received the intermediate key key1 ("ISCJcPhB33cAvq9F9YkaZyU91SfwSObn")! The remaining files are needed to further solve the problem. The message source file reported that sections were lost from it, and we extracted a file named sec1 from the archive.

Apply the readelf utility to the message:


We see that there is a section .extract (16) of size 0x50 (80). We also have one of the 0x50 files extracted from gremlins - first_stuff. Restore this section:

 objcopy --update-section .prepare=first_stuff message 

Run the message again:

Preparing data for extract ...
Preparing data successful
Sorry, but i'm lost my extract section ...

He lacks another section. By analogy with the previous section, we restore this one too:

 objcopy --update-section .extract=sec1 message 

Run the message again:

Preparing data for extract ...
Preparing data successful
Extracting key data ...
Extracting complete successful

All done. As a result, we received an audio file message.mp3. However, if you try to listen to it, we will hear only silence, because the data is zero. Recall that straip
told us that they ate another gremlin, and we still have two unused files in ELF format.

Running them will not give anything but an error:

Failed to execute process './second_stuff'. Reason:
exec: exec format error
The file './second_stuff' is marked by the operating system.

This is all because these objects need to be linked to each other:

 gcc second_stuff piece2 -o gremlin 

As a result, we get:

piece2: In function `main ':
gizmo.c :(. text + 0x5b): warning: the `gets' function is dangerous and should not be used.
gizmo.c :(. text + 0x86): undefined reference to `get_back_function '
collect2: error: ld returned 1 exit status

And again, everything is not as it should be! Use the readelf utility on our “chunks” of a gremlin, but this time we will look at the symbol table (the -s option). For second_stuff:


For piece2:


We see that in one of them there is our function get_back_function, on which the compiler was cursing, and in the second there is a certain function with the name “a4f922hjd9843jd”. Rename it to get_back_function:

 objcopy --redefine-sym a4f922hjd9843jd=get_back_function second_stuff 

Try again to build the file:

 gcc second_stuff piece2 -o gremlin 

piece2: In function `main ':
gizmo.c :(. text + 0x5b): warning: the `gets' function is dangerous and should not be used.

As you can see, now everything is fine. Run gremlin:

Hello ... I tried to remember your name ...
>>

The guy seems to be a good one: he tried to save our message, for which he suffered. Ready to return everything to us, but I just forgot my name. His name is Gizmo (the original name of a good gremlin from the film). This can be seen both during the build process and in any HEX editor at the very beginning of both the original object files and the gremlin file itself.

Let's enter his name (with a capital letter, of course!), Iiii ...

Hello ... I tried to save my name ...
>> Gizmo
Yes, yes! It's my name! Get back your part of file!

As a result, we get another data_section file. It is easy to guess that we also push it into the original message file:

 objcopy --update-section .key=data_section message 

This section .key could be noticed even when we examined the message file with the readelf utility. First, the name she says, and secondly, the size coincides with what Gizmo returned to us.

By running the message file again, we will already receive a normal message that can be
to listen to . It says that we need to take the md5-hash from this file and this will be the key. Take md5 and get the key: 65935b0ae91b566c14c8b584ee8cf85d .

Happy End!

It turns out that an ELF file can be far from just an executable file, but a container for something. This task could have been completed by reversing the binaries, but not by reversing the information masters are strong!

In this embodiment, the passage is quite a few simple manipulations - and the ELF puzzle successfully completed, sections and symbol tables restored, archives unpacked, and our gremlins have nothing left but to change the impressive “The Gremlins Are Coming!” To a white flag and issue the long-awaited the keys!