VBox 4.0.3 (+Xoanon)
As Marigold says, and as we easily can see, VBox protections const of 3 DLLs which are
copied into your \WINDOWS\SYSTEM directories. These DLLs are : VBOXP403.DLL - VBOXB403.DLL
- VBOXT403.DLL. All these DLLs except the first are packed, so we will focus our attention
on VBOXP403.DLL.This DLL acts as a loader/unpacker for the others (among the other things,
again just look at marigold's essay for a complete explanation), so i tought this: if I
find the code which unpacks the DLL, right after the unpacking i can patch *from inside
of VBOXP403.DLL* the protection code which resides in VBOXT403.DLL memoryspace .... and
I did :) Smart approach isn't it ? :)
Note: This kind of patching can be done much easily with a memory patch
(see Stone's essay), but memorypatch
always need a loader, or a TSR-like program to load just before the target. In this way,
we can obtain (as i said) a clean and universal crack which only need to be copied in
place of the original DLL ...
So, stop talking and go on with cracking now ...
First of all, move your system clock ahead so the target expires.
Now, you EXE has been VBoxed with Trial days protection, right? So it will be vulnerable to
BPX GETLOCALTIME from our beloved SoftICE. You will land in this code (after PRET from the
API routine) inside VBOXP403.DLL.We will use the space of this code later to add our
memorypatching code.
:0500E720 81ECCC000000 sub esp, 000000CC
:0500E726 8D442410 lea eax, dword ptr [esp+10]
* we will add memorypatch code here later*
:0500E72A 56 push esi
:0500E72B 50 push eax
* Reference To: KERNEL32.GetLocalTime, Ord:00F5h
|
:0500E72C FF1544C50105 Call dword ptr [0501C544]
:0500E732 8D4C2404 lea ecx, dword ptr [esp+04]
:0500E736 51 push ecx
* Reference To: KERNEL32.GetSystemTime, Ord:0135h
|
:0500E737 FF1540C50105 Call dword ptr [0501C540]
:0500E73D 668B4C240E mov cx, word ptr [esp+0E]
:0500E742 66390D32AC0105 cmp word ptr [0501AC32], cx
:0500E749 7540 jne 0500E78B
:0500E74B 668B44240C mov ax, word ptr [esp+0C]
:0500E750 66390530AC0105 cmp word ptr [0501AC30], ax
:0500E757 7532 jne 0500E78B
Going ahead with tracing, you will find this code in VBOXT403.DLL which checks if the
target is expired or not:
:07005EFB F6451408 cmp eax, [ebp+10]
:07005EFE 7402 jz 7005F02
* NOP it *
and
:7005FAA 3B45F0 cmp eax, [ebp+10]
:7005FAD 751A jnz 7005FC9
* change it to JMP 7005FC9 *
Ok, now theoretically our patch is done.... VBox screen will not appear anymore BUT: we
just did it in memory, how to apply it on the file if VBOXT403.DLL is packed?
Here comes a little Zen, as our +teacher says ... We know that DLL must be unpacked
somewhere, so let's start hunting for the unpacking routine setting a BPM 7005EFE W
(breakpoint on memory range on write). This means SoftICE will popup just when
this memoryspace is accessed for writing
(which is, in our case, the unpacking of VBOXT403.DLL).
Ok, so set this breakpoint and rerun. You will land in our beloved VBOXP403.DLL here:
:0500E856 8BD1 mov edx, ecx
:0500E858 83E203 and edx, 00000003
:0500E85B C1E902 shr ecx, 02
:0500E85E F3 repz
:0500E85F A5 movsd
* this write the unpacked code to DS:EDI *
:0500E860 FF249568E80005 jmp dword ptr [4*edx+0500E868]
:0500E867 90 nop
As you will notice, this routine is executed many times, since the unpacking is done at
little steps. Anyway, we will focus our attention just when EDI reach 07007000. Why? well,
simple: since we want to patch at DS:7005xxx, if EDI reach 07007000 it means the code we
need is already unpacked and ready for our 'rape' :).
Now, problem #2 : we need space to do our memory patch. Easy, look at here ... this code is
of no more use, since the protection is killed. So we can use the memoryspace of this
datecheck code to implement our memorypatch.
First of all, we have to locate the call to this routine and NOP it, since we want to use
it for our purpose. Here it is:
:05002880 6A00 push 00000000
:05002882 E899BE0000 call 0500E720
* just NOP this and the DLL will not call
the datecheck anymore *
:05002887 83C404 add esp, 00000004
:0500288A 50 push eax
Now for the memorypatch. We have to jump to our routine right? so we need to modify this
code right after the VBOXT403.DLL is unpacked in memory:
change
:0500E860 FF249568E80005 jmp dword ptr [4*edx+0500E868]
to
:0500E860 E9C1FEFFFF909090 jmp 500E726
* ok, now this jump to the entrypoint of
our routine *
Here is the memorypatch routine:
:0500E726 81FF00700007 cmp edi, 07007000
* check if the code we need to patch is
unpacked yet *
:0500E72C 7519 jne 0500E747
* act normally if not *
:0500E72E 66C787FEEEFFFF9090mov word ptr [edi+FFFFEEFE], 9090
* patch at EDI-1102 = 7005EFE *
:0500E737 C687ADEFFFFFEB mov byte ptr [edi+FFFFEFAD], EB
* patch at EDI-1053 = 7005FA0 *
:0500E73E 66C787A5EEFFFF9090 mov word ptr [edi+FFFFEEA5], 9090
* patch at EDI-115B = 7005EA5 *
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:0500E72C(C)
|
:0500E747 FF249568E80005 jmp dword ptr [4*edx+0500E868]
* this is the normal jump executed
after unpacking *
:0500E74E 90 nop
:0500E74F 90 nop
You notice I've done another patch at 0500E73E . What's it about? well, it patch this code
:7005E9C F6451408 test byte ptr [ebp+14],08
:7005EA0 BE01000000 mov esi, 00000001
:7005EA5 745B jz 7005F02
* NOP it *
which bypass the 'number of executions' check (another option of VBox, try it with the
builder).
Well ... that's all. VBox is totally dead now, thanks to Marigold and your little xOANINO :)
Go patch the VBOXP403.DLL according to this essay, copy it to your \WINDOWS\SYSTEM overwriting
the original one and say 'CIAO CIAO' to WeiJuhn Li :)
|
VBox 4.10 (Marigold)
This version has a whole bunch of new features:
Checksums for all involved files are authenticated (for VBOXT410 twice) <----+
Checksums for DLL's images in memory are calculated (for VBOXT410 � twice) <- Xoanon's crack R.I.P
Debugger presence in memory is detected <- Bye, bye hopes for virginity restoration
Diassembling of VBOXP410.DLL crashes W32DASM; IDA works but gives wrong disassembly
At first, I was deeply impressed (You know ... a dead body in a room closed from inside
... perfect crime). I prepared myself for long and hard struggle: I unpacked
VBOXT410.DLL, redirected file checksum calculation to the original packed file, add a
section with a copy of original unchanged code and redirected image checksum calculation
to it (it only sounds simple ...). You see, I imagined, knowing Weijun Li ways,
that the check for debugger presence implicated some subtle modification inside the hash
functions, for example, and that it would have been not easy, if ever possible, to find
and remove it. So, I planned to use this modified DLL to collect information, necessary
for unwrapping, without using SoftICE.
You will understand my disappointment when, after sorting things out, I found a function
that simply sets a flag; then this flag is tested, ... jumps ... all that primitive stuff
... 'A paper Tiger', in a word. The only hope, this version must have been made in haste,
and the next will show, at last, those crackers a thing or two. Well, let's hope it!
Here is that unfamous call:
:07006F4B 6A00 push 00000000
:07006F4D 6AFF push FFFFFFFF
:07006F4F 683B9D0000 push 00009D3B
:07006F54 8D8D34FEFFFF lea ecx, dword ptr [ebp+FFFFFE34]
:07006F5A E8E1220100 call 07019240
:07006F5F 8945BC mov dword ptr [ebp-44], eax
In presence of debugger this function returns 26h, change eax to 0 and you will never see
again that awful message: 'If you are using a debugger ...'
Other things to mention:
Image checksum is calculated here:
:070066EA 8BC3 mov eax, ebx
:070066EC 33FB xor edi, ebx
:070066EE F7D0 not eax
:070066F0 3145B0 xor dword ptr [ebp-50], eax
:070066F3 8D85F0FDFFFF lea eax, dword ptr [ebp-210] <- Buffer for checksum
:070066F9 50 push eax
:070066FA 8D8520FFFFFF lea eax, dword ptr [ebp-E0] <- Relocation table
:07006700 81F7494C0000 xor edi, 00004C49
:07006706 50 push eax
:07006707 57 push edi <- Code length
:07006708 33F3 xor esi, ebx
:0700670A FF75B0 push [ebp-50]
:0700670D 81F64A570000 xor esi, 0000574A
:07006713 8975C4 mov dword ptr [ebp-3C], esi
:07006716 89BD0CFFFFFF mov dword ptr [ebp+FFFFFF0C], edi
:0700671C 56 push esi <- Code RVA
:0700671D FF7584 push [ebp-7C]
:07006720 E843120000 call 07007968
and here (parameters are the same):
:070071B2 8D8514FEFFFF lea eax, dword ptr [ebp+FFFFFE14]
:070071B8 C645FC23 mov [ebp-04], 23
:070071BC 50 push eax
:070071BD 8D8520FFFFFF lea eax, dword ptr [ebp+FFFFFF20]
:070071C3 50 push eax
:070071C4 FFB50CFFFFFF push dword ptr [ebp+FFFFFF0C]
:070071CA FF75B0 push [ebp-50]
:070071CD FF75C4 push [ebp-3C]
:070071D0 FF7584 push [ebp-7C]
:070071D3 E890070000 call 07007968
Remember, that any active SoftICE's BPX actually changes the code, so clear them away before
these calls.
File (VBOXT410.DLL) checksum is calculated here:
:07006F62 8D458C lea eax, dword ptr [ebp-74]
:07006F65 50 push eax
:07006F66 8D8504FFFFFF lea eax, dword ptr [ebp+FFFFFF04]
:07006F6C 50 push eax
:07006F6D A138FE0407 mov eax, dword ptr [0704FE38]
:07006F72 FF7028 push [eax+28]
:07006F75 E836DF0000 call 07014EB0
Another check is made inside VBOXB410.DLL, which passes the result to PreviewParadise as
combination of two parameters:
:070072D8 8B450C mov eax, dword ptr [ebp+0C]
:070072DB 8B4D2C mov ecx, dword ptr [ebp+2C]
:070072DE F7D0 not eax
:070072E0 33C8 xor ecx, eax; 1=OK
:070072E2 7510 jne 070072F4
When you know all this, you may restore virginity of the target in the same way as with the
previous version. There are some minor changes in headers of packed sections and other
things ... If you are really going to do this, you will easily sort it out.
But what about a Xoanon-style universal crack for all VBoxed programs? I've got it as a
by-product of solution to my main objective (total unwrapping, you remember).
The modified VBOXT410.DLL I made allows any patching in its code ...
Any questions?
|
VBox 4.10 (Victor Porguen)
In Fravia's prologue to my previous essay , 'Defeating File Integrity Checks Through
Redirection', he observed that 'viral research applied to reversing has quite a lot
to offer ...' This article will describe traditional viral coding techniques as
applied to time limited software. Specifically, I will detail a simple,
straightforward concept of code redirection and apply it to the VBOX 4.10
protection system by Preview Systems. The resulting patch will allow the
full use of any program protected by either the trial version or commercial version of
the product. However, as an initial caveat I will point out that *all* 'VBOXx410.DLL'
files are not identical;
indeed, they are not even compatible between themselves (which would most assuredly be
an irritant if you had actually purchased a VBOX protected application that relied on
a version that was subsequently replaced during a 'trial' session of another product).
While the specific coding described herein may be readily applied to any VBOXx410.DLL
'set of files', and indeed I have tested it successfully on every set I could find, it
is important that the reader realize that there are differences between the sets
themselves.
As a matter of professional courtesy, I will reference the reader to the recent essay
by Marigold, whom I regard with respect, entitled 'VBOX The Hellraiser or the Paper Tiger'
(for a fleeting moment I was tempted to subtitle this essay 'Hellraiser II,
Pinhead's Crack' but better judgment overcame me). The reader should note the
references contained in that article to the 'debugger check' used by VBOX in light of the
fact that the patching technique that I outline will leave that code untouched, thus
VBox protected programs will continue not to function if a debugger is in the background.
The defeating of that routine is not difficult, however, but I shall leave that pursuit
to the reader.
The Goals - I began this essay with three goals in mind: 1) Devise a simple crack that
would thoroughly defeat all VBOXx410 protected applications; 2) Do so with a minimum
amount of byte changes, say no more than 250; and 3) In view of the integrity checks
that are rampant in VBOX, make no code changes to the program. This last goal may sound
impossible (perhaps it is if one takes a truly strict interpretation of the meaning),
but the goal was indeed achieved through the use of API redirection (and the overwriting
of some unused text).
What Viruses Can Teach Us - When we initially began writing computer viruses, and using
'stealth' techniques to hide their presence, we did so by replacing the address for the
DOS interrupt 21 and BIOS Int 13 handlers in the interrupt vector table. Calls by
integrity checking programs to open and read files or sectors could then be
intercepted and the viral code replaced with the original code. However, simply hooking
the address in the IVT was of no help if the integrity checking routine had already
hooked the interrupt and thus was sitting below us (FluShot was an example, as where
the myriad of 'write protect your hard drive' programs that hooked interrupt 13). Our
first attempt to overcome this obstacle was the 4096 virus in which we placed a FAR JMP
to the viral code at the beginning of the interrupt 21 handler which would then replace
the five byte 'cut-out' allowing us full access to the DOS routines. The trap flag was
then set placing the CPU in single-step mode. A few instructions into a DOS call our
interrupt 1 routine would then reinsert the five byte 'cut-out' thus always maintaining
control over the DOS operating system.
Detecting the 'lowest point' of either the DOS or BIOS interrupt vector chain was
easily accomplished by setting the trap flag and sending an innocuous call through the
chain and observing the address on the stack during the interrupt 1 routine.
Why This is Important - The stealth routine implemented by the 4096 virus was quite
successful (so much so, in fact, that it 'escaped' into the wild before we had a
chance to fully complete it ... but that is another story). If you can take control of
the operating system, there are virtually no restraints on your abilities. By implementing
the FAR JMP of the 4096 virus we actually modified the DOS operating system. We can do the
same with a time limited, heavily protected, WIN95 application (well, almost -
we will not directly modify the operating system because of ring transition problems,
however we will do just as well). By taking hold of the appropriate APIs we can dole
out the required return values to the application as well as 'feed' the correct parameters
to both the application and operating system itself - this is what I mean by
'Achieving Redirection Through API Spoofing.'
VBOXx410: How to Crack It, Step by Step - The first step in cracking any time limited
program is to achieve a successful execution of the application, while under a debugger,
after the time limitation has expired; only then may the 'theoretical' crack be written
to the executable. The VBOX protection system, however, uses a routine to detect the
presence of a debugger and Marigold describes it in his essay. While it may be time
consuming to locate such a routine with software tools only, executing the application
simultaneously on identical machines, one equipped with SoftICE and the other with a
hardware based in-circuit emulator, readily highlights the discrepancy in the return
value of EAX from the CALL 7019240 at offset 7006F5A. It is understandable that the
vast majority of readers do not have access to hardware based debugging tools and it
is sufficient to merely keep in mind that a BMPB 7006F5A X followed by an execution
of the CALL and manually setting EAX to zero while under SoftICE will suffice to allow
the program to execute normally under a debugger. The reader is cautioned that, because
of the VBOX code integrity routines, only debug register breakpoints should be used
(except, of course, within our stealth routine) as opposed to traditional CC
breakpoints.
Stepping through the code we come to the DialogBoxParamA call at offset 70025C3 in the
'Trial' version or offset 8002912 in the 'Commercial' version, which displays the VBOX
Time Limitation screen. The return value for 'Try' is zero, the value for 'Quit' is
one. Again, clicking the 'Quit' button and then manually setting the value of EAX to
zero while under SoftICE will allow the program to continue. The final procedure is
to step through the code until we reach the RaiseException call at offset 7035629 which
displays an expiration message and exits. If we simply 'step over' this call, and adjust
the stack accordingly, the program executes flawlessly. Thus, the crack to the entire
VBOX protection system, whether it be the Trial or Commercial edition is to have the
DialogBoxParamA call return zero and to have the RaiseException call return without
executing. Nothing could be more simple; the challenging part, however, is implementing
the crack in view of the varied and diverse protection routines that VBOX implements
(i.e., packing, memory image checks, encryption, etc.)
Obviously we can not simply NOP out the code, since it is both packed and repeatedly
checked. However, does VBOX require the CALLs be executed at all? We know the answer
is 'No' for the RaiseException call, but does the DialogBoxParamA call have to
be executed or does VBOX merely check the EAX register upon the return? Again we step
through the code with SoftICE (remembering to deal with the debug check routine)
and break on DialogBoxParamA. Instead of executing the CALL, we manually set the EIP
register to the offset of the instruction following the CALL and adjust the stack
accordingly. We then set EAX to zero and allow execution of the program ... and
the program fails. We now know that the DialogBoxParamA call must be executed to
satisfy the VBOX protection system.
The next step is to determine where our 'working room' will reside. Looking through
the VBOXP410.DLL we see it was compiled with the Microsoft Visual C++ Run Time Library,
which politely includes a variety of wasted and useless code and text. An area that
immediately jumps out as a possible working area is the vast list of geographic sites
beginning around file offset 206D4 or so. Starting with the beloved homestead of Turkey
(at file offset 20718) we simply overwrite two or three hundred bytes of text with
zeroes and execute the program - and it runs perfectly. VBOX is not checking this
portion of the file either in memory or on disk; thus we now have plenty of room in
which to insert our 'stealth cracking routine'. Once again, we fire up SoftICE and break
(remembering to use debug registers only because of the integrity checking routines)
on the entry point to VBOXP410.DLL, which is at memory offset 5001F99. This corresponds to
file offset 1399 and is where we will insert our 'cut-out' to the stealth routine.
But before we modify the executable on disk we must first determine whether VBOX is
checking the integrity of the replaced code from the disk file itself (we are not
concerned whether VBOX checks the code in memory because we will have restored it).
However, since our stealth routine will be changing memory, we must modify the PE header
so that the .text and .rdata sections are writable. Currently, the characteristics for
.text are Code, Executable, Readable (60000020) while .rdata has the characteristics of
Initialized Data, Readable (40000040). Both of these double word entries must be modified
so that the sections are writable (otherwise our stealth modifications will create page
faults). The determination of whether VBOX is checking the integrity of these code
areas from the disk file is easily made: Simply make the header changes on the disk file
and overwrite the 'cut-out' with five NOPs, then we set a BMPB 5001F99 X and execute the
application. When SoftICE breaks on the loading of VBOXP410.DLL at 5001F99 we manually
insert the original code and allow the application to continue loading and executing
normally (still remembering the debug detection code). The program executes normally
and thus confirms that VBOX is not checking the integrity of either the header or the
location of the cut-out code from the disk file - it is essentially all 'down hill' from
here.
For ease of understanding, the following is the cut-out and stealth routines in
'source code' format. Appendix A has the SoftICE dump of the actual byte values that
correspond to the memory offsets and byte values of the code. This is the crack that
defeats VBOX 4.10:
Entry_Point
jmp Restore_Original_Code
^
|
|--- VBOXP410.DLL Code Is Here
|
v
Restore_Original_Code:
mov dword ptr [Entry_Point],020496B8
mov byte ptr [Entry_Point+4],05
mov eax,[KERNEL32!EnterCriticalSection]
mov dword ptr [KERNEL32!EnterCriticalSection],New_Critical_Handler
mov [Critical_Section_Hdlr],eax
jmp Entry_Point
Counter:
dw 0
Critical_Section_Hdlr:
dd 0
DLG_Hdlr:
dd 0
DLG_Procedure_Hdlr:
dd 0
Return_From_DLG:
dd 0
New_Critical_Handler:
inc word ptr [Counter]
cmp word ptr [Counter],4000
jz Hook_DialogBox_for_VBOXC410
cmp word ptr [Counter],2EOO
jnz True_Critical_Handler
Hook_APIs_for_VBOXT410:
mov dword ptr [KERNEL32!RaiseException],New_Exception_Handler
mov eax,[USER32!DialogBoxParamA]
mov [DLG_Hdlr],eax
mov dword ptr [USER32!DialogBoxParamA],New_Dialog_Handler
jmp True_Critical_Handler
Hook_DialogBox_for_VBOXC410:
mov eax,[USER32!DialogBoxParamA]
mov [DLG_Hdlr],eax
mov dword ptr [USER32!DialogBoxParamA],New_Dialog_Handler
True_Critical_Handler:
jmp [Critical_Section_Hdlr]
New_Exception_Handler:
ret 10
New_Dialog_Handler:
mov eax,[esp+1O]
mov [DLG_Procedure_Hdlr],eax
mov dword ptr [esp+1O],New_DLG_Procedure_Handler
pop dword ptr [Return_From_DLG]
push Back_From_DLG_Call
jmp [Dlg_Hdlr]
Back_From_DLG_Call:
xor eax,eax
mov word ptr [New_Critical_Handler],4feb
jmp [Return_From_DLG]
New_DLG_Procedure_Handler:
cmp dword ptr [esp+08],18
jnz True_DLG_Procedure_Handler
mov dword ptr [esp+08],111
mov dword ptr [esp+OC],495
True_DLG_Procedure_Handler:
jmp [DLG_Procedure_Hdlr]
An Explanation of the Code - The entry point is the location of the five byte 'cut-out' code
and, specifically, is located at file offset 1399 and memory offset 5001F99. Upon loading of
the DLL, this cut-out code is immediately restored by the RestoreOriginalCode routine, thus
all of VBOX's code is now identical to the unpatched version. We have achieved Goal #3 and
consequently all of VBOX's memory checking routines will confirm the integrity of that code.
The RestoreOriginalCode routine also serves another purpose: It 'hooks' the
EnterCriticalSection API that VBOX must call to allow for mutual exclusion synchronization
and replaces it with New_Critical_Handler.
The New_Critical_Handler routine is responsible for waiting for the VBOXT410.DLL
(and VBOXC410.DLL, for the commercial version) to unpack and then it will hook the
RaiseException and DialogBoxParamA APIs, which are the focal point of our crack.
The RaiseException API is vectored to the instruction RET 10, which of course does nothing
more than RETURN with a bit of stack cleanup. DialogBoxParamA is vectored to
New_Dialog_Handler, which is a bit more clever.
The New_Dialog_Handler routine accomplishes two tasks: 1) It replaces the RETURN value on the
stack with the offset of Back_From_DLG_Call; and 2) It hooks the DialogBoxProcedure that
processes messages sent to the dialog box with New_DLG_Procedure_Handler.
New_DLG_Procedure_Handler watches for the ShowWindow message to be sent by the operating
system to the dialog box and replaces it with the message and parameter necessary to close
the box. Control is then returned to Back_From_DLG_Call which places a zero in the EAX
register and then 'closes the door' on the New_Critical_Handler by placing a
JMP True_Critical_Handler instruction (EB 4F) as the first instruction of that routine. We
then JMP back to the VBOX code that followed the CALL DialogBoxParamaA that had transferred
control to our New_Dialog_Handler. Shortly thereafter VBOX will attempt to display the
'expired' message by way of the RaiseException API. Of course, we have hooked that code
with New_Exception_Handler and will courteously return to VBOX without executing the CALL.
The program will then execute normally.
A Summary, Please - Here is the logic flow: 1) VBOXP410.DLL loads; the cut-out code jumps to
the stealth routine that replaces the cut-out code, hooks EnterCriticalSection, and chains
back to VBOXP410.DLL. 2) The New_Critical_Handler waits for VBOX to 'drop its pants' and then
hooks the RaiseException and DialogBoxParamA. 3) The New_Dialog_Handler then 'spoofs' the
ending of the dialog box, and the return values to the application, by feeding the VBOX
dialog box procedure the values it would like to see, at exactly the right time that it
would like to see them, and by intercepting the return. 4) The RaiseException call by VBOX
is then intercepted and RETURNs without doing anything.
A Request To The Reader - Of course, this essay is not intended to encourage the theft of
software programs, or any intellectual property for that matter. Instead it is designed to
foster a better understanding of reverse engineering techniques and software protection
systems. I hope you enjoyed reading this essay, and perhaps learned something as well. If
you did, I would appreciate it if you would drop me an email letting me know your thoughts.
I would very much enjoy hearing from you.
Appendix A - Byte Values and Memory Offsets
; (The Cut-Out Code) This corresponds to File offset 1399 in VBOXP410.DLL
5001F99 E97AF90100 JMP 05021918
^
|
|--- VBOXP410.DLL Code Is Here
|
v
;(The Stealth Routine) This corresponds to File offset 20718 in VBOXP410.DLL
5021918 C705991F0005B8960402 MOV DWORD PTR [05001F99],020496B8
5021922 C6059D1F000505 MOV BYTE PTR [05001F9D],05
5021929 A1AOB50205 MOV EAX,[0502B5A0]
502192E C705AOB5020554190205 MOV DWORD PTR [0502B5A0],05021954
5021938 A344190205 MOV [05021944],EAX
502193D E95706FEFF JMP 05001F99
5021942 0000
5021944 0000
5021946 0000
5021948 0000
502194A 0000
502194C 0000
502194E 0000
5021950 0000
5021952 0000
5021954 66FF0542190205 INC WORD PTR [05021942]
502195B 66813D421902050040 CMP WORD PTR [05021942],4000
5021964 742B JZ 05021991
5021966 66813D42190205002E CMP WORD PTR [05021942],2EOO
502196F 7534 JNZ 050219A5
5021971 C70590890507AB190205 MOV DWORD PTR [07058990],050219AB
502197B A1348A0507 MOV EAX,[07058A34]
5021980 A348190205 MOV [05021948],EAX
5021985 C705348A0507AE190205 MOV DWORD PTR [07058A34],050219AE
502198F EB14 JMP 050219A5
5021991 A1E8760808 MOV EAX,[080876E8]
5021996 A348190205 MOV [05021948],EAX
502199B C705E8760808AE190205 MOV DWORD PTR [080876E8],050219AE
50219A5 FF2544190205 JMP [05021944]
50219AB C21000 RET 0010
50219AE 8B442410 MOV EAX,[ESP+10]
50219B2 A34C190205 MOV [0502194C],EAX
50219B7 C7442410E1190205 MOV DWORD PTR [ESP+10],050219E1
50219BF 8F0550190205 POP DWORD PTR [05021950]
50219C5 68D0190205 PUSH 050219DO
50219CA FF2548190205 JMP [05021948]
50219DO 33CO XOR EAX,EAX
50219D2 66C70554190205EB4F MOV WORD PTR [05021954],4FEB
50219DB FF2550190205 JMP [05021950]
50219E1 837C240818 CMP DWORD PTR [ESP+08],18
50219E6 7510 JNZ 050219F8
50219E8 C744240811010000 MOV DWORD PTR [ESP+08],00000111
50219FO C744240C95040000 MOV DWORD PTR [ESP+OC],00000495
50219F8 FF254C190205 JMP [0502194C]
|
VBox 4.20 (PLUMe)
Tools required
TRW and MKPE
SoftICE
You may have already heard of TR&TRW. It is a wonderful debugger provided by
Liutaotao. I could't say have much I like it. VBOXT410.DLL can't find TRW at all.
I could't give you a patch for VBox. I just can tell VBox how to work.
First of all, install the VBox builder (you need to get a .prv file from their
webserver, so connect to the internet for this and fill the form needed). Then
choose a .EXE file to protect (you could choose also a .DLL or an .OCX, but
choose an .EXE because it's better and easier for cracking purposes. I choose
Official phrozen crew trial crackme) and wrap it with VBox using the builder
(choose now the Trial days protection).
Now the fun begins. And as we can easily see, the whole VBox protection scheme consist
of only one dll which is copied into your \WINDOWS\VBox\command directories. The name
of our target DLL is VBOXT402.DLL. It is packed.
Step 1
Here I'll show you how to use TRW.
Run TRW, select 'hide' button.
Then a green icon appear at right corner.
You can hit right button on it. It appear like that.
Step 2
Let's change time to 30 days later. Now you can run CRACKME.EXE. When VBox window appears,
CTRL-N, enter TRW. You can use 'hwnd' to find VBox window's hwnd. Something like xxxx.
bpmsg xxxx wm_destroy - just like in SoftICE
g - come back to VBox
Press 'quit' button.
Now you are in TRW.
bc * - clear break point
Press F12 a few times, until you come here in VBOXT402.DLL
07006079: call [dword dialogparama]
0700607f: mov esi,eax ; if you press 'try' eax=0, 'quit' eax=1; so
change eax to 0 ... r eax 0.
There have some others check
07001c03: cmp [ebp-10],eax ; if eax=[ebp-10], error dialog will appear; so
change eax
07001c06: jne 07001c2c
07001c08: lea eax,[ebp+10]
07001c0b: lea ecx,[ebp-74]
07001c0e: push eax
07001c0f: mov [ebp-78],ebx
07001c12: call 0702e7d0
07001c17: lea eax,[ebp-7c]
07001c1a: push 07070568
07001c1f: push eax
07001c20: mov [dword ebp-7c],0706e004
07001c27: call 070570a0
07001c2c: lea ecx,[ebp-28]
07001c2f: mov [byte ebp-040,04
07001c2c: lea ecx,[ebp-28]
07001c2f: mov [byte ebp-04],04
07001c33: call 0702d440
07001c38: lea ecx,[ebp-18]
07001c3b: mov [byte ebp-04],02
07001c3f: call 0702d440
.......
07001c7c: call 07032570
07001c71: cmp [ebp-10],eax ; Another check.
07001c74: jne 07001f9b ; if eax=[ebp-10], error dialog will appear. So
change eax
Ok, now theoretically our patch is done ...
1. 07006079: call [dword dialogparama] patch to
07006079: xor eax,eax
0700607b: nop
0700607c: nop
0700607d: nop
0700607e: nop
2. 07001c06: jne 07001c2c patch to
07001c06: jmp 07001c2c
3. 07001c74: jne 07001f9b patch to
07001c74: jmp 07001f9b
VBox screen will not appear anymore BUT: we just did it in memory, that's not permanent, as
you all know very well ... We must now apply our patch on the real file. But VBOXT403.DLL is
packed?
Step 3
Close TRW. (TRW's bpm function doesn't seem to work there)
Let's run SoftICE. (VBox Unpacked code firstly, then check SoftICE)
load crackme.exe
bpm xxxx: 07006079 w;
Ok, so set this breakpoint and rerun. You will land in VBOXT410.DLL here:
009c01b7: repz movsd
009c01b9: mov ecx,edx
009c01bb: and ecx,03
.......
Oh my GOD!! It is encrypted before running. Therefore you could't find these code
inside VBOXT410.DLL.
bpm xxxx: 009c01b7 w;
So set this breakpoint and re-run. You will land in here:
00a001b7:repz movsd
00a001b9:mov ecx,edx
00a001bb:and ecx,03
.......
Try again.
bpm xxxx:00a001b7 w;
So set this breakpoint and re-run. You will land in here:
07093c27:mov [edi],al
07093c23:inc edi
07093c24:inc ebp
.......
Try again.
bpm xxxx:070093c27 w;
So set this breakpoint and rerun. You will land in here:
:07093422 03D0 add edx, eax
:07093424 C1E902 shr ecx, 02
:07093427 F3 repz
:07093428 A5 movsd ; here!!!
:07093429 8BCD mov ecx, ebp
:0709342B 89542414 mov dword ptr [esp+14], edx
:0709342F 83E103 and ecx, 00000003
:07093432 F3 repz
:07093433 A4 movsb
:07093434 8B4344 mov eax, dword ptr [ebx+44]
Yes,you can find these code in VBOTT410.DLL
It is almost same when you bpm xxxx:07001c06 or bpm xxxx:07001c74
Frankly, I did not find an elegant way to patch it. It modifies itself quite a lot.
If find an elegant way to patch it, please let me know.
Now I try to get a clean routine using another approach. But it does not always work, beware!
So let's forget for a while our VBOXT402.DLL. We just want a clean routine.
Run TRW.
Change eax at:
1. 07006079: call [dword dialogparama]
2. 07001c06: jne 07001c2c
3. 07001c74: jne 07001f9b
So I just run our 'Official phrozen crew trial crackme' a window pop-up. Press 'ok', enter
it's main routine window.
Now find its hwnd (you know how to do this, I hope :-), and then just bpmsg on
it inside TRW.
Now: g; go back to phrozen's window,press 'exit'.
Just like before TRW pop-up. Press F12 as long as needed to find the relevant
code ...
00401029: push 00
00401030: push 00401046
00401032: push 00
00401034: push 01
0040103a: push dword 0402dd87
0040103f: call 00401313
00401041: push 00 ; you land here
00401046: call 0040127d
.......: ...
You can go to xxxx:00401029 directly and dump it from memory using 'pedump' command.
Then you get dump1.exe.
MKPE dump1.exe -a -s -f -i3 -ldlllist.sam
FILEOUT.EXE is our 'clean' routine, and it works very well ... so byebye VBox 4.2
As you can now see -once more- commercial ready-made protections are not
so secure as they claim (look at http://www.previewsoftware.com).
But at times my FILEOUT.EXE approach doesn't work ... I wonder why ...
Unfortunately I did not find any clear patterns to reverse this little mistery. If you
understand this, or if you have any other good methods for this target, please
let me know,
we will modify together this essay.
|
VBox 4.20 (alpine)
Tools required
SoftICE
ProcDump
Step 1: The annoying anti-debug trick
Start your OS without SoftICE enabled. Load your program into TurboDebugger and run it
(F9). It will break on an INT 3. Look at SI and DI and you gonna see the magic
values (SI=4647h; DI=4A4Dh). Step over the INT 3 till you passed the RET. Write
down the address of the JuMP (jmp [ebp-07]). You can now quit TurboDebugger.
ebp-07 points to the temporary buffer where the INT 3 and other instructions are executed.
Now reboot with SoftICE enabled.
The ad-trick works like the following:
VBox sets up SEH and then CALLs our INT 3. If SoftICE is present it
will handle the INT 3 without raising an exception, therefore VBox knows SoftICE is
installed. If an exception gets raised the program continues as normal.
Load the program into Symbol Loader. Now set a breakoint on that location, you wrote down
before. But don't use BPX due to CRC-checks. Use BPMB X. Now run it; back in
SoftICE we're gonna raise an exception. Edit the value stored at [ebp-07] to 0 by typing
ed (ebp-07) 0 . That will cause one. Now press F5 and you don't get that annoying temper
message but you get a dialogbox. Press 'Try' and you'll get kicked back to SoftICE again.
Another time change the value at [ebp-07] to 0. Before pressing F5 ... we've to set a
breakpoint
Step 2: Finding final jump
In order to find the final JuMP we've to know what the program is doing next. At least we
can assume it :) It has to get the addresses of the APIs we use in our program. This is
done through GetProcAddress. Break on that using BPX GetProcAddress . Now press F5 ...
back in SoftICE disable all breakpoints and get out of the GetProcAddress CALL by pressing
F12.
Now a kind of annoying thing comes: stepping through masses of code :)
It's not that hard ... I'm gonna shorten it up. You could search for the opcodes to short
it up:
53,53,FF,D6,5B,85,C0,74,2E,68,00,80,00
This should be something like that:
push ebx
push ebx
call esi
Anyway you'll find your way till there (1 min to step to that location). Trace into
CALL ESI there you'll only find one CALL ... step into it
Then step, step, step till you come accross a CALL EAX - don't step into it ... the next
CALL is the last we're gonna to step into. Trace ... and you'll find
mov ebx,[ebp-14]
jmp ebx
That's the final JuMP (EBX is of course the entry point of your program).
JuMP (write down EBX). Step to it, but don't execute the JuMP. Now enter an
infinite loop with
' a eip'
'jmp eip'
Step 3: Dumping the paradise
Open ProcDump. Select the program from the task list. Right-click on it and select full
dump - save it. Open up the PE-Edior and change the entry point to what you saw in EBX
(remember entrypoint= 'what you saw in EBX'-'imagebase'). Now just make it more
comatible and open the file into rebuild PE.
You've now a program without VBox :)
|
|
00. INDEX
09. Commerical Protection Systems
7 VBox