What's new

Programming zero-key pic

Triforce is a bit vague, it supposedly needs a different clock setting than the standard ones ?
You can see why there is so much confusion around these.

IIRC I've been told by various sources that the Tri-Force Type 3 and the Chihiro Type 3 can use the same Zero key.

The Tri-Force Type 1 and the Chihiro Type 1 use the same DIMM board as NAOMI so that to me says that the NAOMI, Tri-Force Type 1 and the Chihiro Type 1 should all use the same key as well.

Then, according to obcd above:
With the proper oscillator settings, a type 3 netboot pic works equal well in a type 1 setup.
That to me says that with the right configuration the same key could be compatible for net-booting on any system.
 
I doubt it is fun: two separate people (or teams?) decapped & deprotected DIMM PICs, and then read it's firmware, then compared results to be sure it is good, and it was - the difference was only DES keys and game BIN name.cant remember details, but iirc there was used "masked UV attack", same as this one, to reset read protection fuses.
it was a long ago (like 10 years?), I don't think Dumping Uninoin was related to this, not sure if DU even existed back then.
I do find stuff like that entertaining, where as others may not.

I worked with a co-worker a few years ago on an MSP430 based product, and another friend of ours hipped us to a UV based technique that allowed that in essence allowed JTAG protection fuses to be bypassed. Semi off topic, but may be "fun" for someone else just the same.

My co-worker does a live demo of the attack here. We were exploiting a Realestate key lockbox FWIW.

https://youtu.be/4cqmFHsojQg?t=1660

https://www.slideshare.net/NoSuchCon/d3-01-thomasbradenexploitationofhardenedmsp430baseddevice
 
well we have the datasheet for the 628a, if we know the oscillator type you can just look up the fuse settings.
 
just to be pedantic, your tutorial does not mention the filename of the bin file it looks for. :D
 
I seem to remember reading somewhere that sega forgot to set the security bit's on some of it's protection pic's and that the code was simply read out. I also have the sources I used to figure out that the problem with type 3 was the oscillator setting. They should resemble one of the others, but the labels are a bit better documented.View attachment netboot.zip
 
not sure if already mentioned; if a (proper) netboot/debug pic is used in a Triforce/Chihiro, you can switch the region of the board by pressing the service button a couple of times, just to add some random stuff to the thread :)
 
@obcd
Code:
AIJYOANSWER
    ADDWF PCL,F          ; !!Program-Counter-Modification
    DT 0x3A,0x70,0x1F,0x71,0x1F,0x4C,0x00,0x01
why there is 0x4C ? does it have any effect ? so far we haven't seen any PIC which gives such aijyo reply.
 
I honesty wouldn't know anymore. Maybe I read the original blog's about reversing the triforce security and found it in there?
I likely started with some sources I got from the internet. I just tried to document some of it during my attempt to understand how it all worked. That's the only reason why I posted the code. It wasn't an attempt to say: "hey, I have the correct sources" I am pretty sure I used this code to program some pic's that worked on a chihiro 3. It's more than 2 years ago I worked on this... I passed it a couple of times when people asked for it in private and never got a complain about it not working. But again, it was only tested on chihiro.
 
I see, I'm just wondering if it have any effect. for sure 6th and 7th bytes not used / ignored by regular DIMM firmwares, I haven't found any code which uses these values. in theory (but unlikely) they might be used in Type3 NEC V850 firmware, I'm almost unfamiliar with it, so curious.
 
If I remember well, our first netboot pic was one I bought on ebay. It was originally used on a chihiro 1 with a defective gdrom. I needed one for a chihiro 3 and tested the one I was having. It worked. I found the source code somewhere on the net and created my own netboot pic. It worked on the chihiro 1 but not on the chihiro 3. Next, I wrote some program on an arduino to check and compare the pic responses in an attempt to figure out why mine wasn't working in a chihiro 3. That's probably the stage where I found the diffence in the AIJYOANSWER and changed it in the sources as well. Obvious, it still didn't work. Only later, I discovered that my netboot pic it's oscillator wasn't running and that the behavour was identical to that with no pic at all. I never really checked afterwards if the modified AIJYOANSWER made a difference or not. It worked which was what counted.
 
Is there an analog to this post for Naomi 1 & 2 bios burning? I recall some folks saying they had problems using top300. I do know that primarily most of the bios's are just ones that came from specific games (like HOD), and in specific regions. There is of course the multi-bios "mod", are there others? Is the source available for these mods just as we've discussed here for the PIC mods?

Is p1pkin 's variant what we all use for multi's?
https://forum.arcadeotaku.com/viewtopic.php?t=29558

Have there been other patches besides this: "technically its vanilla Naomi 1/2 bioses with nice 1byte-patch. that means the code which reads DIP switches and changes region depending on it was already in bios, made by Sega, but not executed in normal circumstances. so there was needed to just enable this code."

If there is a thread that is as verbose to this particular one, but covers the bios topic, please point me that direction. I've just failed my first multi bios burn attempt with TopWin, so I'm on the hunt for what I've done wrong. Maybe I didn't leave the chips in my Chinese eraser long enough !?

For some reason I feel like I have heard of "timing" issues on specific games when using a Multi? Perhaps Atomiswave games had some issues as well? Lots of murky subjects floating around, sorry! Any clarification would be appreciated. I think the end result of this thread was great on the PIC side of the house!
 
bios should be straight forward. Use 21576H from mame for JP or the multi from AO. You can diff the H vs the multi if you want.

If the m27c160 chip passes blank check, it should burn and verify fine unless it's faulty. If it fails blank check then re erase or try a new blank.
 
If the m27c160 chip passes blank check, it should burn and verify fine unless it's faulty. If it fails blank check then re erase or try a new blank.
I ran it through the UV eraser again, about 12 minutes in a different position, making sure the window was clean, etc. After that it flashed as expected, and worked fine.
 
Also for posterity... the "read the mame driver" answer of course yields more detail on what p1pkin did to accomplish this:
You can examine the commit "naomi.cpp: add multi-region BIOS hacks (nw)" https://github.com/mamedev/mame/commit/b6553ce0208c37fa1a3a662bd9650cf9eb97179d
"Multi-region hack notes:
These hacks uses 1KB "NAOMIHAT" IPL from HOTD2 proto BIOS to bypass hardware checksum protection and make the rest of ROM moddable.
Besides IPL it is 2 bytes patch (4 for Naomi2), which enables region-switching function implemented by Sega itself, but left it disabled
(original enable trigger: if text at 001FFD00 will be NOT equal to "COPYRIGHT (C) SEGA etc...").
DIP switch settings:
DSW2 DSW3 DSW4
OFF OFF OFF Japan
ON OFF OFF USA
OFF ON OFF Export
ON ON OFF Korea
OFF OFF ON Australia"

Also some more detail on where the region bytes normally live:
https://github.com/mamedev/mame/blob/master/src/mame/drivers/naomi.cpp#L3209
Scan ROM for the text string "LOADING TEST MODE NOW" back up four (4) bytes for the region byte.
NOTE: this doesn't work for the HOTD2 or multi screen boot roms

It was unclear if the CRC hack was ever shared?
https://sega-naomi.eu/forum/viewtopic.php?t=3573
"fixing the crc checksum is the tricky part. I think Alex did it but he never released it publically, and his closed his blog yet again because of the haters."
...
"the crc is the last few bytes of the rom image. I am not sure if people figured out the CRC format."

Again mame mentions the following about Dreamcast, is it assumed that Naomi CRC has the same vulnerability?
"multi-region hack of mpr-21931/1.01d BIOS, hardware checksum protection passes OK due to algorithm weakness"
https://github.com/mamedev/mame/blob/master/src/mame/drivers/dccons.cpp#L734

"actual checksum algorithm is unknown, but its supposed to be simple and weak,
known few modded BIOSes which succesfully passes this CRC check, because of good luck"
https://github.com/mamedev/mame/blob/master/src/mame/machine/dccons.cpp#L193

"all described above works the same way in all HOLLY/CLX2-based systems - Dreamcast, Naomi 1/2, Atomiswave, SystemSP"
https://github.com/mamedev/mame/blob/master/src/mame/machine/dccons.cpp#L174

Has said "luck" ever changed?

If not... CRC Reveng may help sort it out.
http://reveng.sourceforge.net
logo.png


There seems to be some contention over the following post regarding the origin of the Multi-Bios CRC bypass "luck" we all enjoy now:
http://forum.emu-russia.net/viewtopic.php?p=23024#p23024
"using part of recently dumped prototype HOTD2 bios we was able to bypass Naomi bios checksumm protection!
that means region-free or any other customization is possible now."

You can see what I mean in p1pkin's words here:
https://forum.arcadeotaku.com/viewtopic.php?t=29558#p411121
"I don't want to go deep into tech details, so I'll try to explain shortly -
in the term of BIOS modding, the main problem with HOLLY-chipset based systems (Naomi, Dreamcast, and others) is hardware checksum protection, which algorithm is still unknown btw.
so during all ~15 years life of DC-based hardware was unable to add/change code we want, except few lucky cases, when modded bioses passed check by the luck, because of CRC algo weakness.

it was so until this happened" then he references the above post, and goes on

"does 'arcademodbios' guy(s) hacked/bypassed this security by yourself ? - I don't think so. I doubt they know how it works or even exists (the security checking/unlocking is well obfuscated, so if you don't know it is there - most likely you'll not notice anything at all
icon_pubjoe_wink.gif
)"

oddly enough @skate323k137 is pointing out some of the nuances of the multi as well... https://forum.arcadeotaku.com/viewtopic.php?f=26&t=29558&start=40#p446647

one hits home for me "can confirm, 18 wheeler won't work with the Multibios", as I have this dedicated cab.
 
Last edited:
Back
Top