Good day to all. Last week the next full-time stage of NeoQuest ended . So it's time to publish an analysis of some tasks. I know many have been waiting for this analysis, so I ask all those interested in a cat.

Hellish reverser - my amplua!

In the task we are offered to download the binary, and get acquainted with its source code, to search for vulnerabilities in it, download and unpack it.
')
There is only one directory in the archive, and as it is not difficult to guess, it contains the source code LUA , taken with git . We look at what has been changed:


As you can see, the new file larray.c was added, which apparently contains the vulnerable code. Well, now let's try to determine the location of the flag. Having connected to the server and pressing TAB twice, we can see in the current directory the file FLAG __. TXT

OK. Challenge accepted.
In LUA you can probably execute console commands or just try to open the file. However, not everything is so simple, not only was the new file added to the source code, but some functions were also excluded:


But looking at the changes in the makefile, you can see that the TESTS module was left on purpose or by mistake.

Googling how it can be used, we arrive at a simple code to extract the flag:

 L1 = T.newstate() T.loadlib(L1) a,b,c = T.doremote(L1, [[ os = require'os'; os.execute('cat FLAG__.TXT') ]]) 

What the code does:

1. First we initiate a new test context.
2. Then we load libraries for working with FS.
3. And through doremote we execute system commands in a test context.

After execution we get the key: c91a8674a726823e9edad1a4262da4be7f216d74

QEMU + Ecos = QEcos

This year, it was also not without assignments with QEMU . In the task 2 keys are hidden, having found which it was possible to receive +200 points. Let's start:
After downloading all 3 files, let's start studying them:


The first thing you have to deal with is a modified order of bytes in the dump; it is easy to determine this by running the command:

 $ strings dump.bin .... :CCGbU( utnu3.6 1-0.ubu22utn.6 ) 0.371026040 

In Python, this is solved quite simply:

After the conversion, you can work with the dump:


And so, we have 2 eCos images and a header, the images are separated by zeros between them. through dd cut it into 3 parts, they will be needed later.
But at the beginning, we will try to launch the first image to find out what is required of us:


After downloading, you need to enter a password, and if it turns out to be wrong, we get the message: AUTH FAIL
Unpack the image and send it to IDA. Further by cross-references we find a function that displays an error message:

We rise to the level above, where we see 2 conditions under which the test fails:

Things are easy:

• Patch these transitions
• Archive the ecos.bin file and paste it into the unpacker
• Using the mkimage utility we build a new image for u-boot
• And check the result

After launching a new image to any password, we receive a message with a string that needs to be entered into the u-boot:

Auth process started ...

===============
=== AUTH OK ===
===============

use this key in u-boot: 4a2 # * a11gpiun% 25

Enter and get another key (previously taking from the line sha1 hash): ddf5957cd43a3712e0c67d019a37223043ae6df5

PS As it turned out later, there was a race condition type vulnerability - it was necessary to change the combination while checking it

With the second key, everything is a little more complicated. If you try to run the second image (for this you need to collect the dump in this order: header -> image2 -> image1, or simply change the boot parameters in the u-boot), then the image will not load, but will swear at the wrong CRC32 value:


After a long search, as well as comparing the image size and the number of entries in the log, we find the following:

1. Each block in the log is long: 0xE1
2. Total blocks: 0x48D1
3. A critical error has occurred in block 0x2580
4. It began with an offset in the block: [0x44, 0x47) i.e. 3 bytes

Comparing the dimensions of the block with the real position in the dump, we determine that in the second image the archive ecos.bin.gz is damaged. There is nothing left but to truncate the missing 3 bytes, having the original CRC32 image and the position in which the error occurred.

Using the simplest script, run the brute force, and after some time we get the right combination. Then you can collect the dump and run it, or just unpack the image and use grep to find the desired line:

 $ strings ecos.bin | grep KEY KEY: xs26k=b$km*8_mNf 

Taking from the received line sha1 hash, we get another 1 key: 35f6e7d0d65097f29ad74a7aaf991f2166b0a492

Specter

Here the authors became very confused and suggested that we find and correct the so-called typos in the code. I will give a list of corrections right away, and then I will tell you how they could be found:

Errors # 9 # 10

At the very beginning, the function check_cpu () is called in the main function at the address: 0x000000013FE517E7 :


Here there is a check that the processor model matches, but the string with which the comparison is made is erroneous. In debugging, we see that the value should be correct: GenuineIntel

Error # 11

Being in the function of generating the first key, we see that it is based on the string: A docatca cells. Google search, prompted, its correct spelling: A hecatonicosachoron or 120-cell is a regular polychoron having 120 dodecahedral cells.

 .text:000000013FE53323 lea rax, byte_13FE57030 .text:000000013FE5332A lea rbp, aAHecatwnicosac ; "A hecatwnicosachoron or 120-cell is ar"... .text:000000013FE53331 sub rbp, rax .text:000000013FE53334 mov eax, 1 

Error # 5

If you look below, we see the function call at the wrong offset:

 .text:000000013FE5337D call near ptr sub_13FE53070+3 .text:000000013FE53382 movzx ecx, [rsp+48h+arg_0] .text:000000013FE53387 inc rbp 

Error # 1

In the function at the address 0x000000013FE51390 , a second key is generated:
During debugging, you can see that the conditional transition, after generating the first part of the key, is not true:

 .text:000000013FE513B9 mov rbx, rax .text:000000013FE513BC call sub_13FE53460 .text:000000013FE513C1 test eax, eax .text:000000013FE513C3 jnz short loc_13FE513C9 

Error # 2

The next thing that catches your eye when further viewing this function is not a valid offset when calling a function that accesses the registry:

 .text:000000013FE513EF call near ptr get_SoftwareType+1 .text:000000013FE513F4 test eax, eax .text:000000013FE513F6 jz short loc_13FE51415 

Error # 6

Going deeper into the get_SoftwareType function, and checking the arguments of the RegOpenKeyExA function, we understand that the value: 0x80000003 does not explicitly correspond to HKEY_LOCAL_MACHINE :

 .text:000000013FE536A9 lea rax, [rsp+0D8h+hkey] .text:000000013FE536AE lea rdx, SubKey ; "SOFTWARE\\Microsoft\\Windows NT\\Curren"... .text:000000013FE536B5 mov r9d, 20019h ; samDesired .text:000000013FE536BB xor r8d, r8d ; ulOptions .text:000000013FE536BE mov rcx, 0FFFFFFFF80000003h ; hKey .text:000000013FE536C5 mov [rsp+0D8h+var_90], 64h .text:000000013FE536CD mov [rsp+0D8h+phkResult], rax ; phkResult .text:000000013FE536D2 call cs:RegOpenKeyExA .text:000000013FE536D8 test eax, eax 

Error # 7

Scrolling through the function of generating a second key, to the next part, we see an attempt to get the home directory for the explorer.exe process, and it seems to be nothing ordinary, but from the documentation, you can see that the access mode is not specified correctly, and should be 0x410:

 .text:000000013FE53871 mov r8d, [rsp+278h+pe.th32ProcessID] ; dwProcessId .text:000000013FE53876 xor edx, edx ; bInheritHandle .text:000000013FE53878 mov ecx, 100000h ; dwDesiredAccess .text:000000013FE5387D call cs:OpenProcess .text:000000013FE53883 mov rbx, rax .text:000000013FE53886 test rax, rax 

Error # 3

When debugging a function that generates the third key, we note that another incorrect conditional transition, as a result, does not take into account the response from the executable call from resources:

 .text:000000013FE514B1 call load_exe .text:000000013FE514B6 mov rdi, rax .text:000000013FE514B9 test rax, rax .text:000000013FE514BC jnz short loc_13FE514D7 .text:000000013FE514BE mov rdx, [rsp+28h+a2] ; a2 .text:000000013FE514C3 mov r8, rbx ; out_hash .text:000000013FE514C6 mov rcx, rax ; a1 .text:000000013FE514C9 call calc_sha 

Error # 8

If you extract the tmp.exe file from the resources, then after a quick study it becomes clear that the only argument with which it works is -p :

 .text:000000013FE51147 call memset .text:000000013FE5114C xor eax, eax .text:000000013FE5114E lea rdx, CommandLine ; "tmp.exe -t" .text:000000013FE51155 mov [rsp+118h+ProcessInformation.hProcess], rax 

Error # 12

When trying to extract the tmp.exe file from resources, we notice that it does not have a valid header, we fix OK on MZ and everything works:

Error # 4

It is strange that the second key completely duplicates the first one, because, as we remember, the result should be in the r15 register:

 .text:000000013FE51872 call key2 .text:000000013FE51877 mov r15, rax 

But this is not all in the process of debugging and patching, we stumble on a couple of protective measures. The first is the Explained IsDebuggerPresent :

 .text:000000013FE517EE jz short loc_13FE51844 .text:000000013FE517F0 call cs:IsDebuggerPresent .text:000000013FE517F6 test eax, eax .text:000000013FE517F8 jz short loc_13FE51856 

The second is to check the integrity of the file based on the sha1 hash:

 .text:000000013FE516C3 mov dword ptr [rbp+original_hash], 0D8086BF9h .text:000000013FE516CA mov dword ptr [rbp+original_hash+4], 0AA45EFE5h .text:000000013FE516D1 mov dword ptr [rbp+original_hash+8], 492519ECh .text:000000013FE516D8 mov dword ptr [rbp+original_hash+0Ch], 212C9756h .text:000000013FE516DF mov [rbp+var_30], 5BB58EA1h .text:000000013FE516E6 mov byte ptr [rbp+hash], bl .text:000000013FE516E9 mov [rbp+hash+1], rax .text:000000013FE516ED mov [rbp+var_17], rax .text:000000013FE516F1 mov [rbp+var_F], ax .text:000000013FE516F5 mov [rbp+var_D], al .text:000000013FE516F8 call calc_sha .text:000000013FE516FD mov rax, [rbp+hash] .text:000000013FE51701 cmp rax, qword ptr [rbp+original_hash] 

The integrity check function can either be scored by nop-s, or at the very end simply correct the original hash.

After all these changes, we immediately get all 3 keys:
First key: 2A 93 E7 6A F5 BB E0 92 83 E5 99 E6 63 6D 04 1C 95 9B 3C D7
Second key: B2 D7 CC 3F 58 03 EB C6 4D 14 8E A6 AB 2E FC 10 DE B1 45 8D
Third key: DB 0D 81 6E 50 63 BA 13 65 2F 35 7B 1F 7C E9 FC 1E A1 C1 C6