The checksum is about two magnitudes larger than the input data, so some kind of addition is likely used. Just adding the bytes together does not work, neither does xoring the bytes with a fixed value and then adding them.
I don't think I have the means to try out whether a checksum is correct or not, and I can't generate checksums for arbritary data either. Any ideas, some kind of common algorithm for this perhaps?
Name:
Anonymous2009-01-08 16:10
>>2
Sorry, those are proper checksums that generate full hashes even on short data.
Name:
Anonymous2009-01-08 16:16
You need to try all checksum methods using not only bytes, but words, and dwords, in both little-endian and big-endian. There was a .NET program I used once that had a whole slew of standard checksum methods it would run on data.
Name:
Anonymous2009-01-08 16:16
>>4
Indeed, but this checksum is just used to check the validity of the data.
Name:
Anonymous2009-01-08 16:25
>>4
Why would you not store the data and retain only the checksum? No matter what length the data is, how is that [b]useful[b]?
Start with a checksum of zero: for each byte, if the value == 167, add 882 to the cheksum, if it == 107, add 828. Otherwise, do nothing (possible optimization: add zero, to avoid a conditional jump.)
* Redcar East railway station, England; National Rail station code RCE.
* Recursive competitive equilibrium, an economic equilibrium concept associated with a dynamic program
* Region Code Enhanced, see DVD region code
* Request for continued examination, in United States patent law, see continuing patent application
* Response Center Engineer, a cross between a Help Desk and a Call Center
>>21
Ah, I see, it's not that easy when you are working with a Windows executable on Linux though.
Name:
Anonymous2009-01-26 14:35
>>22
There's probably more tools for analyzing PE modules than there's tools for analyzing ELF. You could start with IDA(commercial, but has linux build), while debugging it in OllyDBG(in WINE) to get it done quickly.
Name:
Anonymous2009-01-27 10:47
>>23
Yeah, I did give OllyDbg a shot... (actually, I think I did for an unrelated problem) but the interface is so confusing with millions of features with undescriptive names. If there was just some nice thing that'd trace a byte from a file through the execution of the program.
Name:
Anonymous2009-01-27 20:43
>>22
The headers are different, but unless you're on a non-x86 machine the actual code is the same. Just figure out where the code starts in the file and at what address it's supposed to be loaded at, and use whatever IA32 diassembler you have.
Name:
Anonymous2009-01-27 22:01
>>24
OllyDBG's interface may be a big complex for a beginner, but it's still the most comfortable ring3 assembly-level debugger I've had to work with so far, given enough time, it becomes very easy/intuitive to use.