neoIP - A new way to generate an IP.BIN without ECHELON or binhack....

Hey everyone!
We have been working on a project recently in order to gain an understanding and have some new kind of fun on the DC.

it started as ip_cracktro which was written as a framework for making intros and cracktros without tampering with 1ST_READ.BINS and such. The project has grown up a little and now we have neoIP a more stable, more feature-filled, wholly new way of making IP.BINS.

This is a public preview of v0.01 before we clean it all up and release the source to the community.
Windows and Linux binaries included.

Edit: almost everything demoing this has been using Crazy Taxi, but it will (should) work with anything. It definitely works with KOS compiled homebrew either scrambled or unscrambled. It's just convenient to test with crazy taxi because it's a commercial game around 100mb and takes a split second to generate a CDI or GDI image.

2nd edit:

• Features planned/being worked on for immediate release
  • General clean up
  • Fixing 1 specific issue (missed a "!" Somewhere)
  • Adding stealth
  • Reworking menu text, make it less "hacker" looking
  • Add support for adding codes without recompiling
    • Add basic menu for toggling these

Thankfully most of those are fairly short and easy, source will probably be released at completion of those, that will at least be the start of a configurable community IP.BIN. timeframe depends on how busy my coursework keeps me.

• Possible future features
  • Automatic GDI/CDI differentiation
  • Loading cheats/patches from VMU
    • Updating patcher core from VMU
    • Software to generate these from the dreamcast itself
  • Runtime gameshark like functionality
  • Ability to add little logos to the license screen
• Software to insert/patch this into existing cdi/gdi without rebuilding the entire image

I'll be working on this and gradually updating this post with info/changes. Please keep suggesting/criticizing the project everyone has come up with so many great ideas that I've never thought of.

 

Previous demonstration.

 

i think something like this could be useful for patching Rez and one of its betas to run in debug mode without needing to use an action replay on hardware, looking forward to trying it.

 

Can you expand on that?

 

Rez and one of the two betas we have don't run in debug mode by default but you can force it by setting a byte with an action replay code, considering you can use this to apply widescreen patches i figure it could probably be used to patch rez to enable the debug without needing to use code discs before running it

 

How did you find the location in both binaries of the memory address? I read the Rez hacking thread, and then disassembled the binary but there's a ton of references to that memory location. How did you come to find the location that ORd with 0x00c000 to find that C5 enables debug

 

Also I can see 12 people downloaded this, has anyone used it? Did it work for you?

Also don't despair in the next version the menu will be toned down, made optional and have new features as well. (Still theorizing on how to implement a mini-gameshark)

 

i haven't as of yet, but since i know what needs to be set for debug to be enabled in memory (c5 is one method, but there's another byte that can be set to 01 for it i think) it should be a good learning experience for me to figure out how to make a patch for it.

Edit: though i see someone already made a patch for the final version today. huh. should make it even easier to find for beta 899 too.

 

code for beta 899 found?

 

So I have been researching and thinking and I believe there is going to be 2 easy ways to implement gameshark functionality

1. Ripping apart the sylverant patcher and keeping only things relevant to patching memory and hooking gd-rom syscalls
2. Hooking certain interrupts and then doing patching things during the interrupt handler (seems a little more voodoo magic, might be better in the end though)

I have simple 1 time binary patching working. It's really simple and I could probably write a utility so people could insert codes into the IP.bin, but that isn't much more useful than patching the binary, but it does look cleaner

 

it is the fine tool for creation of images with dualboot, 4:3 and 16:9

 

Wow! What a good idea, I had not thought of that. I'll put on hold the idea of remaking a tiny gameshark.

I can probably whip up a short menu that people can choose which patches to enable, and a companion utility to insert patches into the IP.BIN

 

It could even be baked in GDIs for convenience with ODE/DS. A minimalistic menu at boot or button combo would be fine in my book.

 

I'm not sure how to make a GDI, but if you use this and choose "boot raw" it should work (maybe?). I haven't tested it.

If you drop some info on how to make a GDI I can do some testing on it.

Your dream from Nov 2015 might be coming true

 

A much better idea would be to just patch the the first 16 sectors/32kb in the track03.bin/track03.iso file. No need to rebuild the whole GDI.

But if you wanted to do so you could use GDIBuilder: http://projects.sappharad.com/tools/gdibuilder.html

 

I downloaded it for archival purposes but in its current state I don't see a whole lot of use for it. Its very very promising though, especially to implement your own trainers (gameshark/codebreaker "built in"). It also isn't available for my platform, so I'm waiting for the source release because I'm too lazy to spin up a VM.

 

That's exactly what I had in mind.

@Mrneo240
Use gdishrink from my GDItools to create a 2048 bytes/sector GDI dump. Then the ip.bin is the first 32kB of the track03.iso. You should not put the mil-cd exploit in it though, just hook your routine, a GDI is just like a retail GD-ROM.

Do you plan on open-sourcing it and putting it up on GitHub?

 

Gotcha, for now I'll add a less friendly version and instructions for what the generator does. (It's really simple, I'll throw in the source for it too)

Basically just writing a file into the IP.BIN and then writing the size of the 1st_read.bin to a specific offset.

I didn't mean to exclude anyone/platform

 

True, at the moment it's not very useful but it's a start. At this point there isn't an overwhelming reason to use it at all, but hopefully in the coming days it will be made useful (I'm thinking hidden by default and just boots, but hold 'x' brings up a menu with patches and options)

So if you're curious, here's the basic instructions: copy the file boot1.bin to offset 0x3800 in an original IP.BIN, filesize encoded as a 32bit goes in offset 0x4c3c-0x4c3f.

Included: boot1.bin, patcher program source (neoip.c and boot.h). Boot1.h was made with bin2c. Should be compileable with gcc and msvc.

 

Is the memory/bootbin patching already implemented? I can't test right now but I plan to.

Note, for patching a gdi, you wouldn't want to apply the gd-reset and scrambling routine with bootbin filesize, so maybe keep that in mind in your implementation if you want it to be easy to adapt to GDIs.

Good job BTW, don't take anything we say here as criticism, we are excited about the possibilities of the tool that's all!