VXDennis the menace Fun with VRAMDIR v1.07	Our tools
1 February 1998	by CoreFixar aka ThunderLord
	Courtesy of Fravia's page of reverse engineering
	Well ThunderLord's advice is correct. And it is a very good idea: we are (supposed to be) master crackers, so there is no point, for us, in producing keygenerators for the zombies, or to diffuse already regged proggies on the web for all lusers and idiots to leech and steal. We have A LOT more to study and to learn on our own steil road to wizardry. So if we find, like here, a program written by a VXD guru, let's get this guy with us, let's have him working with us on our own tools, and let's NOT ruin his application making it available for everybody. Thunderlord's point is a very good one: work on this target (we'll do it all -of course- because we need these techniques ourselves) but keep this target safe from the lusers. Let's hope that the guy who wrote it will give us some teachings or help in exchange... if he does we'll offer him a ready made solide protection for his app, like a binary bit-calculated password or something even more strong :-) so that his app will be (in the next version) safe from lamers.
	There is a crack, a crack in everything That's how the light gets in
Rating	(x)Beginner (x)Intermediate ( )Advanced ( )Expert

I first met VRAMDRIVE when I tryed using Micro$oft's own RAMDRIVE.SYS, which
as always had 
troubles in it, like: "Invalid DOS version and stuff...". So I
searched the web for some new 
RAM drive replacer and found this wonderfull tool.


It is especially usefull if you are working to much with many files, like the
archives you 
download from the web to check out, and you don't want to strain
your harddrive. At the same 
time you are getting higher perfomance and less fragmentation
:) So I hope I made my point 
about the usage of this program, so let's take a
closer look at it...

The first interesting thing is that there is no installation program, just a
simple 
batchfile, which copies some registry updating files and merges them into
the registry. 
That's good, cause there is no "hidden" installation going on...
only the things needed :)

This application consists of two main files: the control panel applet and the
VXD driver. 
The control panel applet is very simple and is only used for adding/deleting
the RAM 
folders. There is even no nag in it. The other thingie is much more advanced:
a virtual file 
system hooking VXD, which mapps the content of the directories
into the memory and this way 
it speeds up the disk access. The most wonderfull
thing is that it resizes the used memory 
according to the directory emptyness...Well
other perfomance stats can be read in the README 
file supplied with application.


The only nasty thing is that this is a demo, and it unloads itself from the memory
in 30 
minutes, writing all the virtual files to disk. So unless you want to boot
ya machine at 
1/1800 Hz (remember this number - "once every 1800 seconds, or
1800000 miliseconds" :) , 
you'll need it to reverse this program.

At first let me say that there would be used no live debugging at all. This can
be explained 
with the fact, that WinIce loads itself as a VXD, therfor it can't
debug other drivers at 
the boot time (correct me if I am wrong, but I tryed and
failed). Therefor we'll only be 
using the deadlist approach which I learned from
+ORC's tutorials from Fravia's site :)

Try loading the vxd in the wdasm - you'll get some garbage without any x-refs
and even 
without the entry point !!! So I loaded it into my trusty ida (Grrrr...)
Which unassembled 
it pretty good. Many procedures were left as undiscovered,
so it is recommended to mark them 
manually. (Use the "C" to mark as Code, and
then as a "P" for procedure).

When I first saw the deadlisting I was astonished how nice it was. I mean all
instructions 
are very clear and all intentions seem throw. It is a perfekt vxd
learning material, the 
only thing is the size of the asmfile - about 260 kb,
which is too much to comment and see 
through in one day. So I started to browse
through all procedures, and almost forgot that I 
was looking for the protection
sheme. Then I had to interrupt myself and to continue the 
standart "Register..."
search :)

But now I know what I'd do on my school holidays - A nice garden chair, 2 liters
of herbtea, 
and 200 pages of vramdir asmcode to enjoy...

Suddenly I saw this:



aThisIsTheTrial	db 'This is the trial version of VRAMDIR. The 30-minute trial
period has
 '

		db 'expired.',0Ah

		db 'From now on files will be written to disk. You',27h,'ll get another '

		db '30-minute the next time Windows starts.',0Ah

		db 'See README.TXT for information on how to get a registered copy.',0



This is easyer than it could have been. The following is just a standart "How
I cracked that 
proggy" stuff:

I checked the reference where this string points to:



;here is the proc which snaps both message and then disables the virtual effect
of a folder

SubTheNag	proc near		; DATA XREF: SubMainEngine+483o

		xor	eax, eax

		push	eax               <-- series of NULL pushes for the following call

		mov	ds:hTimeOutReturn, eax <-- Erases the handle to 30 minute timer

		push	eax

		push	offset aThisIsTheTrial <-- Message to show

		push	offset SubShowNagMsg <-- Sub to continue on, after the VXDJumpCall

		call	SubVJAtAppTime <-- Combination of the call and VXDJumpCall

		mov	ds:fNagOccuredFlag, 1 <-- Bool Flag which indicates if the program

		add	esp, 10h              should begin writing virtual files to disk

		retn	

SubTheNag	endp



;this proc is called by the SubTheNag, and it illustrates how VXD's use their
vxdAPI 
functions

SubVJAtAppTime	proc near		; CODE XREF: SubTheNag+13p

		VxDjmp _SHELL_CallAtAppyTime

SubVJAtAppTime	endp

;After the jump, it returns to previously pushed location, in our case SubShowNagScreen


; we even prepared the offsets for it in the SubTheNag



;this proc is returned to after disabling the ramfolder and it shows a message


SubShowNagMsg	proc near		; DATA XREF: SubTheNag+Eo

		push	ebp

		mov	ebp, esp      <-- Stack Frame, DUH

		push	offset aVramdir <-- A string "VRAMDIR"

		push	dword ptr [ebp+8] <-- 2 Params for the next call

		push	10001000h

		call	SubVGetCurVMhan <-- Again that funny call and jump iside the proc

		push	eax

		call	SubVSysModMsg <-- !!! SysModalMessage to show the nag

		pop	ebp

		retn	

SubShowNagMsg	endp



; 2 jumpprocs called in the abouve proc

SubVGetCurVMhan	proc near		; CODE XREF: SubShowNagMsg+10p

		push	ebp

		mov	ebp, esp

		push	ebx

		VMMcall	Get_Cur_VM_Handle

		mov	eax, ebx

		pop	ebx

		pop	ebp

		retn	

SubVGetCurVMhan	endp

SubVSysModMsg	proc near		; CODE XREF: SubShowNagMsg+16p

		push	ebp

		mov	ebp, esp

		push	ebx

		push	edi

		mov	ebx, [ebp+8]

		mov	eax, [ebp+0Ch]

		or	eax, 1000h

		mov	ecx, [ebp+10h]

		mov	edi, [ebp+14h]

		VxDcall	SHELL_SYSMODAL_Message

		pop	edi

		pop	ebx

		pop	ebp

		retn	10h

SubVSysModMsg	endp

; The interesting thing is the use of the SHELL_SYSMODAL_Message to show the
nagbox. This 
type of messages is only used, when you write directly to the harddrive
and other critical 
stuff... 



Ok we've seen the nag showing routines, and the program-effect deactivation routines
(I mean 
the one where it disables it's virtual ramdrive effekt by setting a flag).
If you want, you 
can see where in other parts of the program this flag is used,
and you'll see, that it is 
only used in a CMP,JNE instructions.

But what about the priming routine, which activates the whole avalanche... Well
after a 
little more browsing around the code, I saw a very big and strange number:
1B7740 beeing 
pushed on the stack. I tryed setting is as an offset but it responded
with a BEEP :) I tryed 
setting is as a relative offset... BEEP. (I am describing
the wonderfull capabilities of 
IDA). At last I pressed H to change the numberbase,
and I got... 1800000.  Then it struck me 
1800000 msec = 1800 sec = 30 min !!!
Well, here comes the code:



loc_20633:				; CODE XREF: SubMainEngine+45Fj

		xor	esi, esi

		call	sub_20868 <-- some crappy stuff

		mov	eax, ds:dword_784

		push	esi		; param	ofs: 18h <-- NULL as a param

		push	offset SubTheNag ; param ofs: 14h <-- Sub to return to after the call


		mov	ds:dword_788, eax <-- some more crap, need mo tea

		push	esi		; param	ofs: 0Ch <-- another NULL as param

		push	1800000		; param	ofs: 08h <--- 30 min, AHHHH !

		call	sub_20B84	; call ofs: 04h <-- Calls a sub and installs a systimer

		mov	ds:hTimeOutReturn, eax <-- saves it's handle

		cmp	eax, esi <--- check if successfull

		mov	eax, 1Fh <--- some param for the next proc

		jz	short lExitTheSub <-- if error on systimer, then bail out

		push	0		; stack	ofs: 0Ch <-- more crappy params

		push	offset sub_1100E ; stack ofs: 08h <-- Sub to continue execution on

		call	sub_20B54	; stack	ofs: 04h <-- after this Nice guy sub

		xor	eax, eax



lExitTheSub:				; CODE XREF: SubMainEngine+24j	
SubMainEngine+47j

;As you can see here it uses that strange technique again: pushing the offset
of another sub 
to return to, instead of a normal jump. 8-}



;here is the sub which calls another one to instal a system timer

sub_20B84	proc near		; CODE XREF: SubMainEngine+493p

		push	ebp		; stack	ofs: 00h

		mov	ebp, esp

		push	esi

		mov	esi, [ebp+14h] <-- Some crap for the sub which handles some local vars


		mov	eax, [ebp+10h]

		mov	edx, offset word_1AB4

		push	offset sub_20BA2 <-- Push'n'continue technique

; there has just been pushed offset of the sub which instals the timer. It would
be executed 
after the following jump to a proc returns.

		jmp	ds:off_20B9E <-- Jump to a strange local variable handling sub

sub_20B84	endp



;timer installation procedure

sub_20BA2	proc near		; DATA XREF: sub_20B84+Fo

		mov	eax, [ebp+8]	; timeout in msec (18000000)

		mov	edx, [ebp+0Ch]	; null

		VMMcall	Set_Global_Time_Out

		mov	eax, esi

		pop	esi

		pop	ebp

		retn	10h

sub_20BA2	endp

;the previous proc loads the registers from the stack and sets a system timer,
which returns 
a timer handle in the ESI. Which is fast loaded into the EAX and
returned to the first 
listing higher up on the page.

That way is the protection sheme reversed, just like any ordinary win proggy.


(actually we were lucky that the programmer didn't use some crazy encryption
and stuff, 
cause vxd's run at the ring 0, where everything is allowed !

I leave the actual patching for you. There can be done several patches, try patching

everything in one place :) I myself patched it in two places.

HINT 1: That system timer installation is quite unnessesary in our purpose...


HINT 2: It must also return a valid handle from the Set_Global_Time_Out, probably
not NULL 
;)



PS: Where to find some documentation about those vxdcalls ? This can be an interesting

project for +HCU. ("Reversing the secrets of vxdapi")



The fully disassembled and partly commented by me deadlisting can be downloaded
from here.

Our tools homepage links anonymity +ORC students' essays academy database
tools Javascript wars cocktails antismut CGI-scripts search_forms mail_Fravia
Is reverse engineering legal?