From aldeid
Jump to navigation Jump to search
You are here
Challenge 5


Uncompress (password is "flare") and you will get 2 files named sender and challenge.pcap with following properties:

sender challenge.pcap
MD5 b39c32f2bac5609eed2b0d1f258a3f40 0e74650637930247b2ee5e703173917e
SHA1 897b1d35c2e261433c1172e7624118ee90dc225e 2b1070ee1f7eb3de69de05e470d57fac315f7d1c
File type PE32 executable (console) Intel 80386, for MS Windows tcpdump capture file (little-endian) - version 2.4 (raw IP, capture length 65535)



The challenge.pcap file is a tcpdump capture file that contains HTTP POST requests. Each of these requests contains data that seems to be part of a KEY (notice this keyword in the User-Agent string):

Let's extract this data for all requests:

$ /usr/sbin/tcpdump -r challenge.pcap -A 'tcp dst port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)' | grep -A2 "Cache" | grep -v "^$" | grep -v "Cache" | grep -v "\-\-" | tr -d "\n"

This string seems to be base64 but trying to decode it leads to nowhere, which means that it is encrypted.


Basic static analysis

Interesting strings:

Mozilla/5.0 (Windows NT 6.1; WOW64) KEY
[!] Could not open internet session.
[!] Could not connect to server: %s
[!] Could not open internet request.
[!] Error sending key data.
[!] Could not open key file: %s

Interesting IAT:

  • InternetOpenA
  • HttpSendRequestA
  • InternetConnectA
  • ReadFile
  • WriteFile

Based on this information, we can already make some assumptions:

  • The executable is manipulating a file, likely named key.txt
  • There is a string (flarebearstare) that could be used as a key
  • Several indications to HTTP connections with POST requests (Notice the hardcoded string for the User-Agent that we have noticed when we analyzed the pcap file)
  • Use of base64 encoding with a custom alphabet

Locate main function

The main function is not named in IDA-Pro and you have to find it. An easy way to locate the interesting code is to look for cross references to interesting strings or imports.

sub_401100 is actually the main function.

Key file

Starting the executable confirms our assumption. The executable is expecting a file named key.txt

[!] Could not open key file: key.txt

Here is the corresponding code:

.text:00401118                 push    0               ; hTemplateFile
.text:0040111A                 push    80h             ; dwFlagsAndAttributes
.text:0040111F                 push    3               ; dwCreationDisposition
.text:00401121                 push    0               ; lpSecurityAttributes
.text:00401123                 push    0               ; dwShareMode
.text:00401125                 push    80000000h       ; dwDesiredAccess
.text:0040112A                 push    offset FileName ; "key.txt"
.text:0040112F                 mov     [ebp+NumberOfBytesRead], 0
.text:00401139                 call    ds:CreateFileA
.text:0040113F                 mov     esi, eax
.text:00401141                 cmp     esi, 0FFFFFFFFh
.text:00401144                 jnz     short loc_401169
.text:00401146                 push    offset FileName ; "key.txt"
.text:0040114B                 push    offset aCouldNotOpenKe ; "[!] Could not open key file: %s\n"

Next, the file is read and its content is saved to a buffer:

.text:0040116B push    0               ; lpOverlapped
.text:0040116D lea     eax, [ebp+NumberOfBytesRead]
.text:00401173 push    eax             ; lpNumberOfBytesRead
.text:00401174 push    80000h          ; nNumberOfBytesToRead
.text:00401179 lea     eax, [ebp+Buffer]
.text:0040117F push    eax             ; lpBuffer
.text:00401180 push    esi             ; hFile
.text:00401181 call    ds:ReadFile

It is then sent to function sub_401250:

.text:00401198 mov     edx, esi
.text:0040119A lea     ecx, [ebp+Buffer]
.text:004011A0 call    sub_401250


sub_401250 is actually modifying the content of the key.txt file using the following transformation (pseudocode):

for (i=0; i<buff_len; i++) {
    buff[i] += key[i % key_len]

where flarebearstare is used as the key.


Then there is a call to sub_4012A0 which is a slightly modified base64 encoding function. It actually uses a custom alphabet with lower case letters swapped with upper ones and vice versa.

.text:004011E3 push    edi
.text:004011E4 push    ebx
.text:004011E5 mov     edx, esi
.text:004011E7 call    sub_4012A0


Then there is a loop that splits the key into 4-bytes chunks and send them to the web server (sub_401000):

Get the key array

We already have the data that is sent to the server thanks to the pcap file. We also know that the executable has swapped lower/upper cases. Based on this information, we can get the initial data:

$ echo "UDYs1D7bNmdE1o3g5ms1V6RrYCVvODJF1DpxKTxAJ9xuZW==" | tr "A-Za-z" "a-zA-Z"| base64 -d | hd
00000000  b9 dc 92 d5 de c1 9c c0  de d4 ed c6 e4 c4 b5 bf  |................|
00000010  aa d1 c9 cb d5 a1 d8 df  d5 d3 d7 92 d5 da 8f d5  |................|
00000020  d4 cf                                             |..|

Script and solution

#!/usr/bin/env python

k = 'flarebearstare'

target = [0xb9, 0xdc, 0x92, 0xd5, 0xde, 0xc1, 0x9c, 0xc0,
          0xde, 0xd4, 0xed, 0xc6, 0xe4, 0xc4, 0xb5, 0xbf,
          0xaa, 0xd1, 0xc9, 0xcb, 0xd5, 0xa0, 0x38, 0xdf,
          0xd5, 0xd3, 0xd7, 0x92, 0xd5, 0xda, 0x8f, 0xd5,
          0xd4, 0xcf]

tmp = []
for c, i in enumerate(target):
    tmp.append(i-ord(k[c % len(k)]))

print ''.join([chr(i%256) for i in tmp])

Executing this python script reveals the solution:

[email protected]


Keywords: reverse-engineering challenge flare fireeye