What's new
By:
Filters

Netboot SRAM backup/restore - AKA Save High Scores and Settings!

Finisterre said:
Uhhh yeah I think you guys wanna look at this
Click to expand...
This isn't new information. What do you think you have found? As MetalliC noted, accessing sram on naomi mobo is straight forward
 
brizzo said:
Finisterre said:
Uhhh yeah I think you guys wanna look at this
Click to expand...
This isn't new information. What do you think you have found? As MetalliC noted, accessing sram on naomi mobo is straight forward
Click to expand...
forgive me, I wasn't aware of people doing it remotely via a vxworks vulnerability in WDB, I know several subsystems are running vxworks as well this may not be all that it is limited to accessing.
 
MetalliC said:
nice
you get not NAOMI RAM dump, but DIMM board RAM, it is separate device running VxWorks.
but good work anyway!
Click to expand...
I wonder if we tried the same thing over the fiber optic interface on the "communications board" what would happen? Anyway, sorry if this was already known!
 
Finisterre said:
I wonder if we tried the same thing over the fiber optic interface on the "communications board" what would happen?
Click to expand...
optic comm board is quite simple device, M68K handle token ring network, there is no high level protocol, only binary blobs sent by game code.
 
Finisterre said:
forgive me, I wasn't aware of people doing it remotely via a vxworks vulnerability in WDB, I know several subsystems are running vxworks as well this may not be all that it is limited to accessing.
Click to expand...
I think you're taking my question the wrong way. Simply asking what you think you found, because you are just posting without any commentary. The NAOMI is a well documented system with only a few mysteries left to solve for complete knowledge of the system.

Personally I don't use a NetBoot setup, but I see absolutely no reason the method suggested by MetalliC that is quoted in the first post of this thread would not work. It should absolutely work, I would speculate winteriscoming got the addressing wrong.
 
Understood! As far as I was aware several of the Naomi components ran on vxworks boards, including the Motherboard, and the NETDIMM, and the multiboard, I had hoped knowing that the known vulnerable WDB interface was available could be useful in accessing memory that you guys were previously trying to hit via other means like the direct physical access.

https://www.kb.cert.org/vuls/id/362332 basically gives remote read / write access to vxworks memory on any device with WDB. Seems it *could* be useful in this landscape.
 

Attachments

  • f355_dx.jpg
    f355_dx.jpg
    20.9 KB · Views: 64
Just so I could understand a bit better I did a diff of your binary vs the original. The change is highlighted in bold.

$ xxd MarvelVsCapcom2.bin > a ; xxd MarvelVsCapcom2_unlocked.bin > b
$ diff a b
132941,132944c132941,132944
< 002074c0: 0000 0000 3047 4242 0101 0001 0001 0101 ....0GBB........
< 002074d0: 0000 0000 0000 0000 3047 4242 0201 0001 ........0GBB....
< 002074e0: 0001 0101 0000 0000 0000 0000 3047 4242 ............0GBB
< 002074f0: 0301 0001 0003 0101 0000 0000 0000 0000 ................
---
> 002074c0: 0004 0000 3047 4242 0101 0001 0001 0101 ....0GBB........
> 002074d0: 0000 0000 0004 0000 3047 4242 0201 0001 ........0GBB....
> 002074e0: 0001 0101 0000 0000 0004 0000 3047 4242 ............0GBB
> 002074f0: 0301 0001 0003 0101 0000 0000 0004 0000 ................
132946,132949c132946,132949
< 00207510: 0000 0000 3047 4242 0501 0001 0001 0101 ....0GBB........
< 00207520: 0000 0000 0000 0000 3047 4242 0601 0001 ........0GBB....
< 00207530: 0001 0101 0000 0000 0000 0000 3047 4242 ............0GBB
< 00207540: 0701 0001 0001 0101 0000 0000 0000 0000 ................
---
> 00207510: 0004 0000 3047 4242 0501 0001 0001 0101 ....0GBB........
> 00207520: 0000 0000 0004 0000 3047 4242 0601 0001 ........0GBB....
> 00207530: 0001 0101 0000 0000 0004 0000 3047 4242 ............0GBB
> 00207540: 0701 0001 0001 0101 0000 0000 0004 0000 ................
257479,257482c257479,257482
< 003edc60: 0000 0000 3047 4242 0101 0001 0001 0101 ....0GBB........
< 003edc70: 0000 0000 0000 0000 3047 4242 0201 0001 ........0GBB....
< 003edc80: 0001 0101 0000 0000 0000 0000 3047 4242 ............0GBB
< 003edc90: 0301 0001 0003 0101 0000 0000 0000 0000 ................
---
> 003edc60: 0004 0000 3047 4242 0101 0001 0001 0101 ....0GBB........
> 003edc70: 0000 0000 0004 0000 3047 4242 0201 0001 ........0GBB....
> 003edc80: 0001 0101 0000 0000 0004 0000 3047 4242 ............0GBB
> 003edc90: 0301 0001 0003 0101 0000 0000 0004 0000 ................
257484,257487c257484,257487
< 003edcb0: 0000 0000 3047 4242 0501 0001 0001 0101 ....0GBB........
< 003edcc0: 0000 0000 0000 0000 3047 4242 0601 0001 ........0GBB....
< 003edcd0: 0001 0101 0000 0000 0000 0000 3047 4242 ............0GBB
< 003edce0: 0701 0001 0001 0101 0000 0000 0000 0000 ................
---
> 003edcb0: 0004 0000 3047 4242 0501 0001 0001 0101 ....0GBB........
> 003edcc0: 0000 0000 0004 0000 3047 4242 0601 0001 ........0GBB....
> 003edcd0: 0001 0101 0000 0000 0004 0000 3047 4242 ............0GBB
> 003edce0: 0701 0001 0001 0101 0000 0000 0004 0000 ................
 
Only the NetDimm uses VxWorks, and it's firmware has been disassembled and documented. This is how netbooting was made possible.

NAOMI is a Dreamcast with extra ram and different bios software, plain and simple. F355 uses custom naomi bios for multiboard stack for multiple monitor configurations.

You mentioned in your intro thread that you do RE professional; I'm guessing you haven't opened naomi_boot.py yet? Look at the functions, then go back to the first post in this thread. Then take a look at MAME source code for NAOMI on GitHub.
 
I have indeed noted the functions were RE'd it is hard to track back all the years of pedigree on how things got where they are. Do you have any of the threads where the original RE work was done? I hadn't seen any of the strings in the binaries referenced on Google anywhere, which they commonly would be. Of course some of the research is 10 years old!

I've literally been poking at this thing for 2 days after is showed up from China. The scene is very scattered across a few popular forums, this one seems to be the most frequented though.

I'll try to keep up a bit more!
 
My understanding is that NetBooting became a thing around 10 years ago now, circa 2009 by tmbinc (and friends). I believe some of the history was on assemblergames, but the forum has gone through some rough times lately.

But soon NetBooting will be a thing of the past ;)

Anyhow, naomi_boot.py has functions to poke/peek the entire memory range of the host (host being the naomi, or triforce/chihiro), hence it should be straight forward to grab the sram contents or re-write them
 
Understood, I was just noting that this place is one of few that has discussed unlocks in the context of SRAM.
I'm sitting here looking at PATCH_CheckBootID() inside of naomi_boot.py and thinking there could be similar per game patches for folks that don't often spend time mucking around in memory that may wish to unlock or alter things (like say the speed of a fireball, or height of a jump, you know the usual).

I wasn't aware of any archive of Game+Known memory locations, and good values and associated outcomes that was readily searchable.

This was about as close as I saw (a few buried posts if you look in the right places)
Latest news on Atomiswave 2 Naomi
So can MvC2 be hacked?

Seems @MetalliC has been one of few mules in the work!
 
Finisterre said:
Just so I could understand a bit better I did a diff of your binary vs the original. The change is highlighted in bold.

$ xxd MarvelVsCapcom2.bin > a ; xxd MarvelVsCapcom2_unlocked.bin > b
$ diff a b
132941,132944c132941,132944
< 002074c0: 0000 0000 3047 4242 0101 0001 0001 0101 ....0GBB........
< 002074d0: 0000 0000 0000 0000 3047 4242 0201 0001 ........0GBB....
< 002074e0: 0001 0101 0000 0000 0000 0000 3047 4242 ............0GBB
< 002074f0: 0301 0001 0003 0101 0000 0000 0000 0000 ................
---
> 002074c0: 0004 0000 3047 4242 0101 0001 0001 0101 ....0GBB........
> 002074d0: 0000 0000 0004 0000 3047 4242 0201 0001 ........0GBB....
> 002074e0: 0001 0101 0000 0000 0004 0000 3047 4242 ............0GBB
Click to expand...
In an attempt to try to learn how to live patch MVC2, I used the following Netboot memory reads, to see your changes to the unlocked rom vs the original.
You can use any triforcetools.py, or Naomi_boot.py, etc. and just borrow the functions and force it to print out hex.

import binascii
print binascii.hexlify(DIMM_Read(0xA0200000+int(sys.argv[1]), int(sys.argv[2])))

$ ./netboot_upload_tool_OSX_HighSierra.bin 192.168.1.2 MarvelVsCapcom2_unlocked.bin
...
$ python naomi_boot.py 29908 68
0004000030474242020100010001010100000000000400003047424203010001000301010000000000040000304742420401000100010101000000000004000030474242

$ ./netboot_upload_tool_OSX_HighSierra.bin 192.168.1.2 MarvelVsCapcom2.bin
...
$ python naomi_boot.py 29908 68
0000000030474242020100010001010100000000000000003047424203010001000301010000000000000000304742420401000100010101000000000000000030474242

I had noticed the "0GBB" strings from my previous memory diff during a quick glance around 0xA0200000 as you guys mentioned.

nLOADING GAME NOW...
LOADING GAME TEST NOW...
LOADING TEST MODE NOW...
0GBB
0GBB
0GBB
0GBB
0GBB
0GBB
0GBB
0GBB
MARVEL^E VS.CAPCOM ^D 2
New Age of Heroes
0 0 0 2 2 4
J A P A N
MARVEL^E VS.CAPCOM ^D 2
New Age of Heroes
0 0 0 2 2 4
U S A
MARVEL^E VS.CAPCOM ^D 2
New Age of Heroes
0 0 0 2 2 4
A S I A
MARVEL^E VS.CAPCOM ^D 2
New Age of Heroes
0 0 0 2 2 4
E U R O

I attempted using the following as writes with no success:
HOST_Poke4(addr + 0, 0x00040000)
HOST_Poke4(addr + 32, 0x00040000)
HOST_Poke4(addr + 74, 0x00040000)

Am I remotely on the right path?
 
You must log in or register to reply here.
Back
Top