What's new
By:

Naomi Net DIMM CD-R 4.03 firmware hack

werejag said:
idc said:
werejag said:
using a gdrom zero pic? or netdim zero pic
Click to expand...
My PIC does both, at least for NAOMI.
Click to expand...
so how is that even possible being its a 1 byte difference.
Click to expand...
It's just the network flag, it set to 1 does not prevent CF/GD from actually booting. Of course you can only do either at a time depending on your jumper configuration but that's nothing to do with the security PIC, I do not know why people assume it does.

P.S. just to clear out any misunderstanding, you cannot net boot if your network flag is set to 0 (obviously), but you can GD/CF boot (or netboot) when it's set to 1.
 
werejag said:
becuase that byte cant be both at same time
Click to expand...
Can’t be both what? There is a byte for ‘network on’ and ‘network off’. Setting it to 01 for on doesn’t prevent anything else from working, unless I’m overlooking something. I’ve been using a single PIC for years in my NAOMI setup. I’ve never been able to try it in Tri-Force or Chihiro though.

If you’d like to test my PIC hex, I’d appreciate it. Just set the jumpers in the DIMM accordingly, GD mode should allow the PIC to work for CF (ABC.BIN), network mode will allow the PIC to netboot.

How to Create a Zero Key (PIC) For Net Booting and CF on NAOMI Chihiro and Triforce
 
mathieulh said:
It's just the network flag, it set to 1 does not prevent CF/GD from actually booting.
Click to expand...
if network flag is 1 and DES key is 0 this considered by DIMM firmware as "special development/debug PIC", games will still boot but there might be unexpected side effects.
 
MetalliC said:
mathieulh said:
It's just the network flag, it set to 1 does not prevent CF/GD from actually booting.
Click to expand...
if network flag is 1 and DES key is 0 this considered by DIMM firmware as "special development/debug PIC", games will still boot but there might be unexpected side effects.
Click to expand...
Thanks for elaborating. :)

I'm curious. What unexpected side-effects have been observed?
 
idc said:
MetalliC said:
mathieulh said:
It's just the network flag, it set to 1 does not prevent CF/GD from actually booting.
Click to expand...
if network flag is 1 and DES key is 0 this considered by DIMM firmware as "special development/debug PIC", games will still boot but there might be unexpected side effects.
Click to expand...
Thanks for elaborating. :)
I'm curious. What unexpected side-effects have been observed?
Click to expand...
As far as I am aware of, it would still be a "special development/debug PIC" even when netbooting the game, so had there been any side effects we would have seen those a long time ago.
 
idc said:
I'm curious. What unexpected side-effects have been observed?
Click to expand...
cant remember, it was like 4 years ago when I was RE'ing various DIMM firmwares, need to revisit IDA bases and check.
I don't think there is practical difference, more like "perfectionist" thing - people who prefer CF boot usually want to have things as much as possible close to original.

@mathieulh right, but we are talking about GD/CF boot, and if you've disassembled DIMM firmware you should know NET and GD boot is different code paths.
 
MetalliC said:
cant remember, it was like 4 years ago when I was RE'ing various DIMM firmwares, need to revisit IDA bases and check.I don't think there is practical difference, more like "perfectionist" thing - people who prefer CF boot usually want to have things as much as possible close to original.

@mathieulh right, but we are talking about GD/CF boot, and if you've disassembled DIMM firmware you should know NET and GD boot is different code paths.
Click to expand...
Right, but I was under the impression that the jumpers on the DIMM choose which code path the DIMM takes, not what's on the PIC?

A zero DES key PIC is a debug PIC, whether the network byte is 1 or 0, is it not?
 
duh, I've revisit this, and IIRC I've explained this already at this forum some time ago.

look at this code in 4.01 firmware
Code: 
RAM:0C09680E                 mov     r8, r1          ; kaijo reply ptr
RAM:0C096810                 add     #6, r1
RAM:0C096812                 mov.b   @r1, r1
RAM:0C096814                 mov.l   #kaijo_netflag, r2
RAM:0C096816                 exts.b  r1, r1
RAM:0C096818                 mov.l   r1, @r2
RAM:0C09681A                 tst     r1, r1
RAM:0C09681C                 bt/s    wr_dev_flag
RAM:0C09681E                 mov     #0, r2          ; not dev
RAM:0C096820                 mov.l   #DES_keyLH, r3
RAM:0C096822                 mov.l   @r3, r1
RAM:0C096824                 tst     r1, r1
RAM:0C096826                 bf      wr_dev_flag
RAM:0C096828                 mov.l   @(4,r3), r1
RAM:0C09682A                 tst     r1, r1
RAM:0C09682C                 movt    r2              ; dev
RAM:0C09682E
RAM:0C09682E wr_dev_flag:                            ; CODE XREF: read_ALL_pic+DC↑j
RAM:0C09682E                                         ; read_ALL_pic+E6↑j
RAM:0C09682E                 mov.l   #development_flag, r1
RAM:0C096830                 mov     #0, r0
RAM:0C096832                 mov.l   r2, @r1
which is basically does: check if network flag !=0 and "DES_keyLH" ==0, and if its true - set "dev mode" flag.

in NAOMI code path "DES_keyLH" (0C129DC8) never written, have FFFFFFFFFFFFFFFF by default, and dev flag will be always reset to 0.
so, its really have no difference in NAOMI while booting from GD or CF.

BUT, in Chihiro/Triforce mode "DES_keyLH" will be written with DES key read from PIC, and if it 0 and network flag is 1 - will be set development mode flag.
Host BIOS or games may read and check this flag, and btw, that's how BIOS enable or disable region change "easter egg".
 
Last edited:
Makes sense, thanks for the clarification, MetalliC. Sorry, I may have not seen (or had overlooked some of the key info) where you discussed this previously. :)

I think we’ll continue to look at the CD-ROM booting possibility. While it has little practical use to many, it would still be good to get it going, without the time bomb at 120 minutes, squeezing all the possible functionality out of the system.

I appreciate that you may have ‘been over some of this before’, but often these things fall victim to time passing; things get missed the first time around, and work gets abandoned because there doesn’t seem to be interest at the time.

If you happen to have any old project files or other notes you’re willing to share, it would be appreciated. It might certainly help to fill in some of the blanks in the current observations and analyses.
 
idc said:
While it has little practical use to many, it would still be good to get it going, without the time bomb at 120 minutes, squeezing all the possible functionality out of the system.
Click to expand...
sure, it is/was a bit interesting tech puzzle, and I think I have it solved :)

try this: in 256-byte [GameID].BIN file you use in your CD images change byte at offset 0x14 to 0xFF, this expected to disarm the time bomb.
for those who might be wondering WTF is going on - there is LBA check of NAOMIGD.BIN file location, it should be at very end of GD disc, and Elsemi missed that check.
 
MetalliC said:
Elsemi missed that check.
Click to expand...
but @MetalliC didn't :thumbsup:

keep-up-the-good-work.jpg
 
  • Like
Reactions: idc
MetalliC said:
idc said:
While it has little practical use to many, it would still be good to get it going, without the time bomb at 120 minutes, squeezing all the possible functionality out of the system.
Click to expand...
sure, it is/was a bit interesting tech puzzle, and I think I have it solved :)
try this: in 256-byte [GameID].BIN file you use in your CD images change byte at offset 0x14 to 0xFF, this expected to disarm the time bomb.
for those who might be wondering WTF is going on - there is LBA check of NAOMIGD.BIN file location, it should be at very end of GD disc, and Elsemi missed that check.
Click to expand...
Wow! Thanks for this insight! I will ask @idc to test this asap! :)
 
MetalliC said:
sure, it is/was a bit interesting tech puzzle, and I think I have it solved :)
try this: in 256-byte [GameID].BIN file you use in your CD images change byte at offset 0x14 to 0xFF, this expected to disarm the time bomb.
for those who might be wondering WTF is going on - there is LBA check of NAOMIGD.BIN file location, it should be at very end of GD disc, and Elsemi missed that check.
Click to expand...
Okay, so setting this byte to 0xFF does indeed seem to disable the two-hour media check 'time bomb'. :)

I've had Puyo Pop Fever re-encrypted with the Sports Jam key, loaded from burned CD-R and using an original Sports Jam PIC, running for two and a half hours with no reset so far. :)

Edit: 3.5 hours without a reset. I turned the game off for the night at that point.

timebombff.PNG
 
Sorry for the question, i haven’t followed that much about this.
Is it possible to have a 3.17 or 4.02/03 dimm update on cdr? I mean, having a disk like that without what is usually done to update dimms (desoldering, reflashing, and so on) ?
The original disks are too expensive for me
 
I think not. As from the box the Naomi gd does not read copy discs so yo update dimms from to 2.01——-3.17 etc you need original discs. From that point you can you NetBoot to upgrade. Hence the price on the 3.17 firm discs. You can always desolder etc but many times it’s outside someone’s comfort zone. @MetalliC correct me if I’m wrong here :-)
 
You must log in or register to reply here.
Back
Top