Not a very useful tool but...

[donkey]

I was playing around today and wrote a simple tool to demonstrate enumerating modules in a program. It does it in 2 ways, first by enumerating all loaded modules using the psapi and also by walking the import directory of the PE file. The demo lists the loaded modules and indicates whether they are imported directly in the PE or whether they are an external dependency (ie loaded by another module). This isn't a very useful tool but it serves to demonstrate a couple of interesting functions so I thought I would upload it in case someone might want to use it for a project.

The source can be built in either 32 or 64 bit without modification and a 32 bit executable is included.

Edgar

[Vortex]

Hi donkey,

Your application in the zip file does not work on my Win Xp Sp3. Running from the command-line prompt, it quits silently.

[donkey]

Don't have a copy of XP around anymore but probably just caused because I didn't initialize common controls, don't really have to on Win7 or Vista so I forget some times. The current zip has it included.

[Vortex]

Hi donkey,

Thanks for the new upload. Now, it works fine. Nice job :U

[donkey]

Here's a version that eliminates the need for the psapi. It uses EnumerateLoadedModules64 from DbgHelp, also it finds the import directory using ImageDirectoryEntryToData which allows us to reduce the search loop considerably.

Edgar

[ragdog]

Hi Edgar

Your last version can i not download for testing
i have no access.

And a other question

I look in your source an it use x64

Rax .....

Why work this on a X86 windows?

I think this works only on a X64 windows

[rags]

Ragdog, i believe GoAsm automatically changes 64 bit registers to 32 bit bit versions when you compile the source
in 32 bit mode, so there is no need to change the source.

[ragdog]

Nice function

i think for Masm must a write a macro for this or?

[donkey]

Hi Ragdog,

In GoAsm's X86 compatibility mode the REX prefix is dropped so the registers become 32 bit (except of course those that have no equivalent in 32 bit). Also the P and S type indicators are changed in the headers for pointers (P) and Unicode (S). You must also be aware that many of the type indicators (eg HANDLE) are automatically resized in windef.h when building for different data width also any type casting will have to be taken into account. For MASM you will have to do a search and replace for the registers I don't think a macro will do it. MASM is not overly friendly to source level compatible code for 32 to 64 bit so it might take some work, since I don't use MASM it is of little concern to me, if you need to compile it use GoAsm or get ready to do some translating. Also as far as I know MASM64 does not support the invoke construct so it would be a bit of a chore to translate anyway, my advice is to use GoAsm for this piece of code.

I tried downloading both files and had no problem so I don't see why you have access problems.

To reiterate, this is not a comprehensive tool, just a test bed for some ideas I had and to try out a couple of DbgHelp functions. Anyone is free to use the code and expand on it however they choose but since this is not a full out application I will favor answering questions in GoAsm syntax over MASM.

Edgar

[ragdog]

Thanks for this information about it :U

If i write a app for x86 and x64 must i change the masm path to the Link64 and ml64 and the complete source
to make it compatible? and for this gives no solution?

Sorry that a post it here in your threat

And this DumpModules is this a test project for your Updated vKim debugger tools?

Greets,

[donkey]

And this DumpModules is this a test project for your Updated vKim debugger tools?

It may end up in the debug tools in one way or the other but it is not meant for that. It is a test for a new approach in a profiler I have been working on for a few years on and off. The DbgHelp api in conjunction with the DbgEng api will hopefully unstall the development of the application which has seen little progress over the last year.

If i write a app for x86 and x64 must i change the masm path to the Link64 and ml64 and the complete source
to make it compatible? and for this gives no solution?

Sorry that a post it here in your threat

As I said, ML64 is not a very useful 64 bit assembler, you might try JWASM if you need MASM syntax, from what I understand it is better adapted to 64 bit coding.

You can post in this thread any time you like, its just that I may not have the answers you're looking for as I tend to avoid using MASM unless I have to since for the most part I write for 64 bits and translate down to 32 bit.

Edgar

[ragdog]

JWASM if you need MASM syntax

I have now look into Jwasm x64  :U

Code Select Expand


.if (rcx == WM_DESTROY)
        invoke PostQuitMessage, NULL
    .else
        invoke DefWindowProcA, rcx, edx, r8, r9
        ret
    .endif

I Test it thank for this info

If this possible to automatically changes 64 bit registers to 32 bit bit versions when you compile the source
with Jwasm?

[donkey]

If this possible to automatically changes 64 bit registers to 32 bit bit versions when you compile the source
with Jwasm?

I doubt it but maybe, you'll have to check it out I have not looked at JWASM at all, GoAsm meets all my needs.