VB Decompiler

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

Moderators and other high-support providers:

Given that we have shown many of the secrets of VB here, should we have a section that includes the GUI properties and their opcodes?
That is, a list of opcodes for each control, giving their function?

Like:

Form
0xXX = Name
0xYY = Caption
etc

CommandBUtton
0xXX = Caption
0xYY = Height
etc

Sarge

_aLfa_ · Posted: Wed Jul 23, 2003 12:08 am Post subject:

why would u want that?

just use COM
_________________
One thing only I know, and that is that I know nothing. (Socrates)

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

So, let me get this straight...

You are willing to tell all kinds of hard-to-get VB secrets here, but are unwilling to post the easy stuff? That doesn't make sense in and of itself.

But further, this is supposed to be a sort of "VB secrets revealed" place; doesn't that imply that we should have a much as possible?

Not too mention that COM is too complicated and too hard to use; that's why I came here, to learn all the neat stuff I did't know...doesn't my lack of knowledge on the easy stuff (which, since I don't know it...isn't really easy) still qualify in that category? After all, if you don't know what it is that you don't know, none of it is easy....therefore, all of it should qualify
as valid fodder for presentation here.

Just seems to me that if you support one side of the story, you should support the other.

However, remember that this is just a suggestion....I will certainly supply that missing info to anyone who specifically asks.

sarge

_aLfa_ · Posted: Sat Oct 04, 2003 11:47 am Post subject:

sorry for the late post sarge
im being kind of busy

well, ur right
we need to get the basics first, as we first learn 2+2 then 2*2

i would help u in posting such a list, just ask if u dont want to put everything and b4 posting it, lets define a readable format so all can learn something from it...

and dont forget to keep up the good work
_________________
One thing only I know, and that is that I know nothing. (Socrates)

golem · Often here Joined: 18 Nov 2002 Posts: 73

The reality is nothing is easier than COM... or smarter... or a better investment of time.

Why would you waste your time compiling a manual list when you can just use COM and get the entire list of standard controls (PLUS OCXs! ).

If you are not capable of figuring out how COM works... on one hand your 'decompiler' doesn't have much of a future now does it? on the other hand you can just use one of many utilities that speak COM and cut-n-paste the standard control info...

If you are a serious student of decompiling VB, you NEED to learn COM.

Carry on!
golem

MrUnleaded · Posted: Sun Oct 05, 2003 12:58 am Post subject:

sarge: there was a TypeLib viewer application that was posted in the files section of the board.....it has some simple code that you could drop into your decompiler...

as far as ive seen.....COM makes things much easier to interpret the data...in a form...but i have seen some inconsistencies......ie COM will tell us that a Property is a long when in reality it is an Integer....

has anyone else seen this or have an explanation for it?? perhaps im using an old .OLB file.....still havent figured out the COM from registry yet....thou i havent tried much...
_________________
-MrU

vbgamer45 · Posted: Mon Jul 19, 2004 1:21 am Post subject:

I have been wondering this a long time. I have seen many documents containing the hex data of certain controls. It kind of seemed a waste of time to hard code all the controls that vb uses. It looks like thats what a lot of semi vb decompiles do such as vbrezq and vbreformer. My question how does COM help you in decompilng components. I looked at the example TypeLib viewer and i see that it returns all the properties inside that control and their datatypes. Now how do you harness that information in your decompiler. Mainly how do you find the order of those properties inside the exe.

sarge · Moderator Joined: 24 Sep 2002 Posts: 194

[:4w9lceqw]
I looked at the example TypeLib viewer and i see that it returns all the properties inside that control and their datatypes.
[/:4w9lceqw]

Well, yeh, that's what it does. And none of THAT data seems to indicate what the opcodes are, or what their lengths are, or what their parameters are, or what (blah, blah,blah).....

Or am I missing something? (but then, apparently, others are, too).

Sarge

PS: the order of properties is alway numeric, but not necessarily sequential.

MrUnleaded · Posted: Mon Jul 19, 2004 3:28 pm Post subject:

well....when i was working on it...i used COM to find all the properties and such using the array indexes as the "opcodes"/property ids....

But often things didnt match up with what they should have been....and so i have to make ugly hacks to make things work as they should...

But what i would expect would be that that information is stored somewher....perhaps i wasnt doing it right. I can't imagine a way that third party controls would be able to determine their own properties without some common data structure.

Many people say to stay away from COM....but here is what i would do if i were you....make a branch in your application....so that it has the option to use a properties database....or COM.... because COM never worked perfect for me.

Anyways, good luck.
_________________
-MrU

vbgamer45 · Posted: Wed Jul 21, 2004 3:48 pm Post subject:

Thank you all for the advice and information. I am going to try both ways and see which one produces better results.

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

Alot of the controls on a form, be it OCX or VB internal, can be reversed using typelibinfo, because by default it arranges all the stuff in a certain way. But keep in mind that OCX's can be coded in anyway. If you've ever reversed an OCX, you probably would have found out that there's a function that handles all the properties and methods and such. An example of this, is NumsOf in a ListView I think it was. It is found nowhere in the typelibinfo, but it is in the forms. If you open up the file it is in (MSCOMCTL.OCX if I recall correctly) with a disassembler, you'll see why.

So the lesson here to learn: VB Controls sometimes follow the default way COM properties and methods are arranged, but this does not necessarily have to be the case.

_aLfa_ · Posted: Fri Jul 30, 2004 5:06 pm Post subject:

Oh my god, I don't post for ages
Anyway I'm happy to see vbgamer evolution, it reminds me my old times buggering MrU (hehe :p)

vbgamer I used a kind of proprietary database for intrinsic VB controls instead of COM, and used COM to parse external OCX properties. Don't expect me to say this is the best way, but it can do the job pretty fast and good, without concerning COM errors like integers being bytes, etc...

Anyway good luck on your decompiler and perhaps I will vote in pscode
_________________
One thing only I know, and that is that I know nothing. (Socrates)

vbgamer45 · Posted: Fri Jul 30, 2004 6:28 pm Post subject:

Thank you _aLfa_, I try to learn new things everyday.
I spent this morning working on coming up with an external componet table.

I have been debating the last couple of days of wether I should hardcode the default vb controls or just continue with COM and figure how to make it work.

I think I may go ahead and use _aLfa_ idea of having a database for the normal controls and using COM parse external OCX's but I think i will leave the COM code there but give the option to use COM instead of the database of opcodes. So I am back to the idea of two branches again.

Now to begin getting the gui opcodes.

MrUnleaded · Posted: Fri Jul 30, 2004 9:18 pm Post subject:

[="vbgamer45":39gm4npj]Thank you _aLfa_, I try to learn new things everyday.
I spent this morning working on coming up with an external componet table.

I have been debating the last couple of days of wether I should hardcode the default vb controls or just continue with COM and figure how to make it work.

I think I may go ahead and use _aLfa_ idea of having a database for the normal controls and using COM parse external OCX's but I think i will leave the COM code there but give the option to use COM instead of the database of opcodes. So I am back to the idea of two branches again.

Now to begin getting the gui opcodes.[/:39gm4npj]Just a thought.

make an interface class....one to use database and one to use com....then just have your program ue database....but fall back on COM.

as you use COM. if the correct results are created, add those COM pieces(propertys,events,etc) to your database.

This way your program can learn...to some extent, and be corrected if needed.
_________________
-MrU

_aLfa_ · Posted: Sat Jul 31, 2004 8:49 am Post subject:

Or if you love COM that much, implement some database with some properties, and everytime your program doesn't find some property opcode then let it use COM to search.

This is more like MrU made (exception list).
_________________
One thing only I know, and that is that I know nothing. (Socrates)