GML [SOLVED] Modify a buffer but keep the CRC32 hash

nesrocks

Member
Very short: I have a buffer and I want to modify some bytes of it, but I want the resulting buffer to have the same CRC32 hash as the original buffer. Got it mostly working, except for one line of code (what is "inverse(x32)").

Assumptions:
- I can get the CRC32 hash of any buffer using this script
- I am freely modifying a known section of the buffer (say, byte range $200-$300)
- I have a 4 bytes section of the buffer I can freely modify to get the desired CRC32 hash (say $ffc-$fff)

I tried following this thread and I got everything working up to the inverse crc part (his step 4). I just don't understand it. It points to scripts in different programming languages that I'm really not familiar with. The rest of the steps are straight-forward, but step 4 is too cryptic as it is. More specifically, I don't understand what does "inverse(x32)" mean. Any ideas?

edit: There's a very verbose explanation here but I'm still lost.
https://www.reddit.com/r/crypto/comments/3h6qeh/generating_crc32_collisions/cu4rg2p/
 
Last edited:
H

Homunculus

Guest
Never tried anything like this, but it's an interesting topic. Try looking at this article, from what I read it's definitely possible to forge any CRC32 provided you have 4 bytes you can freely edit. There’s also an implementation in 4 languages you can analyze.

Good luck!
 
Last edited by a moderator:
H

Homunculus

Guest
The thing is, if I bit shift "P" 32 times to the right it will become always zero because it is 32 bits long. I am missing something here.
I agree, I find the reddit topic incredibly confusing to be honest, and I don't really see what's the point of shifting the polynomial. I'm looking at the code provided in the article I linked before and I have to admit I lack the math background to understand some of the concepts, but if you take the code as is it shouldn't be too difficult to understand what's going on and convert it to GML.
 
Last edited by a moderator:

nesrocks

Member
I'm trying to understand what CRC is, and my god this video is an incredibly good class on that:


Converting scripts from other languages presents a few problems:
1 - I'd have to learn a certain amount of how that language's syntax works
2 - Sometimes they include libraries that only further complicate things

Here's another one: https://itsme.home.xs4all.nl/projects/sources/crc.c
 
Last edited:

nesrocks

Member
The most unusual thing, really. I've used GameMaker to create a level editor for Pick Axe Pete (a game for the ancient console Magnavox Odyssey2 aka Videopac). It takes the rom, presents an interface that allows the user to edit any one of the game's 10 levels, then the user can save the modified ROM.



It works 100% as it should, but I need to patch it to keep the CRC32 to make up for a problem with O2em (the only O2 emulator that exists). It isn't the most accurate emulator ever, so it relies on a few internal "hacks" to make games work properly, and it checks which game the ROM is by its CRC32 hash. So, if I want the editor to cleanly export a ROM that works with the emulator, it has to do that.

Other options are:
1: make the editor export emulator specific xml files to add the generated CRC as a valid entry
2: instruct the user to run the ROM using command line options that fix the problem
3: ignore the problem completely and fix the emulator instead.

Out of these I think option 2 would be the second best thing. But it would be best if it really did just export the ROM with the regular hash. That way it would universally work everywhere.
 
Huh, that's awesome. I've saved that CRC tutorial to my watch later list (for when my Maths brain isn't asleep), but it looks interesting.

Is the emulator open-source, is that why you can fix it instead? Seems to me it would be simpler to fix the emulator - but I like your dedication to originality. Seems it's often the last 1% that takes up most of our time... :rolleyes:
 

nesrocks

Member
By "fix the emulator" I meant to make it more accurate, which is of course the best solution but by far the hardest one. Yeah, I think it is open source.

Yeah, the editor is complete in the sense that there's nothing wrong with the ROM. If I were to burn the ROM into a cartridge and run it on the original hardware it would work perfectly. The problem is O2em.

edit: The reddit post is confusing in part because he says that "reverse bits means reverse the order of the bits", and "inverse bits means flipping them". But when he says "inverse(x32)" he says it means something else entirely.
Also, after looking at the CRC32 video it would seem that inversing x32 would simply mean to flip the most significant bit, which would be something much more sensible to say than "inverse(x32)", so it can't be that either.
 
Last edited:
Top