VB Decompiler

MrUnleaded · Posted: Thu Oct 17, 2002 4:04 pm Post subject: EventTable

Parent: <a href="./viewtopic.php?t=24">Control</a>
Structure Size: 0x18 + (aControl.EventCount * 4)

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

The three "jmp" are addersses to the exported class interface thingybobs from the ocx. I think they are QueryInterface, AddInterface, ReleaseInterface but I cant be quite sure without looking at my code (im in Uni)...

MrUnleaded · Posted: Fri Oct 18, 2002 3:59 pm Post subject: oh yea

[="moogman":136s6j2m]The three "jmp" are addersses to the exported class interface thingybobs from the ocx. I think they are QueryInterface, AddInterface, ReleaseInterface but I cant be quite sure without looking at my code (im in Uni)...[/:136s6j2m]

oh yea...i forgot to mention that.....do you think that those jumps are of any importance to us?

heres the jmps:

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

Ahh there we go. No, not of any importance at all since we could just as easily get the addresses from the import section. But, rather than keeping them as abstract as they currently are, we can document them to show that we know what they do

MrUnleaded · Posted: Tue Dec 03, 2002 11:49 pm Post subject: updated

i updated the struct to show what the three jumps are....even though we dont really need them to decompile....
_________________
-MrU

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Ok, so as per the discussion in the "corrections" forum, both EventPointer and EventTable have issues:

1. EventTable's text points out the need for a new struct representing that array

2. EventPointer's struct need re-definition.

I'll post this message in both forums

sarge

MrUnleaded · Posted: Tue Dec 10, 2002 10:54 pm Post subject:

[="sarge":3ban9f32]
1. EventTable's text points out the need for a new struct representing that array

sarge[/:3ban9f32]
Ok lets start with event table and once we are satisfied move on to event pointer....

The way i see it....in a struct...if we have..

aSomeObjectTable as Long

it means an address to a struct that has an array of "SomeObject"

now when i see:

aSomeObjectArray as Long

i think that means simple an consecutive array of "SomeObject"

and i know not all of the structs follow this..[side note: if you see one let me know/change it] but this one does.....so whats wrong with it?
_________________
-MrU

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

My comment was aimed at your text statement below the struc definition:

"Directly proceeding this structure is an array of Addresses(Longs). "

That array of addresses needs to be defined in a struct, too. I merely wanted to get that struct definition listed/posted like the others (in a nice blue table), so we can reference it properly. Then, of course, we can make that reference. The reference to be made is, if I remember correctly, now named Address5. Once this array struct is created, we can put in a more descriptive name.

Also, the data within this yet-to-be-created struct are pointers that point into other structs (sheesh--don't they all?), so this will allow us to clean up those other structs also.

Sarge

------------------------
I think I'm people type 11

MrUnleaded · Posted: Wed Dec 11, 2002 6:19 am Post subject:

[="sarge":cefzuc79]My comment was aimed at your text statement below the struc definition:

"Directly proceeding this structure is an array of Addresses(Longs). "

That array of addresses needs to be defined in a struct, too. I merely wanted to get that struct definition listed/posted like the others (in a nice blue table), so we can reference it properly.

...

[/:cefzuc79]

i changed the struct....is this what you were wanting? I hope so...What else?
_________________
-MrU

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

Heh, although that structure cant be quickly imported to your local project since the number of sections in the array needs to be constant, but thats fine for the same of completion

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Conceptually, more like this:

Private Type tEventTable
Null1 As Long ' 0x00
aControl As Long ' 0x04
aObjectInfo As Long ' 0x08
aQueryInterface As Long ' 0x0C
aAddRef As Long ' 0x10
aRelease As Long ' 0x14
End Type

Private Type tEventLinkTable
aEventLink1 as Long
aEventLink2 as Long
etc
End Type

Here's the problem...
Note that EventLinkTable (valid name?)is the new struct that contains the address array noted in the text statement previously mentioned. The significant thing here is the length of the table (ie quantity of entries to give the struct size). The end of the table is determined by the number of active events in the module; this is the total number of active events of the form and all the controls. This is NOT the same as the number of events the form/control may have; it is a count of ONLY those ACTIVE events (events that actually have code in them). One obvious answer is to determine how many total active events there are. Since I don't know of any flag/variable (at least that we have defined yet) that keeps that count, there are two other options:

1. Analyze the forms and controls events to get the count. This is probably not the desired method; you will end up analyzing the data just to get a single piece of info to satisfy this struct, when the intent of this struct is to allow you to analyze the data! Sort of a vicious circle...you can do it, but why? Once you've analyzed the data, you don't need this struct anymore, other than as the requirement/knowledge to map out a VB exe as best as possible.

2. Look for the "end-of-table" flag. Wow, this is the obvious answer--why not just do it and forget option #1? Because the "end-of-table" flag, which is a NULL, is currently defined as the NULL that is at the start of the EventTable. (This works out only because the EventTable is guaranteed to immediately follow the EventLinkTable) So, if you follow this thinking, the data becomes:

Private Type tEventLinkTable
aEventLink1 as Long
aEventLink2 as Long
etc...
NULL as long
End Type

and change EventTable to

Private Type tEventTable
aControl as Long
etc
End Type

BUT, the NULL that you have removed from here is required as it is the target of Control.aEventTable, so it CAN'T be moved.

(Take a deep breath)

Now, remember that this is conceptually how it works...what the final struct definitions are, is the intent of this discussion. Once that is decided, the useage of the new elements (aEventLink1, etc) needs to be determined. But we need to set up this struct first.

sarge

PS: This is the first of two complications of "mixed" structs

MrUnleaded · Posted: Wed Dec 11, 2002 4:06 pm Post subject:

[="sarge":1ebe28hs]Conceptually, more like this:

Private Type tEventTable
Null1 As Long ' 0x00
aControl As Long ' 0x04
aObjectInfo As Long ' 0x08
aQueryInterface As Long ' 0x0C
aAddRef As Long ' 0x10
aRelease As Long ' 0x14
End Type

Private Type tEventLinkTable
aEventLink1 as Long
aEventLink2 as Long
etc
End Type
[/:1ebe28hs]

I dont think that we should go this route because this would imply that each Event is different then another and that we should be analyzing them differently. They are the Same....the only difference is the name we give them.... that can be easily determined with COM...

[="sarge":1ebe28hs]
The end of the table is determined by the number of active events in the module; this is the total number of active events of the form and all the controls.
[/:1ebe28hs]
I have to dissagree. the End of table is defined by 4*EventCount; EventCount is the number of events a Control may have. If an event address is null it should not be processed otherwise, continue.

[="sarge":1ebe28hs]
it is a count of ONLY those ACTIVE events (events that actually have code in them).
[/:1ebe28hs]
No because some have code and some are null
[="sarge":1ebe28hs]
...

2. Look for the "end-of-table" flag. Wow, this is the obvious answer--why not just do it and forget option #1? Because the "end-of-table" flag, which is a NULL, is currently defined as the NULL that is at the start of the EventTable. (This works out only because the EventTable is guaranteed to immediately follow the EventLinkTable) So, if you follow this thinking, the data becomes:
[/:1ebe28hs]
there isnt an End Of Table flag...some events have null addresses and some dont....and that depends on which Event it correlates to....

ie it could come in this order:
Form_load
Form_Click
Form_Unload

but if we only had an evvent for Click....it would be like...
00 00 00 00
00 40 XX XX
00 00 00 00

and by this we would know that the address 0040XXXX points to a Form_Click

[="sarge":1ebe28hs]

Now, remember that this is conceptually how it works...what the final struct definitions are, is the intent of this discussion. Once that is decided, the useage of the new elements (aEventLink1, etc) needs to be determined. But we need to set up this struct first.

sarge

PS: This is the first of two complications of "mixed" structs[/:1ebe28hs]

i think you are missing out on a lot by not using COMTLB....all of the events names can be determine by simply knowing the parent control and the index in the events.
_________________
-MrU

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Whoa!

>"the End of table is defined by 4*EventCount".
Absolutely not. It that were true, then the EventLinkTable would have some 21(or whatever) controls for the form + maybe 15( or whatever) for the command button, etc, for a total of maybe 60 or 80 or so. In CommonApp, it only has like 3 (or some other small figure)

>"I dont think that we should go this route because this would imply that each Event is different then another and that we should be analyzing them differently".
It implies no such thing..it implies each EventLink is different, which of course it is, as it points to different structs, each containing pointers to different events.

>"No because some have code and some are null ".
No. ALL have code in them or they wouldn't be in this struct. The "some have code and some are null" struct is completely separate and different.

" think you are missing out on a lot by not using COM\TLB....all of the events names can be determine by simply knowing the parent control and the index in the events. "
> This has nothing to do with this struct. The event names can be determined without any COM/TBL, as they are already in the exe.

Remember, we are looking at the array of address that occur before the EventTable.

Sarge

MrUnleaded · Posted: Wed Dec 11, 2002 8:01 pm Post subject: PROceeding hehe

[="sarge":15m89p9g]Whoa!
...
Remember, we are looking at the array of address that occur before the EventTable.

Sarge[/:15m89p9g]

BEFORE??? there is nothing before the EventTable Structs....

except maybe another EventTable....

here look at my export of CommonApp as i try to explain...

http://decompiler.theautomaters.com/fil ... 06661.html

ill try to show what i mean...

if you look at the offset for the EventTable of lstItems which is at 0x190C...there you have your struct....you move over 0x18 bytes and you are at the end of the part of the Struct that is always the same...[0x1924] after this there is an array of Longs[addresses] 21 of them to be exact....since lstItems has 21 Events....

Well they are all Null because the lstItem control has no code for any of its evetns...

directly proceding [0x1978] is the EventTable for txtItem it has 24 nulls after...again no code for any of its events....

after that we have the EventTable for cmdAdd [0x19F0]....at 0x1A08 is the start of the EventAddresses....the first is the Click Event.....it has a coresponding address...because in the Click event we add the text to the list or whatever....

the address is 0x1AE0.....which takes us to one of the EventPointers....and i will save that discussion for later

i hope this helps sorry if i seemed stand-offish ;0)
_________________
-MrU

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Hey, no problem! Remember what I just went through with ProjectInfo!!!

Anyway, let's try another route. Where does OptionalObjectInfo.Address5 point to? &h1900. Note that this is just BEFORE the EventTable, and, co-incidently, happens NOT to be defined. (Obviously, if it WERE defined, we would have a name for it, and Address5 would have a more proper name).
The whole point of this is, that &h1900 is the same array that is indicated in that text statement . Since the statement is there, I felt we could get rid of it by defining the array properly (as a struct), thus allowing us to get a bit more knowledge of the app format (filling in the gap between &h1900 and &h190C) , as well as cleaning up an ambiguous name like Address5.

Further, note that those address are the active events,quantity 3,etc, as mentioned above.

This is the first step, and by itself is not major. Unfortunately, it has a domino effect that we have not yet attacked. Thus, my strong belief that we better get this part strictly correct before we try those dominos.

Sarge

MrUnleaded · Posted: Wed Dec 11, 2002 9:16 pm Post subject:

[="sarge":fibzs1zv]Hey, no problem! Remember what I just went through with ProjectInfo!!!

Anyway, let's try another route. Where does OptionalObjectInfo.Address5 point to? &h1900. Note that this is just BEFORE the EventTable, and, co-incidently, happens NOT to be defined. (Obviously, if it WERE defined, we would have a name for it, and Address5 would have a more proper name).
[/:fibzs1zv]
ok ok.....before....
[="sarge":fibzs1zv]
The whole point of this is, that &h1900 is the same array that is indicated in that text statement . [/:fibzs1zv]

for the record....it did say proceeding(after)..... not preceding(before)....

[="sarge":fibzs1zv]
Since the statement is there, I felt we could get rid of it by defining the array properly (as a struct), thus allowing us to get a bit more knowledge of the app format (filling in the gap between &h1900 and &h190C) , as well as cleaning up an ambiguous name like Address5.

Further, note that those address are the active events,quantity 3,etc, as mentioned above.
[/:fibzs1zv]

you are correct....kinda....they point to the middle of the EventPointers...of the active Events...

but the thing is....the Active EventPointer addresses(the ones after each event table)....point to 7 bytes before where the other addresses[0x1900-0x190C] point to...so...

either the EventPointer Struct is too long....ie it should be 7 bytes....or....um...well... i dont know....

i do know that my EventPointers get me to the source code....

[="sarge":fibzs1zv]

This is the first step, and by itself is not major. Unfortunately, it has a domino effect that we have not yet attacked. Thus, my strong belief that we better get this part strictly correct before we try those dominos.

Sarge[/:fibzs1zv]

thats why you set up barricades.....soif you knock over some dominos...they all dont get knocked over

so what do you suggest Sarge?
_________________
-MrU

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Ok, the good news is that you have stumbled onto the 2nd point where there are "mixed" structs...

the bad news is:
"so what do you suggest Sarge? "
Aghh! Thats why I was asking you guys!!!

Ok, rather than try to answer that now , let me get back to you later with something that may help. (that's called a "cop-out"!)

Sargeg

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Well, here's the concept - (maybe):

1. First of two parallel paths

(OptionalObjectInfo)
Address5
....points to
.......NewStruct
.......{
..........EventLink1 as Long '0x00
..........EventLink2 as Long '0x04
..........etc
.......}

2. Second of two parallel paths
(EventTable)
text note
....points to
.......EventPointer
.......{
..........Const1 as Byte '0x00
..........Flag as Long '0x01
..........Const2 as Integer '0x05
..........Event_Link as EventLink '0x07
.......}

3. Both paths meet

EventLink
..{
....CompileType as Byte '0x00
....aCodeInfo as Long '0x01
....PushCmd as Byte '0x05
....PushAddress as Long '0x06
....Const as Byte '0x0A
..}

Note that EventLink is a new struct.

This seems close to what happens. Some of the existing stuff needs to be changed, some is new.
Also, I feel that we should make the names used in a calling function match the name in the called function. (Sometimes they don't, like EventPointer.aEvent is the same as CodeInfo).

Can anyone clean this up, either 'cause there's errors or 'cause the flow is objectional?

Sarge

MrUnleaded · Posted: Thu Dec 12, 2002 10:48 pm Post subject:

Alright...alright its starting to make sense to me....but you are slightly off....

ok here is the original EventPointer:

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Two items:

1. It's beginning to look like what I thought I said, so obviously your cleanup is pretty good. Of course, I will review it, (as, I expect, will the rest of the group.) and get back to you.

2. The answer to "compileType According to Sarge[more info?] " was, actually, already posted twice (I think twice, but I know for sure once).
Search for a reference to PCode-vs-Native, and/or a reference to 0x33-vs-0xE9. When you find this, it should raise more questions; I BELIEVE the struct is different between these two, meaning you now have a conditional struct definition. But let's get this part correct first, then modify it to accomodate as needed.

Sarge

PS: as for being "slightly off", well, that's the story of my life. why do you think I am so heavily dependent upon you all? But hey..when this is finished, it will be dynamite!

PPS: Again, a very sincere ThankYou to all of you who are here helping, especially those who have taken the time to put up with my rantings and ravings.

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

Its the people who dont rant and rave, the people who are always content that I worry about; If we were all content then how would anything get done?! Please, carry on Sarge

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Rant...Rave

Rant Rant....Rave Rave

Rant Rant Ran......................................

Ah, hell!

Merry Christmas everybody

Sarge

MrUnleaded · Posted: Mon Dec 16, 2002 2:17 am Post subject:

[="sarge":3u2aazzm]Rant...Rave

Rant Rant....Rave Rave

Rant Rant Ran......................................

Ah, hell!

Merry Christmas everybody

Sarge[/:3u2aazzm]

woo hoo christmas is ten more days....

Merry Christmas and happy new year!
_________________
-MrU