What's new
By:

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

about MVSC2 patch - there was changed unlock byte in default EEPROM data (not SRAM), game write these data into mobo settings EEPROM at 1st boot of this game (after it was changed from some another game).

as you may imagine, in this case patching host NAOMI RAM will not work, because you should do it in exact moment after BIOS loaded game binary into RAM, but game code didn't get to the point there it checking EEPROM ID/contents, which is one of very 1st tasks game code does.

about using cheats - that's how I see it:
run some game in emulator, Demul for example. use cheat finding tool like ArtMoney, it will automatically recognize it and set correct value for system RAM location (@ 0x2C000000 in Demul process space), then find RAM location(s) of whatever values you interested in.
run same game on NAOMI, then game already running apply these cheats using DIMM Host Poke functions.
 
brizzo said:
Only the NetDimm uses VxWorks, and it's firmware has been disassembled and documented. This is how netbooting was made possible.
Click to expand...
Since everyone in the know is already on this thread...

Is it possible to remove/skip the RAM checks in the NetDIMM firmware?

RAM checking is available in the Test Menu, and the checks slow down the game loading process quite a bit...

Anyone?
 
nam9 said:
Is it possible to remove/skip the RAM checks in the NetDIMM firmware?
Click to expand...
yes it is. find some WCCF chd image, for example wccf420e/cdv-10027.chd in MAME romset, extract it, find there checkon.exe file, copy it to new name - checkoff.exe
checkon.exe will enable game binary validation at system boot
checkoff.exe will disable it
 
Last edited:
brizzo said:
Curious if you know what Demul is yet?

Here is a hint if you are on the right path: why are you reading the dimm and writing the host?
Click to expand...
I have indeed seen Demul and Makaron, etc and am aware that many of the enlightened folks here have been involved in the creation of these generous tools.

"why are you reading the dimm and writing the host?" *sigh*... that is what happens when you stay up way later than you expect, and did the same the night before! Thanks for noting that.
 
MetalliC said:
about MVSC2 patch - there was changed unlock byte in default EEPROM data (not SRAM), game write these data into mobo settings EEPROM at 1st boot of this game (after it was changed from some another game).

as you may imagine, in this case patching host NAOMI RAM will not work, because you should do it in exact moment after BIOS loaded game binary into RAM, but game code didn't get to the point there it checking EEPROM ID/contents, which is one of very 1st tasks game code does.

about using cheats - that's how I see it:
run some game in emulator, Demul for example. use cheat finding tool like ArtMoney, it will automatically recognize it and set correct value for system RAM location (@ 0x2C000000 in Demul process space), then find RAM location(s) of whatever values you interested in.
run same game on NAOMI, then game already running apply these cheats using DIMM Host Poke functions.
Click to expand...
Thanks for your patience while I attempt to catch up...
 
I'm not sure if this is useful to anyone... but this is what I was using to poke around and try to follow along. This is just making use of the Triforce Toolbox everyone uses, it is more so for my own purposes, but I thought someone else may like to read it!

I'm sure I'll make changes, so I have the code in GitHub for anyone that wishes to play with it.

https://github.com/MAVProxyUser/Naomi_GameGenie/blob/master/Naomi_GameGenie.py

$ python Naomi_GameGenie.py.txt --ip=192.168.1.2 --len=8 --addr=0x0
Connecting to 192.168.1.2
Using address: 0x0
Memory snapshot:
00000000: 4E 41 4F 4D 49 20 20 20 NAOMI
Hex string for write value:
4e414f4d49202020
No write value, so not writing anything

$ python Naomi_GameGenie.py --ip=192.168.1.2 --addr=0xA0207512 --len=24 --value=040404040404
Connecting to 192.168.1.2
Using address: 0xa0207512
Memory snapshot:
00000000: 00 00 30 47 42 42 05 01 00 01 00 01 01 01 00 00 ..0GBB..........
00000010: 00 00 00 00 00 00 30 47 ......0G
Hex string for write value:
000030474242050100010001010100000000000000003047
Post write memory:
00000000: 04 04 04 04 04 04 05 01 00 01 00 01 01 01 00 00 ................
00000010: 00 00 00 00 00 00 30 47 ......0G

$ python Naomi_GameGenie.py --ip=192.168.1.2 --addr=0xA0207512
Connecting to 192.168.1.2
Using address: 0xa0207512
No length supplied, using 4 as default
Memory snapshot:
00000000: 04 04 04 04 ....
Hex string for write value:
04040404
 

Attachments

Oh, and if I was not clear, the intent here was, push a rom into the NetDIMM, poke, and patch, then go into Test mode, and come back out (and let the game reload itself).

As a quick test I was able to remove two of the start up screens messages. When MVC2 starts up, it normally prints out the game title and date, then an export warning. A quick run of the script above and both messages can be altered, or removed.(and yes I do understand I could just hexedit the .bin before I push it to the DIMM)
 
Last edited:
Finisterre said:
When MVC2 starts up, it normally prints out the game title and date, then an export warning. A quick run of the script above and both messages can be altered, or removed.(and yes I do understand I could just hexedit the .bin before I push it to the DIMM)
Click to expand...
I like where this is going... Anything to decrease load times...
 
Did anyone have success in backing up/restoring SRAM? I'm about at the point where I'd want to try implementing that in my loader.

Also, re: "something far cooler than netbooting": How much time do I have? Should I even bother? LOL
If somebody would like to fill me in on the details, I can better adjust my development.

I've started reworking the crappy old loader I had into something more clean as well. If anyone would like to follow along and/or comment on how it could be improved, check here: https://github.com/tugpoat/ACNTBoot/ (Not putting it into a big announcement thread yet obviously).
 
Last edited:
Aw. :(
Maybe that won't be viable for us then.

Thank you for all your efforts regardless! We all appreciate it.
 
Now that I have an environment I can poke at I figured I'd take a stab as well. I would have to concur with @kuze that there are functions missing of some sort as the ones provided don't work as advertised.

HOST_Read16 no matter what always returns a strange string of bytes:
pi@netboot:~/tmp $ python test.py
We connected
00000000: 4E 41 4F 4D NAOM
4e414f4d
00000000: 00 00 FF FF 0C F8 44 7800 00 00 04 0C FB CD D0......Dx........

These are poking 0xAC000300 so it should match however changing the address at all on Read16 always returns the same 16 byte array regardless so I don't think HOST_Read16 does what's advertised. If you set the window large enough you can catch two differing sets of 16 bytes but it's just garbage from what I can tell.

HOST_Read4 however type is misdeclared. It appears this function uses "type" as the extra bytes beyond the initial byte so to get 4 bytes type always has to be 3. Read4 also only seems to work on multiples of 4 for the start address it seems or you're likely to get garbage.

Read4 is also misnamed, this appears to be DIMM-contents and not the HOST.



Is there any documentation from when the netdimm was reversed with regards to functions and offsets? I've tried to locate any sort of development documentation for Naomi and have yet to come across anything.
 
sammargh said:
Is there any documentation from when the netdimm was reversed with regards to functions and offsets? I've tried to locate any sort of development documentation for Naomi and have yet to come across anything.
Click to expand...
I hear ya. I got some snark when I used the vxworks vulnerability to read DIMM memory and was trying to understand what I had found. It was implied that "it's firmware has been disassembled and documented. This is how netbooting was made possible." 29

The only "documentation" I could find was the stuff in the perl script used to Netboot, which as you've pointed out has some incorrect info in it. IMHO *if* said disassembly were documented it would be easier to Google search things like: naoSetDimmSysInfo, naoSetDevMode, getNaomiServerAddress, or naoSetErrCode, and other functions from the net dim firmware, basically they would show up *somewhere*.

I do understand that there are several layers to this onion however, and would not be surprised to see said info privately circulated amongst OG's as it were. Likewise some of the older forums have collapsed, and their archives have been lost, perhaps there was more info elsewhere.

Beyond that there is of course netboot.rar inside of https://mega.nz/#F!lg4TTIrL!Bs03RF6fYjoUg1YYUt70Dw!B1xnWaBD which "documents" the various required responses.

If you come up with more detail I'd be keen to see what you find. I was wondering also if that VXWorks thing I ran across could somehow be of use.

Good luck!

Update: I hunted around some more and ran across this that you may find useful, again primarily documentation of the Netdimm security bits. "I’ve reversed the DIMM Board SH-4 firmware, and found the Challenge/Response-function. It was easy to reverse the function (in both senses) into python code. Basically, the transmission of 8 bytes works the following way" - https://debugmo.de/2008/05/pah-security/
 
Last edited:
It seems like a lot of in-depth documentation is either privately held, difficult to track down, or exists mostly between the ears of knowledgeable folks. At least, that is my experience with arcade hardware thus far.
That said, I'm nowhere near an expert with assembly and hardware level stuff so I don't tend to get very far given just dumps and "hey maybe the answer is in this bin somewhere"
 
Last edited:
isn't the function that should keep alive the system without security pic writing host memory directly to reset a counter value in memory?

I never experimented with the host functions, but managed to read the dimm contents back using it's functions.

I don't understand how you could read or write host memory, unless it is some memory from the vxworks system or maybe from the software microcontroller integrated in the dimm board fpga or asic.
Again, I can only speak for chihiro. Basically, the host sees the dimm as a disk partition and has some commands it can send to the dimm asic
or emulated cpu using some registers on the LPC bus
(basically x86 io instructions reading and writing registers on some unknown hardware on the dimm board)
It uses these registers to upload the firmware2.bin to the software microcontroller in the asic. There also is a register to control some led's on the dimm board, but those aren't mounted on the retail hardware. You can see the pcb is designed for them. The current limitting resisters aren't mounted either.
I doubt there is something that microcontroller can do to request some memory contents of the host. Besides for debugging purposes, I don't see why it would need that functionallity.
As usual, I'll be happy if I am proven wrong.

#define SEGA_REGISTER_RUAP (SEGA_REGISTER_BASE + 0x00)
#define SEGA_REGISTER_RLAP (SEGA_REGISTER_BASE + 0x02)
#define SEGA_REGISTER_RDP (SEGA_REGISTER_BASE + 0x04)
#define SEGA_REGISTER_DMUAP (SEGA_REGISTER_BASE + 0x06)
#define SEGA_REGISTER_DMLAP (SEGA_REGISTER_BASE + 0x08)
#define SEGA_REGISTER_LAN_GR0 (SEGA_REGISTER_BASE + 0x1E)
#define SEGA_REGISTER_LAN_GR1 (SEGA_REGISTER_BASE + 0x20)
#define SEGA_REGISTER_LAN_GR2 (SEGA_REGISTER_BASE + 0x22)
#define SEGA_REGISTER_LAN_GR3 (SEGA_REGISTER_BASE + 0x24)
#define SEGA_REGISTER_LAN_CNT0 (SEGA_REGISTER_BASE + 0x26)
#define SEGA_REGISTER_INTERRUPT_MASK (SEGA_REGISTER_BASE + 0x80)
#define SEGA_REGISTER_LED (SEGA_REGISTER_BASE + 0x82)
#define SEGA_REGISTER_DIP_SWITCH (SEGA_REGISTER_BASE + 0x84)
#define SEGA_REGISTER_G1_PIO_CTRL (SEGA_REGISTER_BASE + 0x86)
#define SEGA_REGISTER_G1_DMA_CTRL (SEGA_REGISTER_BASE + 0x88)
#define SEGA_REGISTER_DMAAP_WRITE_MASK (SEGA_REGISTER_BASE + 0x8A)
#define SEGA_REGISTER_INTERRUPT_SELECT (SEGA_REGISTER_BASE + 0x8E)
#define SEGA_REGISTER_DIMM_RESET (SEGA_REGISTER_BASE + 0x90)
#define SEGA_REGISTER_CHIP_REVISION (SEGA_REGISTER_BASE + 0xF0)
#define SEGA_REGISTER_DIMM_SIZE (SEGA_REGISTER_BASE + 0xF4)

This are the registers that are used to communicate with the dimm. There are a number of partitions on the harddrive it emulates.
One is called MBCOMM: so I assume it's used for networking.
 
I had figured as much as I don't see why it would ever need direct access to nvram but one can be hopeful. Maybe the host options only work on triforce since that's where these commands came from but I don't have one to verify.
 
obcd said:
I don't understand how you could read or write host memory, unless it is some memory from the vxworks system or maybe from the software microcontroller integrated in the dimm board fpga or asic.
Click to expand...
its almost pure software thing:
- you send some command to DIMM
- its passed to command dispatcher (big switch/case routine, located at 0xC08A340 in 3.17 and 4.01 firmwares),
- command being executed

in case of Host Poke/Peek DIMM does: put some data into DIMM<->Host communication registers, then generate interrupt to Host.

at Host side (I don't know how it works in Triforce or Chihiro, all said below is about NAOMI): game or BIOS code flow interrupted by "External Device interrupt" and jump into IRQ handler, then get into DIMM command handler. not big routine which basically does:
- clear interrupt
- read DIMM communication registers
- determine which command there is - read/write some host memory address or something else.
- do whatever needed
- put reply and result data into DIMM comm.registers
- generate interrupt to DIMM
- return to game/bios

so, to make all this DIMM magic to work there should be - "syscalls" including DIMM command handler copied from BIOS to RAM, initialized (its vector put into IRQ handler list), and enabled "External Device interrupt" request.
some games, like number of cartridge games or ports from Atomiswave, doesn't do this and as result DIMM comm features as well as host reset doesn't work there.
 
You must log in or register to reply here.
Back
Top