View Full Version : Stuck with CRC or similar check..

June 22nd, 2007, 19:54
Hi all,
I'm trying to reverse my first program using IDA but whenever I add a breakpoint or make any alteration to the original executable the program no longer runs.. if I debug using IDA I get a message from the program stating "File Corrupted!" (this is if I add a breakpoint)
I'm guessing that the program detects any modification using CRC or similar..
I have used PEid with the Kanal plugin and it returns the following:

ADLER32 :: 000FF4E3 :: 005000E3
The reference is above.
ADLER32 :: 003A2A99 :: 007A3699
The reference is above.
BASE64 table :: 004B2F90 :: 008B3B90
Referenced at 00592E96
Referenced at 00592EA7
Referenced at 00592EBC
Referenced at 00592ECD
Referenced at 00592F68
BASE64 table :: 004B39E8 :: 008B45E8
Referenced at 00983118
CRC16 [word] :: 00586320 :: 00986F20
The reference is above.
CRC32 :: 00482B10 :: 00883710
Referenced at 004FFEF4
Referenced at 004FFF18
Referenced at 004FFF2D
Referenced at 004FFF42
Referenced at 004FFF57
Referenced at 004FFF6C
Referenced at 004FFF81
Referenced at 004FFF96
Referenced at 004FFFC2
CRC32 :: 00483388 :: 00883F88
Referenced at 00504FB4
Referenced at 00504FD8
Referenced at 00504FED
Referenced at 00505002
Referenced at 00505017
Referenced at 0050502C
Referenced at 00505041
Referenced at 00505056
Referenced at 00505082
CRC32 :: 0050ECA0 :: 0090F8A0
Referenced at 00784B90
Referenced at 00784BA3
Referenced at 00784BB6
Referenced at 00784BC9
Referenced at 00784BDC
Referenced at 00784BEF
Referenced at 00784C02
Referenced at 00784C15
Referenced at 00784C34
MD5 :: 0027C53D :: 0067D13D
The reference is above.
ZLIB deflate [long] :: 00482920 :: 00883520
Referenced at 004FFA14
ZLIB deflate [long] :: 00517868 :: 00918468
Referenced at 007AAEB5

I'm kind of stuck on what to do next to work around this.. I don't even know if I'm even on the right track
Any advice is appreciated!

June 22nd, 2007, 21:33
Use Hardware breakpoint in IDA, right click on the breakpoint, change to Hardware and Execute option.

June 23rd, 2007, 01:54
Find where the message is coming from, and work backwards to find the critical jump that goes there.

June 23rd, 2007, 06:20
Thanks for the info guys, hardware breakpoints did the trick!

Next question is, how can I go about tracking down the 'File Corrupted' bit of code so I can bypass that without using breakpoints in a debugger.. I've searched the strings for 'File Corrupted' but nothing comes up.. I think some of the code is encrypted? as in the strings section I see plenty of things like '$%^&' etc.. Not all of it is though.. as I can see some of the proper strings.
So how can I go about identifying what encryption is used etc.. so I can find the area of code doing the hash checks.. I think I must have picked the worst program to have my first attempt of reversing at!


June 23rd, 2007, 06:36
Yes, this is a tough program to reverse, and you should cut your teeth in something simpler.

Why using IDA debugger? it is slow and cumbersome. Use Olly, save IDA for disassembly.

When yu place a regular break point, behind to courtains the debugger effectively alter the code by changing the byte at the bp address to the opcode CC (int 3). if your program is checking code integrity, blam!.

using hardware breakpoints (you can only place up to 4 simultaneously, you can trace in a more covert fashion.
Also think that the app may be detecting the presence of a debugger or detecting tracing. each subjct has been extensively discussed in the boards and in tuts

June 23rd, 2007, 06:47
Thank you for the explanation naides, that makes exact sense as to whats happening.
In terms of the encryption, how can I find out what was used to encrypt it in the first place? Is there a scanner tool or anything to identify different types of encryption used ?


June 23rd, 2007, 09:41
1. KANAL finds "signatures" typical for the Algos used for Encryption and Hashing, but is not the ultimate word. has false positives and false negatives.

From the list you posted CRC32 CRC16, ADLER32 and MD5 are hashing algorithms: They do not encrypt per se, but produce a "signature" number from the file or from a section of a file. By comparing this signature with something made previously and stored somewhere else, the program detects code alteration or corruption. Note that this hashing may be done on data present in the disk or in memory.

ZLIB is a compression/decompression algorithm, with little encryption capabilities. BASE64 is also a transport algo no real encryption.

Once again what KANAL is saying does not imply that your program is actually USING all this shit to protect itself: For instance CRC16 and CRC32 tables and code are very similar and KANAL always reports both as being used, even if only CRC32 or none at all are actually present.

Send me a link to your program via PM and I will take a look instead of spewing my verbal hallucinations to you

June 26th, 2007, 16:42
Thanks Naides, PM Sent

July 3rd, 2007, 16:12
Well I've been slogging away at this trying to figure out whats going on, and have found the code below which I think is related to the integrity check.. I've put a hardware assisted Read BP on the area I need to modify and it breaks before showing any of the application, as soon as I resume from the BP I get the "File is Corrupted" message and it closes.
To your trained eyes does this look like I may have found the right area, or am I way off on my own little tangent here?


add esp, 0FFFFFFF0h
_2te0cj1p:01BE2FDF mov [ebp-0Ch], ecx
_2te0cj1p:01BE2FE2 mov [ebp-8], edx
_2te0cj1p:01BE2FE5 mov [ebp-4], eax
_2te0cj1p:01BE2FE8 cmp dword ptr [ebp-0Ch], 0
_2te0cj1p:01BE2FEC loc_1BE2FEC: ; CODE XREF: _2te0cj1p:01BABE65j
_2te0cj1p:01BE2FEC jle loc_1B98FC1
_2te0cj1p:01BE2FF2 loc_1BE2FF2: ; CODE XREF: _2te0cj1p:loc_1B98FBBj
_2te0cj1p:01BE2FF2 ; sub_1BE2FDC-117ACj ...
_2te0cj1p:01BE2FF2 mov eax, [ebp-8]
_2te0cj1p:01BE2FF5 movzx eax, byte ptr [eax]
_2te0cj1p:01BE2FF8 jmp loc_1BC3A88

Debugger Info: Breakpoint reached: 0x01BE2FF8 -> 004C6719

Any comments appreciated!

July 3rd, 2007, 17:10
If that part of the code was a crc or similar check, I wouldn't expect them to use a cmp/jle combination. Since it's comparing with zero, I would guess that it's part of some loop.

Why did you post that particular piece of code? Was that because of the hw bp stopped there or some other reason?

July 3rd, 2007, 18:17
Yes this is where the BP stopped (01BE2FF8) so I figured that maybe this is where it was making some checks, guess I'm on the wrong track
I'll try stepping through after the BP and see if I can pinpoint exactly where I bombs out with the file corrupt error.

July 3rd, 2007, 20:59
IDA can do xrefs too, you know...

July 4th, 2007, 02:10
The easiest way is usually to backtrace: Find the error, and eventually go backwards through the program until you find the check that caused the error (check the stack for return addresses, etc).

Of course, this is a lot easier now with the conditional jump logger