Fixing an EXE to not call a DLL?
 

How do you stop an EXE calling in a DLL?

Do you have to edit the Import Table or something?

if it uses LoadLibrary() to load Dll, simply nop the instruction, but probably the program won't work anymore

-loman

How many ways are there of calling a DLL? I'm a complete idio... err n00b :)

I tried LordPE and deleting the DLL in the Import Table section and also deleting a Section from the EXE, both result in a non working EXE.

I tried loading into IDA and looking for LoadLibraryA, but I think it's using GetModuleHandleA and it looks like its located in a separate Section. So I think deleting the Section could work, but how do you successfully delete a Section?

hm
 

Hi Barry.

IMHO, deleting your DLL call isnt a solution for any problem.
A :
- Describe you problem with more details.
B :
- As someone said, if you (let's say) 'delete' DLL call or 'stop' it somehow, i'm sure the application won't work. Simply, the DLL is needed. If you want to 'delete' it cuz of some kind of protection, you don't 'crack' the protection by 'deleting' the DLL...
You have to find the CALL and analyze it ... where it's called and stuff ... So you can jump over it or nop it ... (That's ok if that's part of protection)...

Bla, bla ...

But, provide us more info and you'll get better answers than this one... ;)

if you kill the loadlibrary to some dll some part of the program might not work ... if a program loads a library/dll sure it needs it to some functions and could have many points and calls for the dll.... as previous reply says give us more details about your problem ...and you'll get better asnwers

Without more information, here's a really easy fix. Works for me 99% of the time. No need for anything complex, just standard programming stuff.

Let's say your DLL is called DoBadThings.dll and you want to learn more about it, circumvent it, etc.

From a command prompt type:
dumpbin /EXPORTS DoBadThings.dll > DoBadThings.txt

In TextPad or simular editor, cut out all but the export entries, and in block mode, cut out the first 3 fields (Ordinal, hint, and RVA) leaving only the Names.

Rename "DoBadThings.txt" to "DoBadThings.def", and copy it to the files "DoBadThings.cpp" and "DoBadThings.h"

On the DEF file, insert the following two lines at the begining:

LIBRARY DoBadThings
EXPORTS

and then insert tabs infront of each of the names. You can now type:
lib /def:DoBadThings.def
to generate an import library.

On the H and CPP files, un-mangling if present (pretty easy, P means pointer, etc. google if you run into trouble) and create function stubs. For non-mangled names, use a Macro in Textpad to write out the Curely braces, etc.

If the caller program has savere encryption and antidebug, you can use OutputDebugString in the stub routines to grok calling sequence and parameters even if you have non-mangled names. Otherwise, it's shooting fish in a barrel. (look for push instructions, mov ecx, and add esp instructions to get calling convention and parameter counts).

Rename original "DoBadThings.dll" to "DoBadThings_Original.dll" and put in your own.

In your DLL, call "DoBadThings_Original.dll" as needed for snooping, or only call it sometimes, or don't even call it at all. Your choice.

Not rocket science. A little more work than "just deleting the DLL", but I think you'll find it a bit more usefull.

Since stopping it from loading the DLL isn't usually a good idea, perhaps you just want to stop a certain function to be called? you can do this easily with OllyDbg by pressing CTRL+N until you see the "Names" window...then scroll to the API you want to stop, and right-click, then go to "References". This will show you a list of all the locations where the API is being called.

Now you must make sure that you not only NOP the call, but also all the "push" parameters. Once that is done, you can safely continue execution (most of the time however, stuff will crash or fail because the app is depending on the API call).

Best regards,
Alex Ionescu
http://www.relsoft.net

Good information sgdt, thanks! Always nice to know another way around a problem.

Most of that info went over my head :)

I guess it's a little too advanced for me. However, A friend pointed out that the last section of the file has it's own import table and also the Entry Point is there too and the pointer to the original import table!

He fixed the EXE for me but wouldn't tell me how he did it, I think he's trying to make me figure it out the little tease :)

Sounds like he fixed / patched the IAT table (is that what you call it).

In the exe itself you will see parts which refer to API names (imports from the DLL) and the names of the DLL's themselves (ie Kernel32.DLL) you can edit those in a hex editor.

Yes, it has 2 dll entries and a DoMessage API, this must be dealing with calling the external DLL, then it jumps back into the EXE at another Entry Point to run the EXE proper, but I don't know how to find or fix it!

I think I'll go hit my friend until he tells me :)

Success!!

I think this is more luck than skill though :)

I loaded the EXE into IDA and searched for GetVersion/GetVersionExA, my friend said 95% of the time that's roughly how to find the program start, but not always, something to do with C/C++ compiled programs! So after finding a couple of places that called GetVersionExA and noting the addresses I then loaded the EXE into LordPE went to the Import Table and found the entries for the second import table and used 'kill ImageImportDescriptor' to kill those additional entries so they were not called anymore.

I then changed the EntryPoint in turn to the addresses I noted in IDA and got the program running, I deleted the DLL to make sure and the program runs fine :) This method is probably unique to this program, but I've learned something in doing so, probably all bad practice no doubt and some of you will probably be cringing with disgust at my crude methodolgy, but hey, I managed to achieve my goal :)