Initial Triage#

• File Type: PE32+ executable for MS Windows 5.02 (GUI), x86-64
• Size: 183KB
• SHA256: a0b3e6ab4a53bf745319177035017f222634d2601ba8708292d5fbe440467387

Basic Static Analysis#

• Detect it Easy (Die) show that this file is self-extracted CAB/SFX style packing, where the executable includes a compressed Microsoft Cabinet file (CAB) and extracts/executes it at runtime and it is just a wrapper/loader.
• The .rsrc section is compressed, which is why the tool flags high entropy, classic sign of packing or encryption.
• Compression algorithm used inside the CAB is LZX (as shown), which is common in Microsoft CAB archives.
• So we have to first extract the actual exe from this and analyze it,

• We can extract it using cabextract tool, and it will written in Flare-On_start_2015.exe file,

1
┌──(b14cky㉿DESKTOP-VRSQRAJ)-[~/]
2
└─$ cabextract Flare-On_start_2015.exe
3
Extracting cabinet: Flare-On_start_2015.exe
4
  extracting i_am_happy_you_are_to_playing_the_flareon_challenge.exe
5

6
All done, no errors.

Initial Triage#

• File Type: PE32 executable for MS Windows 4.00 (console), Intel i386
• Size: 2KB
• SHA256: 5d35789ac904bc5f4639119391ad1078f267a157ca153f2906f05df94e557e11

Basic Static Analysis#

• It gives i_am_happy_you_are_to_playing_the_flareon_challenge.exe.
• By running die on it, and it is written in assembly, not C/CPP.
• Also, it has missing DOS Header which means most of the automatic tools fail here because of these setup.

• Running floss for strings analysis,

1
┌──(b14cky㉿DESKTOP-VRSQRAJ)-[~/]
2
└─$ /opt/floss i_am_happy_you_are_to_playing_the_flareon_challenge.exe
3
.
4
.
5
.
6
 ───────────────────────────
7
  FLOSS STATIC STRINGS (18)
8
 ───────────────────────────
9

10
+----------------------------------+
11
| FLOSS STATIC STRINGS: ASCII (18) |
12
+----------------------------------+
13

14
.text
15
.data
16
Pj*h
17
Pj2hX!@
18
h.!@
19
kernel32.dll
20
LoadLibraryA
21
GetProcAddress
22
GetLastError
23
GetStdHandle
24
AttachConsole
25
WriteConsoleA
26
WriteFile
27
ReadFile
28
Let's start out easy
29
Enter the password>
30
You are success
31
You are failure
32

33
+------------------------------------+
34
| FLOSS STATIC STRINGS: UTF-16LE (0) |
35
+------------------------------------+
36
 ─────────────────────────
37
  FLOSS STACK STRINGS (0)
38
 ─────────────────────────
39
 ─────────────────────────
40
  FLOSS TIGHT STRINGS (0)
41
 ─────────────────────────
42
 ───────────────────────────
43
  FLOSS DECODED STRINGS (0)
44
 ───────────────────────────

• These are the the kernel32.dll APIs,
• It can be used for Dynamic API Resolution + I/O Execution Flow. (Just a hypothesis)

1
LoadLibraryA
2
GetProcAddress
3
GetLastError
4
GetStdHandle
5
AttachConsole
6
WriteConsoleA
7
WriteFile
8
ReadFile

• Something related to password/licence checking,

1
Let's start out easy
2
Enter the password>
3
You are success
4
You are failure

• Now, to confirm the imports i used pestudio and indeed it is using those,

Advance Static Analysis#

• So, to analyze it opened it in IDA with manual load because sometimes auto load fails in these kind of binaries, and found that it has only one start function is which is doing something,

• GetStdHandle() is called with: - STD_INPUT_HANDLE → stdin - STD_OUTPUT_HANDLE → stdout
  • Return values (in EAX) are saved as handles for input/output.
• I/O Operations
  • WriteFile() → prints prompt to console (stdout)
  • ReadFile() → reads up to 50 bytes into input_buffer (0x402158)

1
BOOL start()
2
{
3
  int v0; // ecx
4
  HANDLE StdHandle; // [esp+4h] [ebp-Ch]
5
  HANDLE hFile; // [esp+8h] [ebp-8h]
6
  DWORD NumberOfBytesWritten; // [esp+Ch] [ebp-4h] BYREF
7

8
  StdHandle = GetStdHandle(STD_INPUT_HANDLE);
9
  hFile = GetStdHandle(STD_OUTPUT_HANDLE);
10
  WriteFile(
11
    hFile,
12
    aLetSStartOutEa,                            // "Let's start out easy\r\nEnter the password>"
13
    0x2Au,
14
    &NumberOfBytesWritten,
15
    nullptr);
16
  ReadFile(StdHandle, lpBuffer, 0x32u, &NumberOfBytesWritten, nullptr);
17
  v0 = 0;
18
  while ( ((unsigned __int8)lpBuffer[v0] ^ 0x7D) == byte_402140[v0] )
19
  {
20
    if ( ++v0 >= 24 )
21
      return WriteFile(
22
               hFile,
23
               aYouAreSuccess,                  // "You are success\r\n"
24
               0x12u,
25
               &NumberOfBytesWritten,
26
               nullptr);
27
  }
28
  return WriteFile(
29
           hFile,
30
           aYouAreFailure,                      // "You are failure\r\n"
31
           0x12u,
32
           &NumberOfBytesWritten,
33
           nullptr);
34
}

• Expected C code,

1
for (i = 0; i < 24; i++) {
2
    if ((input[i] ^ 0x7D) != encoded[i]) {
3
        print("failure");
4
        return;
5
    }
6
}
7
print("success");

• Here is the flow of code,

  1. Print prompt
  2. Read input
  3. For each character:
     • XOR with 0x7D
     • Compare with stored value
  4. If all 24 match → success
  5. Else → failure

• This are the sequence of bytes which are being XORed with key 0x7D.

1
1F 8 13 13 4 22 0E 11 4D 0D 18 3D 1B 11 1C 0F 18 50 12 13 53 1E 12 10

• Got the flag!!

1
bunny_sl0pe@flare-on.com

• You can also apply this IDApython script which will manually patch the bytes, (only for IDA pro).

1
import idc
2

3
for i in range(0x00402140, 0x00402158):
4
    b = 0x7D ^ idc.get_wide_byte(i)
5
    idc.patch_byte(i, b)

Initial Triage#

• File Type: PE32 executable for MS Windows 4.00 (console)
• Size: 2KB
• SHA256: 9852afb172bc03a50d291c70faa724c69a10af9e6ee88457185ce5e0705216f0

Basic Static Analysis#

• By running die on it, and it is written in assembly.

• Also, it has missing DOS Header which means most of the automatic tools fail

• I ran floss for strings analysis and here is what i get,

1
┌──(b14cky㉿DESKTOP-VRSQRAJ)-[~/]
2
└─$ /opt/floss very_success
3
.
4
.
5
.
6
 ───────────────────────────
7
  FLOSS STATIC STRINGS (20)
8
 ───────────────────────────
9
+----------------------------------+
10
| FLOSS STATIC STRINGS: ASCII (20) |
11
+----------------------------------+
12

13
.text
14
.data
15
PjCh
16
Pj2hY!@
17
hY!@
18
h5!@
19
hG!@
20
kernel32.dll
21
LoadLibraryA
22
GetProcAddress
23
GetLastError
24
GetStdHandle
25
AttachConsole
26
WriteConsoleA
27
WriteFile
28
ReadFile
29
You crushed that last one! Let's up the game.
30
Enter the password>
31
You are success
32
You are failure
33
+------------------------------------+
34
| FLOSS STATIC STRINGS: UTF-16LE (0) |
35
+------------------------------------+
36
 ─────────────────────────
37
  FLOSS STACK STRINGS (0)
38
 ─────────────────────────
39
 ─────────────────────────
40
  FLOSS TIGHT STRINGS (0)
41
 ─────────────────────────
42
 ───────────────────────────
43
  FLOSS DECODED STRINGS (0)
44
 ───────────────────────────

• It gives some kernel32.dll API functions,
• Hypothesis: (console-based loader/tool using dynamic API resolution + file I/O operations).

1
LoadLibraryA
2
GetProcAddress
3
GetLastError
4
GetStdHandle
5
AttachConsole
6
WriteConsoleA
7
WriteFile
8
ReadFile

• Some string related to password things,

1
You crushed that last one! Let's up the game.
2
Enter the password>
3
You are success
4
You are failure

Advance Static Analysis#

• I opened it in IDA, and it has only 2 functions and start function,
  • sub_401000
  • sub_401084

• Func1: sub_401000

• Func2: sub_401084

• This is flow of the whole program,

• Gets stdin/stdout handles via GetStdHandle.
• Prints a prompt to stdout.
• Reads up to 50 bytes from stdin into buffer unk_402159.
• Passes that buffer to the validator function.
• Prints success or failure message based on return value.

• Buffer unk_402159 holds both your input AND the expected hash bytes
• Bytes 0–36 → your typed input
• Bytes 36+ → hardcoded expected values baked into .data
• So the correct key is exactly 37 chars long.

1
pip install angr claripy

1
import angr
2
import claripy
3

4
proj = angr.Project('very_success.exe', auto_load_libs=False)
5

6
flag = [claripy.BVS(f'c{i}', 8) for i in range(37)]
7
state = proj.factory.full_init_state(stdin=claripy.Concat(*flag, claripy.BVV(b'\n')))
8

9
for c in flag:
10
    state.solver.add(c >= 0x20, c <= 0x7e)
11

12
simgr = proj.factory.simulation_manager(state)
13
simgr.use_technique(angr.exploration_techniques.Veritesting())
14
simgr.explore(find=0x0040106B, avoid=0x00401072)
15

16
if simgr.found:
17
    s = simgr.found[0]
18
    print(b''.join(s.solver.eval(c, cast_to=bytes) for c in flag))

1
a_Little_b1t_harder_plez@flare-on.com

Initial Triage#

• File Type: PE32 executable for MS Windows 5.00 (console), Intel i386
• Size: 11.6MB
• SHA256: 6b82463eaa13aba88aab9050f08bcc7658067f4dc4d6ca04f49bbda2201cc70b

Basic Static Analysis#

Running the sample through Detect It Easy (DIE) immediately tells us something interesting:

• 32-bit Windows executable (~11.6 MB)
• Built with Visual C++ 2008 — but wait, it’s actually a Python program packed with PyInstaller
• DIE flags it as packed/compressed
• There’s a large overlay at the end of the file containing zlib-compressed data

Yep, it’s packed alright.

This is classic PyInstaller behaviour. When you bundle a Python script with PyInstaller, it doesn’t compile it like C/C++ — instead it does something sneakier:

1. Bundles everything together — your Python script, the Python interpreter, and all required libraries
2. Packs it into one EXE — the front part is a small C loader, and the actual Python code + libs are stuffed at the end
3. Stores everything in an overlay — this data is appended after the PE structure, often zlib-compressed, which is exactly why DIE throws up the “strange overlay” warning
4. At runtime, the loader quietly extracts the embedded data and runs the Python code from memory or a temp folder

So the strategy here is straightforward - we need to unpack it and get to the actual Python code. We can extract the .pyc (compiled bytecode) files using pyinstxtractor:

1
https://sourceforge.net/projects/pyinstallerextractor/

1
┌──(b14cky㉿DESKTOP-VRSQRAJ)-[~]
2
└─$ python pyinstxtractor.py elfie
3

4
[*] Processing elfie
5
[*] Pyinstaller version: 2.1+
6
[*] Python version: 27
7
[*] Length of package: 12034944 bytes
8
[*] Found 26 files in CArchive
9
[*] Beginning extraction...please standby
10
[!] Warning: The script is running in a different python version than the one used to build the executable
11
    Run this script in Python27 to prevent extraction errors(if any) during unmarshalling
12
[*] Found 244 files in PYZ archive
13
[+] Possible entry point: _pyi_bootstrap
14
[+] Possible entry point: pyi_carchive
15
[+] Possible entry point: elfie
16
[*] Successfully extracted pyinstaller archive: elfie
17

18
You can now use a python decompiler on the pyc files within the extracted directory

1
┌──(b14cky㉿DESKTOP-VRSQRAJ)-[~/]
2
└─$ ls
3
elfie  elfie_extracted  pyinstxtractor.py
4

5
┌──(b14cky㉿DESKTOP-VRSQRAJ)-[~/elfie_extracted]
6
└─$ ls
7
bz2.pyd                      msvcp90.dll              pyi_carchive          python27.dll            _ssl.pyd
8
elfie                        msvcr90.dll              pyi_importers         QtCore4.dll             struct
9
elfie.exe.manifest           out00-PYZ.pyz            pyi_os_path           QtGui4.dll              unicodedata.pyd
10
_hashlib.pyd                 out00-PYZ.pyz_extracted  pyside-python2.7.dll  select.pyd
11
Microsoft.VC90.CRT.manifest  pyi_archive              PySide.QtCore.pyd     shiboken-python2.7.dll
12
msvcm90.dll                  _pyi_bootstrap           PySide.QtGui.pyd      _socket.pyd
13

14
┌──(b14cky㉿DESKTOP-VRSQRAJ)-[~/elfie_extracted]
15
└─$ file elfie
16
elfie: ASCII text

The elfie file sitting in the extraction directory is our next target — it’s a large blob of obfuscated Python code. Time to dig deeper.

Initial Triage#

• File Type: Python script, ASCII text executable, with very long lines (65463)
• Size: 1348KB
• SHA256: 922cc911074008ad494967b41fa48db712293e2572af53e8a5e823ff64c39761

Basic Static Analysis#

• Opening it up, we’re greeted with this beautiful disaster:

1
O0OO0OO00000OOOO0OOOOO0O00O0O0O0 = 'IRGppV0FJM3BRRlNwWGhNNG'
2
OO0O0O00OO00OOOOOO0O0O0OOO0OOO0O = 'UczRkNZZ0JVRHJjbnRJUWlJV3FRTkpo'
3
OOO0000O0OO0OOOOO000O00O0OO0O00O = 'xTStNRDJqZG9nRCtSU1V'
4
OOO0000O0OO0OOOOO000O00O0OO0O00O += 'Rbk51WXI4dmRaOXlwV3NvME0ySGp'
5
...
6
O00OO00OOO0OOOO0OOOO0OO00000OOO0 += 'RabTBrZE'
7
O00OO00OOO0OOOO0OOOO0OO00000OOO0 += 'VXWFY3QUtiTXFXQVYrenh4amxJZXI1MXd1YWJiWkRaWDRQV0'
8
O00OO00OOO0OOOO0OOOO0OO00000OOO0 += 'xDUmhGcnRDcnd4VkF5'
9
O00OO00OOO0OOOO0OOOO0OO00000OOO0 += 'aTBTMXd3OC8yY0ZqdzBIU0JMT0tEcktGckJUTkpvRGw2d'
10
O00OO00OOO0OOOO0OOOO0OO00000OOO0 += 'nNocTB'
11
import base64
12
exec(base64.b64decode(OOO0OOOOOOOO0000O000O00O0OOOO00O +
13
...
14
OOO0000O0OO0OOOOO000O00O0OO0O00O + OOO0O00O00OOOOOOO00OOOO0000O0O00 + O0O00OO00O0O00O0O00O0OOO00O0O0OO + O00OOOOO000O00O0O00000OOO0000OOO + O0O0OOO000O000OO0O0O0OOOOO0OO000))

• Classic obfuscation, variable names that are just random sequences of 0 and O to make it visually impossible to read.
• The trick here is simple though: instead of letting exec() run the decoded payload blindly, we just swap it out for print() and let it tell us what it was about to execute.

• Still pretty messy. After cleaning it up a bit, renaming some variables and fixing the formatting, it starts to look more sensible:

• There are two large base64 blobs in there.
• I decode both of them, and notice they’re also reversed, so I reverse them before decoding. Let’s see what’s inside.

Blob 1:

A glorious meme. 😂 Classic CTF energy.

Blob 2:

Another image. 😗

• And then, hiding right there in plain sight the flag, in plaintext, reversed:

Flip it around and we’re done:

1
Elfie.L0000ves.YOOOO@flare-on.com