 |
VB Decompiler
Hosted by TheAutomaters.com
|
| Author |
Message |
Dr Memory
Expert
Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK
|
|
Posted: Sun Aug 29, 2004 6:08 pm
Post subject: "Structured" Programming report
|
|
I've finnaly used the structures in action, and can make some report ....
My first attempt to use the current Header/ComRegData/ComRegInfo structures was a complete and utter ......
..... success
Yes, folks, it wa a piece of cake! Congrats to all concerned, it is a fine piece of work, yea and verily, amen!
Report 1
I have that DllVBHeader function, it loads VB dll, returns memory header address.
I plug address into pointers of type VBHEADER, COMREGDATA, etc and if they work (your structures, I mean ) I should be able to do VB proud by doing THIS:
| Code: |
pHeader = GetVBHeader(hModuleDll)
dHeader.Pointer = pHeader
MsgBox CSTring(vbHeader(0).oProjectTitle + pHeader)
pReg = vbHeader(0).aCOMRegData
dRegData.Pointer = pReg
MsgBox CSTring(pReg + vbRegData(0).oNTSProjectName)
|
And it worked first time, that always cheers me up, I was impressed ... spot on, guys'n'gal!
ComRegData
There are "ghosts" in the heap in my COMregdata block. Is this block itself a heap image? I suppose that makes sense, but they haven't taken out the garbage, it seems:
| Code: |
170013B4: 00000068 COMregdata 1st Info block at = > 41C
170013B8: 00000030 offset to Proj name => 3E4
170013BC: 00000060 Help dir => 414
170013C0: 00000040 Descn => 3F4
170013C4: 5BC504B5 CLSID {5bc504b5-09da-4f7f-b01c-e89ebc261ef8)
170013C8: 4F7F09DA
170013CC: 9EE81CB0
170013D0: F81E26BC CLSID end
170013D4: 00000000 LCID
170013D8: 00020000 Version info (6 bytes?)
170013DC: 72440000 ghost in the heap? "DrMemo"
170013E0: 6F6D654D
170013E4: 654D7244 Proj Name << 3E4 "DrMemory"
170013E8: 79726F6D
170013EC: 65666600 junk(heap!) "fferent"
170013F0: 746E6572
170013F4: 73696854 Description << 3F4
170013F8: 70706120 "This app does diddly-squat!"
170013FC: 656F6420
17001400: 69642073
17001404: 796C6464
17001408: 7571732D
1700140C: 00217461
17001410: 6F632D6E junk(heap) "n-co", "patible"
17001414: 74617000
17001418: 656C6269
|
The "heap junk" items, "DrMemo", "n-co", were part of an ancient bed of text laid down by a previous compilation, in which I got one of those "not version-compatible" dialog boxes ...
But this came from the PE - the DLL file really did get compiled like that, and it works fine - you'd think it'd take the garbage out before handing it to the linker, very untidy...
What do you think?
I found one obvious mistake in there, I see, the project descn should read "This DLL does diddly-squat!", not "This app"
Thunk Count
This is odd, consistently it's E9, or 233. 4 times that is 3A4, but my BORG listing says there are 232 - and the entry point immediately follows it, and that is definitely offset 3A0.
Am I expecting the wrong thing here?
Cheers
|
|
| Back to top |
|
 |
|
ionescu007
Sometimes here
Joined: 21 Aug 2004
Posts: 33
|
|
Posted: Sun Aug 29, 2004 7:02 pm
Post subject:
|
|
Hi,
Yes the structure is copied from the heap and the heap isn't initailized with HEAP_ZERO_MEMORY so that's why you get garbage.
As for your Thunk Count problem...I really don't understand what you mean..sorry. What's 0x3A4 and 0x3A0? And what's BORG listing?
Best regards,
Alex Ionescu
Kernel Developer, ReactOS
President, Relsoft Technologies
|
|
| Back to top |
|
|
|
Dr Memory
Expert
Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK
|
|
Posted: Sun Aug 29, 2004 8:12 pm
Post subject:
|
|
Hi Alex
BORG is a popular freeware disassembler. It'll do full a msvbvm60 listing in about 10-15 minutes. For freeware, excellent...
The opening code segment begins with a table, with a mixture of function pointers, some other stuff as well, and right at the end, the 5 "jumpaway thunks" (transferring external callers of DllRegisterServer, etc)...
Isn't this the Thunk table opening the show?
| Code: |
; Borg Disassembler v2.27 : F:\MathImagicsNT\MathImagics\Dr Memory\Memory\Project1.dll
;
; Created by Borg Disassembler
; written by Cronos
1000:17001000 ;-----------------------------------------------------------------------
1000:17001000 ;Segment : 1000h Offset : 17001000h Size : 4000h
1000:17001000 ;32-bit Code
1000:17001000 ;-----------------------------------------------------------------------
1000:17001000 LoadTypeLibEx: XREFS First: 1000:17003914 Number : 2
1000:17001000 d57ea077 dd 77a07ed5h
1000:17001004 00000000 dd 00h
1000:17001008 GetModuleFileNameA: XREFS First: 1000:17003897 Number : 1
1000:17001008 0c86e877 dd 77e8860ch
.............
1000:17001024 __vbaHresultCheck: XREFS First: 1000:17003930 Number : 2
1000:17001024 cb060e66 dd 660e06cbh
1000:17001028 __vbaLenBstr: XREFS First: 1000:17003866 Number : 1
1000:17001028 ce490266 dd 660249ceh
1000:17001382 _MSVBVM60::ord_101:
1000:17001382 ff25e8100017 jmp dword ptr [MSVBVM60::ord_101]
1000:17001388 _MSVBVM60::ord_104:
1000:17001388 ff25f4100017 jmp dword ptr [MSVBVM60::ord_104]
1000:1700138e _MSVBVM60::ord_103:
1000:1700138e ff25f0100017 jmp dword ptr [MSVBVM60::ord_103]
1000:17001394 _MSVBVM60::ord_102:
1000:17001394 ff25ec100017 jmp dword ptr [MSVBVM60::ord_102]
1000:1700139a _MSVBVM60::ord_105:
1000:1700139a ff25f8100017 jmp dword ptr [MSVBVM60::ord_105]
1000:170013a0 vbStart:
1000:170013a0 5a pop edx
1000:170013a1 6844640017 push offset loc_17006444
1000:170013a6 6848640017 push offset loc_17006448
1000:170013ab 52 push edx
1000:170013ac e9e9ffffff jmp _MSVBVM60::ord_105
|
There are exactly E8 words in this table or 3A0 bytes ...
Cheers
Dr M
|
|
| Back to top |
|
|
|
ionescu007
Sometimes here
Joined: 21 Aug 2004
Posts: 33
|
|
Posted: Mon Aug 30, 2004 10:22 pm
Post subject:
|
|
Totally unrelated . What you're sseing is the IAT. The Thunk Table is internal to VB and worthless.
Best regards,
Alex Ionescu
Kernel Developer, ReactOS
President, Relsoft Technologies
|
|
| Back to top |
|
|
|
Dr Memory
Expert
Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK
|
|
Posted: Tue Aug 31, 2004 1:28 am
Post subject:
|
|
Well, an IAT is a "thunk" table, so I asumed that was it, and the number of entries was so close
So, what is the "internal Thunk Table" then???
|
|
| Back to top |
|
|
|
Dr Memory
Expert
Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK
|
|
Posted: Tue Aug 31, 2004 1:32 am
Post subject:
|
|
Oh, I nearly forgot!
Did you see my VB pointers in that report?
|
|
| Back to top |
|
|
|
ionescu007
Sometimes here
Joined: 21 Aug 2004
Posts: 33
|
|
Posted: Tue Aug 31, 2004 1:36 am
Post subject:
|
|
I can't really erxplain what the tHunk table is, I haven't looked at it too much. It's something really weird and doesn't even seem to be used at all. You can set it to 0x10 and reduce memory usage significantly and your app should still work.
You're looking at a __vbaS for a DLL, so the VB pointers pushed are different.I don't know what they are yet.
Best regards,
Alex Ionescu
Kernel Developer, ReactOS
President, Relsoft Technologies
|
|
| Back to top |
|
|
|
Dr Memory
Expert
Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK
|
|
Posted: Tue Aug 31, 2004 2:07 am
Post subject:
|
|
No, no, I meant the IMPLEMENTATION of my pointers - don't be fooled by the (0) indexing you see in my code sample above, those are managed pointers - there are no local instances of any of the structures, no data copying (other than to get your CSTRING's converted, that can't be helped;) )
Cheers
|
|
| Back to top |
|
|
|
Dr Memory
Expert
Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK
|
|
Posted: Tue Aug 31, 2004 2:12 am
Post subject:
|
|
And, cutest of all, you can even do the initial thunks needed to initialise the pointers without CopyMemory (indeed, any api, not even a TypeLib)
It's quite audacious ....
|
|
| Back to top |
|
|
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You can edit your posts in this forum
You can delete your posts in this forum
You can vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Memberlist