Re: Unsigned 32 bit
From: Ulrich Korndoerfer (ulrich_wants_nospam_at_prosource.de)
Date: 09/26/04
- Next message: Ulrich Korndoerfer: "Re: Unsigned 32 bit"
- Previous message: Jeff Johnson [MVP:VB]: "Re: arrays or collectionsets"
- In reply to: Jim Carlock: "Re: Unsigned 32 bit"
- Next in thread: Ulrich Korndoerfer: "Re: Unsigned 32 bit"
- Reply: Ulrich Korndoerfer: "Re: Unsigned 32 bit"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 26 Sep 2004 20:35:54 +0200
Hi,
Jim Carlock schrieb:
> Do you or anyone else know of a tool that might help in
> identifying everything in the file? I've got a feeling it's all
> going to have to be getting a full understanding of how
> the PE is organized.
For such things I mostly use OllyDbg (full featured open source windows
debugger from Oleh Yuschuk):
http://home.t-online.de/home/Ollydbg
OllyDbg also can map the PE (knows its structure and names its entries).
OllyDBg understands the debug informations generated in the .pdb file
and can map the source code lines to the assembly code. And also it does
a good job in identifying API-calls (icluding naming them). The
internal table that helps identifying the calls can be extended by the
user to new APis. It can recognize adresses of calls and jumps even if
the adress is held in a register. There is a mighty tracing mode, where
the executed code lines are cached, such being able to go back in the
trace.
And it does a nice job structuring the assembly code by labeling and
commenting code lines and visually showing the program flow. Of course
the user can add comments and labels himself.
Other than other debuggers it structures the memory into modules. The
debug window is confined to one module. Very helpful as one does not
sink in a sea of 2 Gigabytes of bytes. Start and end of module code is
easily found, module entry points are marked, and so on.
Of course there is a memory map, showing the mapping of all modules, of
the heap etc. From this map one selects a module for debugging. A call
to another module is followed easily. The debugging window automatically
changes to the module called.
But VB programs are hard to debug. The best thing one can do is to
isolate the relevant portions of code, wrap them in a *small* program
and compile this with the compile option "Generate debug information"
on.
One has to have a good knowledge of the assembler language and of how
things work under Windows (eg how dlls and programs are layed out, how
dlls are loaded and used, how SEH works, etc etc). And of course how COM
works (how COM structures or objects are, how they are called, etc) and
how VB does COM (which is internally slightly different to standard COM.
Good luck ;-)
-- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
- Next message: Ulrich Korndoerfer: "Re: Unsigned 32 bit"
- Previous message: Jeff Johnson [MVP:VB]: "Re: arrays or collectionsets"
- In reply to: Jim Carlock: "Re: Unsigned 32 bit"
- Next in thread: Ulrich Korndoerfer: "Re: Unsigned 32 bit"
- Reply: Ulrich Korndoerfer: "Re: Unsigned 32 bit"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
