Well, here is a copy of the post I made on another thread, titled
(I think) "Lack of quality on this site":

-----------------(Start 1st Post Copy)----------------
Well, how about this:
Q. Where and why is a controls index value included twice in a VB6 app?
A. Once in the FORM level code so the form can access it, and once in the
control level code so the control itself knows.

Q. How do you find the StartUp module and whether it is a FRM or BAS?
A. "Walk" the exe structure to find the file-type signature, "walk" the file-type
signature/structure to find the file-header info, parse the file-header info to find
the embedded app start-point, parse the embedded app start-point to determine
the app signature, vector off the app signature to find the app entry-point,
"walk" the entry-point signature/structure to find the StartUp module, parse the
StartUp module for its type and name.

Q. What is the key signature for a CommandButton, contained in a FrameBox, which is itself
contained in a FrameBox, which is contained by the SECOND Form in a VB6 SDI (Single
Document Interface) app?
A. 4 (In hex: 0x04). Note: TRICK QUESTION...It is ALWAYS 4; whether placed in a Frame, or in
the Form itself.

Haven't seen this here yet...even though this forum is describe as "Decompiler Discussion Forum". Anyone
know where a discussion forum that has real discussion, is?

Sarge
------------------(End 1st Post Copy)--------------------------

When questioned about my statement of "Decompiler Discussion
Forum", here was my reply (also from the same thread):


------------------(Start 2nd Post Copy)--------------------
Well, I kind of assumed from the concept of "reverse engineering" that, if you were talking about code, you must be decompiling.
If it was a piece of electronics you were reverse engineering, I
would have assumed you were trying to re-create the schematic.

But...
I'm still waiting for the answer...Where the %*&% is a true,
reasonably intellectual, non-flame discussion group???

Sarge
-----------------(End 2nd Post Copy)---------------------------

Comments, anyone?

Sarge

Useful information Sarge. Could this be used to explain how a disabled control is encoded in the PE file? I'm thinking of the VB6 Crackme#2 example where the OK button is disabled. It can be enabled run time, but can a control attribute be changed by modifying the file?

I made a VB6 test app with 1 button, either enabled or not. If I set an Index value for each in the Properties window I can see the 2 Index references in the Form and Control level code as you mention. btw, it seems like this doesn't apply if you *don't* specifically set an Index value? I don't see the reference duplicated in this case.

For the disabled button I chose an Index value to be equal to 7A99h. You can see that referenced twice in the file, the 1st instance is the 1st WORD value, the 2nd is just after the "OK" string:

Disabled Button:

00000599 997A 0800 436F 6D6D 616E 6431 0004 0102 .z..Command1....
000005A9 004F 4B00 0299 7A04 8007 E808 DF02 7701 .OK...z.......w.
000005B9 0800 1100 00FF 0204 00


For the enabled button the value is 7B99h:

Enabled Button:

00000599 997B 0800 436F 6D6D 616E 6431 0004 0102 .{..Command1....
000005A9 004F 4B00 0299 7B04 8007 E808 DF02 7701 .OK...{.......w.
000005B9 1100 00FF 0204 00 .......


I'm thinking that the Enabled = False Property value is encoded somewhere in the Control level code in the disabled example. You see an extra WORD value of 0800h in the disabled hex for example. I know in Delphi the Enabled Property is only encoded if it is FALSE, if it is the default TRUE then it doesn't seem to need to be specified.

If I mess with any of the hex under the disabled button code I get an Invalid File Format error. In Delphi however I've been able to do exactly this and recompile the code successfully using ResHacker. Are there ways to make a hard modification to a VB6 file resource and have it run? More to the point, is there a way to *know* what words and dwords in the PE file might represent certain properties? If I mess with the extra 0800h value and change it to 0900h, then the file runs but the button doesn't show at all (so it might actually be the Visible property value I'm fiddling with).


Meaculpa had asked me if there was a way to make a permanent patch to the runtime solution of temporarily changing the WS_DISABLED flag of CreateWindowExA I gave in the VB6 Crackme#2. I saw your post and thought it might help answer the question, which is why I split the thread.

This is new info you've supplied us with, so I'd be happy to see a discussion of it.

Regards,
Kayaker

Disabled button

00000599 997A 0800 436F 6D6D 616E 6431 0004 0102 .z..Command1....
000005A9 004F 4B00 0299 7A04 8007 E808 DF02 7701 .OK...z.......w.
000005B9 0800 1100 00FF 0204 00

Enabled button

00000599 997B 0800 436F 6D6D 616E 6431 0004 0102 .{..Command1....
000005A9 004F 4B00 0299 7B04 8007 E808 DF02 7701 .OK...{.......w.
000005B9 1100 00FF 0204 00 .......

Edited button
should be enabled

00000599 997A 0800 436F 6D6D 616E 6431 0004 0102 .z..Command1....
000005A9 004F 4B00 0299 7A04 8007 E808 DF02 7701 .OK...z.......w.
000005B9 1100 00FF 0204 0000 00

Yup, that works javelin. So you just delete the Enabled = False entry (I guess it was that after all) and shift everything over by a WORD until the zero delimiter. I would have thought this might have upset some address pointers, but it seems to work OK. Cool.

Kayaker

Not bad, gentlemen! (Or is one or more of you a Lady?)

Two things:

Yes, the index is "not there" if you don't indicate it; more correctly, it is a "0", which more normally be a valid index value,
except the "valid index" flag is not set. So, the data still actually
DOES appear (that is, there is a data byte in that spot in the code) but its unused as its "not the index".

Yes, the concept (CONCEPT only) of removing the two code bytes is correct; the reason is that VB thinks in terms of default data (start thinking like this yourself when reverse engineering this stuff, its a lot easier!). That is, if the button is disabled, the value of the "Enabled" property must be "False", so VB sets the code to say "Enabled False". If the button is enabled, the value of the "Enabled" property is "True", so VB does nothing! Why? Well, if it is not specifically marked as "False", it must be "True", so why waste the code? Thus, by removing the two bytes of data that show the button as disabled, it automatically becomes enabled.
However, you must be carefull in thinking that you can actually just cut two bytes out of the code and move the remainder back
two bytes. There are many addresses that may now be invalid.
It would be better to overwrite these two bytes with some other
two-byte property; one that is innocent and won't change the operation of the button.

Sarge

Here's another thought: The data sequence for the command button disabled is "08 00"; the data sequence for the command button enabled is [no data]. The "08 00" is basically saying "Enable (08) = False (00)". So, based on the concept of
IF ITS NOT FALSE IT MUST BE TRUE, we should be able to say
"Enable (08) = True(FF)". So, try changing the 00 after the 08 to an FF. Then you won't need to move anything, or overwrite with anything that may not be innocent.

Sarge

Hi Sarge,

is it possible to use same/similar technique for menu enabling/disabling in VB applications? I tried to enable menu item using SoftICE but I only 'ungrayed' the menu.

Thank you
sF

Hi,

The menu concept is similar regarding the enable data; it is assumed disabled unless otherwise stated. The enable property for menus is 5 (hex: 0x05), thus a menu item that is disabled is
"Enabled (05) = False (00)"; in the code that is obviously "05 00".
If the menu item is enabled, no code is used.

If you read the previous messages, you will see why it might be better to try "05 FF", but I don't know if that will work---never tried it! Let me know, I'd be interested.

Also, remember that just making the menu text enabled (or even visible, if it happens to be invisible), does just that: it makes the menu text enabled (ungreyed) or visible. It has NOTHING to do with whether or not there is any code that supports that menu selection!

Sarge

"I See", said the blind man to his deaf dog ;-)

Rather interesting the way VB inserts its Control properties into the PE file. Make a few test apps with VB and select various combinations of properties other than the defaults and you start to see a pattern when you compare them.

For a single button control, the *default* byte sequence defining the attributes of that control (VB5) appears to be encoded by the 13 bytes following the null terminated ascii Caption label ("OK" in this case):

----------------------------------------------
Default Property values used on a button
5A8 4F 4B 00 04 90 06 38 04 CF 03 EF 01 11 00 00 FF OK....8.........

The 1st byte value after the null-terminated label defines that it's a button (bit of a guess there) = 04h

The next 4 WORDS are the Position of the button control:
Left.. 0690h = 1680
Top... 0438h = 1080
Width. 03CFh = 975
Height 01EFh = 495

The next 2 bytes (1100) I can't define, then there's the terminating 00FF.
------------------------------------------------

If you modify a property from its default you can see how it's defined.

------------------------------------------------
Enabled = False - 2 bytes
5A8 4F 4B 00 04 90 06 38 04 CF 03 EF 01 08 00 11 00 OK....8.........
5B8 00 FF
the difference is the 0800. Sure enough as Sarge mentions, changing it to 08FF enables the control.
------------------------------------------------

------------------------------------------------
Visible = False - 2 bytes
5A8 4F 4B 00 04 90 06 38 04 CF 03 EF 01 09 00 11 00 OK....8.........
5B8 00 FF
defined by 0900, change to 09FF to make visible.
------------------------------------------------

------------------------------------------------
Appearance = Flat (instead of the default 3D) - 2 bytes
5A8 4F 4B 00 04 90 06 38 04 CF 03 EF 01 11 00 00 1F OK....8.........
5B8 00 FF
difference appears to be 001F.
------------------------------------------------

------------------------------------------------
BackColor = &H008000FF - 5 bytes
5A8 4F 4B 00 03 FF 00 80 00 04 90 06 38 04 CF 03 EF OK.........8....
5B8 01 11 00 00 FF .....
appears to be defined as 03 + the color value 008000FF
------------------------------------------------

------------------------------------------------
Appearance = Flat + BackColor = &H008000FF - total 7 bytes extra from default
5A8 4F 4B 00 03 FF 00 80 00 04 90 06 38 04 CF 03 EF OK.........8....
5B8 01 11 00 00 1F 00 FF .......
------------------------------------------------


You can go on like this forever. What we really need now is a listing of all the identifiers for each property. From this it appears that you can scan the control level code for a control and determine what properties are defined different from default. So far it seems that
Appearance = 00
Back Color = 03
Enabled = 08
Visible = 09
etc.


You can do the same thing with a menu and see that 0005h disables a menu item. Change it to 0004h and it's enabled again. Damn! That is too easy ;-)

5EA 45 6E 61 62 6C 65 64 00 FF Enabled..

609 44 69 73 61 62 6C 65 00 05 00 FF Disable....


This looks great for basic reversing of disabled / not visible controls, where the fact that they *are* disabled means that this must be specifically defined, therefore it's easy to switch them back with a byte change (doesn't do anything about runtime changes though). But what about *adding* bytes to change an attribute? As soon as you do you're going to screw up a bunch of address pointers. The next thing is to find what pointers are important, and if it's possible to fix them.

I'm trying to get a handle on how the VB specific parts in the code section are structured and how they are referenced to each other. Plus, if there are any pointers within the other sections that would need to be changed if you do start moving chunks of hex around.

It seems that beginning at the start of the .text section, first is defined the Project, then the Form, then the Controls in reverse order to which they're added, along with the attributes we've just been discussing, then the Menu items. Then there is the name of the project file and some other stuff, then a big bunch of zeroes.

The fact that there seems to be a large buffer of zero padding makes one think you could add or delete bytes from the Control code to modify the control attributes, and then shift things around without changing the file size or any code that comes after. Then you'd only need to change a minimum number of pointers to readdress the controls from where you made the change down to the zero padding, which could absorb any changes.


After the zero padded section, a new section of code starts that defines something more about the controls and menu items. I'm trying to make heads or tails of what that describes:

B28 436F6D6D 616E6431 00000000 0C004400 Command1......D.
B38 00000000 00000000 4838E99C D5DDD511 ........H8......
B48 8111909F FE04505E 4738E99C D5DDD511 ......P^G8......
B58 8111909F FE04505E 4C38E99C D5DDD511 ......P^L8......
B68 8111909F FE04505E ......P^
etc

You mentioned VB uses Form Level code and Control Level code, how do the 2 levels relate to each other? It seems the Control code for each window component is nested within the Form code, and that they appear to follow each other in the PE file. Are there pointers in the Form level code or elsewhere that reference each of the components in the Control level code? This would be the first thing to determine if you're going to modify the code somehow.

Oh yeah, and does anybody know if there is a resource viewer around that recognizes VB resources?

'bout it for now.

Kayaker

Very impressive! You are where I was, long ago.

Here's some hints:

1. You are correct that 0x04 indicates the command button type. However, it is NOT the 0x04 that immediately preceeds the 0x90-0x06 word. This 0x04 means that the following 4 words (8 bytes) are the size and position data.

2. The 0x11 that follows is the tab index; the data is a word (2 bytes).

3. The termination is NOT 0x00-0xFF, since the 0x00 is the second byte of the tab index. The termination is actually the 0xFF and the sequence of bytes that follow it. Since you didn't give them here, I can't tell you what they are, but I will bet is is probably a 0x02, 0x03 or 0x04. (0x05 is also possible, but is not usually found in a control button section)

4. Yes, "visible" is 0x09, and the data is a byte.

5. As for the desired "list of identifiers", yes, thats the way to go. But be prepared for a bit of work (My notes are at least 50 pages long!)

6. Your comment about adding bytes is valid; the concept of screwing up any following address pointers is a very real concern.
However, I have had very little need to actually add a missing attribute into an app; presumably, the app already does whatever it is supposed to do, and you don't really care that the appearance of the button is 3-D and you want to change it to Flat; obviously it works either way, now that you have been able to enable it.

7. As to the FormLevel code vs ControlLevel code:
Look at my note #3 above about the termination codes. The reason there is more than one is because the control is a child of the parent form, and thus is actually "embedded" within it. The byte sequence after the 0xFF tell how the embedding occurs. Here is an example:

----------Begin FORM----------
Name: frmProperty (SDI)
Caption: Property Value
ScaleMode: 1 - Twip
FontTransparent: True
AutoRedraw: False
BorderStyle: 4 - Fixed ToolWIndow
Icon: (DEFAULT ICON)
LinkTopic: Form1
MaxButton: False
MinButton: False
Left: 2655
Top: 3135
ScaleWidth: 5400
ScaleHeight: 1215
ShowInTaskbar: False
StartUpPosition: 1 - CenterOwner
----------Begin TEXTBOX----------
Name: txtPropValue
Left: 135
Top: 315
Width: 5070
Height: 300
TabIndex: 1
----------End TEXTBOX---------
----------Begin COMMAND BUTTON----------
Name: cmdCancel
Caption: &Cancel
Left: 3735
Top: 720
Width: 1335
Height: 360
TabIndex: 3
Cancel: True
----------End COMMANDBUTTON---------
----------Begin COMMAND BUTTON----------
Name: cmdOK
Caption: &OK
Left: 2190
Top: 720
Width: 1335
Height: 360
TabIndex: 2
Default: True
----------End COMMANDBUTTON---------
----------Begin CHECKBOX----------
Name: chkPropValue
Caption: Check1
Left: 135
Top: 315
Width: 5070
Height: 300
TabIndex: 4
----------End CHECKBOX---------
----------Begin LABEL----------
Name: lblLabel
Caption: &Enter property value:
Left: 135
Top: 60
Width: 4365
Height: 225
TabIndex: 0
----------End LABEL---------
----------End FORM---------

This example program is "VISDATA.EXE", found in the VB sub-directory. Notice that the various controls are contained within the form. This is exactly how they are in the code.

Good luck
Sarge

Thanks for the info Sarge, it starts to make sense once you look at the .frm file.

I've seen your discussions in that "other" decompiler forum ;-) At least we're relatively spam-free here, so I hope you can generate the kind of brainstorming sessions you were looking for. What's the potential for a simple VB resource editor, as opposed to a full blown decompiler?

I was thinking it would be possible to find virtual address pointers to the start of a project or form and walk your way down to the control level, to figure out how the VB components are put together. I tried finding a few pointers to see if I could get into a linked list which tied together the various parts, but I couldn't come up with any hits.

You mentioned the byte sequence after the 0xFF tell how the embedding occurs. Here's mine, it begins with the 02h as you guessed. What significance do the final few dwords have?


0000059B 43 6F 6D 6D 61 6E 64 31 00 04 01 02 00 4F 4B 00 Command1.....OK.
000005AB 04 08 07 48 03 BF 04 DF 02 11 00 00

000005B7 FF 02 04 00 00 50 00 00 00 EC D8 86 4C 6E DF D5 .....P......Ln..
000005C7 11 81 11 F6 AE 82 22 20 5D ......" ]


Begin VB.CommandButton Command1
Caption = "OK"
Height = 735
Left = 1800
TabIndex = 0
Top = 840
Width = 1215
End
End
Attribute VB_Name = "Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False

Cheers,
Kayaker

Hi All,
I hope you are all well.

I don't want to bore anyone with the complete detail, or
duplicate work already done (and posted), but i got a little
further. My complete notes are also available.....



Disabled 2 (with everything else)
00001225 636D 6442 7574 746F 6E32 0004 0107 0042 cmdButton2.....B
00001235 7574 746F 6E32 0002 5901 0316 0000 8004 utton2..Y.......
00001245 4006 2C01 B004 E803 0800 0900 1102 0013 @.,.............
00001255 FF14 FF16 011B 7B00 0000 1F00 2901 2A00 ......{.....).*.
00001265 FF03 3200 0080 0200 000A 00 ..2........


636D 6442 7574 746F 6E32 //button name
00 //terminating zero
04 //command button type
0107 00 //still unknown
42 7574 746F 6E32 //button caption
00 //terminating zero
02 //still unknown
5901 //index value - see above
0316 0000 80 //BackColour with value &H80000016& (1600 0080) see above
04 //4 words button dimentions follow
4006 //dimention data - see above
2C01 //dimention data - see above
B004 //dimention data - see above
E803 //dimention data - see above
0800 //this button is disabled
0900 //this button is NOT visible
11 //still unknown
02 00 //tab index value
13 FF //for this button Default=true
14 FF //for this button Cancel=True
16 01 //for this button DragMode=Automatic
1B 7B00 0000 //Help Context ID
1F00 //the button appearance = flat
2901 //for this button Style=Graphical
2A00 //the Focus Validation is set to CausesValidation=false

later,

Regards,
.MeaCulpa

Heya guys It's been quite a while since I've been here.. and there's some nice stuff BTW Sarge.. good work on sharing what you've learned Umm as far as decompiling forms, I think I've got a list of all controls and their representation somewhere. The only thing I don't have (in paper form) woud be all custom objects. Umm it's been several months (at least) since I've worked with this part of the EXE. I'll see what I can dig up and if all of you could create a "wish list" I'll put together a zip of what I can find.

Good luck!!

joe

(This message may appear multiple times; somehow I got dumped)

Wow! Take a few holiday days off and....%$^#$


1. A Resource decompiler/editor? Hmm...good thought; don't know what it would take, though...have to do some research.

2. 0xFF begins/ends the embedded sequence. The data following the 0xFF tells a) What new embedded level to begin, or b) what existing embedded level to use, or c) what existing embedded level to end, etc.

3. Where is the VB6 "Crack2" that you mentioned; it would help if we were all "on the same page"?

4. Use the sample output I posted from the VISDATA.EXE file, and compare it with a hex listing of that file. You should easily see how the 0xFF ?? ?? ?? sequence works.

(Sidebar: How much should I tell you, vs how much do you want to find out for yourselves? I hesitate to respond to meaculpa's post by just giving him his missing answers [no offense intended];
but I am not sure where to draw the line)

5. Josephco, glad to see you here. I have the exedec program, but frankly don't know how to use it properly, I am always getting error messages! How about a hint? Also, I will be the first to admit that I am still missing about 3 of the codes, mostly because I have not yet found the proper IDE and/or property settings that create them. I would LOVE to compare notes.

6. I have attached a BMP file that may spark your interest, if I can get it to go. The 100k limit means it is a 16-bit color pallette; hope it show up!

Sarge

PS to meaculpa:

Please check my post dated 11/21, item #2.

Thanks

Sarge

Hi All,

@Sarge:
I see you "hesitate to respond" to my posts? I hope i am not that far beyond hope ? )

In your post dated 11/21, item #2 : 0x11 is the tab index value.
You refered to this from Kayaker:
0000059B 43 6F 6D 6D 61 6E 64 31 00 04 01 02 00 4F 4B 00 Command1.....OK.
000005AB 04 08 07 48 03 BF 04 DF 02 11 00 00

000005B7 FF 02 04 00 00 50 00 00 00 EC D8 86 4C 6E DF D5 .....P......Ln..
000005C7 11 81 11 F6 AE 82 22 20 5D ......" ]

So you say the tab index is directly after the 4 words of the resources. ? But the button in the above (your) example is enabled.

From my buttons i got the following after the 4 data/position
words:

0800 //this button is disabled
0900 //this button is NOT visible
11 //still unknown
02 00 //tab index value


My button resource looks like this:
Disabled 2 (with everything else)
00001225 636D 6442 7574 746F 6E32 0004 0107 0042 cmdButton2.....B
00001235 7574 746F 6E32 0002 5901 0316 0000 8004 utton2..Y.......
00001245 4006 2C01 B004 E803 0800 0900 1102 0013 @.,.............
00001255 FF14 FF16 011B 7B00 0000 1F00 2901 2A00 ......{.....).*.
00001265 FF03 3200 0080 0200 000A 00 ..2........


Am i doing something wrong? If so please help.

This post is getting too long, so i will continue in a new one.


(How about sharing your 50+ pages of notes )

@Kayaker: Any comments on this so far?

Regards,
.MeaCulpa

@Sarge:

Right where were we......

If i look at 2 cases of dubble buttons i get this:


disabled
0000123B 0002 0100 0418 06E0 0147 0457 0308 0011 .........G.W....
0000124B 0200 FF03 3200 0080 0100 000A 00 ....2........

disabled
0000126E 0002 0000 04F0 00E0 0147 0457 0308 0011 .........G.W....
0000127E 0000 FF03 2B00 0000 0206 00 ....+......


and the next 2:

enabled
0000123B 0002 0100 0418 06E0 0147 0457 0311 0200 .........G.W....
0000124B FF03 3200 0080 0200 000A 00 ..2........

disabled
0000126C 0002 0000 04F0 00E0 0147 0457 0308 0011 .........G.W....
0000127C 0000 FF03 2B00 0000 0306 00 ....+......


I am showing only the part after the button caption text.
In all of the buttons, after the enable/disable (0800 part) there is the 11 0000 or 1102 0000


Do i understand you correctly in saying the tab index part is:
1100 and 1102 (respectively) and not 0000 and 0200.

I appreciate the help.

As far as the 3 (perhaps more) bytes go that are unknown to me,
can you give me a small hint. ?


Regards,
.MeaCulpa

Back up a step!

My question in reference to giving you hints was only that "do you want me to just tell you the answers" or " do you want to find out for yourself"? I was/am not sure how much to just "give" (= no thinking on your part) or just "hint" (= lots of thinking on your part). Nothing in the question referenced you abilities!

No, I did not say the tab index is directly after the resources. I said that the tab index property is indicated by a 17 (hex 0x11); it may or may not be next in the sequence. Big difference! Think of it like this:

01 02 03 04 05 06 09 0A

In this example, assume all data is one byte long. This byte sequence would be decoded like this:

01 = Property to be accessed
02 = Data for property #1

03 = Property to be accessed
04 = Data for property #3

05 = Property to be accessed
06 = Data for property #5

09 = Property to be accessed
0A = Data for property #9

This type of analysis tells us two things:
1. Each property that is being set, as well as its value
2. The missing 07 and 08 are the default values (where 07 would be the property and 08 the data for property #7, IF they were there).

So what? Well, note that property 9 came directly after property 5, in this case. However, had the missing property #7 existed, it would have come between #5 and #9. So, to say that the tab index property (0x11) comes directly after the Size/Position property (0x04), isn't always true; the visible property (0x09) may come in-between. However, here is why I think that piece of confusion occurred: I was not (and as yet, am not) directly analyzing your byte sequences; I am only telling you what you have wrong or are missing. Please do not relate my info/explanations directly to the code you are submitting. Rather, re-analyze your code using the new (hopefully helpful) info that you now have.

Now, the reason I brought this up was as a result of one of your previous posts that had this:

636D 6442 7574 746F 6E32 //button name
00 //terminating zero
04 //command button type
0107 00 //still unknown
42 7574 746F 6E32 //button caption
00 //terminating zero
02 //still unknown
5901 //index value - see above
0316 0000 80 //BackColour with value &H80000016& (1600 0080) see above
04 //4 words button dimentions follow
4006 //dimention data - see above
2C01 //dimention data - see above
B004 //dimention data - see above
E803 //dimention data - see above
0800 //this button is disabled
0900 //this button is NOT visible
11 //still unknown
02 00 //tab index value
etc....

In this post, you will note the second line up from the botton is
"11 //still unknown ". But, but, but.....I had already responded to Kayaker with the info that 11 is the tab index. PLUS, you yourself said that the following bytes (02 00), were the tab index value.
Doesn't it follow, then, that 11 must be the tab index property, so that the 02 00 can be the tab index data? Once you realize this (that ALL of the data in this byte sequence operates in a similar manner), you should be able to fill in the missing properties. After all, you seemed to have realized that 08 is the enabled property (with its following single byte of boolean data), and that 09 is the visible property (also with its following single byte of boolean data); similarly, you should be able to determine that 11 must be the tab index property, with its following word (= 2 bytes) of the index number!


Hope this is clear.

As to sharing my notes, this is sort of what I have already asked:
"How much help to give". I certainly don't want to supply "crib notes" (Umm, does anybody use them anymore?), I would rather force you to think.

Also, if you want, you can send me your exe file, and I will respond with the analysis results (but NOT how I got them) so you can compare them to your own work.

Sarge

Howdy all

I have done this for most things I've come across. I hope I haven't upset anyone by posting this. I too am curious as to how much to give and how much to help. For me, finding everything out by myself was more fulfilling than reading it somewhere (I don't think any of this is on the net anyway). I can only hope that everyone else is as thrilled as I am about the new grand discoveries in the wide world of VB EXEs!!

Sarge-

I wouldn't mind comparing notes I'm a horrible note taker and to be honest my terminology isn't up to date or probably even correct (I know jack squat about VB coding). I've just figured everything I know out by myself (mostly). My decompiler isn't as advanced as Golem's but it works for me I'm more of a hobbiest when it comes to this than a decompiler writer. As far as ExDec goes... umm it was never really intended to be released. I had a few beta testers that were supposed to report back to me with problems/errors and I was going to fix them. Well as time went on, it was posted on a few tool pages and I lost all control over who could use it. In my private version I have fixed all known errors, HOWEVER there's too much "decompiler" information inside it to release the new version - sorry for any troubles it may have caused.

CommandButton - 0x04

1 Caption text
2 Index Word
3 BackColor color
4 Size size
8 Enabled boolean
9 Visible boolean
a MousePointer Byte
11 TabIndex Word
13 Default boolean
14 Cancel boolean
16 DragMode Byte
17 DragIcon pic
18 TabStop boolean
19 Tag wtext
1b HelpContextID DWord
1c MouseIcon pic
1d Font font
1e WhatsThisHelpID DWord
1f Appearance Byte
22 Picture pic
23 DisabledPicture pic
24 DownPicture pic
25 ToolTipText text
26 OLEDropMode Byte
27 MaskColor color
28 UseMaskColor boolean
29 Style Byte

Umm I don't have the structs readily available here, so you'll have to figure them out on your own (until I can rip them of course).

joe

Hello!

For the record, I agree with all your codes. I will also be a smartXss and tell you that you forgot CausesValidation and RightToLeft , but we'll let those codes be homework for the others. (Just wait until they get to OCX's!) I would suspect that, once all the codes for all the controls are known, their next step would be to analyze the entire exe to find the VB app structures, instead of doing an eyeball view of a hex dump.

Ok on the exedec; I can understand your reasoning.

Keep on trucking!

Sarge

Hiya JoCo, I was hoping you might poke your nose in if I changed the message title ;D Ahh, you guys have got the goods on the rest of us on VB decompiling, can't even compete ;-) I'm just happy both of you are willing to help the rest of us learn.

It's kind of intriguing really. Rip apart and understand an unknown file format from first principles. You kind of need to put aside your preconceptions from regular PE files. Heh, it's time to break out Visdata.vbp, IDA, Google, a hexeditor and a big pot of coffee methinks and get a look at the big picture

I did find one file that's related to the subject:
Visual Basic Project Files Structure
h*tp://www.techtutorials.com/tutorials/vbproject.shtml


I suppose to output any kind of tabulated listing of VB components you need to be able to "walk" the file. Sarge, you said

Q. How do you find the StartUp module and whether it is a FRM or BAS?
A. "Walk" the exe structure to find the file-type signature, "walk" the file-type
signature/structure to find the file-header info, parse the file-header info to find
the embedded app start-point, parse the embedded app start-point to determine
the app signature, vector off the app signature to find the app entry-point,
"walk" the entry-point signature/structure to find the StartUp module, parse the
StartUp module for its type and name.

Can one of you give a clue to that first step, finding the file-type signature, in the PE file? Just a taste now, not the whole bottle. This needs to be savoured slowly like a bottle of fine wine to be fully appreciated ;-)

Thanks and cheers,
Kayaker

Hi All,
I hope you are all well.

@Sarge:
No offence taken whatsoever. Thanks for the help so far. My mistake was i did not think the tab index value could be a word.
Lol, another piece of the puzzle fits......
When i took a step back it struck me : everything follows a pattern of (incremented by 1 ) values when you look at the first 2 bytes......., LOL, stupid me
Thankyou so far, will post findings/ outcries for help/ ameliorations later.

@Kayaker:
Say, you are not a student of Zen are you
Love your way of _thinking_.

Regards,
.MeaCulpa

Kayaker:
Start at the beginning of the file, just as you would suspect. Assuming it is an executable, it must have a DOS header. Parse the DOS header (the structure of the DOS header is available EVERYWHERE!) to find the file type, which should be 17744.
Whoa! Where did that come from?....Hint, when you find the file type, view it as a DWORD (Double Word = 4 bytes) to get this value, then view it as ASCII to see why.


Meaculpa:
Your concept of "incremented by 1" indicates some inspiration on your part. Great! But it is incomplete. Think about this: What happens if a default value occurs in the byte stream? Go back and view my 01 02 03 04, etc. example with specific attention to 07 and 08. Now, rephrase your epiphany.

Wait until you start Fonts and Images!

Sarge

Kayaker -

I'm not exactly sure where this fits in, but from a vb point of view.. everything starts from the VB5! structure.

good luck and have fun everyone!!

joe

You sure choose a cryptic way of viewing PE+28h

Kayaker

Give the man (woman?) a cigar!

Ok, here's the thinking:
To be able to decompile a VB app, you have to first FIND the VB app!. You really don't want to do this by scanning a file to find a sequence of bytes, like you do visually in a hex editor. Rather, you want a program that can do it for you. To find the elusive VB app, you have to start at the beginning of the PE file, and "walk" your way through all the pointers/vectors/offsets/addresses that eventually take you from the "MZ" at the beginning, through the DOS header, to the PE signature, to the PE header, to the PE option header, etc, etc, etc, until you finally FIND the VB structure. Then and only then can you begin to attack the VB app contained within the PE exe.

Now, you COULD write the program to do a byte-by-byte compare of your target file, and it would work much like you do manually in the hex editor: Start at the beginning of the file and scroll and scroll and scroll...until you see what you want ("PE". But this is a) very slow, and b) won't help when offsets and addresses are used (as the will be in the VB app structure), because they won't necessarily have a fixed value. So, let's not try to run before we can walk; rather, we will build up our knowledge in a manner that should make it a sound basis for the really intense stuff later.

As a side note, the data/structures/pointers/etc that we find will be only applicable to VB6 (thats what I use, thats all I have). The app structure for VB5 is similar (works very parallel to VB6) but not identical. If you are using VB5, you have even more work cut out for you!

Programming hint: now that you can find the file type signature, put the code in a subroutine, called from your main code, and try it against various file types. (You will have to either include the FILE/OPEN dialog box, or temporarily hardcode the filepath of the target file). Make your subroutine fill the DOS structure, and return an error code indicating whether the file type is PE or not.
Continue in this manner, with various subroutines for the various structures. We will use this knowledge later.

Now, if you don't want to do this programatically, but would rather have copious (COPIOUS!!!) notes and reams (REAMS!) of paper, so that you can decompile by hand, go for it.

So, there are my thoughts, comments, etc. If this is not the desired path, speak up!

Kayaker: Keep up the good work! Let me know when you find the VB app, then we'll take the next step.

heya guys!

I have already work on what you're talking about:

http://www.programmerstools.org/decompilers.htm#vbde

iorior

Very Nice!

I use RACEVB6. Gives more graphic info and "recovers" embedded graphic images. I'll try to attach a BMP of it.

Maybe the three/four of us should get together some time.

Update: Can't attach my 16 color BMP, its too big. So I tried a mono (black and white). Don't know how it may come out. If you
are interested, here's the email address from the FAQ:

18)What is your Email address?
Send all Emails to: onlinec@bellsouth.net
Be sure to use "RACEVB6" as the subject.

Ugh! I just checked the mono BMP...Ugly. You might want to go ahead and check out the Email address. their BMP is much nicer!
Also, you get the whole FAQ.

Any of the "masters" of this board, can you up the attachment size to maybe 200k?

Sarge

Umm it's been a few days since my last check-in. I haven't had much time to browse the net.. but I've been thinking about all I've read. Sarge, you said you could not decompile pcode yet.. if you have enough information about the procedures (there's tons of structs that need to be identified) and their subroutines, then (and only if you want it) I could help you get to the guts of decompilation. I have choosen one way and I believe golem has gone another. hehe There's tons of information that needs to be digested before the switch from forms decompilation to code decompilation is done. Using ExDec you could probably figure out almost everything needed. I have written an advanced disassembler for native that COULD start to do some decompilation (object.method and other simple stuff).. but it's in the very early stages. I don't even have a proper "loader" installed hehe. If you (or anybody else) is interested in some output.. I believe I could manage to throw some together. The only problem atm with the disassembler is that I haven't completely added all the FPU instruction.. so it won't work on files with a lot of math

Umm hehe kinda funny.. I must have just had a brain fart because I lost my train of thought and can't remember where I was going next haha anyway... almost all of what I know is for the sharing.. but I'm not one to just GIVE stuff away without knowing the person will use it for "honorable" purposes (also I'd like to know that the person has done their homework - just ask the creators of the pcode debugger

later all

joe

iorior:

I have had some time to play with your program. I would like to upgrade my "Very Nice!" to "Very, Very Nice!" . Now, if you could contribute some knowledge or insights, that would be great.

Josephco:
Believe me when I say I KNOW that there is a big difference between Forms code and Modules code! One of the reasons that I have not done that (or even the PCODE-vs-NCODE) is that it was not my original intention. However, as I began to attack VB6 apps, I found that I had to do much analysis that turns out to be very applicable to decompiler functions. So, it is with a sort of serendipity that I fell into this. I have been happy to part with my limited knowledge of forms and controls, which, I realize, is far
behind what others have done. But, I was unable to find anyplace on the 'Net where the low-level basics were even being discussed, much less having the knowldege made available. (Sort of forces the question, "Why is VB decompiler knowledge so closely guarded? What makes IT special?". Anyway, off of my soapbox....Sure, I would love to know as much as I can; if you want to teach, I'll listen. Your contribution of the CommandButton codes is an example (of course, there are a lot of other controls also). It is kind of hard to carry on multiple levels of "school" here; you don't want to get too far ahead of the new-guy. But I am chafing at the bit and yes, I would like to learn more. I think my next venture will be to determine control events, but I am only guessing that that is a logical next step.

As you preach, so shall I learn...


Sarge

Umm I just need to know what direction you need to be pointed in and what you may need (This goes to anybody that's interested and is willing to work hard)

As to the 'decompiler knowledge' being kept secret.. The only things I can say about this are 1) In the wrong hands this has potential to be very damaging to software companies 2) Money has been made from this in the past and the people that know how to do it have grand dreams of getting rich (I don't want to be rich, just able to pay my bills with a bit left over Hrmm what next?

joe

Hi all,
I had to re-register, so now I'm using this new "handle"; but it is the same old me.

Josephco:
Absolutely do I understand the possibilities for mis-use. But I also have to trade that off vs the reverse engineering genre.
I guess I am hoping that anyone who is disciplined enough to put forth the rather intense effort to learn for themselves, will also be have to wisdom to not do anything they shouldn't. I am not comfortable with the concept of giving out my work, but I AM comfortable with discussing/teaching what I know to enable someone else to program his/her own creation. I just will not give out the knowledge without some degree of certainty that it is deserved; that is, that the recipient has put forth some effort and is not just a "gimmee this, gimmee that". In short, I will give lots of hints, but few definite answers. Like a teacher, I want others to think; also like a teacher, I will correct when in error. Often, I will even answer a specific question! Interest just seems to have dropped recently.


Sarge

Hehe I was going to ask if the conversastion has gone private or whether everyone is just busy with other things. Seems that the two of us are pretty much the same in our beliefs If I wanted to piss on one person in particular (G****) I'd release all the information that I have. I have nothing against him.. he's helped me and I've helped him.. there isn't even a rivalry between us. The only thing I would say is that at times he's a bit too cocky.. but I'm sure that's warranted Anyway josephco_@hotmail.com is my email addy if you'd like to ask anything that you'd rather not ask on a public board. Umm everybody have fun and good luck!!

joe

Thanks for the e-address. You'll be hearing from me.

I'm kind of hoping that everyone interested is hard at work applying what we have discussed, learning on their own, and making some progress. I hope to see some more interest/questions in the future. Kayaker and meaculpa may yet return; iorior may yet make a contribution. Maybe even someone new will pop up!

Good luck all

Sarge

Lost but not forgotten ;-)

I'd be more than happy to see further VB discussions in one form or another if anyone wants to take up the cry. I'd like to take a look at iorior's code when I get the chance, to get a top-down look at things and see how forms are handled. I just wanted to see those interested be able to discuss what they wanted in a friendly environment and get a few new ideas flowing around. You never know what can develop.

I agree you shouldn't give away the fort, people should have to be serious and work for their fun. Personally I'm too caught up in my own project to give over to a new major endeavour completely, but it doesn't mean I won't play with the idea If anyone else wants to take on a project to fully understand VB and get help with it, now's your chance. Don't pass up the opportunity!

Regards all,
Kayaker

Thanks!

I was just thinking about you this morning, so I'm not surprised to find a response from you.

I have made an inference that your questions about enabling a control in the code was related to the VBCrackMe #2 you had
mentioned. This implies that this is at least some of the "other project" you had mentioned. Good luck! [Come back when you get stumped on the FF 02 03 04 sequences ]

Sarge

Hi All,
Sadly, i'm also more busy with less time to play ;(
Would like to get my teeth into this more, over the coming
holiday season.

Until later, take care.

Regards,
.MeaCulpa

Hi Sarge

Heh, no I meant my own reversing tool program I've been developing for the past several months. (surprise, non-VB related Probably why I don't want to take on a new project, I know they can evolve and grow into a never ending monster. A little tweak here, a little tweak there, damn, I'm sure I can save a few bytes if I recode this section, gee a toolbar would be nice...you get the idea

Kayaker

1. Ok, my mistake.

2. Been there, done that.

3. Please include automatic dishwashing as a option!

Sarge

Hello all,

please, can anybody post in attachment (or send it to me) some example program (created in VB) with enabled/disabled button/menu? (I don't have VB to create one ).

I'm much obliged to YOU!
sF

There is a file attached that has two command buttons.
One has the caption "ENABLED", the other has the caption
"DISABLED". That, and their "Left" properties, are the only
insignificant differences. The significant difference is that one
has its enabled property set to True and the other has it set
to False.

Good luck
Sarge

All:

For anyone who is interested, a parallel discussion can be found
at:


http://decompiler.com/

Choose "discussion", then "MS Visual Basic" (under the Decompiler heading). There are a large number of posts there, (but some are actually reasonably intelligent), that have to do with a slightly different path to decompiling. Someone who can
put the two together may want to seriously make notes.

Thanks

SargeG

*silence*

hehe I tend to avoid decompiler.com. Although there (at times) is some intriguing conversation, most of the time it's just begging for this or that and the occasional flaming of a person. Hahaha also my french isn't so good, so I can't contribute to the one good current thread :/ Umm any vb projects going on? I'm fairly busy most of the time, but could probably steal some time from something if the cause it good

joe

Hi joco

Well, I have been asking people to try my active x... To date, they have not cracked it. Maybe you can do something about it? I am sure your newest version of exdec should be able to digest it.

I have my own thread in the Mini Project forum.

Regards and respect,
Ryan

Ryan

Hehehe I've given up cracking a LONG time ago Sorry to disappoint you. But if your active x is PCode, then I might take a look at it. Anyway.. good luck!!

joe

Hi,
yes it is in PCode. Feel free to take a look. You might even *recognise* it... Grin

Thanks,
Ryan

okie... I'll see what I'll find But as I told you a while back, exdec doesn't handle OCXs or DLLs. Good luck with everything

joe

hi,
by the way, since the xoom server is down, is there any other place I can get the newest version of exdec?

Thanks
Ryan

Sorry for the delay (I'm a lazy arse sometimes hehe ). Umm There is no updated version of ExDec available. I have a private version but atm it'll stay that way. As far as your OCX goes, I've rebuilt almost everything needed to run it through ExDec. I've had to add a few structures and change the format a bit, but nothing really major. If all goes well, would you like me to send you the output? Don't worry.. if I can decompile it, I won't share what I find with anybody (I hope you believe me)

joe

Hi,
sure, that will be great. Maybe I can tell you what the exact source look like in some of the procedures.
ryan(underscore)thian(at)hotmail(dot)com(remove_this_too)

Ryan

Hi,

I'm glad to see you're finally getting some input on your protection Ryan. Good luck. Cheers Joe.

Regards,
Kayaker

Correction this is the definitive list straight from MSVBVM60.DLL property listing for a CommandButton .

CommandButton - 0x04

[0 Name text]
1 Caption text
2 Index Word
3 BackColor color
4 Size size [4 Left, 5 Top, 6 Width, 7 Height]
8 Enabled boolean
9 Visible boolean
a MousePointer Byte
[b FontName text]
[c FontSize Word]
[d FontBold boolean]
[e FontItalic boolean]
[f FontStrikethru boolean]
[10 FontUnderline boolean]
11 TabIndex Word
[12 Value]
13 Default boolean
14 Cancel boolean
[15 Parent]
16 DragMode Byte
17 DragIcon pic
18 TabStop boolean
19 Tag wtext
[1a hWnd]
1b HelpContextID DWord
1c MouseIcon pic
1d Font font
1e WhatsThisHelpID DWord
1f Appearance Byte
[20 Container]
[21 RightToLeft]
22 Picture pic
23 DisabledPicture pic
24 DownPicture pic
25 ToolTipText text
26 OLEDropMode Byte
27 MaskColor color
28 UseMaskColor boolean
29 Style Byte
[2a CausesValidation]

This is why I dont like the trial and error method as some things never appear until it is too late . For all curious folks out there this stuff is easy. I am thinking about releasing full lists of all of them but I think you should all use your brains and figure it out yourself as the experience is valuable. Here is your hint. Get MSVBVM60.DLL SP5 loaded in IDA. Load the symbols included with the service pack. Go to this offset. You actually do not even need the symbols for this but it makes it easier. 6600B4C8. That is the offset of the Button property listing. It goes in order by index so VB runtime can read a byte and then index the property as a jump table
mov eax, CommandButtonPropertyVTable
mov ebx, ReadInPropertyByteValue
jmp[eax+ebx*4]
Of course the 04 signifies CommandButton and it looks up the table there. Anyway figuring out the data type corrisponding to each property is a little bit different but easily doable just spend some time surfing through. If you look into the pointers in the table they each point to a structure with the offset to the string name of the property, 8 bytes describing the data type and then the last 4 bytes describe the default. Anyway now everyone has the tool to make a PERFECT form decompiler of standard VB controls no excuses .

Snatch

As I said earlier (or maybe it was on another forum) I don't really use text files anymore. I used to keep them updated all the time, but it became a big pain in the arse. A lot of my dirty work is done by using VB5.OLB / TLBINF32.DLL (using C makes it a bit more difficult). Sarge, you could easily incorporate this into your project (but remember I can't code worth sh*t using VB.. so don't ask me for help hehe). But here's a snippet from one of my procedures:


rc = CoCreateInstance(&mCLSID_TypeLibInfo, 0, 1, &mIID_IUnknown, &obj_TLinf);
rc = QueryInterface(obj_TLinf, &mIID_TypeLibInfo, &int_TLinf);

/* m_TLInf.AppObjString = "<Unqualified>" */
sTmp = SysAllocString(L"<Unqualified>";

rc = Set_AppObjString(int_TLinf, sTmp);
SysFreeString(sTmp);

/* m_TLInf.ContainingFile = Path & "VB5.OLB" */
sTmp = SysAllocString(L"vb5.olb";

rc = Set_ContainingFile(int_TLinf, sTmp);
SysFreeString(sTmp);

/* With m_TLInf.TypeInfos.NamedItem("_Form".VTableInterface.Members */
rc = Get_TypeInfos(int_TLinf, &int_TypeInfos);

rc = Get_NamedItem(int_TypeInfos, &sTmpT, &int_NamedItem); /* 13 */
SysFreeString(sTmpT);
rc = Get_VTableInterface(int_NamedItem, &int_InterfaceInfo);
rc = Get_Members(int_InterfaceInfo, &int_Members);


items = iOffset = 0; /* These are really shorts, so clear the hiword */
rc = Get_Count(int_Members, &items);
for (o=1;o<items;o++) {
rc = Get_Item(int_Members, o, &int_MemberInfo);
rc = Get_Name(int_MemberInfo, &sTmp);
rc = Get_VTableOffset(int_MemberInfo, &iOffset);
if (iOffset == index){
rc = Get_Parameters(int_MemberInfo,&int_Parameters);
rc = Get_Count(int_Parameters,&count);
rc = Release(int_Parameters);
rc = Get_InvokeKind(int_MemberInfo,&iKind);
if (iKind == 2){ //get
b=pop();
c=pop();
sprintf(buf,"Get_%ws %s %s \n",sTmp,c,b);
free(c);
free(b);
}
else if (iKind == 4){
b=pop();
c=pop();
sprintf(buf,"Put_%ws %s %s\n",sTmp,c,b);
free(c);
free(b);
}
else
...
...
so on and so forth...

hehe it seems this snippet has more comments than what I usually use (lucky me!).

Anyway, to everyone and nobody in particular:

HAPPY NEW YEAR!!!!

May the new year bring you happiness and good fortune.

joe

Haha JoCo. Looks like I wasnt the only one to be playing around with VTable's and COM . Definitely useful in the land of VB decompilation. A very interesting technology COM is. I had to read a 700 page book about COM and ATL to fully understand the beast. Clever concept but much extra code required to implement the interfaces. Alas, once I know the technology it becomes obsolete and we await to see how SOAP and .NET change the technology. Anyway, cracking .NET programs is going to be the next generation and could pose some problems but now you just need to write a CLR decompiler and you can decompile managed c++, c#, vb all in one swoop. Actually protection was a huge issue so I believe Microsoft will release an encryptor. As if we cant unpack that hah! But if the encryptor is well nested with the CLR it could pose some challenges. We just have to wait a month more til the final release and see. Happy new year!