related posts:
- the original QCRACK post where I try to learn about the original DOS executable
- QCracker - a JavaScript implementation of QCRACK on a webpage
- Continuing QCRACK
- flowlib in QCRACK
- QCRACK SKU Encryption
- Finished with QCRACK - my last post on it
I tried the ENCRYPT.EXE by running it in DOSBOX with various input to see if I can tell what it does.
Just a zero gave a 7
0
7
Two zeroes gave a 7 then an 8, so may not be dependent on length.
00 00
07 08
Continuing shows the value increases then rolls over a byte’s worth.
00 00 ... 00 00 00 00 ...
07 08 ... FE FF 00 01 ...
Adding a non-zero shows it’s either XORing with that starting 7 or subtracts it from 7.
01 00 ... 00 00 00 00 ...
06 08 ... FE FF 00 01 ...
Continuing with more values shows it’s actually XORing.
0F 00 ... 00 00 00 00 ...
08 08 ... FE FF 00 01 ...
00 01 00 ... 00 00 00 00 ...
07 09 09 ... FE FF 00 01 ...
So ENCRYPT.EXE XORes each byte starting with 7, increasing by one each time and rolling over.
Here’s my own qcrypt.c
#include <stdio.h>
#include <stdint.h>
void main(int argc, char* argv[]) {
if(argc < 3) {
printf("Usage: %s <source> <destination>\n", argv[0]);
return;
}
FILE* qcrypt_input;
FILE* qcrypt_output;
if((qcrypt_input = fopen(argv[1], "r")) == NULL) {
printf("couldn't open %s for reading\n", argv[1]);
return;
}
if((qcrypt_output = fopen(argv[2], "w")) == NULL) {
printf("couldn't open %s for writing\n", argv[2]);
}
uint8_t offset = 7;
int c;
while((c = fgetc(qcrypt_input)) != EOF) {
fputc(c ^ offset++, qcrypt_output);
}
}
I checked if SKU.17 was “encrypted” this way when compared to SKU.TXT, but it wasn’t. QCRACK looks in SKU.17 for a game name, so I know it at least knows how it’s encrypted and I’ll probably have to continue reversing the executable.