G1-ATA Devices

[OzOnE]

@SWAT - I know you mentioned this before, but it's given me an idea....

Just as a test, would you be able to write a version of boot_loader_wsc_bfont.bios which asks you to switch back to the stock BIOS chip temporarily?

In other words - it will say "switch back to stock BIOS", then do the 0xa05f74e4 reactivation check (reading from stock BIOS), then say "switch back to SWAT BIOS".

This would let us at least test the custom BIOS with G1 devices.

Do we know if the DC needs to be fully (Hard) reset each time the Holly checksum thing fails?

If not, do you think it would be enough just to keep reading random "chunks" of the BIOS to get it to unlock the G1 port?

So, instead of....

*((volatile unsigned long *)0xa05f74e4) = 0x1fffff;

for(p=0; p<0x200000/4; p++)
x = ((volatile unsigned long *)0xa0000000)[p];

Try a different "size" and start offset each time?

Even if the DC needs to be reset, maybe we can write a simple app to test all different values to see if it can unlock the G1?
As a quick test, it could just attempt to read the MBR on the HDD or something?

Do you know if the protection blocks only DMA access, or does it seem to disable the /CS0 /CS1 chip selects on that port altogether?

I noticed that the BIOS seem to write 0x000042fe to 0xa05f74e4 after it does the unscramble_data() thing too...
http://www.ludd.luth.se/~jlo/dc/security_stuff.c

I can't imagine this locks the G1 port completely after unscrambling a MIL-CD?
Maybe it's just locking it with an arbitrary number so it can be unlocked again later on?

Hmmm, I REALLY want to crack this now.
I wonder if anyone has decapped the HOLLY chip yet?

You did it OK with your sd_loader BIOS, so I'm sure we can do it again.

OzOnE.