[HELP] Visual Basic dll protection

I need some help please. I have a visual basic app that I can get to work within Olly, but when I go to make the permanent changes to the DLL file the app crashes.

Upon further investigation it is during the LoadLibraryW function. If I modify the dll file, the LoadLibraryW function will return file error.

If I use the original dll file, then LoadLibraryW loads the dll without error.

It appears to be some kind of checksum protection. Any thoughts how I might overcome this?

Thanks,

-Malt

As a starting point you can check what lays inside with PEiD->KANAL plugin, which is gonna tell you if there are any known cryptos inside the code. If that doesn't work you can trace back to the CRC/whatever check in the code from the crash point - in this case LoadLibraryW. I hope this helps you



/siddhartha

[taos]

follow the createfilea putting a BP, then you can rename the dll to BAK in the createfilea parameter.(Obviously you must have 2 DLLs, original bak ext., modifyied DLL ext.)

Hi!

this migtht be too simple, but it cant hurt looking there aswell:
dlls carry their own checksum.
from msdn:

Checksums are required for kernel-mode drivers and some system DLLs

This checksum is checked by windows for the above described dll's but is usually contained in all dll's.

Its part of the IMAGE_OPTIONAL_HEADER structure, you can easily recompute that checksum using e.g. MapFileAndCheckSum from the imagehlp.dll

But if you want a quick way to try if this one is used here, grab yourself modifype (hxxp://unattended-sponsor.de/downloads/tools/modpe081.zip) and let it update the checksum for you.

As said, might be too simple but still worth a try!

Greetnx

TheMadGuy

[Jay]

This is from a tutorial by gabri3l (ARTeam) and may (or not) relate to your problem

The problem is that we cannot save the file in that state. This DLL includes Fixups for those calls.

Fixups are the same as relocations. From the PE format reference by goppit:
When the linker creates an EXE file (OR DLL), it makes an assumption about where the file will be mapped into memory. Based on this, the linker puts the real addresses of code and data items into the executable file. If for whatever reason the executable ends up being loaded somewhere else in the virtual address space, the addresses the linker plugged into the image are wrong. The information stored in the .reloc section allows the PE loader to fix these addresses in the loaded image so that they're correct again.


Basically the hex values of the dll are modified to make sure that the CALL corelib.?AsLong@DCString@@QBEJXZ goes to the right place. If we save the program as is when we run it our hex values will be modified too.

In other words it wont be
CODE

002329FD 33C0 XOR EAX,EAX
002329FF 33C9 XOR ECX,ECX
00232A01 48 DEC EAX
00232A02 49 DEC ECX


But rather some of the hex values will change. this will make the program behave erraticaly.


There is hope though. We can view and edit the .reloc section by using LordPE

Open the dll with LordPE and click "Sections"
Now choose .reloc and Right-Click

Choose "Hex Edit Section"

You will now be looking at the relocation table for the executable.

Each table is seperate for each section of the executable.
if you look closely you will see them seperated by something like the following: 0000002000004001000009
-=snip=-

http://intechhosting.com/~access/forums/index.php?act=Search&nav=lv&CODE=show&searchid=069b8e1b05f79333ef7438da71e38c17&search_in=topics&result_type=topics&hl=&st=25

Thanks for the input but no luck.

The dll file is a license.dll type file.

I have tried making the checksum correct... does not work.

You get a File invalid, error C0R-56C error code when LoadLibraryW attempts to load this dll into memory.

I did a compare file between the original DLL and the modified DLL with Lord PE and there are no X marks.

What is strange is that the checksum field is set to 00000000 in the original file as well as my modified one when I use either LordPe or PE Explorer.

I checked the Registers before the call to kernel32.dll LoadLibraryW and they match for both original and modified dll files.

I've attached both the original and modified dll files... Is there anything I did wrong? I've never had a problem with dll files before.

Thank you

[MaRKuS-DJM]

Checksums are required for kernel-mode drivers and some system DLLs

that's usually the case for all drivers. i needed to do it when i patched my SoftICE driver. after i patched my kernel, i didn't need to do that. normally it is only used for drivers.

there might be a check in the initial part of you dll.

I experimented more. I renamed another DLL file to be the same as the one I modified. Looking to see if there was a checksum. There appears to NOT be checksum on the dll file.

I renamed an unrelated dll file to the one in question, and ran the program. It did not report any errors. I am interpreting this to mean that there isn't a checksum check at the time the dll is loaded... that infact there is something wrong with the dll file after I changed 2 bytes with winhex.

Any suggestions?

*EDIT* Checked the dll file with PEiD and it says overlay - "MS Visual C++ Method2 Overlay".

Using PE Explorer I can see the error code and something else about CRC check. Did they utilize a program to give it some kind of protection?

[MaRKuS-DJM]

if LoadLibrary fails, the DLL must prevent the loading in the initial part. from the two bytes you patched, i don't see a reason why the dll isn't loaded. when is this code called?

Originally Posted by Maltese

I experimented more. I renamed another DLL file to be the same as the one I modified. Looking to see if there was a checksum. There appears to NOT be checksum on the dll file.

I Did not undestand what is the reason for such experement ?

If i undestood you correctly
you took some unrelated dll (advapi32.dll, for example) and renamed it to license.dll (your problem dll) -> all works correctly. Yes ? but it does not mean
that there is no checksum test in license.dll.

I think there are self - written (not operation system) checksum test in your license.dll in DllMain function of your license.dll.

Sorry for english (not native language)