algorithm question about delsum HOT 4 OPEN

yeah that's possible, it should also be possible to use the generalized version where 0x1003f is made into a parameter (which would also include djb2), while still being able to recover it efficiently with delsum reverse. i can't say i'll get to it soon though.

are there other algorithms you had in mind?

from delsum.

some good news about Add, WAdd and DWAdd: i think you should be able to get them already as modsum width=8, modsum width=16 wordsize=16 and modsum width=32 wordsize=32, and adding in_endian=big would make them use big-endian values (not setting the module parameter lets it default to 0, which is the same as no modulus at all).

haven't thought about the sign stuff, so i will definitely implement that when i get around to that.

from delsum.

for sure, a generic alternative that can cover other variations (sdbm, djb2) would be great.

Regarding other algorithms, I usually dig around save-game checksums for save-game editing, and there are a bunch of simple checksums that could be added too.

There's the "add" family, generally referenced as ADD, WADD, DWADD (8-bit, 16-bit, 32-bit), these are super simple, just a sum of bytes, like:

Add:

    while (len--)
        add += (uint8_t) *data++;

WAdd:

    len = len/2;
    while (len--) {
        wadd += (uint16_t) *data;
        data += 2;
    }

DWAdd:

    len = len/4;
    while (len--) {
        dwadd += (uint32_t) *data;
        data += 4;
    }

Note: some variations use signed int8, int16, int32 instead of unsigned, or read values as big-endian, and some other variations are all substractions instead of sums, like while (len--) { sub -= (uint8_t) *data++; }.

I understand if you don't have time right now, but it would be great to have such nice reversing tool when working with save-game data. 😄

from delsum.

thanks for the feedback!

from delsum.