Programming zero-key pic

[brizzo]

yavuzg mentioned above that PIC programming files usually include the "CONFIG bits".

The .hex file posted by werejag has incorrect config bits set, fosc[2:0] = 101 (INTOSC internal oscillator)

Took .bin ekorz posted and converted to .hex file with the settings embedded as specified by @ekorz

Should be as simple as load file and write to device

 

[Derick2k]

Since we are on this, arent there 2 keychips to use?

One for netbooting any game, the other for booting any CF game or am I getting it mixed up with firmware? I've only ever done the netbooting.

 

[Derick2k]

yavuzg mentioned above that PIC programming files usually include the "CONFIG bits".

The .hex file posted by werejag has incorrect config bits set, fosc[2:0] = 101 (INTOSC internal oscillator)

Took .bin ekorz posted and converted to .hex file with the settings embedded as specified by @ekorz

Should be as simple as load file and write to device

Awesome can someone test with their programming software and verify we are all good and netbooting is a go with this. We should get his post pinned for easy look up.

 

[RealMFnG]

Since we are on this, arent there 2 keychips to use?

One for netbooting any game, the other for booting any CF game or am I getting it mixed up with firmware? I've only ever done the netbooting.

You are correct. There is no PIC that does both CFBooting and NetBooting.

 

[xodaraP]

My understanding was the reason this wasn't posted here previously and can be hard to find is because the manufacturer of this particular hardware are fairly active in taking legal action - even on long discontinued hardware

I'm always happy to help in PM and have offered to burn chips for those who need them or help them do it themselves

 

[rtw]

This has been discussed before and as @brizzo says hex bits are wrong.

However people are posting a recompiled version of a semi-disassembled code block.

The correct procedure is just to take the official dumped binaries from MAME and change the DES keys.

edit:

Here are the correct setting for the PIC and I included a zero key netboot image taken from the official dump.



View attachment zerokey_net.zip

 

[zeruel85]

I'm using werejag's code as of now, and I haven't encountered any problems. Is it better to update the PIC with brizzo's hex file?

I did not understand very well the differences, please could you explain what change between the older hex file and the newer one?

Also, I always flash the PIC with hex code, never used a BIN file. I'm a little confused about the new discoveries.

Thanks guys.

 

[rtw]

When the original PIC key was dumped back in the days the resultant image was a 2048 byte BIN file.

At this point some people started disassembling the BIN file and recompiling it, however this sometimes introduced bugs and stability issues.

There is no industry standard way to preserve settings for a PIC controller so different manufacturers solve this in different ways, some append a config block at the end of the binary, some pad the binary to 16 KiB bytes and add the config block.

The HEX file is just a different representation of a binary file, it was created to be able to send updates over an ASCII communication channel.

tl;dr

If you want to make a zerokey network PIC use the file that I posted and with the PIC settings I posted.

 

[werejag]

the mame dump is broken i posted corrected hex for cfboot and netboot and those setting mentioned by rtw

 

[rtw]

the mame dump is broken i posted corrected hex for cfboot and netboot and those setting mentioned by rtw

We have had this discussion before, so please tell us how a dump made from a decapped original SEGA PIC is broken ?

 

[werejag]

errors where put in deliberately

 

[twistedsymphony]

If you want to make a zerokey network PIC use the file that I posted and with the PIC settings I posted.

Thanks for posting that.

What about a Zero Key for NAOMI CF booting and Chihiro or Tri-Force setups?

 

[MetalliC]

errors where put in deliberately

please stop this bulls**t.
this was discussed already - there is errors is in disassembled source code floating around, someone who did that disassembly broke it.
but all the dumps of security PIC for GD-ROM games in MAME romset is 100% OK.

 

[rtw]

errors where put in deliberately

Are you saying that SEGA put in errors deliberately ?

If you want to make a zerokey network PIC use the file that I posted and with the PIC settings I posted.

Thanks for posting that.
What about a Zero Key for NAOMI CF booting and Chihiro or Tri-Force setups?

I can upload that later just remember that the zero key for NAOMI CF and GD needs a loader name.

This one uses ABC.BIN

View attachment zerokey_cf_gd.zip

 

[werejag]

feel free to use the broken code. the fixed code can be tested by making a gdrom pic of any game. the broken code will not work.

 

[werejag]

sega didnt dissemble the code and upload it to mame

 

[MetalliC]

sega didnt dissemble the code and upload it to mame

yep, Sega didn't do it.

but, we got original security PIC HEX made by Sega, which was leaked from one game development company not along ago.
when converted to BIN format it 100% match MAME dumps.
any problem with this ?

but as was said - there is broken source code in the net, like this one - https://pastebin.com/jyELVuUt
it is broken in some parts, and it is NOT mame code.

 

[werejag]

the one on the ao wiki is the one that im talking about which is broken and is used by alot of people badly

 

[MetalliC]

the one on the ao wiki is the one that im talking about which is broken and is used by alot of people badly

that code is brief disassembly to demonstrate how security PIC code works inside. it is NOT for practical use, and not designed to be compiled back into binary.
if people not smart enough to understand this - that's theirs personal problem

 

[werejag]

the one on the ao wiki is the one that im talking about which is broken and is used by alot of people badly

that code is brief disassembly to demonstrate how security PIC code works inside. it is NOT for practical use, and not designed to be compiled back into binary.if people not smart enough to understand this - that's theirs personal problem

then why is there this thread since this is the issue at hand?