It would be strange for any kind of protection to be *intentionally* sensitive to machine speed, but I guess the game could have a bug in that regard. If you haven't already, I suggest trying the cputype=386_prefetch setting; and if that doesn't help, maybe try different memory allocation amounts with loadfix.

have you tried fixed amount of cycles?

ripsaw8080 wrote:

It would be strange for any kind of protection to be *intentionally* sensitive to machine speed, but I guess the game could have a bug in that regard. If you haven't already, I suggest trying the cputype=386_prefetch setting; and if that doesn't help, maybe try different memory allocation amounts with loadfix.

I do not know it is intentional or not but looks program very sensible to the speed of machine. I try with 386_prefetch with same error. I try this program with bochs in debugger mode and with different speed (ips) I got different errors which means to me there are some link between machine speed and the program. I have no idea how as I am not an expert programmer. Now I am trying with loadfix without success.

Is there any utility or internal command in dosbox which goes into dosbox debugger after load a program (similar to td, cup386, softice)? Now I start program and after a little time I press alt+break to call debugger but it's not very exact method I think.

robertmo wrote:

have you tried fixed amount of cycles?

Yes with different values (3000,3500,4000,4500,8000 I think).

You can start a program like "z:\debug mygame.exe", and the DOSBox debugger will break at the program's entry point. You can also set a breakpoint on INT 21 (BPINT 21) in the DOSBox debugger and run the program normally, which will break at the DOS execute function (INT 21/4B), and from there it's just a few steps to the program's entry point. The latter method is preferred because some programs object to being run as a child program.

ripsaw8080 wrote:

You can start a program like "z:\debug mygame.exe", and the DOSBox debugger will break at the program's entry point. You can also set a breakpoint on INT 21 (BPINT 21) in the DOSBox debugger and run the program normally, which will break at the DOS execute function (INT 21/4B), and from there it's just a few steps to the program's entry point. The latter method is preferred because some programs object to being run as a child program.

Debug is what I am looking for. Thank you! I am debugging this application and found some strange part of it. Makes checksum for C000 segment, boot sector.

Is this debug only works under integrated DOS system or works with DOS 6.2 as well?

The C000 video bios segment shouldn't be a problem; but DOSBox uses the C800 area as RAM for its internal DOS. I've debugged a different game that has a problem with its copy protection in DOSBox because of the C800 area, so it might be worthwhile to check that.

There are no readable sectors unless you mount a disk image, although DOSBox does a bit of faking for certain INT 13 calls when no images are mounted.

Yes, the DOSBox debugger works with real DOS; however, you can't start debugging with Z:\DEBUG.EXE like you can with the internal DOS, so you'll need to use a breakpoint.

ripsaw8080 wrote:

The C000 video bios segment shouldn't be a problem; but DOSBox uses the C800 area as RAM for its internal DOS. I've debugged a different game that has a problem with its copy protection in DOSBox because of the C800 area, so it might be worthwhile to check that.

There are no readable sectors unless you mount a disk image, although DOSBox does a bit of faking for certain INT 13 calls when no images are mounted.

Yes, the DOSBox debugger works with real DOS; however, you can't start debugging with Z:\DEBUG.EXE like you can with the internal DOS, so you'll need to use a breakpoint.

Thank you. I debug the program and looks like decompress routine fails and run in an endless loop. The program structure is a loader and then some compressed overlay data. Probably there are some corruption in overlay data. So I try to install application again even I do not think there was any corruption in my disc image file. But install gives the attached picture as error I think. I cannot exit just restart works. Most likely it is Chinese or Japanese text which I cannot understand.

"Crazy soup sound to" Setup

The players, first of all thank you for your letters of support for this game, but the supervisor a copy of the wind has not put an end, therefore we had to add a little trouble for you - with a less aggressive protection to protect our food and clothing.

Press the spacebar to Suan, the program will check whether there is protection on the disk!

Crazy Bomber installation program

Dear player, first of all thank you for your support for this game. Since unauthorized copying is not completely banished yet, we had to introduce a small inconvenience - a non-aggresive protection - to insure our income.

After having pressed spacebar, this program will check if the protection exists on the disk.

Remember kids, always wear protection 🙄

Thanks for the translation!

Nothing happen in DOSBox when I press spacebar. I fire up qemu and put my drive image into that. It gives the following error after I press spacebar. I believe it says something about problem with protection (red might a sign for that).

Then I debug the installer in DOSBox and looks like protection uses direct address to call ROM routine. I mean it calls F000:EC59 directly where is no real code in DOSBox so it failed. With some google it seems the address belongs to the floppy interrupt so I think program would like to check some sectors on floppy disc.

Letters can not afford, do not cut open and clean the disc to find the program on the protection!

If Gao you are using genuine original disk, may be due to your floppy disk drive has been damaged or unstable soil, you can try the installation again, or return the disc to the line we mention Luo repair.

If you are using a pirated Gao disk, so please respect the intellectual mess produced Zhao, thank cooperation!

robertmo wrote:

Letters ... thank cooperation!

Thanks for the translation. Is there any way to load a different BIOS into DOSBox? Looks like this program works better with qemu BIOS than DOSBox BIOS.

Checksums of BIOS ROM (0xf000), video ROM segment (0xc000), and the MBR, are used as decryption keys for the data in the overlay. The data are decrypted and unpacked. Bad decryption causing bad unpacking and a system hang.
Presumably the data are encrypted during the installation using those keys, thus preventing the file from being copied to another system.

peterferrie wrote:

Checksums of BIOS ROM (0xf000), video ROM segment (0xc000), and the MBR, are used as decryption keys for the data in the overlay. The data are decrypted and unpacked. Bad decryption causing bad unpacking and a system hang.
Presumably the data are encrypted during the installation using those keys, thus preventing the file from being copied to another system.

Thanks for the analyzation. I cannot run just after a finished installation which is strange. I have two installed version one from 2007 and one from some days ago. The only differences are:

byte 0x12-0x13: 00 00 / ff ff
byte 0x18bfb-0x18c00: fa f9 7a 1e 98 fe / 8a a3 10 83 d6 01

Everything else is identical.

I got it to install and run under VirtualPC, so when I get some time, I'll do a side-by-side comparison to work out where the problem is.
At least we're getting closer. :-)

peterferrie wrote:

I got it to install and run under VirtualPC, so when I get some time, I'll do a side-by-side comparison to work out where the problem is.
At least we're getting closer. :-)

Amazing! Good news indeed. :-)

Got it. I've uploaded a patch to my site (pferrie.host22.com).
The problem was that the Crazy Bomber installer and the game both read the MBR via int 13, and DOSBox does not return anything valid, so whatever was in memory is used for the checksum. The memory contents are different between the two, so the checksum never matches, even immediately after installing.
The patch deals with that by zeroing the buffer so it's the same in both cases.

peterferrie wrote:

Got it. I've uploaded a patch to my site (pferrie.host22.com).
The problem was that the Crazy Bomber installer and the game both read the MBR via int 13, and DOSBox does not return anything valid, so whatever was in memory is used for the checksum. The memory contents are different between the two, so the checksum never matches, even immediately after installing.
The patch deals with that by zeroing the buffer so it's the same in both cases.

Amazing. Thank you very much! So when we played some years ago with emulation speed and finally the EXE runs that was just accidentally.

If I read ASM source correctly I need to run your patch because your patch installs the new interrupt handler and then runs main executable.