Why did mod chip detector code disable itself in Europe?

Members research, findings and information that can be useful towards the PlayStation 1.
Post Reply
Myria
Curious PSXDEV User
Curious PSXDEV User
Posts: 17
Joined: Nov 05, 2014

Why did mod chip detector code disable itself in Europe?

Post by Myria » March 9th, 2018, 11:03 am

The mod chip detector code I saw determined the system region by reading 0xBFC7FF52, the J/A/E byte in the ROM footer. If the region was E/Europe, the mod chip detector detected itself.

I used to use that as the path of least resistance for cracking mod chip detector code: make the conditional branch for Europe always branch.

Why does the mod chip detector code disable itself on European systems?

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

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

If you search this forum (and maybe Assemblergames, I forgot), you will find this most likely explanation:
SCEE simply did not want this code to lock out games from other regions.
My addition to it: Maybe they didn't fully understand what this code would block and management simply banned the idea outright.

In any case, the "antimod" library that's used in most games is bypassed when the console BIOS region letter is "E".
It's a good thing today, allowing for a simple software patch. I assume this method is what Import Player uses for their "antimod killer".

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

Post by TriMesh » March 10th, 2018, 4:52 am

rama3 wrote: March 10th, 2018, 4:38 am If you search this forum (and maybe Assemblergames, I forgot), you will find this most likely explanation:
SCEE simply did not want this code to lock out games from other regions.
My addition to it: Maybe they didn't fully understand what this code would block and management simply banned the idea outright.
They just thought it was a fundamentally bad idea. Suppose someone has a modded console and they see a new game they really want and so rather than waiting for the pirate copy they buy an original. And it won't boot. That's likely going to be the last original game they will ever buy.

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

Post by rama3 » March 10th, 2018, 5:19 am

Maybe I'm jaded but such a pro consumer decision just sounds odd to me.

It is possible though, of course. One other development of the time:
The anti region lock modchip.
It was much more complicated to pull of, but it replaced just the last letter of the SCEX string, allowing games of all regions but no backups.

Maybe those people knew each other? :)

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

Post by TriMesh » March 10th, 2018, 8:53 pm

rama3 wrote: March 10th, 2018, 5:19 am Maybe I'm jaded but such a pro consumer decision just sounds odd to me.

It is possible though, of course. One other development of the time:
The anti region lock modchip.
It was much more complicated to pull of, but it replaced just the last letter of the SCEX string, allowing games of all regions but no backups.

Maybe those people knew each other? :)
I tend to regard it as being a pragmatic move more than anything else. You can basically say there are 3 types of customers:

1) ones that only play original games and have an unmodified console
2) ones that only play pirated games and have a modified console
3) ones that play both original and pirate games and have a modified console

The first 2 groups are unaffected by the modchip check - either because they don't have a chip or because all the pirate games are patched to remove the check, so the only people it will be impacting are the 3rd group. SCEE thought that the most likely result would simply be that they stopped buying original games at all and went 100% pirate, which is obviously a poor outcome if you are trying to sell software.

That's also why they favored the disc based libcrypt protection - it made games harder to copy by actually making them harder to copy, but left the door open for someone to buy and run the original if they got frustrated with trying to get a copy to work.

Those "region defeat only" or "anti-piracy" modchips are not really that complicated - I wrote one back in the day. There was basically no market for them in HK, but they were pretty popular in the UK with game shops that were selling imported games since it wouldn't undercut their market by allowing copies.

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

Post by rama3 » March 10th, 2018, 9:41 pm

Yes, it's entirely reasonable what SCEE did. That's why I find it so odd. As I understand it, the LibCrypt option wasn't available until later, but I may be wrong on that.

Regarding the region defeat chips, it is certainly more difficult to time it to replace just one letter, compared to simply always replacing all letters.
You probably had to gate it after receiving 3 letters, but how did you do that? :)

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

Post by TriMesh » March 10th, 2018, 10:48 pm

rama3 wrote: March 10th, 2018, 9:41 pm Yes, it's entirely reasonable what SCEE did. That's why I find it so odd. As I understand it, the LibCrypt option wasn't available until later, but I may be wrong on that.
At the time the anti-modchip code came out, libcrypt was something that SCEE had in development in their Cambridge research center, so they certainly knew about it. The anti-mod stuff was developed by SCEI.
rama3 wrote: March 10th, 2018, 9:41 pm Regarding the region defeat chips, it is certainly more difficult to time it to replace just one letter, compared to simply always replacing all letters.
You probably had to gate it after receiving 3 letters, but how did you do that? :)
It's not that hard honestly - the thing to remember is that the data stream is basically using an asynchronous serial format with start and stop bits, so I just had some code that started by looking for a sustained '1' bit then waited for a 1->0 transition (start bit) and delayed 2ms (to get in the middle of the bit cell) and verified that the data was still '0'. If it was, then it read the next 8 bits with a 4ms delay between them, assembled them into a byte and checked the next bit cell was a '1' (stop bit). After each byte, check to see if it's the expected value { 'S', 'C', 'E' } and if not go back to looking for the preamble.

After the first 3 characters have been received, wait for another start bit (actually the same code as the last time), then drive the data output low and assert the gate signal, delay another 2ms (since the false start bit detection put you in the middle of the bit cell) and then send out the final character and the stop bit. The trick, such as it is, is recognizing that you don't need accurate timing over the whole message, but just from the active edge of the last start bit.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest