Knight Force is a really tricky one, I've only gotten it to run properly on my IBM 5170 from a floppy disk. My advice in trying to get it to run on anything is start with a floppy, the game doesn't like being on an HDD from my limited experimentation.

Just gave a quick run again on my Pentium 90 and the game freezes up once you get to the gameplay. With a few Moslo attempts I was unable to even get to the title screen.

Quick resume:
My copy of Knight Force arrived and it worked quite well in my p200mmx machine + Win98se real dos reboot + slowdos.
You can copy the floppy to hard disk and play it from there BUT the original floppy has to be present in the floppy drive. No Dosbox tests (yet).

After a failed attempt with my usual image dumper DiskExplorer (I/O error), I managed to make a disk image with ImageDisk (full analysis + keep bad sectors).

As you can see from the result, the culprit of the protection is in the final (bad) sector.
The bad thing is that you have to hope the original floppy doesn't go byebye because the imd image can only be used in emulators like pce, if you attempt to write it back to another floppy, it doesn't write bad sector(s), due to standard floppy drive limitations (?). Unless you buy some fancy and costly special card. I wonder why the imagedisk creator doesn't mention that (or maybe I missed some txt infos).

Samdisk creator claims his low level floppy driver can successfully write back to floppies most of those protections without use of special hardware. I still have to test that program but it seems hella cool and promising.

Whats the date on your executable? Mine is 9-22-89. Im curious why yours runs at 200Mhz and mine wont run at 90.

I'll check asap. In the meantime, Imagedisk's programmer sent me a nice confirmation I copy here:

IMD has no capability to reproduce bad disks. It will record if there was a read error on a sector, but it has no way to recreate a read error when writing a disk. IMD does not support "special hardware", only the NEC-765/Intel-8272 controllers as found in PC's.

To copy copy-protected disks, you need something like the "Catweasel" which is a hardware bit by bit copier.

I don't have Knightforce, but Prehistorik 2 (from the same publisher) has a similar protection that vanilla DOSBox has no change of emulating. Check if the game's executable file has the string "Best Protection Kit by E.ZMIRO !!".

You could buy yourself a Kryoflux or SuperCard Pro device to make a preservation-grade copy of the disk and use it with Hampa Hug's PCE-PC or my DOSBox-TC. Supposedly, 86Box emulates some protections as well using a proprietary and ill-documented format, but I know nothing specific about that.

hi

can one of you make a kryoflux dump from your disk to test writing back ?

@NewRisingSun : where can we download your DOSBox-TC ?

thanks in advance

Dosbox-TC › "tc" means transcopy?

A simple imagedisk image of the disk and the game worked in Hampa Hug's PCE-PC, but I had to ☑ the keep bad sector option . I highly doubt I'll ever buy a special card. Not really have nothing else protected to preserve. I will test with teledisk and copyIIpc too.

Eric Zmiro wrote a loader for his own games, I think its on a bundled release from Titus in 1995 iirc.
You can use it load all the encrypted executables from Titus.
My guess: if you imgmount this CD you can load your game from disk or harddisk.
Although you might probably need to mount your floppy too for the disk check.
I thought the filename was cdplay.com or cdrom.com or something.
Then load your exe like D:\cdplay.com A:\game.exe or game.sqz.

I could be full of shit, its been a while since I played anything from Titus.

After messing around with Knight Force (i.e. debugging the copy protection) I _think_ the protection can be removed by simply going to File Offset C11A hex and patching the byte there from 50 hex to CB hex. Found this thread after googling afterwards.

The result is that the protection function immediately returns and program execution continues. I couldn't make sense of the _actual_ protection function. There is some magic offset calculation via some interrupt when calling the protection function.

Meaning, it _should_ work (Game boots up successfully in DosBox), but there might be some hidden switch/variable set that will affect the game, i.e. an unwinnable boss fight or something. Also I don't have real hardware to compare to.

However to verify this, I'd have to play the game 'till the end... but Knight Force is probably the worst DOS game I've ever encountered. No wonder Titus got famous later with Superman/N64.

W.r.t. the version of the game: I've got a European retail version of the game. It contains two 3.5" disks (one for CGA/Tandy, one for EGA/VGA). It's not a standard sized box, but much smaller, not much larger than 3.5" disks. File hash for KNIGHT.EXE (EGA/VGA) is 0D8E67C7CE0F9A7488BE0230CC2C531F. Images created with WinImage with a USB floppy drive.

I'll probably also take a look on the CGA version. Check should be similar.

Akuma wrote on 2019-07-26, 09:30:

Eric Zmiro wrote a loader for his own games, I think its on a bundled release from Titus in 1995 iirc.

I may be wrong but I think it uses a different protection compared to Titus the fox, prehistorik 2 and others.

spieler8 wrote on 2020-04-15, 18:16:

After messing around with Knight Force (i.e. debugging the copy protection) I _think_ the protection can be removed by simply go […]
Show full quote

After messing around with Knight Force (i.e. debugging the copy protection) I _think_ the protection can be removed by simply going to File Offset C11A hex and patching the byte there from 50 hex to CB hex. Found this thread after googling afterwards.

The result is that the protection function immediately returns and program execution continues. I couldn't make sense of the _actual_ protection function. There is some magic offset calculation via some interrupt when calling the protection function.

Meaning, it _should_ work (Game boots up successfully in DosBox), but there might be some hidden switch/variable set that will affect the game, i.e. an unwinnable boss fight or something. Also I don't have real hardware to compare to.

However to verify this, I'd have to play the game 'till the end... but Knight Force is probably the worst DOS game I've ever encountered. No wonder Titus got famous later with Superman/N64.

W.r.t. the version of the game: I've got a European retail version of the game. It contains two 3.5" disks (one for CGA/Tandy, one for EGA/VGA). It's not a standard sized box, but much smaller, not much larger than 3.5" disks. File hash for KNIGHT.EXE (EGA/VGA) is 0D8E67C7CE0F9A7488BE0230CC2C531F. Images created with WinImage with a USB floppy drive.

I'll probably also take a look on the CGA version. Check should be similar.

Yep, I have spanish version, I can confirm the package is small but bigger than 3.5" floppy, similar to cdrom jewel case.
I have single floppy though. Final boss is unwinnable here (or I'm doing something wrong). I tried several times, following this guide. It seems that at least one gamer in the world (user Vyothric) was able to finish pc version 🤣 (see HERE). But he used a different pc version on 5,25" disk. I encounter this problem with original AND hexedited executable on my VGA version. So I don't know what to think.

Myloch wrote on 2020-05-15, 15:28:

Akuma wrote on 2019-07-26, 09:30:

Eric Zmiro wrote a loader for his own games, I think its on a bundled release from Titus in 1995 iirc.

I may be wrong but I think it uses a different protection compared to Titus the fox, prehistorik 2 and others.

I think you are totally right 😁

Really curious if that patch from spieler8 works though, did anyone apply it ?

Unfortunately the CGA version is more difficult. It uses a custom packer; the main game content/logic seems to be in FILECODE.SQZ; and LOADER.EXE unpacks the actual EXE in memory. Since packers are quite difficult -- at least for me 😀 -- I gave up on this. md5 for FILECODE.SQZ is FD884F7A1B214C7AEFBAB75039DCE4E8.

If anyone wants to patch the VGA version but has a different executable. After some startup routines, there is a sequence of calls

55 push bp
8B EC mov bp, sp
83 EC 06 sub sp, 6
9A 0A 00 11 0B call sub_B11A ; -> this is the protection call
9A 11 04 09 11 call sub_114A1
9A DB 03 09 11 call sub_1146B
9A 45 03 09 11 call sub_113D5
9A 10 00 09 11 call sub_110A0
9A 6A 00 09 11 call sub_110FA

noping the call out doesn't work, as there is some self-modifying code-thing going on.

The function at sub_B11A actually looks similar to this:

sub_B11A proc far
50 push ax ; 0cfe:000a // cga:0bf0:000a
53 push bx
51 push cx
52 push dx
57 push di
56 push si
1E push ds
06 push es
55 push bp
FA cli <- some interrupt magic going on
33 C0 xor ax, ax
8E D8 mov ds, ax
assume ds:seg000
C7 06 04 00 D5 01 mov word ptr loc_3+1, offset byte_B2E5
8C 0E 06 00 mov word ptr loc_3+3, cs
9C pushf
58 pop ax
0D 00 01 or ax, 100h
50 push ax
9D popf
FB sti ; <- some interrupt magic going on

It looks like this game uses TurboC, which uses fastcall convention. So we can just immediately reutrn without worrying to mess with the stack (50 -> EB, i.e. return).

But what's happening between cli and then sti (resulting in an immediate interrupt and doing mad jumps around) is beyond me; this is why I am paranoid about this not being fully cracked.

I don't have old hardware, so it's difficult for me to understand how the game actually behaves with the actual protection running.

spieler8 wrote on 2020-06-24, 15:54:

It uses a custom packer; the main game content/logic seems to be in FILECODE.SQZ

SQZ? That sounds vaguely familiar.

A quick Google search turned up https://www.sac.sk/files.php?d=7&l= ; do any of the various "SQZ" programs work?

Here's an expanded discussion about Titus's SQZ format:

http://www.shikadi.net/moddingwiki/Titus_Inte … SQZ_Compression

The perl implementation at the bottom of the page should work.

spieler8 wrote on 2020-06-24, 15:54:

... FA cli <- some interrupt magic going on 33 C0 xor ax, ax 8E D8 mov […]
Show full quote

...
FA cli <- some interrupt magic going on
33 C0 xor ax, ax
8E D8 mov ds, ax
assume ds:seg000
C7 06 04 00 D5 01 mov word ptr loc_3+1, offset byte_B2E5
8C 0E 06 00 mov word ptr loc_3+3, cs
9C pushf
58 pop ax
0D 00 01 or ax, 100h
50 push ax
9D popf
FB sti ; <- some interrupt magic going on

...

But what's happening between cli and then sti (resulting in an immediate interrupt and doing mad jumps around) is beyond me;

The assumption that DS equals SEG000 is just wrong. SEG000 is where the executable starts, but that's a relative address, meaning its value changes depending on which part of the computer's memory the program was loaded into. The code that we have here sets register AX to zero by XOR-ing it with itself and then moves AX into DS, so DS is set to 0 and the code that follows effectively writes two words to the memory at 0000:0004 and following. That's the memory location where the interrupt vectors are stored, I think, so the code is actually setting interrupt vector 1 to point to the code at offset 0x01D5 in the current code segment.

Since the code requires two instructions to write the two words into the interrupt table, it is generally a good idea to disable interrupts with CLI before doing so. Otherwise an interrupt might occur that uses the vector you are currently modifying, causing the CPU to execute code that it was never meant to execute for this interrupt and probably crashing the system. Once all that's done, STI enables the interrupts again.

Interrupt vector 1 is the "single step" interrupt (used for debugging). When the "trap" bit in the CPU's flags register is set, interrupt vector 1 is going to be executed after every single instruction. Everything from PUSHF to POPF is just to set the trap bit in the flags register.

I strongly recommend checking out the code at offset 0x01D5 in that code segment to figure out what's actually happening here. It might be the copy protection itself, or it might just be some code that's supposed to prevent you from single-stepping through the program with a debugger.

Thanks so much K1n9_Duk3! Currently I'm super busy, but I'll look into this later. This is really helpful. I've seen messing around with Int3 and Int1 to make debugging harder in several games (DosBox debugger doesn't care about software interrupts though), but I was thinking Int21 w/ AH = 25h and just didn't recognize this - but sure, why would they go via DOS; just mess with the IVT directly!

btw if someone wants to contact me via PM - hypothetically speaking - note that the vogons board rules wouldn't allow me to reply - I just have a few posts on this board, and sending PMs is not possible. If only some mod could change this... 😀

Interesting: the CGA version can be succesfully unpacked with this open-source tool: https://sourceforge.net/projects/opentitus/
Generates a .lvl file, but it's actually a dos exe. Disassembly looks very similar to the EGA/VGA version.

IIRC it's possible to play from the hard disk by using the DOS SUBST command