PDA

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

swifty
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:
Code:


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!
TQN
June 22nd, 2007, 21:33
Use Hardware breakpoint in IDA, right click on the breakpoint, change to Hardware and Execute option.
LLXX
June 23rd, 2007, 01:54
Find where the message is coming from, and work backwards to find the critical jump that goes there.
swifty
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!

Cheers
naides
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
swifty
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 ?

Thanks
naides
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
swifty
June 26th, 2007, 16:42
Thanks Naides, PM Sent
swifty
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?

Code:


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

_2te0cj1p:01BE2FEC loc_1BE2FEC:                            ; CODE XREF: _2te0cj1p:01BABE65j

_2te0cj1p:01BE2FEC jle     loc_1B98FC1

_2te0cj1p:01BE2FF2

_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!
squidge
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?
swifty
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.
LLXX
July 3rd, 2007, 20:59
IDA can do xrefs too, you know...
squidge
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