Kobrahsoft DB1 protection

[Pegaz]

It’s been almost 10 years since the wos discussion, about disk protection in Kobrahsoft DB1 Plus 3 backup disk utility.
https://spectrumcomputing.co.uk/index.p ... 6&id=11645
In that thread, some explanations are given for this stubborn protection, but a definitive solution hasn't been found.
https://www.worldofspectrum.org/forums/ ... ion/35643/

Some things are still unclear:
- How to bypass the original disc check during every backup?
- How to copy master disk itself?
- Why almost all known emulators crash, except Spectaculator and Unreal Speccy, which bypass protection without problems.

After almost a decade, maybe it's time to solve this mystery?
I tried to apply the solution suggested by user Battle Bunny, but failed to get a usable disk copy that would work on my +3 and all other emulators, except few of these I mentioned.
This protection is obviously implemented on multiple levels, the program is moving from one location to another and this is just too much for me.
I know that there are some top programmers here, so maybe someone would like to take a look at and suggest a solution.
Its a very useful tool, but with incredibly rigid protection.
Even if you had the purchased disc at the time, you could not make a backup, but you had to pay the cost of sending a new disc to the manufacturer in case your copy is damaged.

[Stu]

The "check original disk" routine is at $8b41, with the relevant part being as follows:

Code: Select all

$8b63	ld	b,$01		; set b to 1
	ld	hl,$5b3b
	ld	a,$cb
	cp	(hl)
	jr	nz,$8ba7	; jump to $8ba7 if the first check fails
	inc	hl
	ld	a,$fd
	cp	(hl)
	jr	nz,$8ba7	; jump to $8ba7 if the second check fails
	inc	hl
	ld	a,$bc
	cp	(hl)
	jr	nz,$8ba7	; etc.
	inc	hl
	ld	a,$dd
	cp	(hl)
	jr	nz,$8ba7
	call	$830c
	ld	de,$8bd8
	ld	bc,$8eb6
	ld	hl,$5b00
	call	$8e08
$8b8e	ld	b,$01		; set b to 1
	ld	a,($8eb7)
	cp	$20
	jr	nz,$8ba7
	ld	a,($8eb8)
	cp	$20
	jr	nz,$8ba7
	ld	a,($5b00)
	cp	$b0
	jr	nz,$8ba7
	ld	b,$00		; set b to 0 if all checks pass
$8ba7	pop	af
	ld	($8eb4),a
	ld	a,b
	and	a
	ret

Patching each ld b,01 to be ld b,00 effectively makes the routine always return the "yes this is the original disk" response. This can be done by directly editing the disk file as follows:

Offset $2700 - $ea > $eb
Offset $272b - $58 > $59

These bytes are encrypted on disk so we need to write values that will decrypt to $00.

Combine this with Battle Bunny's patch to prevent the decryption from crashing due to the incorrect value of i:

Offset $1aca - $ed $57 > $3e $00

With these patches I'm able to load DB1 in Fuse and clone a disk without needing to insert the DB1 disk when prompted. It still won't copy itself but it's a start!

[Pegaz]

Thanks Stu.
What tool did you use to edit the disk file?
I tried with ZX Block Editor, but I can't find all the addresses you mentioned.

[Pegaz]

In the meantime, I succeeded with the HxD editor.
It works really nice, except for cloning itself...

[Pegaz]

Interestingly, I tried to back up the original image with the ancient RealSpectrum emulator and it worked!
This emulator crashed earlier with the original unmodified disk, like most others, but now performs error-free cloning itself, with this patched image.
However, I tried the same with Spin and SpecEmu, but both failed and stuck at the beginning of recording...

[Stu]

Yeah just a regular old hex editor does the trick!

I've been trying to copy Where Time Stood Still (a Speedlock +3 game) as it's specifically mentioned in the Crash review of DB1 as a protected disk that it can handle. However I've had no luck copying it in several emulators (Fuse, UnrealSpectrum, Inkspec, Retro Virtual Machine). I'm not sure if it's an emulator issue, an additional layer of protection in DB1, if the version of WTSS that Crash copied was different to the one in the WOS archive, or any combination of the above!

[Pegaz]

You're right, this is really interesting and if its another layer of protection, then it is very cleverly designed.
So far, Spectaculator copying most protected disks as well and behave the same with unmodified or your patched image.
He even clones WTSS, but makes a large 946 Kb dsk image, which only works while the copy is still in the virtual drive, right after recording.
After that, every attempt to open such a dsk file, results in a file not valid error.
The RealSpectrum emulator also clones a large number of disks (with patched image only), as well as some protected ones, but crashes with WTSS, Batman the movie and few more.
I'll try RealSpectrum later with a physical disk drive and data caching turned off, just to be sure.
Other emulators get stuck at the beginning of the recording process.
btw, in that old wos thread, Battle Bunny suggested this change as well:

At $ 2781, change FC 36 B2 BF EF 84 to 31 77 39 7B 41 0F
This changes the encrypted calls to the copy protection routine and error reset so that they decrypt to six NOPs.

Is this change unnecessary now, after your changes to $2700 - $ea>$eb and $272b - $58>$59 ?
I have to admit that this is the strangest and best protection I have seen so far.
I'm especially surprised that some of the best emulators, like SpecEmu, can't handle this disk, nor the reasons why Spectaculator behaves this way.
The saga seems to be continuing ...

[Stu]

btw, in that old wos thread, Battle Bunny suggested this change as well:

At $ 2781, change FC 36 B2 BF EF 84 to 31 77 39 7B 41 0F
This changes the encrypted calls to the copy protection routine and error reset so that they decrypt to six NOPs.

Is this change unnecessary now, after your changes to $2700 - $ea>$eb and $272b - $58>$59 ?

Battle Bunny's patch overwrites the call to the disk check when DB1 is first loaded, along with the subsequent "crash if the disk check failed" instruction. So the patch isn't strictly necessary since the disk check never returns a fail result -- however if the disk check takes a few seconds then that patch will at least speed up loading a little bit.

[Pegaz]

Today I tried patched DB1 and several disc games with hardcore protection (After Burner, Robocop, Chase HQ 2, Wec Le Man) using DB1 and DU54, but I failed to copy any of them on real 3.5" disk drive and RealSpec emulator under DOS and win 98.
Also I tried the cpdwrite tool (DOS), but it didn't work either.
If the original DB1 can copy such disks on real +3 machine, then maybe this DB1 dsk backup from the archive wasnt done properly from the beginning.
I also read that some games refuse to work on 3.5 "disks and work well on an internal 3" drive, but it would be worth checking only with the original DB1 and a real +3.
It remains to try copying these most stubborn titles using SamDisk, but I can't try it because its looking for some newer windows based pc with real (internal) floppy drive, which I don't have available at the moment...