sanyo mbc 550 michtron copy protection removal help

[digress]

ok, so if this is inappropriate please say so but the software is 34-35 years old now and I really think it's time it was cracked for archival purposes and emulation use. I'm afraid the disks are going to go bad any day now. surprised they still work.

so they games I have which are all original require the original keydisk inserted before the game/program will run. I found you could occasionally use another disk as the keydisk as it was checking for bad sectors I assume.

anyways i have dumped images on my site of them. If someone with some knowledge of cracking wanted to help. There is a sanyo emulator that partially works under mess that can run the images.

http://eriscreations.com/index.php/sanyo-mbc-550-vintage-computer-fan-site/sanyo-disk-images/

time bandit
thunder chief
mud pies
major motion

 

[SomeGuy]

You only dumped them with Teledisk? For full preservation you should dump them with a Kryoflux or SuperCard Pro, or send the disks to someone who can archive them (and possibly create functional backups) for you. These tools can archive almost all protection methods, and emulators have popped up that can even deal with crazy stuff like laser hole protection.

The mbc 550 isn't fully IBM compatible, but for IBM PC titles, the PCE emulator can run many heavily protected titles "as is".

 

[digress]

Thanks. I heard of the kryoflux but not the supercard pro. I think I might pick up one of them and see if that will do the trick.

You only dumped them with Teledisk? For full preservation you should dump them with a Kryoflux or SuperCard Pro, or send the disks to someone who can archive them (and possibly create functional backups) for you. These tools can archive almost all protection methods, and emulators have popped up that can even deal with crazy stuff like laser hole protection.

The mbc 550 isn't fully IBM compatible, but for IBM PC titles, the PCE emulator can run many heavily protected titles "as is".

 

[JohnElliott]

I haven't tried this, but for Time Bandit at least, I think the protection check is called by the byte sequence E8 DA 05 72 FB on cylinder 11 head 0 sector 1 of the disk image. Replacing the five bytes with 90 90 90 90 90 may bypass it. If the protection is the same on all disks, then a similar sequence E8 xx xx 72 FB may also be present on other titles.

Time Bandit behaves more like a booter than a well-behaved executable, so it's very unlikely that it'll work on non-Sanyo hardware. The first thing it does is blank the interrupt table (except for INT FB, the keyboard interrup, which it hooks). It then copies itself to 0040:0000, and it reads / writes disk sectors by bit-banging the WD1793 directly.

I haven't looked very closely at what form the protection takes, but track 1 of BANDIT.TD0 has only three sectors (numbered 0x01, 0x43, 0x02) of size 256, 128 and 1024 respectively, so I'm guessing that's what the protection code is accessing.

 

[JohnElliott]

I had another look at the protection code, and searching for the sequence B2 02 B9 03 00 80 F2 03 and replacing the first two bytes by EB 13 should bypass it. But the resulting EXE still didn't seem to work on MAME - the problem may be some other part of the emulation rather than the copy protection code.

I was able to locate the data for the sprite graphics, and extract them. They start at offset 3120 in the file, and each graphic is 192 bytes long, consisting of 3 mono bitmaps for the three planes. A bitmap is 32x16 pixels, stored in a 4x4 array of tiles that are 8 pixels wide and 4 high.

 

[seat safety switch]

I didn't have much luck with the TeleDisk images – they seemed to lock up MAME and a lot of other tools that I pointed at it, even after converting to HFE or another format.

Those tiles make sense as the 6845 has a weird way of drawing characters - they draw four pixels high at a row.

I loaded a bare BANDIT.EXE (provided by Rick Companje) into Ghidra a few months ago and got started reverse-engineering the crack, also using MAME as an emulator, although my notes aren't great. I ended up painting myself into a corner and probably should back up and try again...

After skipping over a lot of bad sector checks (checking the FDC for error bits,) I thought I was done. The most recent thing I tried to patch was a chunk (around offset $95c6) where the executable seems to be loading chunks of sectors into memory and searching them, but obviously with just the bare EXE on a new disk image I'm not going to have much luck doing that, as my disk will look totally different.

Rick Companje's "DEBUG" jump script for it skips right over this code (by breaking at $8ee8 and then jumping to $8ef3), as well as a lot of other setup code, so while the game's attract mode is running fine in MAME the keyboard isn't set up so you can't play it, and something seems off with the graphics bitplane alignment which could be a MAME bug. I've attached a picture of it running in MAME.



Ideally it would be nice to have an original disk, and make a flux-level backup with a Greaseweazle or similar.