[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?

Using Olly...

Inside the .rdata of the dll I see the error text:

100257B0 4D 6F 64 75 6C 65 73 2E Modules.
100257C0 00 00 00 00 41 70 70 6C 69 63 61 74 69 6F 6E 50 ....ApplicationP
100257D0 72 65 66 69 78 00 00 00 00 00 00 00 4D 6F 64 75 refix.......Modu
100257E0 6C 65 73 00 00 00 00 00 43 4C 69 63 65 6E 73 65 les.....CLicense
100257F0 43 6F 6E 74 72 6F 6C 3A 3A 6F 6E 43 6F 6D 6D 61 Control:nComma
10025800 6E 64 28 25 73 29 20 75 6E 68 61 6E 64 6C 65 64 nd(%s) unhandled
10025810 00 00 00 00 00 00 00 00 00 00 00 00 43 4D 5F 43 ............CM_C
10025820 48 45 43 4B 5F 41 50 50 4C 49 43 41 54 49 4F 4E HECK_APPLICATION
10025830 5F 4C 49 43 45 4E 53 45 00 00 00 00 00 00 00 00 _LICENSE........
10025840 57 69 64 67 65 74 50 74 72 00 00 00 4E 61 6D 65 WidgetPtr...Name
10025850 00 00 00 00 43 4D 5F 43 48 45 43 4B 5F 4D 4F 44 ....CM_CHECK_MOD
10025860 55 4C 45 5F 4C 49 43 45 4E 53 45 00 00 00 00 00 ULE_LICENSE.....
10025870 5C 73 79 73 74 65 6D 33 32 5C 00 00 00 00 00 00 \system32\......
10025880 63 6F 6E 74 00 00 00 00 78 10 00 10 4C 69 63 65 cont....x...Lice
10025890 6E 73 65 20 45 6E 67 69 6E 65 20 43 52 43 2D 45 nse Engine CRC-E
100258A0 72 72 6F 72 00 00 00 00 00 00 00 00 41 70 70 6C rror........Appl
100258B0 69 63 61 74 69 6F 6E 20 63 68 65 63 6B 00 00 00 ication check...
100258C0 00 00 00 00 46 69 6C 65 20 69 6E 76 61 6C 69 64 ....File invalid
100258D0 2C 20 65 72 72 6F 72 20 43 30 52 2D 35 36 43 00 , error C0R-56C.

MaRKuS,

Not sure how I can explain, but I will try.

I traced the EXE file, the welcome splash opens, then it loads the libraries before the program gets to run... There must be something inside the dll that when it opens it may create an unhandled exception (see above) and display the error code. I took another dll from the program and renamed it and the program got past the loadlibrary section just fine. The license dll is the only one with the Visual C++ Method2 [OVERLAY] in the PE Header from PEiD. The rest of the DLL's are just Visual C++ Method2.

Any thoughts?

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)

I found a way around the problem....

After investigating the problem DLL.... I found the conditional branch creating the error... I just told it to always jump past it.

Problem solved.

Thanks for everyone's input. I appreciate it!

Malt

[MaRKuS-DJM]

nice you solved it
as you see from your posted code, it was definitive a CRC-check:

Originally Posted by Maltese

10025880 63 6F 6E 74 00 00 00 00 78 10 00 10 4C 69 63 65 cont....x...Lice
10025890 6E 73 65 20 45 6E 67 69 6E 65 20 43 52 43 2D 45 nse Engine CRC-E
100258A0 72 72 6F 72 00 00 00 00 00 00 00 00 41 70 70 6C rror........Appl