Patching file

[peterg70]

Hey all

I have a program that is capable of detecting when i patch a DLL due to axprotect codemeter wrapper.

the file is also digitally signed.

When i searched around on internet I found a similar patch was done on the same file but it is not detected as modified.
When I compared the files I noticed 20 bytes has been modified.
If I attempt to change one of these new values the file is detected as modified again.

So somehow the cracker has managed to make the hash check for the DLL to pass by changing the 20 bytes.

Does anyone know of a program that calculates the old hash and then works out what is needed to make the patched dll pass the same hash

thanks

[TechLord]

If you can share the files with me, then I will take a look.
The CRC check function for Wibu Codemeter is there mainly in the same file itself and the wrapper code does it.
So generally, the CRC checking function(s) have to be patched, to avoid "failing" the check.
In case of the Wibu's OWN files, like WibuCm32.dll for example, the runtime also checks the digital signatures, as does the Kernel component of the Wibu Codemeter.
Depending on the version of the Codemeter/AxProtector used, the pointer to the CRC of the file is found at a particular location.
See this post and the attached screenshots.

http://forum.exetools.com/showpost.php?p=100098&postcount=21

So you should ensure that the CRC always either comes out to the "passing" value at runtime, OR patch the checking function.

USUALLY this will suffice.

If the RUNTIME etc is checking the digital signature then it's a wee bit more complicated.

I can only say after I actually see the file.

[peterg70]

it would seem that axprotect has the capability of monitoring files outside the exe for modification.

Unwrapping and patching can be done on the exe but trying to avoid excessive work for no value.

So chasing patching the licensing DLL for flexlm. Patches work but software in exe detects the modification.

Like I said before someone else has managed to recalculate the hash by modifying 20 byte near the end of the file to make it not detect the modification.

What hashing of externallly protected files does axprotect have?

[copyleft]

As you have access to an already patched signature in the file, you already know where the signature is located ...good luck
you could simply put memory breackpoint on signature location and find the calling algorithm(s). it might be easy to patch algorithm(s) or even recalculate it.

[maktm]

If it detects whenever a byte is changed then it has a CRC check on the .text section of the file (or something similar). There are multiple ways of going around this, but most of them are complicated. Some methods are:

> Disabling checks completely by finding the functions that check them (Stack tracing comes to mind)
> Finding the stored value for the CRC and then modifying it the exact value required, after the bytes are changed.

All these are pretty difficult but one other method you can do is to reroute control flow by setting breakpoints in the .data/.idata sections or causing exceptions anyhow then catching these exceptions in handlers (using winapi functions to set on top of chain) and then modifying what is required.


Best advice I have is to see how that other guy did it. Compare the two files (original and modified) to see the changes he made.

Hope something here helps

[evlncrn8]

im guessing a lot has changed in 10 years, has reversing stopped?

[peterg70]

reversing hasn't stopped.

Just with encryption layers and self modifying code a simple task 10 years ago is no longer routine. Programmers can create a messy code as this is the current acceptable norm.

So why go through days of decompile/reversing when there are other ways to solve the problem.

Back on topic
The patch is straight forward in external dll. The main exe is axprotected. Techlord has done extensive work on it. I don't want to decompile exe/patch as this would need to be done to many exe. So attacking the dll which is common is easier.

What i asked was there a tool that can get the same CRC value after patching as before by adjusting some bytes in the file.

Originally Posted by evlncrn8

im guessing a lot has changed in 10 years, has reversing stopped?

[rasta]

There is a tool for peid to change crc to a given value. However algos for crc can be modified a bit, so it could be useless (due to different CRC algo).

[psgama]

Hey Peterg, how goes the battle with the DLL? Make any headway? Or are you still stripping the Wibu protection from everything?

I have same problem
Most of expert use loader to by pass the same.
I am not expert that.
Pls. if Any one explain clue how to make it....

[Notmex]

Why dont you guys try to use a DLL with a Vectored Exception handler? This would not modify the code or trigger any CRC mechanism. You could use hardware breakpoints or PAGE flags to catch the exceptions and work your modifications out from there.

[Mpower04]

Hi Notmex-

Can you explain what a Vectored Exception handler is or point me in the direction of a good tut? I'm working on a few FlexLM (11.9 - 11.13) targets and I want to learn as much as possible.

Thanks!

[Mpower04]

Hi Peterg-

Any updates? Have you been successful or made progress? I'm having the same issue at the moment.....

[psgama]

I'm assuming some progress was made by someone, as there is a file floating around for the specific protection he is referring to patched to pass checksum from what I gather. Haven't really looked into it other than what I've seen on the boards, as I have no need and am licensed for work anyway. This may be the original file he was referencing

3.60.0.117

Patch 1) 000E1E77 From FF 95 84 FE FF FF TO B8 00 00 00 00 90
Patch 2) 0011D037 From FF 95 84 FE FF FF TO B8 00 00 00 00 90
Patch 3) 001C6085
From > B3 D6 E0 0E D7 C3 88 80 CD 18 BC F7 9B C7 23 CE 50 E4 A9 09
TO > 93 27 36 4D C9 88 DE 9D 2B BF E6 67 67 28 DE 03 06 5E 3B A5