@foone@digipres.club
THEY CHECKSUM THE FIRST 16KB OF EXECUTABLE RAM?
@foone@digipres.club
I patched the EXE to have the right value, but then they checksum it, and now the value is wrong!
THEY CHECKSUM THE FIRST 16KB OF EXECUTABLE RAM?
I patched the EXE to have the right value, but then they checksum it, and now the value is wrong!
I need a comparative DOS CPU tracer.
Like, load two copies of the same EXE, and run until the execution diverges
THEY CHECKSUM THE FIRST 16KB OF EXECUTABLE RAM?
I think they might be depending on the value of the weird sector elsewhere. like they're loading it SOMEWHERE, maybe they overwrite some code?
I need a comparative DOS CPU tracer.
Like, load two copies of the same EXE, and run until the execution diverges
and... it doesn't work.
tertiary copy protection?
I think they might be depending on the value of the weird sector elsewhere. like they're loading it SOMEWHERE, maybe they overwrite some code?
I have 37 bytes. this won't be hard
and... it doesn't work.
tertiary copy protection?
normal people don't do this. normal people don't write 16bit DOS assembly in 2025.
I have 37 bytes. this won't be hard
okay I now know HOW to crack the game, I just gotta write the x86 assembly.
normal people don't do this. normal people don't write 16bit DOS assembly in 2025.
oh god they overwrite the DOS interrupt 1E in the middle, to make DOS think it's a different kind of floppy disk.
okay I now know HOW to crack the game, I just gotta write the x86 assembly.
so you can't just overwrite check_copyprotection_sector with return 0
oh god they overwrite the DOS interrupt 1E in the middle, to make DOS think it's a different kind of floppy disk.
they call the copy protection on two different sectors, and throw the out-of-phase error if they give the same result, I think
so you can't just overwrite check_copyprotection_sector with return 0