samrussellbg

thanks :) the braiding approach is super clever too, this was one of those weird moments where you find something and then have to triple check your results because how could i accidentally find something better than the algorithm that hasn't been touched in decades...

the part i really like is that it gives us small improvement on the pclmul too, as the non-accelerated algorithm doesn't really stand a chance against the accelerated opcode on newer hardware so it probably isn't going to see much use in practice. however... i think hardware solutions could possibly benefit (e.g. ethernet cards)

the zlib-ng guys are super welcoming and helpful, working with them was a very pleasant experience

I forget, these were the outputs of my test scripts and I wasn't exactly fastidious here, at least the axes all start from zero :)

IIRC they're off by maybe a factor of 10 or 100, the test scripts just generate a bunch of (seeded) random data and then execute the CRC of X bits Y times and that's where the number comes from, it's consistent across the different tests even if the units are wrong

this is why i wrote the unpacker in python so you can see what's happening :)

the reason i posted this isn't because there's a lack of LZEXE unpackers around, but because learning to reverse is hard and i wanted to share an example of the step by step process of what reversing looks like. it's very tedious and slow. functions like these are places where a lot of reversers are going to give up and look elsewhere, so i wanted to show an example of how to break it apart piece by piece instead of getting lost or giving up

you have no idea how happy it makes me that people recognize the reference :)