Changing the Size of a .ODD File

One of the highlights of using a Macintosh is the way files are stored on them. A file on a Mac is actually two files, one called the "data" fork (what we're used to using on Windows) and a "resource" fork, which is extremely easy to edit and is where Oddballz stores its data for that platform. Unfortunately, we've got to dig through a hex editor on Windows (or use Eggz Scrambler, which is admittedly not the greatest approach to the task). Resources on the Mac can be any size and can change size. On Windows, if we run out of space while making a breed, we're stuck. Right? Wrong! I'll show you how to make a breed with as much data as you want in it.


	I warn you ahead of time that this is not not not for those new to hexing to try. It's a lot of work pushing numbers, and can be quite aggravating. There is also the potential to seriously damage Oddballz. And there is also the fact that we are reverse-engineering Oddballz. Although Ubi Soft isn't likely to do something about it, keep it in mind that we are very clearly over the fence here.

First! Foremost! Some more one-word sentences, then I'll tell you a bit of background about .ODD files. They're .EXE files, like Oddballz itself (or nearly any other Windows program.) Way back when Oddballz came out, Windows 95 was still new, and most people were still using Windows 3.1. Seeing as the body of their market used Windows 3.1, they wrote Oddballz to run on it. Why does this matter? Because Windows 3.1 programs (called "New Executable" programs because they weren't made for the older Windows 1.0) are not the same on the inside as Windows 95/98/Me/NT/2K/XP programs (called "Portable Executable" programs.) They're very squeezed together, no breathing room at all, so you'll have to be careful when doing this. One wrong byte and you could crash your computer. It's hard to find a program that can do all this for you manually, because the format is so old.


	For this tutorial, we'll be using Grinnz, because it's the breed I tested this all out on. I'm assuming you already know how to edit a breed, how to use a hex editor, and how to cut and paste data. It's best if you do your editing before you do this procedure, so you'll know how long you need to make it. Where I use "&D1000" or some such, I mean "1000 in base 10" instead of in base 16, which is what many of the numbers here are. When I use &H in front of a number, it means it's specifically hexadecimal.

First, make sure you have eXeScope installed. Open GRINNZ.ODD in it and find out the numbers of the resources you've made longer (if you haven't made a resource longer, don't worry about it.) Write this down. Then close eXeScope and reopen GRINNZ.ODD in a hexadecimal editor. Even though we're overcoming one of the obstacles of such a program, we still have to use such a program, because we're still crunching numbers. You should see something like the following (all the numbers I hand you will be in hexadecimal - Base 16 - format, so you may need to convert them to regular Base 10):

If this doesn't look like this (it may not be exactly identical) then you're probably not working with an Oddballz egg. Otherwise, skip it. Start at the "PE" directly under it. And remember the offset, &H90, because that will be needed later. &H24 bytes from that will be the first of a set of numbers we'll need, because it (plus the PE's offset, &H90) is where the Resource Table begins. It's a 2-byte-long WORD format - to get the needed number out of it, multiply the value of the second byte by &D256 and add it to the first byte.

Now we're at location &HE0 in the file, and it looks rather barren. But believe it or not, this next stretch holds the key to changing the size of the file. It's arranged as follows:

This is the point where we go back to the data we got in eXeScope. You'll find the resources' type numbers in their IDs (as you collected them.) The resources' ID numbers (usually 1) will be the 8th and 9th bytes in the corresponding &D12-byte-long chunks we picked up (if it's the first resource of type Foo, it'll be the first &D12-byte strip in Foo's definition.) I don't show chunks of hexadecimal code here, because it all looks indecipherable and differs between breed. Also in that strip, pick up the offset (1st and 2nd bytes) and the length (3rd and 4th bytes).

Turn the alignment multiplier into a power of 2. For instance, if the multiplier is 9, you'd use 2⁹ (which is &D512.) Then, multiply the offsets and the lengths you wrote down by the number you got. This will give you the locations of the resources, starting from the beginning of the file. Notice that the number will (most likely) be a multiple of &D512. The new resource must have a length rounded up to the nearest multiple of &D512. If it's &D1025 bytes, you'll have to tack on &D511 null bytes (&H00) to the end. Now, go to select the original resource, including the null bytes that may act as filler to make it long enough, and paste this on top of it, so everything after is pushed down.

You'll have to manually go through and change all the resources to reflect the fact that they're &D512 bytes farther down. This will be done by adding 1 (remember that the much larger number came out of multiplying it by &D512) to the offsets of every resource after it. Don't forget to add 1 to the length WORD in the Resource Table. If you miss any of this, it's quite likely that Oddballz will crash.

And guess what? You're done. If you change a few more offsets, then it will work as an executable, but because you've left some alone, it probably won't open. But rest assured that Oddballz can still read it, because it only works with the parts of the file that I just showed you.