Kingsoft Protection
This protection appears on various games by Kingsoft.
This description is based on the game Quiwi.
When in the quiz game Quiwi the protection check fails, it seems to load and run normally but all quiz questions are "Ist dies eine Raubkopie?" (Is this a pirate copy?)
Generally track 1 is read with speed zone 3. The protection has a modified track 1 sector 20, where the sector header is written in speed zone 3 and following data block in speed zone 0.
Track 1 Sector 20 decoded at speed zone 3. Notice the data block area that is incorrect with decoding at speed zone 3.
sync 31
; header
gcr 08
begin-checksum
checksum 76
; sector
gcr 14
; track
gcr 01
; id2
gcr 32
; id1
gcr 51
end-checksum
gcr 00
gcr 00
; Trk 1 Sec 20
bytes 52 94 a5 29 4a 52 94 83
bits 1111111
; start of data block
sync 31
bits 0010100101
bytes d9 71 d8 9c 7b e3 71 ef 8e 22 9d 28 f8 8e 94 eb be 23 8b 77 5d d8 89 1d 8b e3 7b a2 24 88 8b 91 c5 8b a5 7a 47 e2 f8 8e c5 cb b8 8b dc 75 dc 7b e3 72 37 11 7b dc 7b dc 7e 47 b9 17 8d 95 f1 1d 89 d7 76 2e f1 c5 b8 d7 1f 11 23 b6 e9 4e 3d de 3b c7 1e ef 44 48 ef 1e f7 c4 88 a3 a2 38 f7 63 11 23 76 dc 5b e3 6f d8 db 56 db ae 88 91 c7 1d 8b e2 38 f7 6d ee 44 48 e9 5c 71 c7 be 28 89 1c 5b de f7 1d 29 f1 1d 8b e3 76 2e 3d f1 1e e3 8f 77 a2 24 69 13 8b 71 ee f1 c7 1c 6b 8f 7c 47 79 11 47 1e f8 8f bb 94 be 23 91 1c 7b bc 88 91 f7 71 ef 88 e3 8e 3f 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a d2 f5 3d 4f 53 d4 f5 3d 4f 53 d4 f5 3d 4f 53 d4 f5 3d 4f 53 d4 f5 3d 4f 53 d4 f5 3d 4f 53 d4 f5 3d 4f 53 d4 f5 3d 4f 53 d4 f5 3d 4f 53 d4 f5 3d 4f 53 2e ee d4 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a 52 94 a5 29 4a ff
bits 1
The same data block decoded at speed zone 0 returns a block with a correct start and correct GCR 07 as data block id:
sync 31
; data
gcr 07
begin-checksum
gcr c4 49 45 53 45 53 20 d0 52 4f 47 52 41 4d 4d 20 49 53 54 20 28 43 29 4f 50 59 52 49 47 48 54 47 45 53 43 48 55 45 54 5a 54 2e cf 52 49 47 49 4e 41 4c 45 20 4b 4f 45 4e 4e 45 4e 20 4e 55 52 20 42 45 49 20 cb c9 ce c7 d3 cf c6 d4 20 44 49 52 45 4b 54 20 4f 44 45 52 20 41 55 54 4f 52 49 53 49 45 52 54 45 4e 20 c8 41 45 4e 44 4c 45 52 4e 20 45 52 57 4f 52 42 45 4e 20 57 45 52 44 45 f4 ff
bits 1101011111
bits 1101011111
Comparison between different dumps results that the first 127 GCRs are always identical, while the remaining data in the data block is not well defined. Thus the signature here is at speed zone 0:
gcr c4 49 45 53 45 53 20 d0 52 4f 47 52 41 4d 4d 20 49 53 54 20 28 43 29 4f 50 59 52 49 47 48 54 47 45 53 43 48 55 45 54 5a 54 2e cf 52 49 47 49 4e 41 4c 45 20 4b 4f 45 4e 4e 45 4e 20 4e 55 52 20 42 45 49 20 cb c9 ce c7 d3 cf c6 d4 20 44 49 52 45 4b 54 20 4f 44 45 52 20 41 55 54 4f 52 49 53 49 45 52 54 45 4e 20 c8 41 45 4e 44 4c 45 52 4e 20 45 52 57 4f 52 42 45 4e 20 57 45 52 44 45
This signature is the same for Side 0 and Side 1 of Quiwi.
The Emulator G64 'Variable Speed Zone on the same track' Problem
When using G64 as image format the tracks speed is purely determined by the track length in bytes in the emulators. The emulator rotates the track data virtually every 200ms. It is decoded again with the set speed zone. Thus, a previously decoded flux based stream with speed zone 3 is identical in the emulator when it is again decoded at a speed zone 3 setting. For this specific case we have the advantage that speed zone 3 uses a faster clock than speed zone 0 that we need for sector 20. Thus, if the track length of track 1 corresponds to speed zone 3 (default) and sector 20 is present as if the actual speed zone 0 data is encoded at speed 3 then in emulation set at speed zone 0 the data should be decoded with GCRs c4 48 ... etc.
So we save as track data in speed zone 3:
bytes d9 71 d8 ...
which is decoded in emulation when read as speed zone 0:
gcr c4 49 45 53 ...
whereas this is the actual read data.
Of course this only works because we map here the faster clocked speed zone 3 to the slower clocked speed zone 0. Please note that the speed zone 3 byte pattern can as well be different and still decode to the correct GCRs at speed zone 0.
Another trick can be exploited when targeting D64 format. In the D64 emulation the speed zone setting is basically ignored as only the data is read. Thus, after the 127 GCRs signature, that consists of valid GCRs the sector can simply be filled with any data. As the protection check ignores the checksum, we can set a valid data block checksum as well and get an error free D64.
Thus for our D64 only:
sync 31
; data
gcr 07
begin-checksum
gcr c4 49 45 53 45 53 20 d0 52 4f 47 52 41 4d 4d 20 49 53 54 20 28 43 29 4f 50 59 52 49 47 48 54 47 45 53 43 48 55 45 54 5a 54 2e cf 52 49 47 49 4e 41 4c 45 20 4b 4f 45 4e 4e 45 4e 20 4e 55 52 20 42 45 49 20 cb c9 ce c7 d3 cf c6 d4 20 44 49 52 45 4b 54 20 4f 44 45 52 20 41 55 54 4f 52 49 53 49 45 52 54 45 4e 20 c8 41 45 4e 44 4c 45 52 4e 20 45 52 57 4f 52 42 45 4e 20 57 45 52 44 45 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 10 ef d1 a7 f5 0e fd 1a 7f 50 ef d1 a7 f5 0e fd 1a 7f 50 ef d1 a7 f5 0e fd 1a 7f 50 ef d1 a7 f5 0e fd 1a 7f 50 ef d1 a6 b7 c0 f0 f0 f0 f0 f0 f0 f0
; checksum wrong, should be 42
checksum 42 ; Just set the expected checksum here
end-checksum
; invalid checksum
gcr 0f
gcr 0f
bytes 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 57
