Hello,
Who Can help me.
I look of a simple Code i included and it compare
the File with the CRC32 or simple CRC.
I Can include CRC - Code manuell in compiled exe file with
hexeditor.
I need a simple code.
Thanks.
Who Can help me.
I look of a simple Code i included and it compare
the File with the CRC32 or simple CRC.
I Can include CRC - Code manuell in compiled exe file with
hexeditor.
I need a simple code.
Thanks.
I?m not sure what u?re lookin for since i don?t understand ur question ..if u?re lookin for an CRC32 algo check the
Algorithms & Source Code Part of the Forum there was recently a dicsussion about CRC32
Algorithms & Source Code Part of the Forum there was recently a dicsussion about CRC32
Sorry for my bad english.
I need a small source it check CRC in my EXE File.
I need a small source it check CRC in my EXE File.
Fred556,
Allanon already gave you the correct answer.
If you search for "CRC" in the "Algorithm & Source Code" forum with the search engine of this board, you will come up with this thread:
http://www.asmcommunity.net/board/index.php?topic=4628&highlight=crc
Regards,
bAZiK
Allanon already gave you the correct answer.
If you search for "CRC" in the "Algorithm & Source Code" forum with the search engine of this board, you will come up with this thread:
http://www.asmcommunity.net/board/index.php?topic=4628&highlight=crc
Regards,
bAZiK
Store your CRC in an unused portion of the MZ header. Obviously
only calculate CRC from the end of MZ header to the end of file.
At runtime, read MZ header from disk (or access at IMAGEBASE from
memory), get the CRC32 value, and sum up the rest of the file.
Easy as eating pies :)
only calculate CRC from the end of MZ header to the end of file.
At runtime, read MZ header from disk (or access at IMAGEBASE from
memory), get the CRC32 value, and sum up the rest of the file.
Easy as eating pies :)
someone will modify your program (crack,infect with virus...) and re-calculate the CRC .... or simply crack the code that performs the check .. or ... X). But what the hell ... its funny to learn protection schemes.
And indeed hunter is right - most implementations of self-checks are
embarrasing to look at. Use standard routines, have a single point
of failure, etc. And often they don't do anything but bother the
legitimate users.
embarrasing to look at. Use standard routines, have a single point
of failure, etc. And often they don't do anything but bother the
legitimate users.
someone will modify your program (crack,infect with virus...) and re-calculate the CRC .... or simply crack the code that performs the check .. or ... X). But what the hell ... its funny to learn protection schemes.
Yeah, but it is so much fun to slow them down and
you can often frustrate them.
Hello,
can I use the same code that is used for creating file's CRCs for strings?
Thanks,
sF
can I use the same code that is used for creating file's CRCs for strings?
Thanks,
sF
Assuming your routine takes pointer to data and its size as input, then yes.
Store your CRC in an unused portion of the MZ header. Obviously
only calculate CRC from the end of MZ header to the end of file.
At runtime, read MZ header from disk (or access at IMAGEBASE from
memory), get the CRC32 value, and sum up the rest of the file.
Easy as eating pies :)
Is this method *portable* and secure?
I mean, isn't it dangerous to put informations in unused room (reserved room?) of the MZ header (pe-header?)... I'm especially thinking about next windows versions...
I didn't really worked on such headers for now... and your method to put some informations here is interesting me...
Thanks.
Hi Readiosys:
Although f0dder (and others) knows surely better than me, from my own reasonings, these are absolutely sure:
---
WORD @ MajorImageVersion
WORD @ MinorImageVersion
BYTE @ MajorLinkerVersion
BYTE @ MinorLinkerVersion
and definitely a lot of places in the DOS stub ;) (which gets mapped by the Windows loader)
---
This one in the PE is probably sure too, but there's no absolute guarantee:
DWORD @ Win32VersionValue (a.k.a. Reserved.. i.e. the DWORD just before SizeOfImage)
---
Although f0dder (and others) knows surely better than me, from my own reasonings, these are absolutely sure:
---
WORD @ MajorImageVersion
WORD @ MinorImageVersion
BYTE @ MajorLinkerVersion
BYTE @ MinorLinkerVersion
and definitely a lot of places in the DOS stub ;) (which gets mapped by the Windows loader)
---
This one in the PE is probably sure too, but there's no absolute guarantee:
DWORD @ Win32VersionValue (a.k.a. Reserved.. i.e. the DWORD just before SizeOfImage)
---
Thanks a lot ;)
Seems really appropried to receive a 32-bit CRC. ;)
WORD @ MajorImageVersion
WORD @ MinorImageVersion
WORD @ MinorImageVersion
Seems really appropried to receive a 32-bit CRC. ;)
IMAGE_OPTIONAL_HEADER:
+-----------------------------------? --- +0000004Ch
? Reserved1 ? Size : 1 DWORD
+-----------------------------------?
i always use this one. and i think it IS secure. ms should
already know that many programs like exe-packers use
those "reserved" spaces. but yes, they could change it
in future so if you*'re really paranoid i think the original
MZ header is better suited for you :)
(oops sorry maverick, you meant this one... :stupid: )
to make this post a little bit "usefull" here's the code to
read your checksum:
INVOKE GetModuleHandle, NULL
MOV EDI, EAX
ADD EDI, [ EDI + 03CH ]
MOV EAX, [ EDI + 04CH ] ; EAX -> CRC32
Originally posted by stealthFIGHTER
Hello,
can I use the same code that is used for creating file's CRCs for strings?
It should work for strings as well. Are you looking for a way to keep someone from changing text that your executable displays. I have some code that will encrypt strings and decrypt it at runtime. I found some other ways that really gives dissassemblers fits. They will give an assembly file that can produce an working executable, but it is twice the original size.
Hello,
can I use the same code that is used for creating file's CRCs for strings?
It should work for strings as well. Are you looking for a way to keep someone from changing text that your executable displays. I have some code that will encrypt strings and decrypt it at runtime. I found some other ways that really gives dissassemblers fits. They will give an assembly file that can produce an working executable, but it is twice the original size.
Originally posted by Readiosys
Is this method *portable* and secure?
I mean, isn't it dangerous to put informations in unused room (reserved room?) of the MZ header (pe-header?)... I'm especially thinking about next windows versions...
I can't think of any valid reasons to store the CRC in the header. It would be safer to encrypt and store it in the code section. Putting dummy strings around it also makes disassembly much more
difficult. Use of the extended ASCII characters makes some of the code actually look like actual code to debug and IDAFW.
Is this method *portable* and secure?
I mean, isn't it dangerous to put informations in unused room (reserved room?) of the MZ header (pe-header?)... I'm especially thinking about next windows versions...
I can't think of any valid reasons to store the CRC in the header. It would be safer to encrypt and store it in the code section. Putting dummy strings around it also makes disassembly much more
difficult. Use of the extended ASCII characters makes some of the code actually look like actual code to debug and IDAFW.
Thanks a lot ;)
Seems really appropried to receive a 32-bit CRC. ;)
Readiosys: good choice.. :)
If I can give you a quite obvious advice (I do so because other people here, beginners, may read too, and I've seen a problem in this regard many times) the best thing to do would be to make many check routines.. not just one. Cracking 10 of them is harder than cracking 1 of them. What about 1000? You (cr?cker) have to find them anyway, and remove them all. 1000 take some serious time. But one must not use the same code for all 1000, otherwise a simple pattern matching will find and remove all of them in one shot. Here having your own compiler helps a lot, I reckon. ;)
Also, crypting your EXE (with your own crypter, not a standard/known one) and making use of self-modifying code to generate these check routines sure helps..
CRC-32 has been cracked anyway, so one should find a more secure algorithm (what about making your own? unknown algorithms are harder to cr?ck.. :grin: ), otherwise storing the checksum in a single DWORD becomes then the weak point..
I can't disclose too many brainfarting ideas here.. but in my experience the above if applied correctly is enough for most situations. The hardest part is about EXE crypting and having your own protection_code generator (compiler) to avoid to write by hand 1000 original, sufficiently_different check routines.
Also, be careful about the extreme weakness of standard solutions like CRC-32.
I'd rather use the MZ header than the PE header for storing the
checksum. Mostly a matter of taste, I guess. There's lots of unused
room in the MZ header, and you can be pretty sure microsoft isn't
going to come up with uses for it - while that *might* (though not
very likely) happen with some of the PE fields.
checksum. Mostly a matter of taste, I guess. There's lots of unused
room in the MZ header, and you can be pretty sure microsoft isn't
going to come up with uses for it - while that *might* (though not
very likely) happen with some of the PE fields.
In one of my programms, I overwrite the stupid "This program cannot be run in DOS mode" message with a MD5 sum ;)
Assuming your routine takes pointer to data and its size as input, then yes.
Hi,
thank you for your reply. And please, can you provide little example how to use CRC on string?
Regards,
sF