VB Decompiler

Anonymous · New User Joined: 10 Feb 2008 Posts: 0

NumBytes: 5
ArgStr: h%h%
SrcStr:
Comments:

Runtime engine:
[asm:3re0n41c]

movzx ecx, word ptr [esi]         ; ecx = arg0 (constant pool index)
movzx edi, word ptr [esi+2]       ; edi = arg1 (method arguments size)
add   esi, 4
add   edi, esp
mov   edx, [ebp-54h]              ; edx = constantPool
mov   eax, [edx+ecx*4]            ; eax = constantPool(arg0)
or    eax, eax                    ; if eax = 0 then
nop
jz    _lblEX_ImpAdCallFPR4_22     ; goto ImpAdCallFPR4_22
 
lblCheckEventMonitors:
  cmp   _g_EventMonitorsEnabled, 0  ; if EventMonitors are enabled
  jnz   lblEventMonitorsEnabled
  call  eax                         ; call function
 
lblStackError_0:
  cmp   edi, esp
  jnz   StackErr_0
 
lblNextOpCode:
  xor   eax, eax
  mov   al, [esi]
  inc   esi
  jmp   ds:_tblByteDisp[eax*4]

[/asm:3re0n41c]

MrUnleaded · Posted: Wed Dec 18, 2002 11:13 pm Post subject: Post - Moved

[="sarge":yq634onl]You guys are gonna love this!!!

The address at offset 0x34 should be renamed to something like aExecutionReferenceTable. It is a pointer to an array of addresses, whose values are the "flow control" for those procedures who are called as "external" to a given procedure. Like this example:

1. SubMain is:
call sub1
call sub2
call sub3
end

2. sub1, sub2, and sub3 are procedures within the same module; their actual code doesn't matter.

3. Under PCode, SubMain looks like this:
0A 00 00 00 00
0A 01 00 00 00
0A 02 00 00 00
(end)

4. The three "0A"'s are obviously the calls, but here's how they work:

ObjectInfo.aExecutionReferencTable contains, say, 0x10C0. This is the ExecutionBaseReference. It is the address of the array of ExecutionPointers. Go there.

5. You will now find three addresses in this array, let's use:
0x10EC
0x10F8
0x1104

6. These are pointers to the CodeExecution struct, that is sort of like this:

MrUnleaded · Posted: Thu Dec 19, 2002 4:17 pm Post subject: more info on this one....

the first integer is an Index for the ConstantPool[it gets out a long]......its looking for a name of an event\Procedure

theres a catch.....this first integer includes external functions like MsgBox...which makes things a little more difficult...

the second integer....is simple...it is an Integer....it tells the number of bytes used for the Event\Procedure....with 4 bytes per item[a pointer i assume....] basically take this number and divid by 4 and you will get the number of arguments
_________________
-MrU

MrUnleaded · Posted: Sat Dec 21, 2002 9:00 pm Post subject: only thing holding me back...

[="MrUnleaded":20hndx0u]

theres a catch.....this first integer includes external functions like MsgBox...which makes things a little more difficult...

[/:20hndx0u]
ok well ive managed to figure out that at the location it points to you get a jump command

that jump command directs you to an Address in the Import Address Table[Directory 12 of the PE Optional Header]

only thing is im not sure how to resolve the address to get the name out of the library....

does anyone know how to do this?

if you refer to commonApp 1.0 then the IAT is at 0x1000 and the first address is 0x735205EE but the imagebase on MSVBVM60.DLL is 0x66000000 and the size of msvbvm60.dll doesnt exceed 0x1D5205EE so im not sure where to look to get out msvbvm60.dll's export of MsgBox...

or am i doing this wrong and 0x735205EE isnt even an address?

i was reading the PE stuff on the IAT and it says before binding it is a HintOrdinal and after binding it is an Address.....

if this is before binding....[which i dont think it is] we are looking at an address.....any suggestions?
_________________
-MrU

Anonymous · New User Joined: 10 Feb 2008 Posts: 0

The load base (which is what you should look at) for MSVBVM is 0x73420000
The address for rtcMsgBox is 0x73502096 (Entrypoint E2096)

You can use:

Dim hVB As Long
Dim hModule As Long
hVB = GetModuleHandle("MSVBVM60.DLL") ' Returns the instance handle. Since its always loaded, dont bother loading it

Debug.Print Hex(GetProcAddress(hVB, "rtcMsgBox"))

To show you that info. This should help.

Oh, and something that should also make you slap your head in d'oh:
0x735205EE is the proc address of MethCallEngine. (EntryPoint 0x1005EE)

If you need any more guidance then just say I wouldnt want to give too much away, because its not a challenge then no?

Anonymous · New User Joined: 10 Feb 2008 Posts: 0

Oh, almost forgot: http://www.dependencywalker.com/ should help. Use it on commonapp or MSBVM and then check up the thingybobs ie rtcMsgBox and MethCallEngine

MrUnleaded · Posted: Mon Dec 23, 2002 5:25 pm Post subject:

[="moogman":3dxc3q2q]The load base (which is what you should look at) for MSVBVM is 0x73420000
[/:3dxc3q2q]

hmm ok....things are beginning to make sense....how do you get the loadbase? do i have to examine it with my PE header reader?

[="moogman":3dxc3q2q]
The address for rtcMsgBox is 0x73502096 (Entrypoint E2096)

You can use:

Dim hVB As Long
Dim hModule As Long
hVB = GetModuleHandle("MSVBVM60.DLL") ' Returns the instance handle. Since its always loaded, dont bother loading it

Debug.Print Hex(GetProcAddress(hVB, "rtcMsgBox"))

To show you that info. This should help.
[/:3dxc3q2q]

alright but how do i get the function name from the address?

[="moogman":3dxc3q2q]
Oh, and something that should also make you slap your head in d'oh:
0x735205EE is the proc address of MethCallEngine. (EntryPoint 0x1005EE)
[/:3dxc3q2q]
yea i saw that Hiew told me

[="moogman":3dxc3q2q]
If you need any more guidance then just say I wouldnt want to give too much away, because its not a challenge then no?[/:3dxc3q2q]

there always a challenge waiting behind the current door at which we stand
_________________
-MrU

Anonymous · New User Joined: 10 Feb 2008 Posts: 0

[:42fw79a2]there always a challenge waiting behind the current door at which we stand[/:42fw79a2]

You are correct, GrassHopper. This is a lesson we have all learned, and will probably learn again.

(signed)
Worshipful Master

er.. better known as Sarge

Anonymous · New User Joined: 10 Feb 2008 Posts: 0

Ok, yes to summarise:

@ ImpAdCallFPR4 has two integer parameters. 1) a variable pool index and 2) the size of parameters.

@ We can get the variable using standard methods

@ This variable points to a section of assembly code as follows:

mov edx, 401498h
mov ecx, offset ProcCallEngine
jmp ecx

(I remember when joCo and I were discussing this a while ago. Heh, it makes sense now...thanks joe )

As we can see from this, edx holds the address of the procedure and then ProcCallEngine basically gets called.

***OR*** in the case of external you get the jmp table.
jmp ds:rtcMsgBox --> The external rtcMsgBox 0x(96 20 50 73)

@ So we know that the address of rtcMsgBox (for example) is 0x73502096. How do we resolve it to a function name asks MrU... We use the info in the Import section. Of course, this information would have been first processed and cached and then it would be easier and quicker to lookup these addresses.
I cant be bothered to explain, but basically:

IMAGE_DATA_DIRECTORY(IMAGE_DIRECTORY_ENTRY_IMPORT).VirtualAddress will help
IMAGE_IMPORT_DESCRIPTOR will help
Note that there is always one more IMAGE_IMPORT_DESCRIPTOR than there are
imports. Check the .Characteristics and if it = 0 then you've got the last
structure. Exit your loop then
Otherwise, carry on. The rest *should* be self-explanatory

PS. MrU, are you sure that you were looking at the right place when you got out MethCallEngine (or ProcCallEngine) instead of rtcMsgBox?