VB Decompiler Forum Index VB Decompiler
Hosted by TheAutomaters.com
 
  MemberlistMemberlist
 

EventPointer

 
   VB Decompiler Forum Index -> Structures
Author Message
MrUnleaded
Site Admin


Joined: 21 Sep 2002
Posts: 385
Location: California

Posted: Thu Oct 17, 2002 4:08 pm     Post subject: EventPointer

Parent: <a href=http://decompiler.theautomaters.com/viewtopic.php?t=25>EventTable</a>

Code:
Private Type tEventPointer
Const1 As Byte ' 0x00
Flag1 As Long ' 0x01
Const2 As Long ' 0x05
Const3 As Byte ' 0x09
aEvent As Long ' 0x0A
' 0x0E &lt;-- Structure Size
End Type


Related Items:
<a href=http://decompiler.theautomaters.com/viewtopic.php?t=27>aEvent-&gt;CodeInfo</a>
Back to top
_aLfa_
Site Admin


Joined: 21 Sep 2002
Posts: 233
Location: Aveiro, Portugal

Posted: Fri Oct 18, 2002 6:53 pm     Post subject:

i've this to add:
b1 As Byte
l3 As Long
b2 As Byte
_________________
One thing only I know, and that is that I know nothing. (Socrates)
Back to top
sarge
Moderator


Joined: 24 Sep 2002
Posts: 194

Posted: Mon Oct 21, 2002 10:23 pm     Post subject: Const2

Hi, all!!

All this assumes I am making your structure links correctly....

[Sidebar: for example, "CodeInfo" calls for "EventPointer" as a parent, yet there is nothing in "EventPointer" that references "CodeInfo"...or am I missing the linkage altogether?)

Based on the "three jump address" description in "EventTable", I think I can find it in a exe. Then, using your Note below the "EventTable", I can find the array of "EventPointer" address that preceedes it (This array only appears before the FIRST EventTable - not all of them. Also, it is the address pointed to by "Address5" in "OptionalObjectInfo" - as we have previously discussed). Using them, I attempt to access their respective "EventPointer" structures. However, each address points to offset 0x07 in the "EventPointer" structure, not to the beginning of the structure. [This offset,which you have as part of Const2, is the codetype flag, and will be a 0x33 if the code is compiled as PCODE, or E9 if the code is compiled as NATIVE.]

The start of the "EventPointer" structure (which seems to contain the value 0xB8) is actually pointed to by each event code in the EventBlock (my name for it).

Perhaps the "EventPointer" structure needs to be changed?


Sarge
Back to top
MrUnleaded
Site Admin


Joined: 21 Sep 2002
Posts: 385
Location: California

Posted: Tue Oct 22, 2002 1:56 am     Post subject: Re: Const2

[="sarge":9xqj0fnc]Hi, all!!

All this assumes I am making your structure links correctly....

[Sidebar: for example, "CodeInfo" calls for "EventPointer" as a parent, yet there is nothing in "EventPointer" that references "CodeInfo"...or am I missing the linkage altogether?)[/:9xqj0fnc]

you are partly correct in that CodeInfo requires EventPointer as a parent.....but can also have ProcedureTable as a parent(which is less complex)

and maybe i didnt make it clear enough but on the EventPointer Struct....the aEvent item is the pointer to the CodeInfo

[="sarge":9xqj0fnc]
Then, using your Note below the "EventTable", I can find the array of "EventPointer" address that preceedes it [/:9xqj0fnc]

correction....The Array of addresses to the EventPointer[s] proceeds(after) the EventTable

[="sarge":9xqj0fnc](This array only appears before the FIRST EventTable - not all of them. Also, it is the address pointed to by "Address5" in "OptionalObjectInfo" - as we have previously discussed). [/:9xqj0fnc]

So then OptionalObjectInfo.Address5 points to the EventTable???

[="sarge":9xqj0fnc] Using them, I attempt to access their respective "EventPointer" structures. However, each address points to offset 0x07 in the "EventPointer" structure, not to the beginning of the structure. [/:9xqj0fnc]

hmm.....interesting.....no comment on that....as of yet....

[="sarge":9xqj0fnc] [This offset,which you have as part of Const2, is the codetype flag, and will be a 0x33 if the code is compiled as PCODE, or E9 if the code is compiled as NATIVE.]
[/:9xqj0fnc]

is that right? I will make the changes after evaluation...

[="sarge":9xqj0fnc]
The start of the "EventPointer" structure (which seems to contain the value 0xB8) is actually pointed to by each event code in the EventBlock (my name for it).

Perhaps the "EventPointer" structure needs to be changed?
[/:9xqj0fnc]

i never said i was right be specific about what needs to be changes and ill look into it asap
_________________
-MrU
Back to top
sarge
Moderator


Joined: 24 Sep 2002
Posts: 194

Posted: Tue Oct 22, 2002 11:46 am     Post subject:

Thanks for your reply.

I hesitate to simply say that some structure is wrong, as I am still trying to work out the inter-relationships between them, then have to match them to my notes; this is difficult enough because of the naming differences, but of course you also have definition differences! I suspect it may get even worse when we get to parsing the procedures.

One example of my difficulities is the one you mentioned:
"and maybe i didnt make it clear enough but on the EventPointer Struct....the aEvent item is the pointer to the CodeInfo ". It is very hard to determine that the address of Event is actually CodeInfo. Shouldn't the names match, so that aEvent becomes aCodeInfo (or vice versa)? And, of course, this assumes that CodeInfo is a more proper name for that structure than Event.

You're right about proceedes/preceeds...my bad. That may be why I asked what I asked; if they didn't match up, that would just further add to my confusion.

Two comments, please:

1. Would it help to have a demo program so we can use some specific examples of what the discussions are referencing?

2. Since I don't use structures the way you do, I can't make these nice boxes with colored text, etc. However, I could make a (rather lengthy) text explanation. This of course makes things much more complex, as even the relatively few paragraphs in these posts are sometimes hard to follow. (Thus, the demo program would help).


Thanks for bearing with me

Sarge
Back to top
Anonymous
New User


Joined: 10 Feb 2008
Posts: 0

Posted: Tue Oct 22, 2002 11:59 am     Post subject:

Im not quite sure on your theory about the E9 thing. If you look in most native-compiled exes, you'll notice an "array" (if you can call it that of 0xE9's and 0x9E's just after. This may really just be a side effect of native compilation
Back to top
sarge
Moderator


Joined: 24 Sep 2002
Posts: 194

Posted: Tue Oct 22, 2002 1:04 pm     Post subject: P-vs-N

Perhaps...but doesn't that mean it can be an indicator? I've found that that particular byte is usually one or the other. However, I 'm not sure what you mean by array. Each entry in that particular block of code contains it's own E9 (if native, of course), just like it has its own B8 at the start.


Maybe we need a flow-chart type of diagram to show the inter-relationships between these structs? It would also help on the naming differences.


Sarge
Back to top
MrUnleaded
Site Admin


Joined: 21 Sep 2002
Posts: 385
Location: California

Posted: Tue Oct 22, 2002 2:32 pm     Post subject: Re: P-vs-N

[="sarge":2uu377ok]Perhaps...but doesn't that mean it can be an indicator? I've found that that particular byte is usually one or the other. However, I 'm not sure what you mean by array. Each entry in that particular block of code contains it's own E9 (if native, of course), just like it has its own B8 at the start.


Maybe we need a flow-chart type of diagram to show the inter-relationships between these structs? It would also help on the naming differences.


Sarge[/:2uu377ok]

perhaps we could work on a Visual Representation.....sarge im sure you would enjoy seeing my HTML Memory Map routine.....it helps visualize the layout of the structures by Color highlighting the Hex.....ill post an example soon....

also....i have notice major differences in this struct when compiled in native vs pcode....for one the sizes are different.....another....the native version has no pointer....i am thinking that it should be a um...[variable] struct that changes depending on if it is native or pcode.....

the current post is based on pcode information....


also about the CodeInfoaEvent name...i guess it wouldnt hurt to change the name to codeInfo.....i just originally named it Event.....because it is one....

moog: could you do me a favor and post the latest version you have of commonApp 1.0 and also commonApp 2.0 (native and pcode for both,and perhaps the source also?) that way we have some reference versions to work with.....because i have two seperate versions on commonApp 1.0 from you....

p.s. i have found some unique stuff that i will post soon....im still looking into it more....
_________________
-MrU
Back to top
Anonymous
New User


Joined: 10 Feb 2008
Posts: 0

Posted: Tue Oct 22, 2002 2:50 pm     Post subject:

The versions found at extra.decompiler.com are the "real" versions. I still havent put the source up for CommonApp2. I can do...
Back to top
sarge
Moderator


Joined: 24 Sep 2002
Posts: 194

Posted: Tue Oct 22, 2002 5:23 pm     Post subject:

That would probably help a lot! Thanks.

Also, if the byte in question is 0x33, you just skip two bytes and get an ADDRESS. If the byte in question is 0xE9, you don't skip any bytes and just get an OFFSET.

And of course, you need to know the difference so you can parse it.

More also, if you use CommonApp as our reference, all my notes are already done, and I can refer to addresses directly. This will allow me to post a flow-chart for CommonApp that shows how to get to the control-vs-GUI events. You can then translate that into structures. Is this acceptable to you?

sarge
Back to top
sarge
Moderator


Joined: 24 Sep 2002
Posts: 194

Posted: Tue Oct 22, 2002 5:28 pm     Post subject: Aghhhh!

Ok, so I came here first. Now, going back to the main index, I can see you DID choose to use CommonApp. Thanks! I will attempt to post my stuff this PM (east coast) time.

Sarge
Back to top
MrUnleaded
Site Admin


Joined: 21 Sep 2002
Posts: 385
Location: California

Posted: Tue Oct 22, 2002 6:08 pm     Post subject: Re: Aghhhh!

[="sarge":2i5f1rlz]Ok, so I came here first. Now, going back to the main index, I can see you DID choose to use CommonApp. Thanks! I will attempt to post my stuff this PM (east coast) time.

Sarge[/:2i5f1rlz]

I will also post my HTML Output of CommonApp.exe tonight...or this afternoon.....
_________________
-MrU
Back to top
sarge
Moderator


Joined: 24 Sep 2002
Posts: 194

Posted: Tue Oct 22, 2002 11:55 pm     Post subject: Stuff

For CommonApp:

Concept...............Address..............Name...................Comment
(Start)...................$11B4........VBheader.signature..........VB5!
move 30h..............$11E4.........aProjectInfo................points to $127C
move to ptr............$127C
move 04h..............$1280..........aObjectTable..............points to $14B8
move to ptr...........$14B8
move 30h..............$14E8...........aObject....................points to $150C
move to ptr...........$150C...........Object......................points to $17C0
move to ptr...........$17C0
move 68h.............$1828............Address5..................points to $1900
move to ptr..........$1900

[Sidebar: Since I am having trouble "connecting the dots" in reference
to the remaining structures (names not matching, etc), I have resorted to a text description.]

At $1900 are three addresses that point to offset 7 of EventPointer. There are three addresses here because in this case there are three events. I call this the ProcedureBlock (although a better name would probably be EventBlock). After the ProcedureBlock comes the EventTable at $190C; I believe this is correct because the EventTable structure contains references to the three unusual "jmp" addresses, and that follows the flow of CommonApp at $1918, $191C and $1920. This would seem to indicate that MrUnleaded's note under the EventTable structure should reference the PREceeding addresses, not the PROceeding addresses. Thus, he would be referencing the ProcedureBlock.


In the EventTable at $190C (this is the first of four; there are three controls, plus the form itself):
aControl points to the Control structure at $1860. In this structure at offset 20h is a pointer to the name of the control associated with this EventTable, and therefore to the events which follow. (As an FYI, I used the name because it was easier; there is index and type data here also.) In the case of CommonApp, the control name is "lstItems". By accessing the data analyzed in the GUI block (not explained here), you can associate "lstItems" with a ListBox, which has 21 events. In this case, none of the events are active, so the next 21 addresses are all 0x00000000. Then the next EventTable at $1978 begins. This continues for all contols.

Ok, so suppose an event is NOT 0x00000000? The pointer then points to
EventPointer. Offset 7 in EventPointer is of particular concern to us.
First of all, it tells us whether the this particular event code is compiled
in Native or Pseudo. It also tells us where to find the next reference to
finally GET to the code. If the compile type is Pseudo, this byte will be
0x33. This tells us to skip the next 2 bytes, then get an address value. If the byte is E9, the compile type is native and it tells us not to skip any
bytes, and just get an offset value. In either case, you can get to the code for that event.

Each of the event addresses for a control correspond to the event for that control as listed in the IDE. So, by knowing the name of the control, the name of the event, and the code address, you can easily come up with "cmdAdd_click" at $1DA8.

Based on this, I believe the EventTable structure should have added to it, a reference to aEvent, whose quantity is variable and depends upon the control type. Further, it should be indicated that the quantity of EventTable structures depends upon the number of controls.

Further, I believe that the EventPointer structure should be changed to reflect the variable at offset 7, and the related differences in the bytes that follow it.

Further, I believe that "address5" should be renamed.

I would also like to suggest that a structure be created for the event code itself. The elements should include the parent address, the size and the fact that the code/structure size is variable.

Finally, all of these structures are related in this manner for each individual form in an exe, with one structure following the other. Therefore, there could be one "giant" structure containing all these others,
which would serve to indicate that there are no "unknown" bytes between them.

Well, there you have it...hopefully in understandable form; even more importantly, hopefully correct!

Sarge
Back to top
MrUnleaded
Site Admin


Joined: 21 Sep 2002
Posts: 385
Location: California

Posted: Wed Oct 23, 2002 3:41 pm     Post subject: Re: Stuff

[="sarge":34hrd5rl]For CommonApp:

.....


Sarge[/:34hrd5rl]


Alright i will work on it this friday
_________________
-MrU
Back to top
Anonymous
New User


Joined: 10 Feb 2008
Posts: 0

Posted: Sat Dec 07, 2002 11:10 pm     Post subject:

You are correct about the EventTable being strictly the wrong size, but the reason I originally created it like this was more of a header-structure. Just as certain aspects of structures before point to arrays of addresses, it could be viewed that the EventTable "points" to an array of addresses defined by a number stored in OptionalObjectInfo.

The rest I cant argue about
Back to top
sarge
Moderator


Joined: 24 Sep 2002
Posts: 194

Posted: Sun Dec 08, 2002 10:27 pm     Post subject:

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
Back to top
   VB Decompiler Forum Index -> Structures All times are GMT
Page 1 of 1

 
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