LINE.exe unpacking

I found binary bug bounty opened on windows executable called Line [1]. But the binary is packed, so the first thing to do is to unpack it.

Click me


Click me

### Heading 1. Foo 2. Bar * Baz * Qux ### Some Javascript ```js function logSomething(something) { console.log('Something', something); } ```

The first steps

The binary is packed and DiE shows Themida/Winlicense(2.X).

I guess this is not full protection which Themida/Winlicense can offer, because you can walk-through the packed code with x86dbg and ScyllaHide [2] with all options enabled.

OEP searching

• Set breakpoint on VirtualProtect (not at the start of the function because Themida will detect it).
• Count the number of calls to VirtualProtect which were hit before the binary started GUI.
• Restart debugger and set memory breakpoint to whole first section in the last VirtualProtect call.
• This will reveal OEP 13F2252.
• Create dump and fix imports.

Going deeper

There is a code signature check inside the launcher, it’s trivial to fix it.

Proper import fix

After some debugging it became obvious that Scylla [3] fails to restore all imports properly. The reconstructed binary works (at least up to the login window) if ASLR is disabled. Scylla recognize a lot of imported functions and rebuilds it properly, but some of imports were not fixed, and that binary is working only until ASLR shift the bases of the libraries.

Invalid code (the pointer looks weird):

0092ce70 83c108          add     ecx,8
0092ce73 90              nop
0092ce74 e90798de0e      jmp     Qt5Gui!QTextOdfWriter::QTextOdfWriter+0x10 (0f716680)

Let’s investigate why Scylla fails to rebuild imports. Well, it leverages the disassembler in order to find references to imports. If disassembler fails to decode the code chunks properly, those chunks won’t be fixed. Let’s consider next example.

Note 0092CE74 address – it’s jump to the imported function. But if you just scroll the disassembler window in the debugger, you will see that disassembled output has changed.

There is no instruction starts from 0092CE74 address anymore because it’s part of previous opcode. So, the technique when you disassemble whole binary line-by-line is kind of error prone. Instead I propose to change logic of Scylla:

1. Let’s don’t use disassembler from the beginning, instead let’s just scan for all pointers.
2. If we find pointer to another library’s export we consider this pointer as a candidate for imports of current module.
3. Let’s disassemble backwards from that pointer and if find valid opcode which contains that pointer, than you can add it to the new imports and rebuild it.

That took too much time. Instead I just used pattern scan for E9/E8 opcode, that worked [4]. It was still slow but acceptable (~3-5 mins).

Btw, I found IAT at 016B9000.

The next issue is that the case mov eax, ds:[0x1234] was not fixed, too :(

Valid code:

Failing code:

Unfortunately Scylla covers only direct movs, like this mov eax, 0x1234. It’s actually b9 opcode:

But if you leave “New IAT” option unchecked in Scylla, this will solve this particular issue :)

In order to debug further execution stages you need to run the executable with next command line.

LINE.exe run -t 856554

But unfortunately now we’ve hit the same issue but in new place:

The code at 004708a8 is pointing to nowhere but it should point to IAT. Actually I had a mistake in IAT size. I thought it should be number of APIs, but it’s size of it in bytes. After fixing this, I’ve got the working binary.

Let’s sum up, what we’ve done.

1. Used ScyllaHyde to bypass debugger checks.
2. Used patched Scylla with improved direct API search feature. [4]
3. Set next values to Scylla when dumping:

name	value
OEP	13F2252
IAT	016B9000
IAT size	4084

References

1. LINE - Bug Bounty Program - HackerOne
2. GitHub - x64dbg/ScyllaHide: Advanced usermode anti-anti-debugger
3. GitHub - NtQuery/Scylla: Imports Reconstructor
4. IAT search without disasm. · expend20/Scylla@a9d4c01