Page 1 of 1

DISASSEMBLING VISUAL BASIC APPLICATIONS Understanding Machine code generated by Visual Basic Rate Topic: ***** 1 Votes

#1 born2c0de   User is offline

  • printf("I'm a %XR",195936478);
  • member icon

Reputation: 187
  • View blog
  • Posts: 4,673
  • Joined: 26-November 04

Post icon  Posted 26 July 2006 - 03:56 AM

This formatting of this tutorial isn't intended to be this way.
For the version with original formatting, download the PDF or the TXT versions attached with this post.

- Sanchit Karve

printf("I'm a %XR",195936478);

CONTACT ME : born2c0de AT hotmail DOT com





The information provided in this tutorial must not be used for Reverse
Engineering any application.


If the Reader still chooses to break Protection Mechamisms after reading this
tutorial, he/she shall alone be responsible for the damages cause and not the

If you wish to post certain Sections of the Tutorial on a Website, you are free
to do so provided you inform the author and publish the Selected Text from the
Tutorial as it is without modification.

The Author has not copied text or any other information directly from a Source.
However, some information from some sources has been used to write this tutorial.
These Sources have been mentioned in the References Section.

You are permitted to continue reading the tutorial only if you agree to the text
given above.


Each Section in this Tutorial has a specific Topic Code enclosed in square
brackets. This arrangement has been made so that you can jump to a specific
topic simply by searching for the topic code from your Browser.

At many places in the tutorial, I've explained a few things which are almost
unnecessary to know when dealing with Visual BASIC programs but I've written
them for those who are interested in Hacking (And I don't mean that
'hack-an-email-address' sort of a kid. The original meaning of Hacking has
been ruined by pathetic people like them. Hacking in literal terms stands for
The original meaning of a Hacker is:
"A person who enjoys exploring the details of programmable systems, as opposed
to most users, who prefer to learn only the minimum necessary."

The extra details I've given in this tutorial are for those who want to be such
ethical hackers.

The Topic Code [XTRA] and [/XTRA] has been given for marking "extra-information"
sections and you are free to skip such sections. Text within the [XTRA]..[/XTRA]
blocks is given for extra information.
You can search for the Extra Information using the Topic Code.


As long as you know Assembly Language, it is easy to read disassembled listings
of executable files written in C/C++ or PASCAL, especially if you are using
IDA Pro as your disassembler. This is so because C and C++ Compilers generate
(or at least try to) efficient code. Some Compilers like Borland C++ use simple
instructions for complex operations(also remember that this is not always the
case) which make it easier to study them. Implementation of Code Constructs such
as loops, IF statements, Ternary IF statements, switch constructs etc. can be
found very easily as each one is unique and distinct.

However the same is not true for Applications written in Visual BASIC. VB
Programs are said to be very slow and hence deliver poor performance. There is a
reason for this. Visual BASIC programs unlike those written in other languages
don't use Windows API Directly. Local functions present in VB Runtime Files are
called which call functions from the Windows API.Most of the Visual BASIC
functions are present in MSVBM60.DLL (if you've got Runtime Files ver. 6.0).
So to study VB programs, we must disassemble and analyze the MSVBM60.DLL file as
Since VB programs use such a complex API Function call procedure, programs tend
to run slower.(There are other reasons as to why VB programs run slower but I
won't be covering it as it's off-topic.)

It becomes difficult to analyze VB Programs as it uses functions which are not
part of the Windows API and hence we are not acquainted with them.

My primary aim in this Tutorial is to teach the reader how to understand
disassembled listings of programs written in Visual BASIC.

My secondary aim is to help you realise why Visual BASIC is not suitable for
writing small,fast and efficient programs.

Almost all authors of Visual BASIC books mention that Visual BASIC does not
give you applications with good performance.
This tutorial tells you why.

The Tutorial will talk about executable files compiled in Visual BASIC in
Native Code ONLY and not p-code.

After reading this tutorial, you should be able to disassemble,debug and
understand Visual Basic Applications. You may also be able to reverse engineer
Protection Mechanisms written in Visual BASIC and that's where the next section
comes in.


You are required to have a basic understanding of Visual BASIC,C,the Windows API
and 80x86 Microprocessor Assembly Language.
It would be advisable to have a copy of Intel's 80x86 Instruction Set Manual.
Intel provides this manual free of charge. If you need this manual, contact me.

This Instruction Set Reference is Volume 2 of Intel Architecture Software
Developer's Manual.

The Software Developer's Manual consists of 3 volumes:
: Basic Architecture - Order Number 243190
: Instruction Set Reference - Order Number 243191
: System Programming Guide - Order Number 243192

You can provide these Order Numbers to get a copy of these manuals. For this
tutorial only Volume 2 is required.


You will need the following tools to proceed with the Tutorial.

* COMPILER : Visual Basic 6.0
* DISASSEMBLER : IDA Pro 4.x or higher
* DEBUGGER : OllyDebug Ver. 1.09d or higher
* NuMeGa SmartCheck 6.x
* VBDE version 0.85 by iorior
* VBReformer

VBDE is not required but it's always better to have it as it gives addresses of
entry-points of most VB procedures.

VBReformer is used to see the Property values of all objects in a Visual Basic
Form. It even allows you to change the value of Object Properties such as Forms,
Command Buttons etc. Import Libraries can also been seen. This Application is
not required for this Tutorial but it's better to have it.

NuMeGa SmartCheck is again not required but it is useful when we have no idea
what a particular procedure of VB does. You can run a program from it like a
Debugger and view its log files and find out which procedure is called and what
operations are carried out etc.

You can have API Documentation from MSDN or you can use the API Text Viewer Tool
supplied with Visual Studio or browse MSDN Online ( Certain
Applications like APIViewer will also do.

I have given the names of the Tools that I have used. But you are free to use
any disassembler and debugger as long as you are comfortable using it but I
advice you to use the tools that I have used above. SoftIce is better than
OllyDebug but the latter is good enough for VB Programs so it doesn't matter
which one you use.

Once you have the necessary knowledge and tools, you can proceed further.
Let's begin.


When you open a VB Program from IDA, you'll end up with the following code.
				 push	offset dword_4012B4
				 call	ThunRTMain
; ---------------------------------------------------------------------------
				 dd 0, 300000h, 400000h, 0, 0E9960000h, 82E6FCDFh, 939C4C23h
				 dd 0EB969B2Fh, 73D5h, 0, 1, 34303230h, 72503033h, 63656A6Fh
		; etc etc etc

This doesn't make any sense does it? If you keep scrolling further you will see
sections of code and data. Each Section has a meaning in VB Programs and you can
see a general idea of a Visual BASIC program's Section Map below.

... IAT (First Thunk ok apis)

Next Section(NS):
... some data

... transfer area (Jumps to imported functions)

... lots of data

... local transfer area (for internal event handlers)

... other data

... code

... lots of data

... .data Section

Let us now start analysis from the entry point of the program.
push	offset RT_Struct
call	ThunRTMain

It's C equivalent would have been:

A function ThunRTMain is called which accepts one parameter. We'll soon find out
that the parameter is a structure.
Simply putting a step over command on the CALL statement results in the
execution of the Application.
Wierd Isn't it?
For Pascal,C and C++ Programs there is always a start() function that takes all
CommandLine Parameters,Gets ProcessThreads,Module Handles etc. We didn't see
anything of the sort in a Visual BASIC Program.

But actually, VB does have a start function. The start function code is placed
in the ThunRTMain Function. Let's verify that by disassembling the MSVBM60.DLL
and viewing the ThunRTMain Function. I've mentioned only a part of the
ThunRTMain Function Code.

 ThunRTMain	  proc near

 arg_0		   = dword ptr  8

				 mov	 esi, [ebp+arg_0]
				 mov	 dword_7352F7DC, esi
				 and	 [ebp+var_4], 0
				 lea	 eax, [ebp+StartupInfo]
				 push	eax	; lpStartupInfo
				 lea	 eax, [ebp+StartupInfo]
				 push	eax	; lpStartupInfo
				 call	ds:GetStartupInfoA
				 movzx   eax, [ebp+StartupInfo.wShowWindow]
				 mov	 dword_7352F7D8, eax
				 push	hModule
				 push	esi
				 mov	 esi, offset dword_7352F470
				 mov	 ecx, esi
				 call	sub_7342DECD
				 mov	 [ebp+var_1C], eax
				 test	eax, eax
				 jl	  short loc_7342DEC5
				 push	0			; lParam
				 push	0			; wParam
				 push	1069h		; Msg
				 call	ds:GetCurrentThreadId
				 push	eax	; idThread
				 call	ds:PostThreadMessageA
		; Other Code

				 or	  [ebp+var_4], 0FFFFFFFFh
				 push	0			; uExitCode
				 call	ds:ExitProcess
				 jmp	 loc_734619B3

 loc_7342DEC5:						; CODE XREF: ThunRTMain+60j
				 push	eax
				 call	sub_Free_Memory
				 jmp	 short loc_7342DEB4

As you can see, it does call all the Functions that the start() function does in
C and PASCAL programs. But what about CommandLine() Function from KERNEL32.DLL?
MSVBM60.DLL does call that function as well but that function call is placed in
deeply nested function calls. You can open the Imports Window to see the
Imported Function and see the cross-reference to a procedure in MSVBM60.DLL

The sub_Free_Memory procedure calls various API Functions but if you keep
reading the procedure, you'll soon come across the HeapFree() Function which is
imported from kernel32.dll.

Now I guess you now know the purpose of the ThunRTMain Function.
Let us now see what structure is passed to it.

If we double-click on the RT_Struct offset, we reach an address containing
certain values.
It is a huge structure and each part needs to be seen one at a time.

Explaining the Structure will take up a lot of time and since I want to focus on
the Code Constructs of Visual BASIC, I won't explain the Structure Passed to

All I can tell you is that the structure contains the PE (Portable Executable)
Header Details. It is this header that is read by Resource Editors.

I found a good source for understanding the structure that is passed to
ThunRTMain and I suggest you read it if you are interested in knowing PE Header
Details. The link to the Article is given in the References [REFR] Section. The
article is titled "VISUAL BASIC REVERSED - A decompiling approach" and is
written by Andrea Geddon.
If the link is dead by the time you are reading this, you can contact me on my
email address to get the article.


Create a Form with a CommandButton. Click the CommandButton and add a simple
Msgbox Code as shown below:
Private Sub Command1_Click()
		Msgbox "Ssup"
End Sub

Open the Compiled EXE File with IDA Pro.
Click the Strings Tab to find the "Ssup" String.
Double-Click the String to find its cross-reference.
Scroll up to the top of the procedure.
You should see something like this:

[Explanation is partly given by comments after an instruction.]
Command1_Click  proc near

 var_64		  = dword ptr -64h
 var_5C		  = dword ptr -5Ch
 var_54		  = dword ptr -54h
 var_4C		  = dword ptr -4Ch
 var_44		  = dword ptr -44h
 var_3C		  = dword ptr -3Ch
 var_34		  = dword ptr -34h
 var_2C		  = dword ptr -2Ch
 var_24		  = dword ptr -24h
 var_14		  = dword ptr -14h
 var_C		   = dword ptr -0Ch
 var_8		   = dword ptr -8; Destructor Object
 var_4		   = dword ptr -4
 form_object	 = dword ptr  8

				 push	ebp			; These two instructions
				 mov	 ebp, esp	; open the Stack Frame.
				 sub	 esp, 0Ch	; Allocates 12 bytes on stack
				 push	(offset exception_handler+1); Starts Exception Handler
				 mov	 eax, large fs:0
				 push	eax
				 mov	 large fs:0, esp
				 sub	 esp, 88h	; Allocates 136 bytes on stack
				 push	ebx
				 push	esi			; Saves Values of Registers
				 push	edi

										; Loads the Destructor
				 mov	 [ebp+var_C], esp
				 mov	 [ebp+var_8], offset destructor

									; Allocating Dynamic Resources
				 mov	 eax, [ebp+form_object]
				 mov	 ecx, eax
				 and	 ecx, 1
				 mov	 [ebp+var_4], ecx
				 and	 al, 0FEh
				 push	eax
				 mov	 [ebp+form_object], eax
				 mov	 edx, [eax]
				 call	dword ptr [edx+4]; Calls MSVBM60.Zombie_AddRef
				 mov	 ecx, 80020004h
				 xor	 esi, esi
				 mov	 [ebp+var_4C], ecx
				 mov	 eax, 0Ah
				 mov	 [ebp+var_3C], ecx
				 mov	 [ebp+var_2C], ecx
				 mov	 [ebp+var_34], esi
				 mov	 [ebp+var_44], esi
				 mov	 [ebp+var_54], esi
				 mov	 [ebp+var_64], esi
				 lea	 edx, [ebp+var_64]
				 lea	 ecx, [ebp+var_24]
				 mov	 [ebp+var_24], esi
				 mov	 [ebp+var_54], eax
				 mov	 [ebp+var_44], eax
				 mov	 [ebp+var_34], eax
				 mov	 [ebp+var_5C], offset aSsup; "Ssup"
				 mov	 [ebp+var_64], 8
				 call	ds:__vbaVarDup
				 lea	 eax, [ebp+var_54]
				 lea	 ecx, [ebp+var_44]
				 push	eax
				 lea	 edx, [ebp+var_34]
				 push	ecx
				 push	edx
				 lea	 eax, [ebp+var_24]
				 push	esi
				 push	eax
				 call	ds:rtcMsgBox	; Calls the MsgBox Function
				 lea	 ecx, [ebp+var_54]
				 lea	 edx, [ebp+var_44]
				 push	ecx
				 lea	 eax, [ebp+var_34]
				 push	edx
				 lea	 ecx, [ebp+var_24]
				 push	eax
				 push	ecx
				 push	4
				 call	ds:__vbaFreeVarList
				 add	 esp, 14h
				 mov	 [ebp+var_4], esi
				 push	offset continue_after_jump
				 jmp	 short fake_a_call_instr

				 lea	 edx, [ebp+var_54]
				 lea	 eax, [ebp+var_44]
				 push	edx
				 lea	 ecx, [ebp+var_34]
				 push	eax
				 lea	 edx, [ebp+var_24]
				 push	ecx
				 push	edx
				 push	4
				 call	ds:__vbaFreeVarList
				 add	 esp, 14h
; ---------------------------------------------------------------------------

; ---------------------------------------------------------------------------

				 mov	 eax, [ebp+arg_0]
				 push	eax
				 mov	 ecx, [eax]
				 call	dword ptr [ecx+8]; Calls MSVBM60.Zombie_Release
				 mov	 eax, [ebp+var_4]
				 mov	 ecx, [ebp+var_14]
				 pop	 edi
				 pop	 esi
				 mov	 large fs:0, ecx
				 pop	 ebx
				 mov	 esp, ebp
				 pop	 ebp		; Closes Stack Frame
				 retn	4
Command1_Click  endp

Simply by looking at the entire procedure you can't exactly figure out what the
hell happens when the whole subroutine is executed. If you know Assembly well
and have had the patience to read through the code, you should notice a few neat
things in the code.


Before I begin explaining the procedure, I want to teach you how to recognise a
procedure in Visual BASIC. They can be called Procedure Signatures.
1) A Procedure has the open and close Stack Frame instructions.
2) The First Procedure in a VB Program is always preceded by
12 0xCC Bytes (which corresponds to the INT 3 Instruction) followed by
4 'T' bytes (0xE9) followed by 12 0xCC bytes.
3) Procedures other than the first are preceded by 10 NOP(0x90) Instructions.


The Open/Close Stack Frame Instructions are even found in C/C++ and Pascal
programs and hence can be termed as a universal method of determining procedures.
However that is not always the case.

--> Many compilers just JMP instructions to fake a Call Instruction. This Jump
is at times a CALL to a procedure. IDA Pro does not detect such
CALL 'emulating' instructions but OllyDebug does recognise such
code patterns.

--> Visual C++ allows the programmer to write naked functions. Naked functions
mean that the compiler does not allocate space for its arguments nor does it
include the stack open and close frame instructions.

But since we are dealing with Visual BASIC, we can ignore the second case. You
will see an example of the first case shortly.

: 2) THE 0xCC BYTE

The 0xCC Byte is used to Generate the INT 3 Exception, which is known as the
"CALL TO INTERRUPT" Procedure. It is used by Debuggers such as OllyDebug and
SoftIce to set software Breakpoints. Debuggers insert the 0xCC byte before the
instruction which it wants to set a breakpoint on. As soon as the INT 3
Instruction is executed, Control is passed onto the Debuggers Exception Handler.

Here is the description taken directly from Intel's Software Developers Manual
Volume 2 : Instruction Set Reference.
"The INT 3 instruction generates a special one byte opcode (CC) that is intended
for calling the debug exception handler. (This one byte form is valuable because
it can be used to replace the first byte of any instruction with a breakpoint,
including other one byte instructions, without over-writing other code). To
further support its function as a debug breakpoint, the interrupt generated with
the CC opcode also differs from the regular software interrupts as follows:
• Interrupt redirection does not happen when in VME mode; the interrupt is
handled by a protected-mode handler.
• The virtual-8086 mode IOPL checks do not occur. The interrupt is taken without
faulting at any IOPL level."

That's how debuggers work. That's also the concept of certain anti-debugging
techniques. Since the 0xCC code is injected by Debuggers before an instruction,
the CRC (Cyclic Redundancy Check) Value of the code also changes. Some
Antidebugging techniques encrypt the program with a key which is the CRC value
of the program. When a program is being debugged, its CRC value changes and with
the result the program doesn't get decrypted.
Such methods are effective in stopping amateur wannabe hackers from
understanding their code but its not foolproof and an expert hacker can get past
this technique with ease.

So much for what '0xCC' is. But why is it placed before the First Procedure in
VB Programs?
I've found no answer to that so far. This wastes a lot of space in a program.

If you try to disassemble a Console Program written in Visual C++, you'll find
many instructions which set parts of the stack to the '0xCC' value. You will
also find 0xCC bytes scattered across the disassembled listing.

If only Visual Studio was Open Source, we could have seen the code generation
code and come up with an answer and improve the code generation code too.
I hope you also realise why Open Source is slowly gaining momentum.

3) The 0x90 Byte

Here is the description taken directly from Intel's Software Developers Manual
Volume 2 : Instruction Set Reference.

"Performs no operation. This instruction is a one-byte instruction that takes up
space in the instruction stream but does not affect the machine context,
except the EIP register.
The NOP instruction is an alias mnemonic for the XCHG EAX, EAX instruction."

This byte is injected into serial generation/checking procedures by amateur
hackers where the protection mechanism is weak. This is known as bit-hacking.
Sadly enough, bit-hacking STILL works for defeating plenty of today's Commercial
Applications. Guess they never realised the importance for code-security.

While writing programs in Assembly Language, if you use Forward Referencing in a
few situations or use a wrong Jump Instruction to jump to certain addresses,
chances are quite bright that the Assembler will fill in some bytes with the NOP
As a result, having the presence of the 0x90 Instruction in your code is
considered bad programming.

But again, I see no reason why the 0x90 Byte is present in Visual BASIC.
Removing such entries will reduce the executable size drastically.

Programs like VBDE rely on such Procedure Signatures to identify where a
procedure is present.


Let us start by analyzing the procedure in portions.
First the Procedure opens the Stack Frame. Then it allocates 12 Bytes on the
stack for the Destructor and other variables. ( We shall see the Destructor in
detail after a short while. )
Then it allocates Dynamic Resources and calls the Zombie_AddRef Function.

What does the Zombie_AddRef Function do? It Takes the Object Reference.
In this function the parent object (in this case Form) is passed as a parameter
and uses AddRef to increment reference count of the object (instantiation).
Since COM objects are responsible for their lifetime, the resources they use are
allocated until the reference count is 0, when it reaches 0 the objects enter
zombie state & can be deallocated to free resources.
Refer COM object management documentation for more detailed information.

Right after the call of the Zombie_AddRef Function there are MOV instructions
which assigns values to many variables. That follows a reference to the "Ssup"
string followed by a call to the rtcMsgbox procedure.

Why does it seem so wierd? Shouldn't it simply call the rtcMsgbox Function?

Let us find out why in a little more interesting manner.
Intuition tells us that no matter what the function does, it will end up calling
the MessageBoxA or the MessageBoxW Function. So let's set a breakpoint on the
MessageBoxA and MessageBoxW Functions.

To do that, start OllyDebug and load the Executable file by pressing F3.
After the program is loaded, press Alt+E to open the Executable Modules window.
Double click USER32.DLL to open the disassembled listing of the User32.dll file.
From there press Ctrl+N to open the Imports/Exports window. Then Scroll over
till you see the MessageBoxA and MessageBoxW Functions. Click them one at a time
and press F2 to set a breakpoint.

Now press F9 to run the program. The Application should open. Click the
CommandButton. Now instead of the Debugger halting at a breakpoint of MessageBox,
the MessageBox comes up without any halt to the Debugger.

Why does this happen? Does this mean that rtcMsgBox has a seperate copy of the
MessageBox code within itself? Though it seems like a possible reason, it is
unlikely to happen as Microsoft Developers built the Windows API so that they
could be reused for performance. So that means that some API Function is called
which displays the MessageBox.
So let us try another experiment. In the same Imports/Exports Section of
User32.dll we see 2 more MessageBox functions which are MessageBoxIndirectA and
MessageBoxIndirectW. Let's try setting a breakpoint on both these Messages.

After the breakpoint is set, press F9, and click the Command Button.
This time, the Debugger halts at the MessageBoxIndirectA function.
Interesting isn't it? All Visual BASIC Applications which use the Msgbox()
Function are actually calls to MessageBoxIndirectA and not MessageBox as thought.

This is an important characteristic. So the Next time you set a breakpoint on
the MessageBox function and the debugger halts at a breakpoint, you can be
pretty sure that someone has used the MessageBox() API Directly by consulting
the API Text Viewer for the VB Declaration.

Let us now see the prototype of the MessageBoxIndirect() API Function.

Private Declare Function MessageBoxIndirect Lib "user32" Alias
"MessageBoxIndirectA" (lpMsgBoxParams As MSGBOXPARAMS) As Long

Only One Parameter? So then how is the Message Body and Title passed to the
Function? For that we'll need to see the declaration of the MSGBOXPARAMS

cbSize As Long
hwndOwner As Long
hInstance As Long
lpszText As String
lpszCaption As String
dwStyle As Long
lpszIcon As String
dwContextHelpId As Long
lpfnMsgBoxCallback As Long
dwLanguageId As Long
End Type

This suggests that the required parameters are assigned to variables and the
reference to that object is passed to that function.
So That suggests that the many MOV instructions found before the rtcMsgbox call
are used to initialise the MSGBOXPARAMS Structure.

To confirm our doubt, let's compare the MOV instructions with the code found
before the MessageBoxIndirect function is called.

  mov	 edx, [eax]
  mov	 [ebp+hWnd.lpszText], ecx
  mov	 ecx, [eax+8]
  mov	 eax, [eax+0Ch]
  push	esi
  push	ebx
  test	ah, 40h
  mov	 [ebp+hWnd.hInstance], edi
  mov	 [ebp+hWnd.lpszIcon], edi
  mov	 [ebp+hWnd.lpfnMsgBoxCallback], edi
  mov	 [ebp+hWnd.cbSize], 28h
  mov	 [ebp+hWnd.hwndOwner], edx
  mov	 [ebp+hWnd.lpszCaption], ecx
  mov	 [ebp+hWnd.dwStyle], eax
  mov	 [ebp+hWnd.dwLanguageId], edi
  jz	  short loc_734A6133
  mov	 [ebp+hWnd.lpfnMsgBoxCallback], offset sub_734A6098


  mov	 esi, ds:MessageBoxIndirectA
  lea	 eax, [ebp+hWnd]
  call	esi; MessageBoxIndirectA

Interesting to see that....Isn't it?

Next comes the __vbaFreeVarList Function. From its name we can see that it
deallocates the address of a certain number of variables. This function actually
does no work except call the __vbaFreeVar Function multiple number of times.

Let us see how both functions work.

__vbaFreeVar : Frees a Temporary Variable.

__vbaFreeVar accepts only 1 Argument, which is the address of the variable to be
deleted. This argument is ALWAYS passed through ECX.
Uses the API Function __imp_SysFreeString()[Ordinal Number 6] from OLEAUT32.DLL
that carries out the actual deallocation of a variable.

__vbaFreeVarList : Frees Temporary Variables.

Have a look at this Snippet:
				 lea	 ecx, [ebp+var_54]; Variable 1 stored in ecx
				 lea	 edx, [ebp+var_44]; Variable 2 => edx
				 push	ecx			 ; Variable 1 pushed
				 lea	 eax, [ebp+var_34]; Variable 3 => eax
				 push	edx			 ; Variable 2 pushed
				 lea	 ecx, [ebp+var_24]; Variable 4 => ecx
				 push	eax			 ; Variable 3 pushed
				 push	ecx			 ; Variable 4 pushed
				 push	4			; Free 4 Temp. Variables
				 call	ds:__vbaFreeVarList

The code is pretty easy to understand. This function frees temporary variables
that are passed as arguments to it.Interestingly each memory location is
16 bytes wide.
This is an interesting function as it can accept variable arguments.
It's equivalent function call in C would be:

where its declaration would be:

int __vbaFreeVarList(int NUMBER_OF_VARIABLES_TO_FREE,<addresses of the vars>...)

If we analyse the code of __vbaFreeVarList, we actually find multiple calls of
__vbaFreeVar. Have a look at the source code of __vbaFreeVarList.
				 public __vbaFreeVarList
__vbaFreeVarList proc near

 arg_0		   = dword ptr  4
 arg_4		   = dword ptr  8
 arg_8		   = dword ptr  0Ch

				 mov	 ecx, [esp+arg_4]; Address of Variable to delete
				 push	esi			; Saves value of esi
				 lea	 esi, [esp+4+arg_8]; esi = Address of Next Variable
				 call	__vbaFreeVar; function call
				 mov	 eax, [esp+arg_4]; eax gets value of num of
										; variables to be freed
				 cmp	 eax, 1			; If eax<=1 then
				 jbe	 short freed_all_vars; jump to end of function.
				 push	edi			; Value of edi is saved on stack
				 lea	 edi, [eax-1]; edi=eax-1

	; THIS IS A WHILE LOOP :  while(edi){ /*CODE*/ }
				 mov	 ecx, [esi]	; ecx=Address of Variable to Delete
				 add	 esi, 4		; esi = Address of Next Variable
				 call	__vbaFreeVar	 ; function call
				 dec	 edi		; edi--;
				 jnz	 short loop_start ; Jump to beginning of the loop if
									; edi is not ZERO.
									; Well Written Code.No need for a
									; CMP Instruction as DEC
									; Instruction affects the ZERO Flag
				 pop	 edi		; Value of edi is restored.

				 pop	 esi		; Value of esi is restored.
				 retn					 ; Return to the calling function
ENGINE:7352009D __vbaFreeVarList endp

As you can see, __vbaFreeVarList uses a while loop to free each variable one by
one using the __vbaFreeVar Function.
Notice that the address of the variable to be freed is stored in ECX always.
You can disassemble the __vbaFreeVar Function to confirm that.

Now let us see what happens when after the MessageBox is shown.
This is the most interesting part.

After the MessageBox is displayed, a clean up code is executed that deallocates
all the variables used in the entire procedure. Have a look at these statements
in the Command1_Click() Code.

push offset continue_after_jump
jmp short fake_a_call_instr
; ---------------------------------------------------------------------------

; ---------------------------------------------------------------------------

; code

This is the 'CALL-Simulation' instruction. If you recall, before a call function
is executed, the processor pushes the location of the instructions which are
supposed to receive control after execution of a function is over.
VB instead of issuing a call instruction simulates it using the push, jmp and
retn instructions. It is small sections of code like this that reduce Visual
BASIC's efficiency and performance.

Let us still see why this is done.

The CALL-Simulation Instruction calls the MSVBM60.Zombie_Release function.
This is the destructor code. Doesn't that remind you of something?
The instruction
mov [ebp+var_8], offset destructor
contains the offset of the destructor code. But is this so?
Double-click on the 'offset destructor' text and you'll land up here.

destructor dd 80005h, offset loc_401A7E, 0, offset loc_401A85, 102825FFh

Hmm...this contains more offsets? By simply double-clicking the offsets you land
up at the destructor code again. That's why the CALL simulation code is used so
that the destructor code looks like its an inline function.

If you're more curious, you can also double-click the 'exception_handler' text
to see where that leads to.

Well, after a long journey into the Command1_Click() Procedure, we're finally
done analyzing it.

From this point onwards, I shall explain only the important section of code
rather than explain such intricate details once again.

Let us proceed further.
This Time let us create a Visual BASIC Application using only a module.
We shall use the Main Subroutine.

Use this code:
Sub Main()
	MsgBox "Ssup"
End Sub

What you will realise that the Procedure code is an exact copy of the code we
dealt with earlier. This means that Form Procedures and Module Procedures are
treated alike. This also means that the Command Button code procedure had no
chance of using any information of the Form Object.

Let's take another example.


Create a form without any controls. The code in the form module is as follows:
Private Sub Form_Load()
	If "Sanchit" <> InputBox("ssup") Then
		MsgBox "wrong"
		MsgBox "Right"
	End If
End Sub


Attached File(s)

Is This A Good Question/Topic? 0
  • +


#2 m2s87   User is offline

  • D.I.C Regular
  • member icon

Reputation: 21
  • View blog
  • Posts: 390
  • Joined: 28-November 06

Posted 15 January 2007 - 04:53 PM

I must say, i learned something about the topic. Good, educational tutorial :^:
Was This Post Helpful? 0
  • +
  • -

#3 deadbeefhash   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 1
  • Joined: 16-January 07

Posted 16 January 2007 - 12:37 PM

View Postborn2c0de, on 26 Jul, 2006 - 03:56 AM, said:

So much for what '0xCC' is. But why is it placed before the First Procedure in
VB Programs?

0xCC ('int 3' instruction) can be used for alignment purposes between functions. Because of Intel's x86 memory design, aligned memory access is significantly faster than unaligned access. When calling a function, the instruction stream latency is lower when the function is aligned to a certain value. Before the start of a function, 'int 3' instructions are inserted until the address is aligned to some value (from what I've seen, 16 seems to be the most common on x86). When executing, if the instruction pointer invalidly reaches the 0xCC alignment bytes, the program will crash with a protection fault or trigger a breakpoint if debugged.

Instruction alignment is also useful for loops or segments of code that are repeatedly executed. Sometimes you'll see a seemingly useless 'nop' instruction or a one or two byte instruction that will always be jumped past. For small loop routines, the entire block of code can be cached and the physical memory won't need to be accessed in order to read the instruction stream.

This post has been edited by deadbeefhash: 16 January 2007 - 12:38 PM

Was This Post Helpful? 0
  • +
  • -

#4 born2c0de   User is offline

  • printf("I'm a %XR",195936478);
  • member icon

Reputation: 187
  • View blog
  • Posts: 4,673
  • Joined: 26-November 04

Posted 17 January 2007 - 03:49 AM

View Postdeadbeefhash, on 17 Jan, 2007 - 01:07 AM, said:

When executing, if the instruction pointer invalidly reaches the 0xCC alignment bytes, the program will crash with a protection fault or trigger a breakpoint if debugged.

Aah, I knew 0xCC served a purpose...Thanks.

View Postdeadbeefhash, on 17 Jan, 2007 - 01:07 AM, said:

Instruction alignment is also useful for loops or segments of code that are repeatedly executed. Sometimes you'll see a seemingly useless 'nop' instruction or a one or two byte instruction that will always be jumped past. For small loop routines, the entire block of code can be cached and the physical memory won't need to be accessed in order to read the instruction stream.

Yes, I am aware :)
NOP Slides are also used for Stack and Buffer Overflow Attacks.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1