Publishing games.

Trev · Post by **Trev** » Fri Jul 11, 2008 2:35 am

Call me a stubborn optimist but I believe finished or nearly finished versions of the folowing games actually exist : Waterworld , NHL '96 , Wing 4 , MK3 , Golden Gate . Anyone think or know of others ?

Isis is almost a sure bet.

Maybe Descent too ...

mattyg · Post by **mattyg** » Fri Jul 11, 2008 11:15 am

..................and Madison High , McKenzie & Co ! oops did I really mention those

Post by **3DOKid** » Fri Jul 11, 2008 1:44 pm

What are they?

BryWI · Post by **BryWI** » Fri Jul 11, 2008 2:35 pm

Mobius wrote:Hmm... It looks like it's just using the BannerScreen file from Game Guru. I'm not finding any other GG files in there. Maybe there's something in the LaunchMe, though. I will keep digging.

Any luck?

Trev · Post by **Trev** » Fri Jul 11, 2008 5:19 pm

Madison High , McKenzie & Co

What are they?

Part of ALG's line of games for girls ... I know atleast one of them landed on the pc.

Personally, I would have rather had Saturncide. Remember that one? Had screenshots & advertisements floating around back in the day.

Add in Orbattack and it seems that ALG had a good number of scrapped 3DO games. Wasn't there also another gun game too ... fast draw showdown or something?

mattyg · Post by **mattyg** » Fri Jul 11, 2008 10:46 pm

mckenzie & co did make it to pc. As Trev says it was part of ALG's games for her division. It was such a diversion from their norm that some magazines still had it listed as a coming soon shooter ! It was essentially a fmv based "adventure" where you got to choose such wonderfully mundane things as what to wear and which boy to date - I kid you not! As perhaps a sign of things to come (the sims , NDS fashion designer etc) it was actually a minor hit on pc and actually spawned an expansion disc that follwed our young heroine into college. The 3do version was being coded alongside the pc version and had the same release date. Knowing ALG this game probably did exist and may able to be reverse engineered from the pc version.Apparently the original pc game turns up every now and then but the expansion is considered reasonably rare and has some value. Not my cup of tea but does fit in with Trips overall vision and an interesting curio.

Mobius · Post by **Mobius** » Fri Jul 11, 2008 11:02 pm

BryWI wrote:
Mobius wrote:Hmm... It looks like it's just using the BannerScreen file from Game Guru. I'm not finding any other GG files in there. Maybe there's something in the LaunchMe, though. I will keep digging.
Any luck?

Possibly. I'll probably have some sort of update in the next couple of weeks.

Post by **3DOKid** » Sat Jul 12, 2008 6:41 am

When I queried about encryption I was told to use this by one source:

"OperaFS[De]Compiler.exe"

Some parts of the menu are in Russian, and since I didn't have Russian language support installed on my PC it couldn't even ask someone what the menu options meant. (All the words came up as ?????????, which doesn't help)

The program is here with some other stuff here:

http://altmer.arts-union.ru/3DO/3do_utils.htm

Russian speakers, your help is needed

mattyg · Post by **mattyg** » Sat Jul 12, 2008 8:51 am

don't you have the orbatak proto 3do kid? Could it be reverse engineered?The pathways/routines requiring coins to start/continue could be changed in theory thus making it a vaiable game release YOU COULD BE RICH!!

Post by **3DO Experience** » Sat Jul 12, 2008 1:29 pm

I have the Orbatak proto too, as well as artwork that was given too arcade owners. To play this you would most likely need the 3DO Mouse as the set up required trackballs. If it works with the mouse on a test unit is something I can't test. (need a test unit)

mattyg · Post by **mattyg** » Sun Jul 13, 2008 11:46 pm

We might be actually getting somewhere with this. I didnt realise orbatek was a track ball game - it should be possible to butcher a mouse and rebuild it inverted in a zippy box or similar to simulate a track ball. If there is any one with a working test station and someone made a cdr copy of the proto of orbatek ..................maybeeeeeeeeeeeeeee it just might work. The sub routines governing coin play should be rudimentry its just that bloody encryption!

cdoty · Post by **cdoty** » Thu Jul 17, 2008 6:04 am

Mobius wrote: Hmm, so he's in this for a profit... I wonder if anything could change his mind. Or if he really wants money, if he'd be willing to sell the know-how for encrypting discs.

That's what I tried to get him to sell, but he seemed to think it was too complex for other people to use his 'method'.

Post by **3DO Experience** » Fri Jul 18, 2008 2:43 am

His site is gone now. Or maybe just down for a bit.

cdoty · Post by **cdoty** » Fri Jul 18, 2008 9:43 pm

3DO Experience wrote:His site is gone now. Or maybe just down for a bit.

It's up, and contains something that might be useful:
http://thdo-homebrew.narod.ru/HB_programming.htm

There's a disk, with 3DO sdk programs, that will boot on any 3DO player.

Gir Draxa · Post by **Gir Draxa** » Fri Jul 18, 2008 11:41 pm

I'm thinking the encryption is done matting one CD image over another. A friend and I monkeyed with that idea using the 3DO Memory Manager from the memory unit to some (limited) success (title screen pops up) but ran out of time and desire to do it. Since the image file for the Guru is equally small, I can see how he'd want to work with it.

Using UltraEdit32 we were trying to re-target the avatars for the various menus. We using a similar concept as I mentioned years back on the Freedo forum about language editing. Once we got down the right spot to paste in the new pieces of image file, the rest we thought would be simple, but something just seemed to be failing once we got past the load screen popup for Golden Gate.

I'm sure it'd work, it's just taking the time to figure out what we were missing from our works, and right now.. if I had that much time, I'd get the Collective back up and running (still want to btw, TIME is a very precious commodity at the moment... soon.

).

Also, as to the Russian gentleman, we contacted him last year about encrypting a couple of our betas. He wasn't so interested in money as he was in where we got them. No mention of cash was ever made though.

Any help I may offer, I can pass on.

Drax

Gir Draxa · Post by **Gir Draxa** » Sat Jul 19, 2008 12:03 am

Oh, and ORBATAK needs to have it's user input redone. Its searching for the JAMMA interface (coin input, 1up, 2up, as well as the controllers). The game itself runs well, but only on an arcade enabled 3do and arcade hardware (or Supernova hardware) or version 1.7? of Freedo. Freedo doesn't support the JAMMA input

, but you can see the game run in demo mode.

In theory, you could probably strip the files off the CD, making changes to set it to freeplay mode and such, then use the tools the Russian gentleman provided to build a basic image again. Messed around with the overly simple control input setup and some images in SHADOW: War of Succession, and built a cd image, but the cd only worked on Freedo, not my testers unit.

Drax

cdoty · Post by **cdoty** » Sat Jul 19, 2008 3:53 am

Gir Draxa wrote:I'm thinking the encryption is done matting one CD image over another. A friend and I monkeyed with that idea using the 3DO Memory Manager from the memory unit to some (limited) success (title screen pops up) but ran out of time and desire to do it. Since the image file for the Guru is equally small, I can see how he'd want to work with it.

I wonder if it's the signature file in the image?

I did some hex editing on an image, and it would still boot. So, either a portion of the image is actually checked, or different parts are checked each time. (I think the Jaguar does something similar, and only checks a small part of the cartridge each time.)

I'd like to find a way get OperaFS [De]Compiler to rebuild an iso. That would be a decent starting point.

There was a discussion a while ago on rec.games.video.3do, mentioning the signature file:

Oh yeah, all of the disks that I've looked at have a file named "signatures".
They're all 0x52000 bytes long and they're not identical. I haven't figured
out what they are just yet, but I'll keep looking.

I've found out a little more about the "signature" files. The number of
non-zero entries in the file is the same as the number of used blocks on
the disc. Maybe this is a CRC or some other code used for error checking.

That would equate to a 656 MB CD-Rom, which is pretty close to the 72 min limit.

cdoty · Post by **cdoty** » Sat Jul 19, 2008 4:11 am

Gir Draxa wrote:In theory, you could probably strip the files off the CD, making changes to set it to freeplay mode and such, then use the tools the Russian gentleman provided to build a basic image again. Messed around with the overly simple control input setup and some images in SHADOW: War of Succession, and built a cd image, but the cd only worked on Freedo, not my testers unit.

Can you explain how you did this, and what tools you used?

I couldn't get Opera[De]Compiler tools to rebuild an image.

What version of windows were you using? I've only tried Windows XP.

Gir Draxa · Post by **Gir Draxa** » Sat Jul 19, 2008 6:31 am

Well, to 'rebuild' an image from stuff you may have extracted from a 3DO CD is very simple. There are only two buttons on the front of OperaFS[de]Complier. Click the one on the right, it probably says "??????ISO" if you don't have Russian Language Support. Choose the folder you want to turn into an ISO, double click the folder so it opens, but keep the name highlighted. A new screen will open and you can name your ISO and choose it's location.

Once it's done, boot it as an ISO in FREEDO WIP 1.7.

btw, anyone know of a way to convert to and from 3DO ANIM files on a XP PC? I know a couple games with rather open architecture that could be given new life with just some new graphics.

Drax

Gir Draxa · Post by **Gir Draxa** » Sat Jul 19, 2008 6:33 am

Oh, and cdoty, if you hex edit an image, remember to use a prog like ULTRAEDIT32. Others try to convert the image in some fashion, and even one byte out of place and the disc is toast.

Drax

cdoty · Post by **cdoty** » Sat Jul 19, 2008 8:38 am

Gir Draxa wrote:Oh, and cdoty, if you hex edit an image, remember to use a prog like ULTRAEDIT32. Others try to convert the image in some fashion, and even one byte out of place and the disc is toast.

I'm wondering if this is true. Maybe I was editing a second or third copy. Another part could be that only one instance of the data is changed, there appears to be at least two copies of the data on the Game Guru disk.

Maybe only the BannerScreen and system files are encrypted. It is always located at 0x71800 in the iso image (even for a normal 3d0 release).

As a test, I went through and changed "Guru" to "Mumu" on the Game Guru iso, and it still boots, and shows "Use the Game Mumu Code Library" on the initial screen. The only "Guru" i didn't change were the GameGuru.cfg parts.

The interesting part is to see if the compression is based on the sector number. This should be easy to verify.

And, after that, I changed all "Mark" to "Work", including "Marked" to "Worked". The image still booted, using Freedo and an FZ bios from 1999.

I moved to the Homebrew CD, searching for (c) (non-case sensitive), I changed the data to 2008. In one case it was already 2008, so I changed it to 2007. The CD still boots.

In addition, I changed Homebrew to Gnomenew, and it still boots.

Changing one byte in the BannerScreen file causes it to not boot . (Search for 'APPSCRN' in the iso).

It would make sense that the entire cd isn't encrypted, or the signature file couldn't be inserted without messing up the encryption values.

cdoty · Post by **cdoty** » Sat Jul 19, 2008 8:53 am

The homebrew iso contains some source code. Look at 0xbf9f84 in the iso image.....

cdoty · Post by **cdoty** » Sat Jul 19, 2008 5:31 pm

The signature file has no effect on the booting. I completely zero'd out the 0x52000 bytes, and it still worked. I did this on the homebrew iso and On Side soccer.

It would appear as if very little is actually encrypted. I removed minmem for the AppStart script, and changed text in launchme, and it still boots. The BannerScreen is encrypted, somewhere. One byte changed causes the boot to fail. It's more than a simple CRC encryption.

There is a location at 0x800-0x9c0 that has to contain valid data. It appears to be Directory headers. It contains the rom_tags. Here's a description of the Opera FS structures:

-== File system description ==-

Volume header record of a 3DO CD:
0x00 - 0x00 1 u8 Record type (always 1)
0x01 - 0x05 5 u8 Synchronisation bytes (always 0x5A) (padding?)
0x06 - 0x06 1 u8 Record version (always 1)
0x07 - 0x07 1 u8 volume flags (details unknown)
0x08 - 0x27 32 u8 volume comment
0x27 - 0x47 32 u8 volume label
0x48 - 0x4b 4 u32 volume identifier
0x4c - 0x4f 4 u32 block size (always 2048?)
0x50 - 0x53 4 u32 block count (total number of blocks on the disk)

0x54 - 0x57 4 u32 directory identifier for the root dir
0x58 - 0x5b 4 u32 number of blocks in the root dir
0x5c - 0x5f 4 u32 block size for the root dir
(always the same as volume block size?)
0x60 - 0x63 4 u32 last copy of the root dir (#copies - 1, always (?) 7)
0x64 - 0x83 32 u32 locations of the copies, in blocks, counted from the
beginning of the disk

A directory block begins with a directory header, followed by zero or more
directory entries. A directory may take multiple blocks.
A directory entry is never split over multiple blocks; if a block does not
have enough space for a complete entry, it can be partially unused.

Directory header:
0x00 - 0x03 4 s32? Next block in this directory, 0xffffffff if this is the
last block.
Offset in blocks from the first block in the dir?
(if this is true, it can't be -1, as that is 0xfffffff)
0x04 - 0x07 4 s32? Previous block in this directory, 0xfffffff if this is
the first block.
Offset in blocks from the first block in the dir?
0x08 - 0x0b 4 u32 flags (details unknown)
0x0c - 0x0f 4 u32 offset from the beginning of the block to the first
unused byte in the block
0x10 - 0x13 4 u32 offset from the beginning of the block to the first
directory entry in this block (always (?) 0x14)

Directory entry:
0x00 - 0x03 4 u32 flags
The least significant byte seems to be
0x02 - File
0x06 - Special file
0x07 - Directory
This is OR'ed with (one or more of):
0x40000000 - this is the last dir entry in the block
0x80000000 - this is the last dir entry of the dir
0x04 - 0x07 4 u32 identifier
0x08 - 0x0b 4 u8 entry type
"*dir" - directory
"*lbl" - label (points to volume header)
"*zap" - catapult (fast startup information)
something else - file. Seems to be the last 4 letters
of the extension, right padded with spaces if less.
Sometimes the case is retained, sometimes it is
converted to lowercase.
0x0c - 0x0f 4 u32 block size (always the same as volume block size?)
0x10 - 0x13 4 u32 length of entry in bytes
0x14 - 0x17 4 u32 length of entry in blocks
0x19 - 0x1b 4 u32 burst (function unknown)
0x1c - 0x1f 4 u32 gap (function unknown)
0x20 - 0x3f 32 u8 File name, padded with '\0'. Not sure whether it's
always \0-terminated.
0x40 - 0x43 4 u32 number of the last copy of the entry (#copies - 1)
0x43 - 4*n u32 offset to the copies, from the beginning of the disk,
in blocks.

cdoty · Post by **cdoty** » Sun Jul 20, 2008 8:00 pm

Gir Draxa wrote:Well, to 'rebuild' an image from stuff you may have extracted from a 3DO CD is very simple. There are only two buttons on the front of OperaFS[de]Complier. Click the one on the right, it probably says "??????ISO" if you don't have Russian Language Support. Choose the folder you want to turn into an ISO, double click the folder so it opens, but keep the name highlighted. A new screen will open and you can name your ISO and choose it's location.

Which version of Windows are you using?

How big is the created ISO?

Does it normally take a long time to do?

I tried rebuilding the Homebrew ISO, and it continues to do something for about 5 minutes, until I terminate the process. The resulting ISO is 130 MB, whereas the original ISO is about 36 MB.

Could you do a capture of the settings you use for extracting files from an ISO, and for re-building the ISO?

Also, can you tell me what the ?????? ?? (SPY) button is used for. It dumps out some .spy files, but what do they contain information about?

The Homebrew disk contains some utilities that are not on other disks. There is BANGON, which dumps a bunch of information to the debug.fz10.mes file.

I couldn't get CERTIFY to work. From the text in the file, it appears to be the same type of program as BANGON, maybe from an older SDK or something.

BANGON appears to be a hardware test, rather than a encryption verification program.

Mobius · Post by **Mobius** » Mon Jul 21, 2008 4:18 pm

cdoty wrote:
3DO Experience wrote:His site is gone now. Or maybe just down for a bit.
It's up, and contains something that might be useful:
http://thdo-homebrew.narod.ru/HB_programming.htm

There's a disk, with 3DO sdk programs, that will boot on any 3DO player.

Hmm... I had e-mailed him an ISO with one of the SDK programs to have it encrypted. I was hoping to do a before/after comparison of the unencrypted and encrypted images. Then he just goes and releases the whole set instead. Damn.

cdoty · Post by **cdoty** » Mon Jul 21, 2008 4:19 pm

I wonder if the Lynx encryption shares anything with the 3DO encryption. Both systems were partly designed by RJ Mical.

I asked about the Lynx encryption on AtariAge, and got the following answer (Thanks to Karri):

It is standard RSA encryption. The formula is:

PLAINTEXT = (ENCRYPTED ^ 3) % PUBLIC_KEY

The public key is
static unsigned char N[MAX_m] = {
0x35, 0xB5, 0xA3, 0x94, 0x28, 0x06, 0xD8, 0xA2,
0x26, 0x95, 0xD7, 0x71, 0xB2, 0x3C, 0xFD, 0x56,
0x1C, 0x4A, 0x19, 0xB6, 0xA3, 0xB0, 0x26, 0x00,
0x36, 0x5A, 0x30, 0x6E, 0x3C, 0x4D, 0x63, 0x38,
0x1B, 0xD4, 0x1C, 0x13, 0x64, 0x89, 0x36, 0x4C,
0xF2, 0xBA, 0x2A, 0x58, 0xF4, 0xFE, 0xE1, 0xFD,
0xAC, 0x7E, 0x79
};

You decrypt the data in 51 byte chunks.

So basically you take 51 bytes and treat it as a very large number and raise it to the power of 3. Then divide it by the 51 byte very large public key and the modulo of this division is the plain text (51 bytes).

After that you take the next 51 bytes and repeat this procedure until the whole binary has been decrypted.

The private key for doing the encryption is not known in plain text. It was encrypted by another RSA key which means that it existed only for a brief time in the Amiga RAM during the encryption process.

I did find RJ's site (http://www.mical.org/), I wonder if he would be willing to share any information on the encryption.

Gir Draxa · Post by **Gir Draxa** » Mon Jul 21, 2008 7:14 pm

Greetings,

Sorry for the breaks in my replies, but time is a commodity anymore that I just am in short supply of. Here's the answers I have from here at work :

"Which version of Windows are you using?"
XP Pro

"How big is the created ISO?"
Slightly larger than the collected amount of the files. My rips Shadow and Game Guru turned into slightly smaller ISOs than one made direct from the disc.

"Does it normally take a long time to do?"
Depends on the amount of files to recompress into the iso. Shadow took about 45 secs-1min, Guru was done in a heartbeat.

"I tried rebuilding the Homebrew ISO, and it continues to do something for about 5 minutes, until I terminate the process. The resulting ISO is 130 MB, whereas the original ISO is about 36 MB."

Thats very odd. I wonder what could be the issue. I've tried it on 3 machines, XP pro & 2 XP home with no probs. No recompiling has taken more than 4-5 minutes, even Killing time.

"Could you do a capture of the settings you use for extracting files from an ISO, and for re-building the ISO?"
Sure. I'll try to do that this week for you.

"Also, can you tell me what the ?????? ?? (SPY) button is used for. It dumps out some .spy files, but what do they contain information about?"

I will have to check my notes at home. I haven't monkeyed with that option much lately.

Drax

Windows Killer · Post by **Windows Killer** » Mon Jul 21, 2008 7:18 pm

Haven't read all the posts, but yes, only the boot files are encrypted, or rather, hashed. And don't use FreeDO to test modified images, because FreeDO doesn't care about valid encryption anyway. It can boot unencrypted games without even the need for a special bios (which is the key point, as afaik, the bios just reads the signatures and refuses to boot the disc if they don't match. FreeDO seems to patch that part of the bios.)

cdoty · Post by **cdoty** » Mon Jul 21, 2008 8:47 pm

Gir Draxa wrote:Thats very odd. I wonder what could be the issue. I've tried it on 3 machines, XP pro & 2 XP home with no probs.

I got it to work. It works, if I extract the image, and rebuild it before exiting the program.

WindowsKiller wrote:Haven't read all the posts, but yes, only the boot files are encrypted, or rather, hashed. And don't use FreeDO to test modified images, because FreeDO doesn't care about valid encryption anyway. It can boot unencrypted games without even the need for a special bios (which is the key point, as afaik, the bios just reads the signatures and refuses to boot the disc if they don't match. FreeDO seems to patch that part of the bios.)

Have you figured out how the files are hashed yet?

Was that with FreeDO 1.7? Have you tested with 1.9?

Gir Draxa · Post by **Gir Draxa** » Mon Jul 21, 2008 8:49 pm

Very true Windows Killer. But we're not testing for encryption, we're first using it to test to see if the image we rebuild works. If so, then on to the encryption we go. Since I only have the original betas of the games OG turned bootable, I'm not quite sure how they beat the boot problem.

I'm still assuming the image overlay is how it was done, hence why everyone wonders why the Game Guru logo pops up. I think a simple compare between the beta and the original would yield the some of results we need.

Sadly, while I thought I had pre-ordered the games long ago, that never came to fruition.

How I got left out is going to be a heavy mystery to me for a while.

Drax