BIOS region check routine bypassing

Members research, findings and information that can be useful towards the PlayStation 1.
rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

BIOS region check routine bypassing

Post by rama3 » February 21st, 2018, 1:50 am

Intro:
As most of you know, the BIOS of most Japanese and some later EU machines checks the license data on each game and only boots the software if that license data is of the correct region.
To quote nocash's docs:
CDROM ISO Volume Descriptors

System Area (prior to Volume Descriptors)
The first 16 sectors on the first track are the system area, for a Playstation disk, it contains the following:

Sector 0..3 - Zerofilled (Mode2/Form1, 4x800h bytes, plus ECC/EDC)
Sector 4 - Licence String
Sector 5..11 - Playstation Logo (3278h bytes) (remaining bytes FFh-filled)
Sector 12..15 - Zerofilled (Mode2/Form2, 4x914h bytes, plus EDC)

Of which, the Licence String in sector 4 is,

000h 32 Line 1 (" Licensed by ")
020h 32+6 Line 2 (EU) ("Sony Computer Entertainment Euro"," pe ") ;\either
020h 32+1 Line 2 (JP) ("Sony Computer Entertainment Inc.",0Ah) ; one of
020h 32+6 Line 2 (US) ("Sony Computer Entertainment Amer"," ica ") ;/these
041h 1983 Empty (JP) (filled by repeating pattern 62x30h,1x0Ah, 1x30h)
046h 1978 Empty (EU/US) (filled by 00h-bytes)

The Playstation Logo in sectors 5..11 contains data like so,

0000h .. 41h,00h,00h,00h,00h,00h,00h,00h,01h,00h,00h,00h,1Ch,23h,00h,00h
0010h .. 51h,01h,00h,00h,A4h,2Dh,00h,00h,99h,00h,00h,00h,1Ch,00h,00h,00h
0020h .. ...
3278h 588h FF-filled (remaining bytes on sector 11)

the Logo contains a header, polygons, vertices and normals for the "PS" logo (which is displayed when booting from CDROM). Some BIOS versions are comparing these 3278h bytes against an identical copy in ROM, and refuse to boot if the data isn't 1:1 the same:
- US/ASIA BIOS always accepts changed logos.
- PAL BIOS accepts changed logos up to v3.0E (and refuses in v4.0E and up).
- JP BIOS never accepts changed logos (and/or changed license strings?).
I want to develop a modchip routine that ideally skips these checks and behaves like a regular NTSC-U or earlier EU BIOS.
To do this, I need some help finding the routine in a BIOS dump, then figuring out on which pins of the BIOS IC this code is transferred, and when.
Ideally, there is a simple conditional branch that I can just NOP, but who knows.
Note: This is essentially similar to what the OneChip code does on later EU machines, connecting to A18 and D2 and dragging D2 down at a precise time. I want to patch bypass the entire region check routine though.

I hope one of you knows how to tackle this. Logic analyzer and previous experience (designing / coding my modchip) is there ;)

User avatar
Administrator
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2686
Joined: Dec 31, 2012
I am a: Shadow
PlayStation Model: H2000/5502

Post by Administrator » February 21st, 2018, 4:51 am

Ah, so Sony patched their bootloader/kernel initialisation routines to perform this check. Hmm. Best thing would be to first find the offset in the BIOS where this compare/check takes place, then, pop the BIOS pins on a logic analyser and look for the instructions you found. Finally, slowly narrow it down to what pin/address contains it, and then implement a patch.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » February 21st, 2018, 5:16 am

The check was probably always intended. It appeared in the Japanese boot code almost immediately after the initial batch of consoles. EU and NTSC-U consoles probably have the code for it, but disabled. I don't know this though, it's just speculation.

Anyway, it all starts with identifying what code initializes the check / what instruction to patch.
It's probably best to do this on a Japan ROM for SCPH-7500, on the assumption that it stayed in the same location up until the last PSOne code.

Is there a known decompile of those versions? That'd be awesome.

kHn
Active PSXDEV User
Active PSXDEV User
Posts: 40
Joined: Nov 08, 2017

Post by kHn » February 21st, 2018, 5:33 am

The check is on the OSD executable, and the OSD executable is compressed in some BIOSes.
I did hardpatch a PS BIOS image (during the POPStarter development) to skip the bootsector check, luckily it was not packed.
But this approach, for compressed OSD, would require the injection of a subroutine (patcher) in the unpacker stub, to patch the unpacked code in the RAM before it's executed. Or at worse, a controlled-corruption attack, yuck.
Dunno how to do that with a modchip, since I'm no hw guy.

User avatar
Administrator
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2686
Joined: Dec 31, 2012
I am a: Shadow
PlayStation Model: H2000/5502

Post by Administrator » February 21st, 2018, 6:18 am

rama3 wrote: February 21st, 2018, 5:16 am The check was probably always intended. It appeared in the Japanese boot code almost immediately after the initial batch of consoles. EU and NTSC-U consoles probably have the code for it, but disabled. I don't know this though, it's just speculation.

Anyway, it all starts with identifying what code initializes the check / what instruction to patch.
It's probably best to do this on a Japan ROM for SCPH-7500, on the assumption that it stayed in the same location up until the last PSOne code.

Is there a known decompile of those versions? That'd be awesome.
Not that I know of. The only person I know who would actually know exactly what you're looking for is NO$CASH. Sadly, he has disappeared (for months now) and no one knows why or what's happened to him.

kHn wrote: February 21st, 2018, 5:33 am The check is on the OSD executable, and the OSD executable is compressed in some BIOSes.
I did hardpatch a PS BIOS image (during the POPStarter development) to skip the bootsector check, luckily it was not packed.
But this approach, for compressed OSD, would require the injection of a subroutine (patcher) in the unpacker stub, to patch the unpacked code in the RAM before it's executed. Or at worse, a controlled-corruption attack, yuck.
Dunno how to do that with a modchip, since I'm no hw guy.
Either way, it gets decompressed into memory later on by the boot routines and the compare logic is executed, so it can still be checked on the BIOS's physical pins I reckon.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

kHn
Active PSXDEV User
Active PSXDEV User
Posts: 40
Joined: Nov 08, 2017

Post by kHn » February 21st, 2018, 7:40 am

Reversed the POPStarter patches, I'm leaving that here in case you wanna see what it does :
24523402.ZIP
The BIOS comes from the emulator btw.
The patches for license and logo checks (4 modified instructions) are useful. The rest is not needed.

There was also another hack to skip the entire OSD loading and let the kernel deal with the inserted disc. Can't find it atm. "Fast booting" is off topic anyways :? .

User avatar
Administrator
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2686
Joined: Dec 31, 2012
I am a: Shadow
PlayStation Model: H2000/5502

Post by Administrator » February 21st, 2018, 10:52 am

kHn wrote: February 21st, 2018, 7:40 amThere was also another hack to skip the entire OSD loading and let the kernel deal with the inserted disc. Can't find it atm. "Fast booting" is off topic anyways :? .
FASTBOOT.S
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » February 21st, 2018, 5:34 pm

Thanks, I had read about the compression but forgot. This complicates things a little ;p

Patching the extracted routine later, that'd require listening on the bus all the time and looking for that code to appear.
It may be possible. But things are going fast and there'll be a lot of data to look at.

Thanks also for the fastboot idea. That's a good, new approach :)

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » February 22nd, 2018, 2:26 am

I thought about it some more and always reach the same conclusion:
It would be best to bypass the OSD and load some form of replacement.
Fastboot for example, or nocash's full BIOS replacement, or even just Caetla.

I'd like to have a solution with little soldering effort for the user.
(Otherwise, we could all just drop in EEPROMs with the BIOS clone :) )
With the compressed OSD though, I don't think it will be possible to patch it on the fly.

That shifts the problem somewhat:
I'm now looking for a way to branch the boot process off to code on a different device than the mask ROM.
It would be pretty awesome if instead of the OSD, it would run an executable on a Memory Card.
This executable would then boot a game or do some other useful stuff.
Alternatively, the new loader could exist on the "modchip", one of the ESP series microcontrollers, with their large flash memory.

To get back to the soldering effort, it would be too much to ask of users to solder like 18 address wires + 8 data wires, so the chip can serve the program over the regular bus.

I guess I need a clever idea on how to serve code with less wires. Any suggestions? :)

@kHn:
Your archive contains a patched OSD.EXE, right? I'd bet this would also work directly, leaving the original experience intact.

User avatar
TriMesh
Verified
PSX Aptitude
PSX Aptitude
Posts: 226
Joined: Dec 20, 2013
PlayStation Model: DTL-H1202
Location: Hong Kong

Post by TriMesh » February 22nd, 2018, 12:16 pm

rama3 wrote: February 21st, 2018, 5:16 am The check was probably always intended. It appeared in the Japanese boot code almost immediately after the initial batch of consoles. EU and NTSC-U consoles probably have the code for it, but disabled. I don't know this though, it's just speculation.
The check was always in the Japanese consoles, it was just bugged in the earliest versions - it compared the boot sectors and if it didn't match then it suppressed the display of the black boot screen - but carried on booting anyway.

The most likely reason the check is not carried out in the NTSC:U/C boot ROM is that the same ROM is used both for the US version of the console (which boots NTSC:U/C discs) and the Asia variant (which boots NTSC:J discs)

The reason that the PAL PSone boot ROM is so easy to patch is that the PAL and NTSC:U/C versions are almost identical and which set of behavior you get is based on reading the territory byte in the ROM - so if you corrupt the read from that location so it doesn't match "E" then the ROM will boot in NTSC:U/C mode, which doesn't have the territory check. This is also why it runs in 60Hz.

kHn
Active PSXDEV User
Active PSXDEV User
Posts: 40
Joined: Nov 08, 2017

Post by kHn » February 22nd, 2018, 12:49 pm

rama3 wrote: February 22nd, 2018, 2:26 am@kHn:
Your archive contains a patched OSD.EXE, right? I'd bet this would also work directly, leaving the original experience intact.
Yep, it's the OSD EXE extracted from the BIOS image, + a valid PS-X header, so it can be opened in your fav disassembler for you to see what's patched inside.
Perhaps it (and the others from real BIOS dumps) could be run directly too. Though, this one has no Memory Cards / CD Player menus, since it comes from an emulator. It just shows the PS logo.

Also, I found the patch which does fast boot,
In the BIOS image I've posted, $BFC06990 : 0FF01BFC (jal $BFC06FF0) to be replaced with 0FF00648 (jal $BFC01920). Quite hackish lol.

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » March 7th, 2018, 2:05 am

Another idea to reduce wiring effort:
- Remove BIOS chip
- Wires on D0 to D7, CE, OE
- watch CE and start sending out bytes on D0 - D7 according to pre-recorded pattern

This idea hopes that all the BIOS code will be read only once, at system startup.
Also, it assumes that the access pattern is always the same or can be easily adjusted to target hardware.
If all criteria are met, this should work without ever looking at any address lines :)

Myria
Curious PSXDEV User
Curious PSXDEV User
Posts: 17
Joined: Nov 05, 2014

Post by Myria » March 9th, 2018, 10:55 am

What did Japanese Yaroze consoles do in order to be able to boot non-Japanese games?

My SCPH-7000W, which is very much like a Yaroze, simply has an American BIOS (including the region letter in the footer that mod chip detector code reads).

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » March 10th, 2018, 4:33 am

Probably the same method as debug consoles: The Mechacon software (ROM inside the chip that controls the drive) simply allows all regions.
This isn't possible to replicate, because one would need to replace the consumer version Mechacon with such a special chip. (And they are rare ;) )

Anyone any thoughts on the reduced wiring BIOS replacement?
I'd love to hear some opinions before diving into it ;p

fulas
Curious PSXDEV User
Curious PSXDEV User
Posts: 10
Joined: Jul 05, 2017

Post by fulas » March 30th, 2018, 4:41 am

rama3 wrote: March 10th, 2018, 4:33 am Anyone any thoughts on the reduced wiring BIOS replacement?
I'd love to hear some opinions before diving into it ;p
I don't know ,but I think that the last chips for PS2 ,like Modbo, Cristal Chip, Matrix Infinity... works with that behaiviour .
If you look at one intallation diagram , it seems like only data-bus and some control-bus lines are used to hack the Bios.

Would be something like that ,when the psx looks for a cartridge plugged , at 1F000000 , inject the header from Arduino,and a little routine that will be loaded into Ram area and then executed , at this moment ,we have a control over PSX :?: :?:
Take a look at this source code from Charles Macdonald site.
Charles Macdonald wrote: romload - AR ROM replacement that copies $7E00 bytes of appended
data to work RAM at $80010000 and does a JAL to that
address afterwards.

Code: Select all

;----------------------------------------------------------------------------
; PSX test program
;----------------------------------------------------------------------------

workram                 equ     $80010000

;----------------------------------------------------------------------------
; ROM entry point
;----------------------------------------------------------------------------

                        org     $1F000000

                        dw      entry_point_2
                        db      "Licensed by Sony Computer Entertainment Inc."
                        dcb     $50, $20

                        dw      entry_point_1
                        db      "Licensed by Sony Computer Entertainment Inc."
                        dcb     $50, $20

entry_point_1:
                        ; Call our init routine
                        j       init
                        nop
entry_point_2:
                        ; Return to BIOS
                        jr      ra
                        nop

;----------------------------------------------------------------------------
; Startup code
;----------------------------------------------------------------------------
init:
                        ; Copy program to work RAM (~32K)
                        li      a0, ramcode
                        li      a1, workram
                        li      a2, ramcode+$7E00
        copycode:       lw      v0, (a0)
                        sw      v0, (a1)
                        addiu   a0, a0, 4
                        addiu   a1, a1, 4
                        bne     a0, a2, copycode
                        nop

                        ; Jump to work RAM entry point
                        li      t0, return
                        li      t1, $80010000
                        jalr    t0, t1
                        nop
return:
                        ; Return to caller (BIOS)
                        jr      ra
                        nop

                        ; Pad to exactly 512 bytes
                        dcb     $A8, $AA
ramcode:
Of course we haven't address-bus, thats means , that the Arduino have to do all work related jumps, conditions,..,and then send PSX

fulas
Curious PSXDEV User
Curious PSXDEV User
Posts: 10
Joined: Jul 05, 2017

Post by fulas » March 31st, 2018, 6:49 am

Going a little further , Arduino Uno runs at 16MHz while PSX CPU at 32MHz , don't know how many cycles of clock are consumed by a external-memory read, but is pretty sure the UNO is too slow to send data at wanted time, the problem would be solve by slowing down the CPUCLK through IC204 CLK GEN

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » April 2nd, 2018, 2:13 am

This approach seems great so far. About that CPU speed: I really don't know much about ROM reading yet but I assumed that OE pin was there to signal that data is ready. Shouldn't this enable us to deliver the data at the speed we want?

fulas
Curious PSXDEV User
Curious PSXDEV User
Posts: 10
Joined: Jul 05, 2017

Post by fulas » April 2nd, 2018, 7:17 pm

rama3 wrote: April 2nd, 2018, 2:13 am This approach seems great so far. About that CPU speed: I really don't know much about ROM reading yet but I assumed that OE pin was there to signal that data is ready. Shouldn't this enable us to deliver the data at the speed we want?
AFAIK OE is a signal from MIPS to get data from memory , in other hand I don't know a Wait signal that freeze the CPU.

User avatar
TriMesh
Verified
PSX Aptitude
PSX Aptitude
Posts: 226
Joined: Dec 20, 2013
PlayStation Model: DTL-H1202
Location: Hong Kong

Post by TriMesh » May 16th, 2018, 4:41 am

rama3 wrote: April 2nd, 2018, 2:13 am This approach seems great so far. About that CPU speed: I really don't know much about ROM reading yet but I assumed that OE pin was there to signal that data is ready. Shouldn't this enable us to deliver the data at the speed we want?
The signal you want is conventionally called WAIT - but in the PlayStation architecture it's internal to the CPU chip and not a pin you can get at. There are a bunch of control registers at 0x1f801xxx that control wait states, among other things, but I never managed to work out exactly what they all did.

Some of it is pretty obvious, though - for example, the second nibble of the word at 0x1f801008 controls the access time on the expansion ROM.

Sorry this is a bit vague, but I really never got my head around how it worked...

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » May 16th, 2018, 8:51 am

TriMesh:
One of the reasons I want to work on this is testing out those config bits. I assume it is possible to speed up at least some operations, if the hardware plays nice. Something like the old RAM timing tweaks in PC BIOSes, RAS-CAS delay etc ;)

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests