Well well. I felt this subject needed a new thread and since I am presenting a new idea I hope it is appropriate. What I notice always is that people are willing to put up for less than perfect. I was working with JoCo on the VB Decompiler right when he began the project I believe and I noticed that we had two fundamentally different approaches. Compile tons of sample applications and compare and analyze. Good luck with some of the structures as pointers in there can be relative to many things as in the begining of the structure or some other offset. I had a different method. Disassemble MSVBVMx0.dll and vbx.exe and vbax.dll. Start putting things together about what is actually going on. What you find is simply amazing and can help you write a decompiler that will knock the socks off all others. First of all, VB has options to make about 12 different types of projects from activex controls to dlls. Each is treated in very slightly different ways. You actually save time by realizing exactly where the differences lie. I cannot write a decompiler without doing it this way because there might be some possibilities left out. Of course this is tough and a lot of work but it amounts to about the same believe it or not. I looked over the list of command button properties that JoCo provided and I definetly noticed it was incomplete. Not doubting that he has the rest but point in case it is easy to miss over stuff. However, he has a program out and I do not. I just wish people would rethink their approach. The VB program files are not packed and do not even attempt to be protected. Although the code is very overbloated and complicated. Hello world! Symbol files. Freely available from Microsoft. Perhaps some of you have also taken this approach but it seems not. I dont have to ask questions about the format because there are no mysteries. Just assembly code my friends. I am thinking about providing my notes too because I am never going to have time to write the decompiler but I really would rather that everyone have an absolutely complete reference to aid them. I have many data structures and the entire form system decoded or partially decoded. I need to keep searching to fill in a few gaps still. I just gave up because of time. I would much rather be wasting it on writing a decompiler but we dont always get what we want.


Snatch

Well met old friend As you pointed out my example was missing some things and I've added most of what I know to ExDec and stopped using files (good or bad.. you decide). When offering help, I have to go through my code and rediscover what I did in the first place haha. But I for one would like a copy of your notes My work is in no means complete and I'm sure your work would definately compliment mine. As always I'd share what I was able to with whoever needed it (with your blessings of course). Whenever you have a bit of free time, just zip up whatever you feel is appropriate and send it over to josephco_(at)hotmail(dot)com (haha since my last public display of an email address on this board I've been flooded with porn advertisements!!! Lets see if this will change it hehe).

Thanks in advance,

joe

Here, here!

Well said! I too, have disassembled the VB IDE (VB6 for me). I also DO allow for the various different type of exe's that VB6 makes, although I don't make a big deal out of explaining/displaying that info for the user; he usually doesn't care! Also, a lot of info has been traded on "that other forum"
[ask Joe about it, I don't want to offend him ] I even posted my start-up routine for parsing the PE file to find the VB structure. I'm a believer in group knowledge.

Fine, let's all trade notes. Who goes first? Who do we trust? How do we determine what info is needed by who? Or do we start at the beginning so we all walk together?

SargeG

Unfortantely I am on vacation from school where my computer is now so I do not have access to all my notes but I will shortly and then I will email them. I do have Visual Studio 6.0 SP5 professional on my dads computer at my ease though so I think my present to the reverse engineering community will be an interesting tool that I will rewrite originally made by Matt Pietrek in an MSDN article. What it does is converts Typelibs to MAP or DBG files. This is very useful in not only integrating the MSVBVM60.dbg file in service pack 5 but now you can integrate another msvbvm60.dbg with slightly different information with the whole COM interface description in there for all events and methods of the controls implemented. VB6.exe and VBA6.dll have no VBA6.dbg or VB6.dbg for service pack 5. The only ones I know of were released on the original CD which is about 5 service packs ago . I thought about using the original ones because there are some very nice symbols in there but why not use the typelibs instead and stay current. VBA6.dll/1 and VB6.exe/3. MSVBVM60.dll/1 and MSVBVM60.dll/3. Those are the type library resources in the files. Of course there are the .olb files as well that bind to MSVBVM60.dll. Anyway the possibilities are endless. Too bad I do not know how to make IDA .til files so I could add the type information in and it could automatically identify paramters of say EXEPROJECTINFO* types . So that will be my new years present hopefully I will have it done in a few days. The old dos version does not work very well and does not let you have seperate typelib files from the dll/ocx/exe. I am going to update it and throw a windows GUI on it. Believe me this tool can make figuring what the hell is going on in the vb runtime a lot easier.

Snatch

I, too, would like any notes you may have. Also, of course, I will be happy to share with you any of my info. The dbg files for VB6 sound neat! How do we want to handle all this sharing?

SargeG

Ditch VB. VB3, VB4, VB5, VB6, ... VB9999999 - all garbage. If you deal in VB you deal in merde. Sometimes there will be a target that uses VB and, in turn, requires a VB solution. So be it.

But if VB is your choice of programming "languages" - and I use that term loosely - then you are hopelessly behind the curve and should give up right now. Do not quarrel with Master Rummy. Accept my words as a fact. Un Fait Accomplit, as it were.

Make the break. VB is garbage, merde en fact.

Sorry to offend, as I'm sure I've done, but VB will get you nowhere fast. Accept the fact that c'est vrais. Tant pis. Grow up, kids, because you will never contribute anything worthwhile to the scene if you persist in the use of VB.

I completely disagree with you. VB is a great learning language. And there are many crackers that suck shit at coding. I cant believe how few crackers can actaully even write a resource dumper the write way that works on all executables. I started out as a coder, cracking came later. And I started by writing disassemblers and exeviewers. I used to exclusively write in visual basic. Then I realized the language is crap and sucks for anything useful. But for learning it is a great tool. Programming concepts are invaluable. Now I can never ever use VB again for I know the power of Visual C++ and with MFC it makes coding a little let painless and boring. I hate to tell you but windows assembly is just plain dumb if you dont have a use for it. I want rapid development and power. I can not stand writing user interface code for 99% of the time. I want to write the actual program logic code. Of course I will never write another line of VB again though unless it is to test my decompiler. A decompiler is a good project though. It teaches you much about cracking an interpreted target and is a coding and reversing challenge in itself. And now VB.NET is going to be just as adequate a language as J++ and C# or managed C++. They all compile to the same thing its just different syntax. So please dont rant on without respect for tools. VB is Bill Gates brain child which is why we are nowhere near seeing the last of it because he likes it so much since he implemented and created the idea. Nobody should ever use VB for any program after they really know how to code though. You cant write a decompiler or even an exevier though in VB. Use a double data type lol. Any language that doesnt support unsigned variables is weak. Not to mention the API upon which it is based. Respect VB for what its worth, a good decompilation target and a great learning tool. But we should all move on and become proficient coders in a more powerful language.

Snatch

I'll go even further:

The single most over-riding reason for VB is speed. Not of execution (obviously), but of development. RAD is an absolute must for any support or test tool that needs to be ready before the product-that-is-to-be-tested. Sure, the shipable/sellable app will certainly be written in non-VB, but I can just see the powers-that-be saying "Oh, you need another full software project, with its time and cost and manpower constraints, to test and support the software project you just finished? Sure, we don't mind if you are late and overbudget!" Sorry, don't think so. VB is invalulable in throwing together those mini-apps that make supporting and testing the big app possible. Not to mention (so why am I?) that almost anybody can maintain them; that's where we usually start the new-hires, so they can be productive while they learn the product.

Sarge

Friend you have not learned MFC and that is the bottom line. MFC development is just as fast as VB with out a doubt. Not to mention that you get pointers and native data types. But it is your choice as you said if you just want to play around. I dont play around. I write my application once and never rewrite it again. I dont need to bother this way. Its RAD and its good. I suggest you learn MFC as you will be able to agree with me on this point. Not to say that VB wont work but um you say RAD? Hah the reason I switched from VB to C++ a long time ago was cuz I saw the limitations of VB with certain things and tried to get around them and wasted more time trying to get around them then I did just writing them in the other language. You will see what I mean. Try writing a disassembler in VB like I did. It is ugly and painful and much easier in C++. So is anything that requires binary translation . But the bottom line is it is just our preferences no big deal. We can still share the wealth.

Snatch

Nope, sorry, won't fly. I particularly like "I write my application once and never rewrite it again." Try doing that in a testbed environment, you won't last long. As for limitations, there are constraints in any language; the limitations are usually the ability of the programmer.

I particularly like the emphatic statement many people make:
"Its not a real programming language". Hmm, how did they make that determination? I can write instructions in a given syntax, compile it, and get an operational app. Thus, I have written a program. Which part is not real? And how does having C syntax make any difference from having Basic syntax? It doesn't, its just the language. Same-O Same-O.

Finally, how dare VisualC call itself "visual"? In VisualBasic, at least the visual part is understood; I select a form and I get an already define form. It is definitely a visual aspect. Can I do that in VisualC? Nope. In fact, that is one of the big disappointments in that connotation; "VisualC" implies that I get forms, just like in VisualBasic, but that I program in C syntax, not Basic syntax. But is that the case? No.

Point is, there is strength to both, but I have yet to see VB RAD be beat by C RAD.

SargeG

Heh we should probably end this silly argument but I guess it serves an interesting point. Namely one of that in C all I have to do to read in the exe headers is this:

IMAGE_DOS_HEADER DosHeader;
File.Read(&DosHeader, sizeof(IMAGE_DOS_HEADER);
IMAGE_NT_HEADERS32 NTHeaders32;
File.Read(&NTHeaders32, sizeof(IMAGE_NT_HEADERS32);
IMAGE_SECTION_HEADER* SectionHeaders = new IMAGE_SECTION_HEADER[NTHeaders32.FileHeader.NumberOfSections];
File.Read(SectionHeaders, sizeof(IMAGE_SECTION_HEADER) * NTHeaders32.FileHeader.NumberOfSections);

etc... and so on.

It is the specific use here that makes C++ especially appealing. That good old winnt.h file has every portable executable structure and signature defined in there with every flag etc. Now talk about RAD. I did not have to make my own structures, I do not have to worry about DWORDs that could throw off VB's long type. The nature of any binary viewer application is much more supported and more rapidly developed in C++. I know it can be done in VB but with much more work(I have done it my first EXEVIEW application with a dissassembler was in VB). But it takes more work and it is plain in clear and I have written the code for both. Of course the visual aspects are much easier. I wont even touch that point. But this is an actual code application. Heh anyway maybe we should end this discussion it isnt leading us any progress on the decompiler and that is our goal here after all. Just our preferences and we could probably argue for years about it .

Snatch

Well, I certainly agree that this could go on and on.

As for the ease of reading files, you are correct...as least a far you have interpreted my postings. What has NOT been said here is the ease of reading files in VB using the API (the details of which need not be discussed). The reason for this lack of "high power" VB action is simply simplification (Wow, how's that for alliteration?). Don't forget, many of those reading this forum for information are not fully experienced; I feel obligated to explain the facts as easily as possible. I would much rather say "use the SEEK command" then have to explain how to use an API. This continues to put the emphesis on learing what is desired, without forcing the added burden of learing HOW to learn it.

As an aside, how does your short, easy to write code, teach me the ins-and-outs of the PE file? All it does is GIVE me the answers, when I want to know HOW TO GET the answers.

Besides, isn't writing a reverse engineering app in VB, the very language that you want to reverse, have a sort of irony to it?
As the saying goes: "If you can't see the poerty in that, you have no soul"

SargeG

Heheh well you are certainly entitled to work in VB and if you produce the same results who cares in truth. We all have our own understandings and tools to help us better understand. We might as well share our knowledge in a form that everyone can understand which shouldnt be too tough since most reverse engineers have a base knowledge about programming that is pretty strong. It is ironic that you are writing a decompiler in the language you are decompiling. DoDi's biggest mistake was doing that with his VB3 decompiler. I got his decompiler to decompile itself into perfectly good source. Of course it took a few hours of analyzing his VB protector to see how to reverse the protection and rebuild the file. It actually isnt too hard. So I hope you take your own words of advice if you ever release something and change the language. Otherwise your tool can be its own kiss of death. And believe me this is the truth .

Snatch

Ha! I love this! You are the first person to point out this delimma!
Yes, you hit it! Do I really want to release a program that can "undo" itself? I of course asked myself that question before I got started. My answer? "uh, um, well, ah, hmm!" Actually, I don't know. If the purpose of the program is to help learn, and someone wants to learn how to decompile VB, then it must of course work on itself. But then, do I receive any benefit? SHOULD I receive any benefit? If this is to be a freeware/shareware program, does it matter? Or should I....well, whatever. This is too much an ethical consideration that my overworked mind can't handle right now. (Ask me again in a few weeks when after I work out a few minor bugs.)

SargeG

Hehe . Actually I have something I would like to point out to the masses. To write the perfect decompiler you have to disassemble and understand MSVBVMx0.DLL perfectly. Of course the interpreter does not access all the data in the exe and theres a lot of useless stuff the compiler puts in. But to make a decompiler you need to satisfy the interpreter for the reason that any VB protections will only satisfy the interpreter and can strip out all the garbage. After the interpreter is satisfied then you can add the information from the compiler VBx.EXE and VBAx.DLL so you can make use of all the extra unneeded information for a better decompilation. But all the code that makes use of that should be conditional and there should be an option to use it or not because as I said protections will throw things off. Of course a sophisticated enough protection can still satisfy the interpreter but do some very clever initialization stuff to still throw the decompiler off but in this case I would consider the file packed not protected so much and unpacking would be needed. Just some thoughts.

Snatch

On the topic of decompiler protections, surely all protection wrappers have some sort of custom stub where it encrypts/packs the actual vb exe. So logically, this stub would have to unencrypt/unpack the vb exe information into memory somewhere. Forgive me if im wrong, but would that mean that it would be possible to make a program to find the memory location of the vb exe data and decompile that rather than the actual exe file? Im not sure how one would do this mind, since im not that advanced at low-level stuff like this. Twas just a thought though

-moogman