Flare-On 7 – Task 10

Stage 3

We know the flag is not complete… But where to go next? This is how the last part of the code being executed looks (the handle called on truncate ):

We can see the last thing executed is some callback function. I named it call_mem0, because the pointer was earlier initialized with 0. So it seemed to be again a call to MEMORY[0] – which is supposed to be handled inside the grandchild:

But it doesn’t seem correct… And indeed, after hooking strncmp I confirmed that the execution never reaches here. So, there is another overwrite somewhere… But where?

The thing that may raise some suspicion, is that a buffer that is processed in the previous part is 40000 bytes long… It turns out the buffer that is being filled here is to small to contain the data that is being copied into. As a result, the pointer (call_mem0) gets overwritten, and no longer holds the 0 value, but the pointer to the shellcode. So, the next stage is executed in an unusual way – by a buffer overflow.

To get the code that is going to be executed next, we need to dump the buffer that is passed into truncate function. I did it using again LD_PRELOAD and overwriting truncate with my own function (code available here) that just dumped the binary. Then I copied the binary string into a hexeditor.

Inside the buffer we can see the shellcode that is going to be loaded now:

We can extract this code and load it into IDA. And hooray! This time no nanomites or other obfuscation whatsoever. Just a simple code that we need to clean up a bit. At the end of the shellcode there are some strings, that are then referenced by their offsets. I filled them in the IDA view:

We can also see this shellcode will access the buffer that was filled by the original executable, by using its absolute address (yeah, the original binary is not going to be relocated). The strings are some long hexadecimal numbers. At first I thought they may be hashes, but after analyzing how they are used, it turned out that they are just long integers initialized by strings.

So, there are some operations performed on those big integers. I didn’t want to analyze those functions statically (as it was laborious), but I wanted to understand what operations do they represent. To find out, I decided to export them and call from my own wrappers. It can be done using various emulation frameworks, but since this is still x86 code and containing nothing Linux-specific, I decided to make a wrapper app on Windows. I loaded the shellcode in the executable memory, referenced functions by their offsets, and applied them on my own buffers. Calling convention of the functions was atypical, so I had to call them via wrappers with inline assembly. Example:

//_DWORD *__usercall sub_89F@<eax>(_DWORD *a1@<eax>, int a2@<edx>, int a3@<ecx>)
signed int op_set_value(void* a1, int a2, int a3)
{
    BYTE *func_offset = (BYTE *)(0x89F + (ULONG_PTR)g_Buf);
    __asm {
        mov eax, a1
        mov edx, a2
        mov ecx, a3
        call func_offset
    };
}

It turned out to work pretty well for identification of the basic operations.

Yet, some parts were missing. I’ve got a hint to search for a big int library that was used in this code. It is the following library: https://github.com/kokke/tiny-bignum-c . Knowing this, the reconstruction of the full code turned out much easier. This is the final result that I’ve got:

At this point we can see that the next part of the flag is verified by being input to and equation. The result of this equation is then compared with the hardcoded big number.

One of the numbers seems to be dynamically generated – calculated from a random buffer. But after loading the shellcode to my wrapper and making some experiments with various random inputs, I found out that the result is unaffected by the input: “c10357c7a53fa2f1ef4a5bf03a2d156039e7a57143000c8d8f45985aea41dd31”, so we can use this number just as a constant.

The full equation is:

                                                      
(input * "c10357c7a53fa2f1ef4a5bf03a2d156039e7a57143000c8d8f45985aea41dd31")
% "d1cc3447d5a9e1e6adae92faaea8770db1fab16b1568ea13c3715f2aeba9d84f"        
= "d036c5d4e7eda23afceffbad4e087a48762840ebb18e3d51e4146f48c04697eb"

We are dealing here with a simple asymmetric cipher, related to modular arithmetic on co-prime numbers.

equation:
(inp * a) % b = c

The formula to reverse this equation is:

solution:
inp = inverse(a, b) * c % b

For the required calculations I used the following online toolkit: https://www.boxentriq.com/code-breaking

  1. Finding the inverse:
inverse(a, b) =
inverse(c10357c7a53fa2f1ef4a5bf03a2d156039e7a57143000c8d8f45985aea41dd31,
d1cc3447d5a9e1e6adae92faaea8770db1fab16b1568ea13c3715f2aeba9d84f) =
7d6990db0059850d8e02937be5e2ac7b9dfe6411de316c1e462762c24d647b5c

2. Calculating the solution:

inp = inverse(a, b) * c % b = 7d6990db0059850d8e02937be5e2ac7b9dfe6411de316c1e462762c24d647b5c * 
d036c5d4e7eda23afceffbad4e087a48762840ebb18e3d51e4146f48c04697eb % 
d1cc3447d5a9e1e6adae92faaea8770db1fab16b1568ea13c3715f2aeba9d84f =
6d6f632e6e6f2d6572616c6640733369707075705f306e5f

Now we need to convert it into ASCII (I did it by just pasting to a HxD hexeditor):

The string just needs to be reversed, and we’ve got the final part of the flag!

w3lc0mE_t0_Th3_l4nD_0f_De4th_4nd_d3strUct1oN_4nd_n0_puppi3s@flare-on.com

If you finished reading this post, please share your feedback leaving a comment below!

About hasherezade

Programmer and researcher, interested in InfoSec.
This entry was posted in CrackMe and tagged , . Bookmark the permalink.

1 Response to Flare-On 7 – Task 10

  1. 0xstan says:

    Great write-up !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s