Thanks to my reader Max I have fixed another bug in the Molebox unpacker.
I hope you find this unpacker useful. But if it doesn't work for you, please send me an error report with all the details you can and I'll try to fix it. Have fun!
While reversing a certain executable, I needed to figure out what data it sends over SSL/TLS. It's not using standard WinHttp functions but custom Schannel/SSPI implementation that's similar to CURL.
One of the steps in the process is to obtain SecurityFunctionTable using code like this:
|
1 2 3 4 5 6 7 8 9 10 |
pInitSecurityInterface = (INIT_SECURITY_INTERFACE)GetProcAddress( g_hSecurity, "InitSecurityInterfaceA" ); if(pInitSecurityInterface == NULL) { printf( "Error 0x%x reading InitSecurityInterface entry point.\n", GetLastError() ); return FALSE; } g_pSSPI = pInitSecurityInterface(); // call InitSecurityInterfaceA(void); if(g_pSSPI == NULL) { printf("Error 0x%x reading security interface.\n", GetLastError()); return FALSE; } |
And then you can use the obtained SECURITY_FUNCTION_TABLE to call different SSPI functions.
Sure, InitSecurityInterface and the SECURITY_FUNCTION_TABLE structure are described on MSDN (just the start of structure is shown for brevity):
So, I added the corresponding structure definition to IDA and tried to analyze the calls. It made no sense whatsoever.
What's happening here?
After some head scratching, I searched WDK for SECURITY_FUNCTION_TABLE definition. And here it is:
I wonder where the Reserved1 field has gone... wink
Fix the structure definition in IDA and magically all the calls make perfect sense:
Morale of the story - MSDN is great for quick reference but having a full Windows SDK/WDK installed is priceless.
Morale #2 - always carefully check IDA standard structures. Apparently, IDA doesn't have SECURITY_FUNCTION_TABLE defined - but it does have proper definition for SecurityFunctionTable.
Thanks to my readers I have fixed few more bugs in the Molebox unpacker.
I hope you find this unpacker useful. But if it doesn't work for you, please send me an error report with all the details you can and I'll try to fix it. Have fun!
Few days ago Xjun briefly mentioned a new feature of VMProtect 3.1 - it uses direct syscalls to check if software is running under debugger. I decided to take a quick look myself and figure out how exactly it works.
I'll give you 2 targets for the research:
In addition to that, I'll provide a very simple demo executable which replicates part of the VMProtect protection, so that you don't waste time looking at obfuscated code.
As a debugger in 32-bit OS you can use anything you like. On 64-bit OS you will really need to use WinDbg - as far as I know, it's the only debugger that can handle those tricks..
Let's start by debugging oppo_flash_tool.exe. First, we need to get past the usual tricks like IsDebuggerPresent and CheckRemoteDebuggerPresent. If you're reading this, I'm sure you know how to do that.
Few moments later we'll arrive here:
|
1 2 3 4 |
00dcfd8e f744250000800000 test dword ptr [ebp],8000h 00dcfd96 e9f6bdfdff jmp 00dabb91 ... 00dabb91 0f84841a0b00 je 00e5d61b |
Remember this conditional jump. It's taken on 32bit OSes and not taken on 64-bit OS.
Let's look at 32bit OS version first. Now VMProtect prepares to call sysenter.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
00e5d61b 56 push esi 00e5d61c 85f8 test eax,edi 00e5d61e 57 push edi 00e5d61f 0facd074 shrd eax,edx,74h 00e5d623 6633d3 xor dx,bx 00e5d626 53 push ebx 00e5d627 8bd9 mov ebx,ecx 00e5d629 81fcfe567054 cmp esp,547056FEh 00e5d62f 8bd3 mov edx,ebx 00e5d631 35fb5cc775 xor eax,75c75cfbh 00e5d636 c1e202 shl edx,2 00e5d639 0fbae028 bt eax,28h 00e5d63d 8bc5 mov eax,ebp 00e5d63f 6681fbda38 cmp bx,38DAh 00e5d644 8d0410 lea eax,[eax+edx] 00e5d647 f7c615443214 test esi,14324415h ... |
Since the code is obfuscated, here comes a cleaned-up version. Please note that in other applications, different registers can be used.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
;input: ; ECX = number of parameters for the syscall ; [EBP] = syscall id. See https://github.com/tinysec/windows-syscall-table ; [EBP+4] .. [EBP+X] = params for the syscall ; [EBP-4] .. [EBP-8] = free space to save registers push esi push edi push ebx ; save register values for later lea eax, [ebp+ecx*4] mov dword ptr [ebp-4], eax mov dword ptr [ebp-8], esp ; set up stack frame for syscall setupParams: mov eax, dword ptr [ebp+ecx*4] push eax sub ecx, 1 jnz setupParams ; put syscall number in EAX mov eax, dword ptr [ebp] ; the actual call call trampoline1 ; restore stack and frame pointers mov esp, dword ptr [ebp-8] mov ebp, dword ptr [ebp-4] ; save result mov dword ptr [ebp], eax ; restore registers pop ebx pop edi pop esi jmp 00de21de trampoline1: call trampoline2 retn trampoline2: mov edx, esp sysenter retn // -- continue VM execution as usual -- 00de21de 8b06 mov eax,dword ptr [esi] 00de21e2 8db604000000 lea esi,[esi+4] 00de21ea 33c3 xor eax,ebx 00de21ec 8d807cc2efb1 lea eax,[eax-4E103D84h] 00de21f6 f7d0 not eax 00de21fd 35ee613a76 xor eax,763a61ee 00df9a28 48 dec eax 00df9a29 f8 clc 00df9a2a c1c002 rol eax,2 00df9a2e 33d8 xor ebx,eax 00df9a32 03f8 add edi,eax 00df9a34 e9a0eafbff jmp 00db84d9 00db84d9 ffe7 jmp edi ... 00ddaeba 8b542500 mov edx,dword ptr [ebp] |
Here it is getting interesting! smile You cannot use sysenter instruction from 32-bit code in 64-bit Windows. But, as ReWolf described few years ago, one can mix x86 code with x64 code in the same process. And that's exactly what VMProtect 3.1 is doing.
Let's go back to that conditional jump and see what happens in 64-bit OS. The jump will not be taken:
|
1 2 3 4 |
00dabb91 0f84841a0b00 je 00e5d61b 00dabb97 9adf4ce8003300 call 0033:00E84CDF 00dabb9e 668cd1 mov cx,ss 00dabba1 668ed1 mov ss,cx |
Far call?! Last time I saw that was in 16-bit Windows era..
As explained in ReWolf's article:
Summing things up, for every process (x86 & x64) running on 64-bits Windows there are allocated two code segments:
- cs = 0x23 -> x86 mode
- cs = 0x33 -> x64 mode
So, as soon as you execute that call, you'll switch to a 64-bit world. WinDbg happily recognizes that, all other debuggers just go astray..
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
00dabb97 9adf4ce8003300 call 0033:00E84CDF 00000000`00e84cdf 56 push rsi 00000000`00e84ce0 57 push rdi 00000000`00e84ce1 53 push rbx 00000000`00e84ce2 8bd9 mov ebx,ecx 00000000`00e84ce4 8bd3 mov edx,ebx 00000000`00e84ce6 33c9 xor ecx,ecx 00000000`00e84ce8 81fb04000000 cmp ebx,4 00000000`00e84cee 0f8606000000 jbe 00000000`00e84cfa 00000000`00e84cf4 8d8bfcffffff lea ecx,[rbx-4] 00000000`00e84cfa c1e103 shl ecx,3 ... |
x64 code does pretty much the same thing as x86 code - sets up a stack frame, sets up registers and then executes syscall instruction. Cleaned-up and shortened version follows:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 |
;input: ; ECX = number of parameters for the syscall ; [EBP] = encoded syscall id. ; High order byte = special handling info ; Lowest 15 bits = syscall id ; [EBP+4] .. [EBP+X] = params for the syscall ; [EBP-8] .. [EBP-10] = free space to save registers ; [EBP-..] = free space to use in specific syscalls push rsi push rdi push rbx mov ebx,ecx mov edx,ebx xor ecx,ecx ; calculate new stack frame pointer cmp ebx,4 jbe @F lea ecx,[rbx-4] @@: shl ecx,3 shl edx,2 mov rax,rbp add rax,rdx ; save registers mov qword ptr [rbp-8],rax mov qword ptr [rbp-10h],rsp ; adjust RSP sub rsp,rcx and rsp,0FFFFFFFFFFFFFFF0h add rsp,rcx ; useless? mov r10d,dword ptr [rbp] shr r10d,9 ; set up params for syscall test ebx,ebx je doneSettingParams loopSetParams: mov eax,dword ptr [rbp+rbx*4] cmp ebx,1 jne @F mov rcx,rax jmp nextParam @@: cmp ebx,2 jne @F mov rdx,rax jmp nextParam @@: cmp ebx,3 jne @F mov r8,rax jmp nextParam @@: cmp ebx,4 jne @F mov r9,rax jmp nextParam @@: push rax nextParam: sub ebx,1 jne loopSetParams doneSettingParams: ; check if syscall needs special handling mov rax,qword ptr [rbp] mov r10d,eax shr r10d,18h ; 3 = NtQueryInformationProcess cmp r10b,3 jne doSyscall ; fix current process pseudo-handle, if it's there cmp ecx,0FFFFFFFFh jne @F movsx rcx,cl @@: ; is this ProcessDebugObjectHandle request? cmp edx,1Eh jne @F ; if so, fix buffer and size for ProcessDebugObjectHandle request. ; It should be 8-bytes long. lea r10,[rbp-18h] mov r8,r10 mov r9d,8 @@: jmp doSyscall doSyscall: and eax,7FFFh sub rsp,20h call trampoline jmp processResult trampoline: mov r10,rcx syscall ret processResult: ; check for special handling again mov r10d,dword ptr [rbp] shr r10d,18h ; 3 = NtQueryInformationProcess cmp r10b,3 jne returnToX86 ; is this ProcessDebugObjectHandle ? cmp dword ptr [rbp+8],1Eh jne returnToX86 ; were 2 buffers the same in original call? mov ecx,dword ptr [rbp+0Ch] cmp ecx,dword ptr [rbp+14h] je @F ; if not, copy returned DebugObjectHandle back to original buffer mov r10d,dword ptr [rbp-18h] mov dword ptr [rcx],r10d @@: jmp returnToX86 returnToX86: nop mov rsp,qword ptr [rbp-10h] mov rbp,qword ptr [rbp-8] mov dword ptr [rbp],eax pop rbx pop rdi pop rsi retf |
You'll notice that x64 version is slightly more complex due to the way parameters are passed (registers vs. stack). It also includes a special treatment for 8 special edge cases - it will modify syscall parameters to adjust buffers and pointer sizes to satisfy requirements for 64-bit code.
NOTE - to keep code simple, I only showed the part which deals with NtQueryInformationProcess but other cases are similar.
As you can see, return back from x64 to the x86 world is a simple retf instruction. x86 code continues right where it left off:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
00000000`00e7edf1 cb retf ... 00dabb9e 668cd1 mov cx,ss 00dabba1 668ed1 mov ss,cx 00dabba4 8b16 mov edx,dword ptr [esi] 00dabba6 3bf8 cmp edi,eax 00dabba8 80fbf2 cmp bl,0F2h 00dabbab 81c604000000 add esi,4 00dabbb1 6685c8 test ax,cx 00dabbb4 33d3 xor edx,ebx 00dabbb6 f5 cmc 00dabbb7 8d927cc2efb1 lea edx,[edx-4E103D84h] 00dabbbd 6681ff8e5b cmp di,5B8Eh 00dabbc2 f7d2 not edx 00dabbc4 80fbf5 cmp bl,0F5h 00dabbc7 81f2ee613a76 xor edx,763a61ee 00dabbcd e9479f0500 jmp 00e05b19 00e05b19 4a dec edx 00e05b1a f8 clc 00e05b1b c1c202 rol edx,2 00e05b1e 33da xor ebx,edx 00e05b20 6681fff273 cmp di,73F2h 00e05b25 03fa add edi,edx 00e05b27 ffe7 jmp edi ... 00ddaeba 8b542500 mov edx,dword ptr [ebp] |
Instruction at address 0x00ddaeba is the same for both x86 and x64 OS-es and VM continues as usual.
I provided you with 2 real-world test executables. Oppo seems to be simpler and use just 3 syscalls:
Asshurt doesn't have antidebug trick with NtQueryInformationProcess but it uses additional syscalls for some purposes:
Since VMProtect is using undocumented Windows features, it somehow needs to ensure that the protection will work on each and every Windows version. That's VMProtect's biggest strength and also the biggest weakness.
Windows' syscall numbers change in each version and also between major builds. Use the wrong syscall number and you're guaranteed to receive unexpected results. So, VMProtect developers had to hardcode a table with Windows build numbers and corresponding syscall id's in the executable.
You can see the syscall numbers in the j00ru's page (slightly out of date) or in tinysec's windows kernel syscall table
To obtain Windows build number, VMProtect uses information from PEB (Process Environment Block). The method is already described in The MASM Forum, so I'll just reproduce the (ugly) code from their page:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
print "Read From Process Environment Block:",13,10 ASSUME FS:Nothing mov edx,fs:[30h] ;PEB.InheritedAddressSpace ASSUME FS:ERROR mov eax,[edx+0A4h] ;eax = Major Version push eax push edx print ustr$(eax),'.' pop edx push edx mov eax,[edx+0A8h] ;eax = Minor Version print ustr$(eax),'.' pop edx mov eax,[edx+0ACh] ;eax = build and eax,0FFFFh ;because win 7 collapses print ustr$(eax),13,10,13,10 pop eax |
VMProtect checks only the build number and picks the corresponding syscall number. However, if the build number is not in the internal database, it will not use direct syscall and fall back to standard protection. Bingo, problem solved - no need for ugly hacks like Xjun's SharpOD plugin!
Hint: VMProtect 3.1 doesn't support Windows 10 Creators Update (build number 15063).
As promised, here is a download link for the test application: https://mediafire.com/?niqqbs0fqcq8n23
Note: it should support most common builds of Windows XP/7/8.1/10. Windows 2003/Vista and other rare systems are not supported!
If it shows "OK" message, you've hidden your debugger well. If it shows "Debugger detected", you have a problem. smile
Have fun!
kao.
EDIT: Updated download link for Oppo. Mediafire's antivirus tends to have plenty of False Positives..
I've written about my fight with Google Chrome updates and broken features in the past. This time let's talk about the brain-dead decision to disable Backspace.
This was their rationale for the change:
We have UseCounters showing that 0.04% of page views navigate back via the backspace button and 0.005% of page views are after a form interaction. The latter are often cases where the user loses data. Years of user complaints have been enough that we think it's the right choice to change this given the degree of pain users feel by losing their data and because every platform
has another keyboard combination that navigates back.
So, just because 50 persons out of each 1'000'000 are f*king idiots, all the others have to suffer? Makes no sense to me.
To prove my point, let's look at the simple Google search: "Google Chrome backspace". It gives 238'000+ results. First few results are: "Backspace to go Back - Chrome Web Store", "Go Back With Backspace - Chrome Web Store", "Back to Backspace - Chrome Web Store", "How to restore the backspace key as a keyboard shortcut to go back in ...", "So where's the Chrome flag to RE-ENABLE BACKSPACE going back a...".
Apparently, I'm not the only one who is hurt by this change.
When the change was first introduced in Google Chrome, developers also created a hidden feature that you could set and make Backspace work as it used to. To use it, you just need to launch chrome.exe with a command-line like this:
|
1 |
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --enable-features=BackspaceGoesBack |
But in commit 0fe1505a this feature was removed as well.
If you enter the commit number in Chromium Find Releases tool, you'll see that in went out in public in v61.0.3116.0. Another check in Chrome Channel Releases tool will tell you that as of this moment the change is already out for both Canary and Dev channels, and will hit Beta and Stable channels in next months:
So, let's fix this issue for good! And by "fixing it" I don't mean some stupid JavaScript-based Chrome extension (which doesn't work when JavaScript is disabled and in hundreds of other cases..), I mean a proper fix in the code.
If you've read my previous post, you know the drill. Set the symbol path, load chrome.dll in IDA, get yourself some coffee and wait. Wait a lot. And after 20-30 minutes you'll be able to start working.
This is the commit that's causing our headaches: commit 0fe1505a and the corresponding place in disassembly of Chrome 58:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 |
.text:0001819AB871 mov ecx, edi .text:0001819AB873 sub ecx, 33000 .text:0001819AB879 jz short locIDC_BACK .text:0001819AB87B sub ecx, 1 .text:0001819AB87E jz short locIDC_FORWARD ... .text:0001819AB8D9 locIDC_FORWARD: ; CODE XREF: chrome::BrowserCommandController::ExecuteCommandWithDisposition(int,WindowOpenDisposition)+BEj .text:0001819AB8D9 mov rcx, [rbx+0F0h] .text:0001819AB8E0 mov rax, [rcx] .text:0001819AB8E3 call qword ptr [rax+110h] .text:0001819AB8E9 .text:0001819AB8E9 doGoForward: ; CODE XREF: chrome::BrowserCommandController::ExecuteCommandWithDisposition(int,WindowOpenDisposition)+1C3j .text:0001819AB8E9 mov rcx, [r14+18h] ; browser .text:0001819AB8ED mov edx, r15d ; disposition .text:0001819AB8F0 call ?GoForward@chrome@@YAXPEAVBrowser@@W4WindowOpenDisposition@@@Z ; chrome::GoForward(Browser *,WindowOpenDisposition) .text:0001819AB8F5 jmp loc_1819AC7C2 .text:0001819AB8FA ; --------------------------------------------------------------------------- .text:0001819AB8FA .text:0001819AB8FA locIDC_BACK: ; CODE XREF: chrome::BrowserCommandController::ExecuteCommandWithDisposition(int,WindowOpenDisposition)+B9j .text:0001819AB8FA mov rcx, [rbx+0F0h] .text:0001819AB901 mov rax, [rcx] .text:0001819AB904 call qword ptr [rax+110h] .text:0001819AB90A .text:0001819AB90A doGoBack: ; CODE XREF: chrome::BrowserCommandController::ExecuteCommandWithDisposition(int,WindowOpenDisposition)+1DBj .text:0001819AB90A mov rcx, [r14+18h] ; browser .text:0001819AB90E mov edx, r15d ; disposition .text:0001819AB911 call ?GoBack@chrome@@YAXPEAVBrowser@@W4WindowOpenDisposition@@@Z ; chrome::GoBack(Browser *,WindowOpenDisposition) .text:0001819AB916 jmp loc_1819AC7C2 ... .text:0001819AB954 mov ecx, edi .text:0001819AB956 sub ecx, 33007 .text:0001819AB95C jz loc_1819AB9FC .text:0001819AB962 sub ecx, 2 .text:0001819AB965 jz short loc_1819AB9BC .text:0001819AB967 sub ecx, 1 .text:0001819AB96A jz short locIDC_BACKSPACE_BACK .text:0001819AB96C cmp ecx, 1 .text:0001819AB96F jnz loc_1819AC729 .text:0001819AB975 .text:0001819AB975 locIDC_BACKSPACE_FORWARD: ; feature .text:0001819AB975 lea rcx, ?kBackspaceGoesBackFeature@features@@3UFeature@base@@B .text:0001819AB97C call ?IsEnabled@FeatureList@base@@SA_NAEBUFeature@2@@Z ; base::FeatureList::IsEnabled(base::Feature const &) .text:0001819AB981 test al, al .text:0001819AB983 jnz doGoForward .text:0001819AB989 mov dl, 1 .text:0001819AB98B jmp short loc_1819AB9A3 .text:0001819AB98D ; --------------------------------------------------------------------------- .text:0001819AB98D .text:0001819AB98D locIDC_BACKSPACE_BACK: ; CODE XREF: chrome::BrowserCommandController::ExecuteCommandWithDisposition(int,WindowOpenDisposition)+1AAj .text:0001819AB98D lea rcx, ?kBackspaceGoesBackFeature@features@@3UFeature@base@@B ; feature .text:0001819AB994 call ?IsEnabled@FeatureList@base@@SA_NAEBUFeature@2@@Z ; base::FeatureList::IsEnabled(base::Feature const &) .text:0001819AB999 test al, al .text:0001819AB99B jnz doGoBack .text:0001819AB9A1 xor edx, edx .text:0001819AB9A3 .text:0001819AB9A3 loc_1819AB9A3: ; CODE XREF: chrome::BrowserCommandController::ExecuteCommandWithDisposition(int,WindowOpenDisposition)+1CBj .text:0001819AB9A3 mov rax, [r14+18h] .text:0001819AB9A7 mov rcx, [rax+0F0h] .text:0001819AB9AE mov rax, [rcx] .text:0001819AB9B1 call qword ptr [rax+108h] ; window()->MaybeShowNewBackShortcutBubble() .text:0001819AB9B7 jmp loc_1819AC7C2 |
What a mess!
Luckily for us, compiler decided to emit nice switch table in version v61.0.3153.2:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
.text:0001806CE0C3 loc_1806CE0C3: ; CODE XREF: sub_1806CDF28+CFj .text:0001806CE0C3 lea eax, [rbx-33000] ; jumptable 00000001806CE00B default case .text:0001806CE0C9 cmp eax, 0Bh ; switch 12 cases .text:0001806CE0CC ja loc_1806CEACC ; jumptable 00000001806CE03B cases 2-11,13 .text:0001806CE0D2 lea rcx, off_1806CEC30 .text:0001806CE0D9 movsxd rax, dword ptr [rcx+rax*4] .text:0001806CE0DD add rax, rcx .text:0001806CE0E0 jmp rax ; switch jump ... .text:0001806CEC30 off_1806CEC30: .text:0001806CEC30 B2 F4 FF FF dd offset locIDC_BACK - 1806CEC30h .text:0001806CEC34 5B FD FF FF dd offset locIDC_FORWARD - 1806CEC30h ; jumptable 00000001806CE0E0 case 1 .text:0001806CEC38 91 FD FF FF dd offset loc_1806CE9C1 - 1806CEC30h ; jumptable 00000001806CE0E0 case 2 .text:0001806CEC3C B3 FD FF FF dd offset loc_1806CE9E3 - 1806CEC30h ; jumptable 00000001806CE0E0 case 3 .text:0001806CEC40 D5 FD FF FF dd offset loc_1806CEA05 - 1806CEC30h ; jumptable 00000001806CE0E0 case 4 .text:0001806CEC44 9C FE FF FF dd offset loc_1806CEACC - 1806CEC30h ; jumptable 00000001806CE0E0 default case .text:0001806CEC48 F5 FD FF FF dd offset loc_1806CEA25 - 1806CEC30h ; jumptable 00000001806CE0E0 case 6 .text:0001806CEC4C 21 FE FF FF dd offset loc_1806CEA51 - 1806CEC30h ; jumptable 00000001806CE0E0 case 7 .text:0001806CEC50 9C FE FF FF dd offset loc_1806CEACC - 1806CEC30h ; jumptable 00000001806CE0E0 default case .text:0001806CEC54 15 FE FF FF dd offset loc_1806CEA45 - 1806CEC30h ; jumptable 00000001806CE0E0 case 9 .text:0001806CEC58 43 FE FF FF dd offset locIDC_BACKSPACE_BACK - 1806CEC30h ; jumptable 00000001806CE0E0 case 10 .text:0001806CEC5C 65 FE FF FF dd offset locIDC_BACKSPACE_FORWARD - 1806CEC30h ; jumptable 00000001806CE0E0 case 11 |
To make Backspace work as intended, we can simply overwrite 2 entries in jump table.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
.text:0001806CEC30 off_1806CEC30: .text:0001806CEC30 B2 F4 FF FF dd offset locIDC_BACK - 1806CEC30h .text:0001806CEC34 5B FD FF FF dd offset locIDC_FORWARD - 1806CEC30h ; jumptable 00000001806CE0E0 case 1 .text:0001806CEC38 91 FD FF FF dd offset loc_1806CE9C1 - 1806CEC30h ; jumptable 00000001806CE0E0 case 2 .text:0001806CEC3C B3 FD FF FF dd offset loc_1806CE9E3 - 1806CEC30h ; jumptable 00000001806CE0E0 case 3 .text:0001806CEC40 D5 FD FF FF dd offset loc_1806CEA05 - 1806CEC30h ; jumptable 00000001806CE0E0 case 4 .text:0001806CEC44 9C FE FF FF dd offset loc_1806CEACC - 1806CEC30h ; jumptable 00000001806CE0E0 default case .text:0001806CEC48 F5 FD FF FF dd offset loc_1806CEA25 - 1806CEC30h ; jumptable 00000001806CE0E0 case 6 .text:0001806CEC4C 21 FE FF FF dd offset loc_1806CEA51 - 1806CEC30h ; jumptable 00000001806CE0E0 case 7 .text:0001806CEC50 9C FE FF FF dd offset loc_1806CEACC - 1806CEC30h ; jumptable 00000001806CE0E0 default case .text:0001806CEC54 15 FE FF FF dd offset loc_1806CEA45 - 1806CEC30h ; jumptable 00000001806CE0E0 case 9 .text:0001806CEC30 B2 F4 FF FF dd offset locIDC_BACK - 1806CEC30h ; jumptable 00000001806CE0E0 case 10 .text:0001806CEC34 5B FD FF FF dd offset locIDC_FORWARD - 1806CEC30h ; jumptable 00000001806CE0E0 case 11 |
Mission accomplished! smile
In the next part of this blog series, I'll show you how to make this patch more user friendly and a few ways how to automate the patching (so that you can receive automatic Google Chrome updates, if you wish).
Till next time!
kao.
For one of my private projects, I needed to decrypt some data. Original executable uses Enigma's EP_CryptDecryptBuffer function but I needed to implement the same thing using .NET. Much to my surprise, there was no information about what encryption algorithm is used by Enigma or how it works internally. So, I started by compiling Enigma's sample project CryptBuffer and debugging the executable.
TL;DR - IDEA cipher in CBC mode, password = MD5(user_password), IV for CBC comes from IDEA.Encrypt(8-zeroes, password).
After protecting my executable with Enigma, few assembly lines
|
1 2 3 4 |
004142FA 68 B85E4100 PUSH crypto_p.00415EB8 ; ASCII "password" 004142FF 68 00100000 PUSH 1000 00414304 53 PUSH EBX 00414305 E8 EEF9FFFF CALL <JMP.&enigma_ide.EP_CryptDecryptBuf> |
got changed into something horrible that looked like an Enigma's VM:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
004142FA 68 B85E4100 PUSH crypto_p.00415EB8 ; ASCII "password" 004142FF 68 00100000 PUSH 1000 00414304 53 PUSH EBX 00414305 E8 EEF9FFFF CALL crypto_p.00413CF8 .. 00413CF8 FF25 44D44100 JMP DWORD PTR DS:[41D444] ; crypto_p.004EEC6C .. 004EEC6C /E9 C6A60800 JMP crypto_p.00579337 .. 00579337 68 6D5133A1 PUSH A133516D 0057933C E9 BBC1FEFF JMP crypto_p.005654FC .. 005654FC 60 PUSHAD 005654FD 9C PUSHFD 005654FE B2 01 MOV DL,1 00565500 BE 00000000 MOV ESI,0 00565505 8DBE CC775600 LEA EDI,DWORD PTR DS:[ESI+5677CC] 0056550B 8D3F LEA EDI,DWORD PTR DS:[EDI] 0056550D B9 01000000 MOV ECX,1 00565512 31C0 XOR EAX,EAX 00565514 F0:0FB10F LOCK CMPXCHG DWORD PTR DS:[EDI],ECX ; LOCK prefix 00565518 74 0F JE SHORT crypto_p.00565529 0056551A 3A15 C8775600 CMP DL,BYTE PTR DS:[5677C8] ... |
I didn't feel like spending my time on analyzing that. Much easier solution was to put hardware breakpoints on my data and password and wait for them to trigger. In a few seconds I landed into code that looked like MD5 (notice the constants!):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
... 00454E1C 89D7 MOV EDI,EDX 00454E1E 31CF XOR EDI,ECX 00454E20 21DF AND EDI,EBX 00454E22 31D7 XOR EDI,EDX 00454E24 01F0 ADD EAX,ESI 00454E26 8D8407 78A46AD7 LEA EAX,DWORD PTR DS:[EDI+EAX+D76AA478] 00454E2D C1C8 19 ROR EAX,19 00454E30 01D8 ADD EAX,EBX 00454E32 8B75 04 MOV ESI,DWORD PTR SS:[EBP+4] 00454E35 89CF MOV EDI,ECX 00454E37 31DF XOR EDI,EBX 00454E39 21C7 AND EDI,EAX 00454E3B 31CF XOR EDI,ECX 00454E3D 01F2 ADD EDX,ESI 00454E3F 8D9417 56B7C7E8 LEA EDX,DWORD PTR DS:[EDI+EDX+E8C7B756] ... |
and few hits later I landed into code that I didn't recognize at first:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
... 004DB61C E8 DBFDFFFF CALL crypto_p.004DB3FC 004DB621 66:8B446E 7E MOV AX,WORD PTR DS:[ESI+EBP*2+7E] 004DB626 66:0147 02 ADD WORD PTR DS:[EDI+2],AX 004DB62A 66:8B846E 800000>MOV AX,WORD PTR DS:[ESI+EBP*2+80] 004DB632 66:0147 04 ADD WORD PTR DS:[EDI+4],AX 004DB636 66:8B946E 820000>MOV DX,WORD PTR DS:[ESI+EBP*2+82] 004DB63E 8D47 06 LEA EAX,DWORD PTR DS:[EDI+6] 004DB641 E8 B6FDFFFF CALL crypto_p.004DB3FC 004DB646 66:8B47 04 MOV AX,WORD PTR DS:[EDI+4] 004DB64A 66:894424 0C MOV WORD PTR SS:[ESP+C],AX 004DB64F 66:8B07 MOV AX,WORD PTR DS:[EDI] 004DB652 66:3147 04 XOR WORD PTR DS:[EDI+4],AX ... |
Delphi compiler had helpfully included RTTI information telling me that this second piece of code belongs to a class called TIdeaCipher. Now I had all the information I needed, I just had to put it all together. smile
There aren't many IDEA implementations in C#. In fact, there are 2: by BouncyCastle and by LexBritvin. Since I'm not a big fan of huge and complex libraries like BouncyCastle, so I took the simplest possible code: from Github and modified it a bit.
First, we need change password generation algorithm to use MD5 to generate real password:
|
1 2 3 4 5 |
private static byte[] generateUserKeyFromCharKey(String charKey) { MD5 md5 = MD5.Create(); return md5.ComputeHash(Encoding.ASCII.GetBytes(charKey)); } |
Second, we need to add support for CBC mode. It requires both calculating correct IV value and pre/post-processing each block we're encrypting or decrypting.
Calculating IV is quite simple:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
// IV for CBC mode byte[] IV; public Idea(String charKey, bool encrypt) { byte[] key = generateUserKeyFromCharKey(charKey); // Expands a 16-byte user key to the internal encryption sub-keys. int[] tempSubKey = expandUserKey(key); // calculate IV subKey = tempSubKey; IV = new byte[8]; crypt(IV, 0); if (encrypt) { subKey = tempSubKey; } else { subKey = invertSubKey(tempSubKey); } } |
Processing each block is slightly harder but not a rocket science either. As explained in image borrowed from Wikipedia:
.
Before decrypting the data block, we need to store the encrypted values as IV for the next block. After decrypting the block, we need to XOR each byte of data with a corresponding byte of IV. Unfortunately, during encryption the data flow is different, so the simple crypt function has to be replaced with 2 functions: encrypt and decrypt.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
/** * Decrypts array * * @param data * Buffer containing data bytes to be decrypted */ public void decrypt(byte[] data) { for (int q = 0; q < data.Length; q += 8) { // save original bytes for next IV byte[] origBytes = new byte[8]; Array.Copy(data, q, origBytes, 0, 8); // decrypt data crypt(data, q); // xor data with previous IV for (int w = 0; w < 8; w++) data[q + w] ^= IV[w]; // copy original data to next IV Array.Copy(origBytes, IV, 8); } } |
Few more cosmetic changes and that's it! We got clean and nice implementation of EP_CryptDecryptBuffer in pure C#. smile
Download link: https://bitbucket.org/kao/ep_cryptdecryptbuffer/
Have fun!
P.S. My implementation only supports cases where data length is divisible by 8, adding support for other lengths is left as an exercise for the reader.
If your Olly is crashing when loading executable protected by VMProtect, you most likely have outdated dbghelp.dll somewhere on your path. Grab the latest version from Microsoft and put it in the Olly folder.
Well, that might be enough to work around the issue that I had - but I still wanted to know what's causing the crash.
If you try to debug Olly with another Olly, you'll see the Access Violation happening somewhere in dbghelp.dll:
|
1 2 3 |
Log data, item 0 Address=6D529B91 Message=Access violation when reading [C4983C3E] |
|
1 2 3 |
6D529B8E 8B55 F4 MOV EDX,DWORD PTR SS:[EBP-C] 6D529B91 66:833C42 00 CMP WORD PTR DS:[EDX+EAX*2],0 6D529B96 75 07 JNZ SHORT DBGHELP.6D529B9F |
Check register values in Olly:
|
1 2 3 4 5 6 7 8 9 |
EAX 00000000 <---------------- ECX 00000001 EDX C4983C3E <---------------- EBX 0458A390 ESP 0018A450 EBP 0018AC94 ESI 045EE7E8 EDI 045EF738 EIP 6D529B91 DBGHELP.6D529B91 |
For some reason, value in EDX is garbage and therefore access violation happens.
Call stack doesn't tell us much:
|
1 2 3 4 5 6 7 8 |
Call stack of main thread Procedure / arguments Called from Name from PDB DBGHELP.6D52997D DBGHELP.6D52ACFD LoadExportSymbols(struct _MODULE_ENTRY *, struct _IMGHLP_DEBUG_DATA *) DBGHELP.6D52A755 DBGHELP.6D52B035 load(char *, DWORD) DBGHELP.6D52ADB8 DBGHELP.6D5264B2 InternalLoadModule(char *, char *FullPath, char *Str1, unsigned __int64, unsigned __int32, void *, struct _DBGHELP_MODLOAD_DATA *, unsigned __int32) DBGHELP.SymLoadModuleEx DBGHELP.6D526502 DBGHELP.SymLoadModule64 DBGHELP.6D526522 DBGHELP.SymLoadModule OLLYDBG.00491502 |
And same piece of code in IDA doesn't help much either:
|
1 2 3 4 5 6 7 8 9 10 11 |
.text:6D529B8E loop_check_something: ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+225j .text:6D529B8E mov edx, [ebp+ptrAllocatedMemory] .text:6D529B91 cmp word ptr [edx+eax*2], 0 ; <---------------- .text:6D529B96 jnz short loc_6D529B9F .text:6D529B98 add [ebp+var_10], 10h .text:6D529B9C inc [ebp+arg_4] .text:6D529B9F .text:6D529B9F loc_6D529B9F: ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+219j .text:6D529B9F inc eax .text:6D529BA0 cmp eax, ecx .text:6D529BA2 jb short loop_check_something |
So, it's debugging time! Set breakpoint to start of LoadExportSymbols, then set hardware breakpoint on write to address [ebp+ptrAllocatedMemory].
First hit is initialization of variable with 0:
|
1 2 3 |
.text:6D529986 xor ecx, ecx .text:6D529988 test byte ptr dword_6D57F438+1, 4 .text:6D52998F mov [ebp+ptrAllocatedMemory], ecx |
Second hit stores the address of allocated memory:
|
1 2 3 4 5 |
.text:6D529AA7 call _pMemAlloc@4 ; pMemAlloc(x) .text:6D529AAC xor ecx, ecx .text:6D529AAE cmp eax, ecx .text:6D529AB0 mov [ebp+ptrAllocatedMemory], eax .text:6D529AB3 jz loc_6D529D56 |
And third time is a charm:
|
1 2 3 4 5 6 7 8 9 |
.text:6D529AF5 lea edx, [ebp+exportFunctionName] ; 0018A45C .text:6D529AFB sub edx, eax ; EDX = FBAD009A .text:6D529AFD .text:6D529AFD loop_strcpy_overflows: ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+188j .text:6D529AFD mov cl, [eax] .text:6D529AFF mov [edx+eax], cl ; <---------------- .text:6D529B02 inc eax .text:6D529B03 test cl, cl .text:6D529B05 jnz short loop_strcpy_overflows |
Good folks at Microsoft have left us with a nice buffer overflow. exportFunctionName is defined as byte array of size 2048 bytes. Any exported function name longer than that will cause stack overflow and (possibly) subsequent crash.
010Editor with PETemplate confirms that the export name is indeed very long (3100 chars):
From what I can tell, it's a similar (but not the same) bug to what was described by j00ru at http://j00ru.vexillium.org/?p=405 (see "PE Image Fuzzing (environment + process)")
Stay safe!
P.S Here's an example file, if you want to test your Olly: https://forum.tuts4you.com/topic/38963-vmprotect-professional-v-309-custom-protection/
P.P.S. CFF Explorer, HIEW and IDA do not show us any exports in this example file - but that's a matter of another story..
The Flare-On 2016 challenge ended almost 6 months ago and just today I received the coveted police-style badge.. That must be some sort of a record! smile
This update has been long overdue. Finally it supports files larger than 2GB! smile
Full changelog:
Hopefully I didn't break anything during the rewrite. But if I did, send me an email and I'll fix it! smile
EDIT 2x: Very stupid error fixed. /me embarrassed. Sorry.
Last few months people kept bashing antivirus and security software in general. Like on Twitter or their personal pages. Sure, Twitter is full of opinionated idiots who just love to complain about everything that doesn't match their point of view. On a few occasions they are right and even I have written about some of the issues with antiviruses before.
But!
But you'd be f*king stupid to delete your antivirus just because it has some bugs. Doorlocks get picked by criminals every day and people still use them. Professional lockpickers do exist - it's their job to break lock's security mechanism and get you back in the house when you lose your keys. Tavis Ormandy is a professional lockpicker - only he works in the digital world. It's his job to break digital security mechanisms and help vendors to fix the issues.
Having said that, not all software is created equal. Sometimes new and dangerous features get added to an otherwise great software. These features look good on paper but they can really ruin someone's day. Today, I'll demonstrate one such feature.
NetBalancer is a Windows application for local network traffic control and monitoring. It shows you the network traffic on your computer and helps you to set limits, priorities and rules for that traffic. Some sort of a firewall - but better. It can prioritize your traffic, schedule it for specific times, do statistics, make graphs and charts and what not. And it looks really good!
NetBalancer's Predefined Priorities is a feature that looks great on paper.
For those of you who are not sure what priorities are best for your PC we decided in NetBalancer 8.5 to add some predefined priorities.
These priorities include the most used programs and processes, currently about 1700 total (and counting), and are set to match the needs of most users
It could be used for virtually everything:
The possibilities are endless. In fact, virtually all of the antivirus products use similar databases to preconfigure their firewalls. It makes total sense after all!
However, the devil is in the details. All such databases must be maintained. New version of Skype comes out, you need to update database. League of Legends releases new update, you must update the database. And you must do it very fast, so that your users don't suffer from misbehaved firewall. It's a lot of work.
Since NetBalancer is made by a small company called SeriousBit SRL, I was naturally curious how they manage to do that. smile
First, I needed to obtain the complete database of the priorities. You could try to find something in C:\ProgramData\SeriousBit\NetBalancer\ but it would be more interesting to find and download correct files for the official servers, right? smile After a quick string search, I learned that priorities can be downloaded from https://netbalancer.com/api/internal/predefinedpriorities. It's a huge JSON file but isn't encrypted or signed in any way.
That's a serious red flag right there. Security companies vigorously protect their databases - it's their know-how, their crown jewels. And they use digital signatures to make sure that the databases aren't tampered with. After all, which developer wants to see his product in news like "MalwareBytes: multiple security issues"? smile
OK, in this case JSON file is downloaded over HTTPS, therefore it's slightly harder to intercept traffic and modify it. So, let's ignore this issue for a moment and look at the JSON data instead.
In a minute or two, I was in the full "WTF?" mode.
Here's an excerpt from the JSON, prettified for easier viewing:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
{ "$type": "Events.PredefinedPriority, Events", "ExeNameCrc": 1772190657, "Priority": { "$type": "Events.AppPriorityInfo, Events", "AdapterId": -1521929413, "ExecutablePath": "driver.okaya.g200l.rar", "DownloadPriority": "High", "UploadPriority": "Normal", "DownloadLimit": 30000, "UploadLimit": 30000, "DownloadDelay": 0, "UploadDelay": 0, "DownloadDelayJitter": 0, "UploadDelayJitter": 0, "DownloadDropRate": 0.0, "UploadDropRate": 0.0, "PerConnectionLimits": false } }, ... { "$type": "Events.PredefinedPriority, Events", "ExeNameCrc": 3944917558, "Priority": { "$type": "Events.AppPriorityInfo, Events", "AdapterId": 2089926557, "ExecutablePath": "msi1f5.tmp", "DownloadPriority": "High", "UploadPriority": "Normal", "DownloadLimit": 30000, "UploadLimit": 30000, "DownloadDelay": 0, "UploadDelay": 0, "DownloadDelayJitter": 0, "UploadDelayJitter": 0, "DownloadDropRate": 0.0, "UploadDropRate": 0.0, "PerConnectionLimits": false } }, |
Setting high priority for RAR and TMP files.. More than 2000 entries like that? WTF?
How about this?
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{ "$type": "Events.PredefinedPriority, Events", "ExeNameCrc": 4213633860, "Priority": { "$type": "Events.AppPriorityInfo, Events", "AdapterId": -118159810, "ExecutablePath": "sexual babe receives screwed - xnxx.com.flv", "DownloadPriority": "High", "UploadPriority": "Normal", "DownloadLimit": 30000, "UploadLimit": 30000, "DownloadDelay": 0, "UploadDelay": 0, "DownloadDelayJitter": 0, "UploadDelayJitter": 0, "DownloadDropRate": 0.0, "UploadDropRate": 0.0, "PerConnectionLimits": false } }, |
Yes, I want to download my porn with a high priority, thank you very much!
But how on earth that got through the QA process? Is there any QA process in SeriousBit SRL? I highly doubt that..
All those entries made me think - how is it possible that NetBalancer's database contains such crap information? Most obvious answer was - it's submitted by users. To verify the guess, I took a sneak peek inside SeriousBit.NetBalancer.Core.dll. And there it was:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
public static void smethod_1(bool bool_0) { try { ... using (WebClient webClient = new WebClient()) { NameValueCollection expr_77 = new NameValueCollection(); expr_77["priorities"] = gparam_.smethod_0(true); NameValueCollection data = expr_77; bytes = webClient.UploadValues("https://netbalancer.com/api/internal/predefinedpriorities", "POST", data); } catch (Exception arg_126_0) { GClass48.smethod_11(arg_126_0, "LoadFromWww", "C:\\wrk\\seriousbit\\netb\\deskapp\\src\\SeriousBit.NetBalancer.Core\\Priorities\\PredefinedPrioritiesTable.cs", 91); if (bool_0) { throw; } } finally { GClass51.smethod_1<DateTime>("LastPredefinedPrioritiesLoaded", DateTime.Now); } } |
The call is coming from here:
|
1 2 3 4 |
if (GClass51.smethod_0<bool>("PredefinedPrioritiesEnabled", false, true) && GClass51.smethod_0<bool>("LoadPredefinedPrioritiesAutomatically", true, true) && GClass51.smethod_0<DateTime>("LastPredefinedPrioritiesLoaded", DateTime.MinValue, true) < DateTime.Now.AddDays(-7.0)) { GClass30.smethod_1(false); } |
There you have it - if you have enabled "Predefined Priorities", NetBalancer will also silently upload all your priorities to their servers.
Want to wreak some havoc with unsuspecting users of NetBalancer? Post your own JSON file that blocks all traffic for all the browsers - apparently NetBalancer doesn't validate user submissions and will happily distribute them to other users. bigsmile
I was also wondering what is the meaning of ExeNameCrc field. smile Turns out that NetBalancer uses CRC32 of filename as a key in the dictionary that manages process priorities To make matters easier, they also supply you with a proper filename in ExecutablePath field. So, if you want to make sure your malware has unlimited traffic and high download priority, just name it swarm.exe:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{ "$type": "Events.PredefinedPriority, Events", "ExeNameCrc": 1475648703, "Priority": { "$type": "Events.AppPriorityInfo, Events", "AdapterId": 1630508967, "ExecutablePath": "swarm.exe", "DownloadPriority": "High", "UploadPriority": "High", "DownloadLimit": 0, "UploadLimit": 0, "DownloadDelay": 0, "UploadDelay": 0, "DownloadDelayJitter": 0, "UploadDelayJitter": 0, "DownloadDropRate": 0.0, "UploadDropRate": 0.0, "PerConnectionLimits": false } }, |
Indeed, CRC32("swarm.exe") = 1475648703, as you can verify in some online CRC32 calculator..
A quick test confirms that too:
Trust is a delicate subject. On the one hand, all the Cloud and Connected things make your life much easier. On the other hand, you must choose wisely who you trust and what data he/she can access. I doubt that SeriousBit intentionally created such buggy and dangerous feature in NetBalancer. But that doesn't mean I would ever want it to be running on my machine!
Have fun and stay safe!