Exetools  

Go Back   Exetools > General > General Discussion

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 07-05-2003, 09:55
wellbeing
 
Posts: n/a
Visual Basic 6 SP5 Build Differences

Hi,

I'm new to PE File analysis and I am trying to understand why my Visual Basic project continually changes so much from build to build (I suspect it's the data segments) - and to be able to analyse the differences so that I can explain them all.

My environment is Windows 2000, Visual Basic 6 Service Pack 5. I have also tried Windows NT 4 (and it has the same problem) but I can't change my development environment.

There are a lot of people here who understand file formats better than I do and I hope someone can offer me some help in solving my problem.

I have recently found Microsoft's article on "An Indepth Look into the Win32 Portable Executable File Format - MSDN Magazine Feb, 2002" (hxxp://www.msdn.microsoft.com/msdnmag/issues/02/02/PE/default.aspx). I have also downloaded all tools that I can find on analysing PE Files (the most useful I found so far was PELord from hxxp://y0da.cjb.net/). However, this tells me that the differences include date/time stamps (which was obvious using "fc.exe") - but I still can't justify most of the differences.

If I generate a vanilla "VB Executable", there are still a lot of differences. If I change the title of the main form from Form1 to Form2, PELord can not recognise this change correctly using the compare option.

Is there a tool that will allow me to compare code segments to determine they are equivalent? Other than spending a lot of time to come up to speed with PE Files and writing my own tool, I can't see any other way to justify the differences I am seeing.

Thanks for any help



Well Being
PS My apologies for entering direct links above. I have since corrected that

Last edited by wellbeing; 07-05-2003 at 10:02.
Reply With Quote
  #2  
Old 07-05-2003, 21:39
Sarge
 
Posts: n/a
Part of the problem is the poorly written VB IDE/compiler. It is normal for two sequential builds, made one immediately after the other, to be significantly different. part of these differences is the obvious one of date-and-time. But, for the most part, the differences are just the garbage that VB fails to clean up. While the significant code portions are of course correct, the unused "don't care" portions of memory are also just dumped into the exe.

A helpful procedure, after you have finalized your code, is to shut down your machine, re-boot, and go immediately into VB without any other progs running. Then, compile. In this manner, you will get the cleanest exe, as the garbage has not yet been put into memory, so it doesn't make it's way into your exe. Note that this method just gives you the "cleanest" exe, not a "clean" exe.

Since this is not a PE file problem per se, a better way to analyze a VB exe specifically is to attack it in the manner it is created; that is, not as a PE file, but as a VB file. Otherwise, you will spend a lot of time analyzing significant parts of the exe that don't mean anything. Of course, you need the PE info to find the VB info IN the exe.

Sarge
Reply With Quote
  #3  
Old 07-06-2003, 08:01
wellbeing
 
Posts: n/a
Thanks for the info Sarge. This is exactly what I suspected the problem was. I am still amazed that this issue isn't readily discussed among VB developers (mind you, i'm only new to VB so maybe noone discusses it but everyone knows it).

Does anyone have any ideas on a simple way to identify what portions of the PE file are junk (ie. their values don't matter)? I've found a utility that gives me an excellent summary (it clearly shows the different segments) - but it doesn't help me determine what "can" be different and what "can't" be different for a VB executable.

Here's where i'm up to.

1. Run pedump (the updated '98 version) and generate output1.txt and output2.txt

2. Use WinMerge (found on sourceforce) and generate a diff between the two files.

By doing this, I can isolate the code into different sections in an easy to see format. However, this only partially helps because all of the segments are different between the two executables and I am not sure of an easy way to discriminate between critical code and non-critical "data memory" (which I suspect is the culprit).

I unfortunately need to have a repeatable method for determining the difference. Any help would be greatly appreciated.

Thanks again


Well Being
Reply With Quote
  #4  
Old 07-07-2003, 21:21
Sarge
 
Posts: n/a
Just remember to distinguish between the VB essential and non-essential stuff as opposed to the PE essential and non-essential stuff (I don't think there is any non-essential in a PE file, but I can't be positive). My point is, there is a lot of stuff required in a PE file to meet the PE protocol/format, that has absolutely no relationship to the VB stuff. So, while this stuff is non-essential to VB, it is definitely essential to the PE.

Hope the above is reasonably clear...?

Sarge
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Visual basic decompiler Zeocrack General Discussion 3 11-24-2022 04:38
help with visual basic and API Warren General Discussion 5 08-26-2005 13:48
[HELP] Visual Basic dll protection Maltese General Discussion 12 08-13-2005 19:05


All times are GMT +8. The time now is 17:28.


Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX, chessgod101
( 1998 - 2024 )