Blackhoodie17, of reverse and women

Filter by category:

December 13, 2017 by Nha-Khanh Nguyen
Digital Security at Blackhoodie17

Blackhoodie17, of reverse and women

"Because a girl-to-girl conversation is so much more fruitful than a full classroom with only one or two women hiding in the corners." These are Marion Marschalek (@pinkflawd) words, organizer of the Blackhoodie workshop which, since this year, has become a real bootcamp. Taking place in the CIRCL's office in Luxembourg for its 3rd edition, the event focused on Reverse Engineering hosted from Friday 24th to Sunday 26th November 2017, a little less than 70 apprentice female reversers and even initiated ones. From all over the world and from lots of IT domains, developers network architects, cloud, data scientists, reversers and also lawyers gathered at this place. All share a common interest: the desire to be able to pown some malwares at the end of the weekend.

As you understand, this is a reverse engineering women-only conference. But still, Marion explained this choice  in her blog and during the HamburgSides 2015. Being a minority is not always simple, especially in an ultra-technical field like Reverse Engineering. It is by teaching in front of an assembly with a majority of males (class, workshop, conference) and by her own experience as a woman in the field that the idea of Blackhoodie came to her mind.

So that's how I ended up getting involved in a weekend with girls, who thought this would happen to me, not quite ordinary...

Badges
Blackhoodie badge and booklet... But what are those hexadecimal characters in the background?


Lots of interesting presentations

11h, at the CIRCL office, the morning began with some short presentations by some participants from previous editions (but not only), to share a project, feedback or even a knowledge transfer. Here is the agenda:


Flash dumping - Kylma (@_Kylma)

Kylma explained in her presentation how to dump a chip. To do so, she explaied in detail the steps of her project to extract the chip from the initial card, thanks to a "badass hairdryer", to the drawing and manufacture of a PCB she designed to receive the chip in order to dump the firmware easier.
 

Malware analysis using logic - Barbie Auglend (@barbieauglend)

Quite often, during a malware analysis, most people are going headstrong off on the code analysis and its behavior. Barbie gave us another vision of binary analysis using logic, thanks to a SMT solver.
 

Monitoring Engineers with the Cloud - Carly Schneider (@_5chn31d3r)

Carly Schneider told us about Google Cloud Platform, an alternative solution to AWS. The problem is that there are no tools dedicated to server security. Carly then told us how her team started to implement their own tools and then gradually came to work with Google. The fruit of their collaboration gave birth to Forseti, a security tool for better project management on CGP.
 

Sandbox evasion - MyShelle

MyShelle exposed us the different methods of sandbox evasion using Powershell and PS2EXE or thanks to obfuscation with strings manipulation, adding some junk code. However, the last method only works with dynamic analysis. It is important to combine dynamic analysis with static analysis if you want to effectively study malware.
 

Network forensics - Essy (@casheeew)

Using BadRabbit as an example, Essy illustrated the network-oriented forensic analysis of the malware. Thanks to a lab made up of two virtual machines, Essy showed us how malware infects one of the VMs through packet analysis on Wireshark, and then infects the second machine via the SMB/CIFS shares.

SIMtrace - Chrysh (@chrysh4)

Chrysh presented her research project carried out during her Bachelor's thesis: the modification of an Osmocom SIMtrace into a sniffer and emulator of an old Nokia or Motorola phone.


Kernel Shim Engine - Gaby (@pwissenlit)

In this presentation, Gaby introduced us to a relatively recent component in the latest Windows systems: the shim kernel shim engine. Shims, used in Windows backward compatibility, are usually userland side. Here, it is a similar component but kernel side. Gaby then explained from A to Z how these shims work, what they are used for and how to create them.

Malware analysis for policy muggles - Mara (@marasawr)

Finally, Mara told us about the vision of policies and how malware research and weapons of mass destruction are often being confused, often talking about cyberwar and attribution in APT attacks.

Some of these talks are now available at https://www.blackhoodie.re/archive/.

Présentations
Kylma introducing flash dumping on PCB. Photo credit:  Securitymadein.lu


Things are getting serious...

The first day began with the analysis of a compressed binary. Marion started introducing our best friend of the weekend: IDA pro. A first presentation of the tool and its multiple functionalities was then given: the display of decision blocks, implemented functions, imported Windows libraries...
 
IDA présentations
Marion Marschalek explaining a binary disassembled on IDA. Credit photo: @S_I_NI

Thereafter, the event took the form of a workshop where each participant tried to understand how the binary works. We set breakpoints, we executed the binary, we oberseved. Under Marion's advised tips and tricks, participants learned to decompress a binary gradually. Then the analysis. Analysis is requires a lot, lot of patience (arm yourselves with your painkillers, you'll need it). "We spent an eternity to find a little piece of information. This is a reverse engineering, yay!"
 
The second binary we tried to understand was an IRC botnet. You had to navigate through the available functions and understand the sequence of instructions. In reality, there is no need to understand each instruction line by line. The most important thing is to understand the functioning of each block and their logical sequencing. Reverse demands also a lot of Microsoft's MSDN documentation aimed at facilitating the understanding of the Windows calls function made in the code and the identification of the reasons why they are invoked. The diversity of each profession allowed us to progress in complementarity on the exercise, each one bringing their own specific knowledge: developers for the understanding of the algorithm induced by the C code and stack manipulation, forensic investigators for the common mechanisms and Windows artifacts used in malware, network architects for the connection mechanisms to servers, etc.

While some of the participants enthusiastically absorbed the rudiments of the art of disassembly, advanced workshops for former participants took place in parallel at the back of the room. The following workshops took place on Saturday and Sunday:

Advanced workshops
_Noutoff showing symbolic execution with MIASM. Crédit photo: @barbieauglend_

Nice meetings and fruitful discussions

In the end, what should we remember from this weekend staring at assembly code to death - as Marion Marschalek says so well? First, the initiative of a conference on reverse engineering was generally very well received and welcomed by the ITsec community. While she was able to help some of the participants to blossom or find themselves in this very masculine environment, Marion was also able to pass on her knowledge and passion for reverse engineering to all who didn't know how to approach the beast. In addition to this, the event was also a real meeting place for multicultural encounters resulting in extremely rich exchanges concerning social and knowledge-sharing points, which could take down all the clichés about women that we can still hear. It has also enabled some of the participants to make their first talk at a technical conference and dabble in their first workshop, to finally cross the line of the international conference in a near future, where we are looking forward to hearing them.

And about this hexadecimal string?

As in every good ITsec conference, when you put in the hands of aspiring hackers something that seems to be a computer code, you can be sure this will end up in everyone's favorite disassembler.

After a few minutes of labor and one less retina (because with black writing on a dark green background, the OCR doesn't work very well, but neither do our eyes), we extract the following hexadecimal chain:

90 90 90 90 55 48 89 E5 48 89 7D E8 48 89 75 E0
89 55 DC 8B 45 DC 89 45 FC EB 2F 8B 45 FC 48 63
D0 48 8B 45 E0 48 01 C2 8B 45 FC 48 63 C8 48 8B
45 E8 48 01 C8 0F B6 00 89 C1 8B 45 FC 29 C1 89
C8 83 F0 42 88 02 83 6D FC 01 83 7D FC 00 79 CB
48 8B 45 E0 5D C3 CC CC CC CC 00 00 00 00 6F 75
74 70 75 74 20 3D 20 01 36 32 24 29 2C 21 2F 33
55 23 1C 22 1D 15 17 52 21 14 10 4E 0C 09 1F 54
57 56 47 5D 4E
00 00 00 00 00 00

Immediately, we notice a repetition of the number 90 and some patterns here and there. Experienced reversers that we are now, we think that it was probably a NOP-sled, maybe even a payload written in ASM? Let's disassemble all that.

Hexa disassembled

At first sight, it seems not to be a payload but a function. We can observe after what seems to be at the beginning a NOP-sled, the prologue of a function.

push   rbp
mov    rbp,rsp

When calling a function, the actual address is saved into the stack in order to go back to it at the end of the function called, and then continue the program.
We notice 3 arguments are passed into the function:

mov   [rbp-24], rdi
mov   [rbp-32], rsi
mov   [rbp-36], edx

The use of the rdi, rsi and ecx registers shows that the code maybe be compiled for a Linux x64, according to the convention. So we have our fist argument, rdi at the [rbp-24] address, address, the second at the address [rbp-32] and the third at the [rbp-36] one.

We also identified a loop. The fisrt jump instruction jmp     short loc_46 leads us a value test:  dword ptr [rbp-4] compared to 0 and followed by a second jump jns     short loc_17. While the value in the dword ptr [rbp-4] address is not equal to 0, we looped into loc_17.  Loop and end condition are iteration counters. We noted the repetitive access to the address [rbp-4] and a subtraction of the value contained therein at the end of the loop. Therefore, this is without a doubt our counter, containing at first iteration, the last argument.

Let's now look further this loop. It seems to make several operations on our arguments. To be more precise, we can identify 4 arithmetic operations: 2 add and 2 sub, all some mov operations previous them. Let’s cut the function into 4 parts, after each arithmetic operations to make it clearer.

mov     eax, [rbp-4]
movsxd  rdx, eax
mov     rax, [rbp-32]
add     rdx, rax

mov     eax, [rbp-4]
movsxd  rcx, eax
mov     rax, [rbp-24]
add     rax, rcx

movzx   eax, byte ptr [rax]
mov     ecx, eax
mov     eax, [rbp-4]
sub     ecx, eax

mov     eax, ecx
xor     eax, 66
mov     [rdx], al
sub     dword ptr [rbp-4], 1


For each operationto be executed, temporal values are stored into registers like eax.
Let's analyze the first instruction bloc.

mov     eax, [rbp-4]
movsxd  rdx, eax
mov     rax, [rbp-32]
add     rdx, rax


The first four instructions seem to perform an addition on the content of the [rbp-4] and [rbp-32] addresses, which respectively contain at first iteration the last argument, i.e our loop counter i and the second argument.

So at this state, we have: rdx = i + arg2

The second bloc does exactly the same thing but this time with the first argument.

mov     eax, [rbp-4]
movsxd  rcx, eax
mov     rax, [rbp-24]
add     rax, rcx


This time, we have: rax = arg1 + i

Now, let's focus on the third bloc.

movzx   eax, byte ptr [rax]
mov     ecx, eax
mov     eax, [rbp-4]
sub     ecx, eax


In this bloc, the first instruction get the value contained at the rax address, arg1 + i. This value is a byte which is then substracted from i, then stored into ecx.

ecx = byte - i

And finally, the last bloc:

mov     eax, ecx
xor     eax, 66
mov     [rdx], al
sub     dword ptr [rbp-4], 1


Here, the value we just obtained at the bloc 3, ecx, is xored with the 0x42 constant. Then the result byte (al being the low part of the eax register, so corresponding to 8 bits), is stored at the address rdx, that's to say the address i + arg2 (and not the address of i + arg2).

Our last instruction simply decrements i.

At this step, we understand that 3 arguments are passed to the function. The last argument corresponds to the number of iteration the loop makes.

To sum up, the two first blocs give us two memory addresses in the buffers provided by in the parameters: rax = arg1 + i and rdx = i + arg2. A read access is performed on the rax address whereas it is a write access which is performed on the rdx address. Each loop, the byte we get from rax is substracted from i, then xored with 0x42 to be finally stored into rdx.

Once out of the grind, rax which is conventionally our return value, now contains the content of the address [rbp-32], previously arg2. So, we have a function which xor each character of a string after substracting it from the incremental value and then returning the result.

Now the final step is to re-code the function reversing the xor operation in order to decipher what it seems to be located after the padding found in the hexadecimal chain, so which have not been disassembled later:

90 90 90 90 55 48 89 E5 48 89 7D E8 48 89 75 E0
89 55 DC 8B 45 DC 89 45 FC EB 2F 8B 45 FC 48 63
D0 48 8B 45 E0 48 01 C2 8B 45 FC 48 63 C8 48 8B
45 E8 48 01 C8 0F B6 00 89 C1 8B 45 FC 29 C1 89
C8 83 F0 42 88 02 83 6D FC 01 83 7D FC 00 79 CB
48 8B 45 E0 5D C3 CC CC CC CC 00 00 00 00 6F 75
74 70 75 74 20 3D 20 01 36 32 24 29 2C 21 2F 33
55 23 1C 22 1D 15 17 52 21 14 10 4E 0C 09 1F 54
57 56 47 5D 4E
00 00 00 00 00 00

#include <stdio.h>

void cipher(unsigned char *word, int size) {
    char    xor[size];

    while (size >= 0) {
        xor[size] = (word[size] ^ 0x42) + size;
        size--;
    }
    printf("flag = %s \n", xor);
}

int main() {
    unsigned char    xor[30] = {0x01, 0x36, 0x32, 0x24, 0x29, 0x2C, 0x21, 0x2F, 0x33, 0x55, 0x23, 0x1C, 0x22, 0x1D, 0x15, 0x17, 0x52, 0x21, 0x14, 0x10, 0x4E, 0x0C, 0x09, 0x1F, 0x54, 0x57, 0x56, 0x47, 0x5D, 0x4E};
    cipher(xor, 29);

    return 0;
}


Which finally give us:

Flag

Thanks Gaby for having designed this little reverse engineering initiation challenge, which provides a pleasant introduction to the activity and recall some basic concepts and conventions.