[SOLVED] Psychic Detective - Copy Protection?

[Administrator]

*EDIT* Solved. The security is checking for the "swap trick" which correlates to the table of contents (TOC) not being updated with the correct values.

Anyone experienced an issue with the game 'Psychic Detective' before from Electronic Arts? They seem to be doing some sort of check, but I can't quite figure out what it is. It's not LibCrypt nor EDC according to ReDump.

The design is quite interesting too. Looks like an 'Amiga Guru Meditation' replica

"DEAD END ALERT: U R N0T 3L!T3 3NUF 2 P13RAT D!Z CD"
"PSYCHIC BURN OUT: FEEDDEAD C0EDBABE".

While debugging, I've noticed that the registers contain "FEEDDEAD" and "C0EDBABE" too. They must have copied them there for a laugh.

http://redump.org/disc/31425/

[rama3]

So there's basically 2 big methods for detecting a chipped console:
- modchip detection
- LibCrypt

LibCrypt would only appear after a certain date, around the FF8 release date.

I totally don't trust the old modchip stealth routines, so if you use real hardware and have one of these, try to debug what it actually does. An LED can often times be added to old chips.

Of course, it's absolutely possible that some games use different "tricks".
I always wondered why games never appear to check if the BIOS and Mechacon regions match with the disk, for example.

[Administrator]

Actually, I burned this image (MD5 5a5efc9317a9be8e3656866857398012) to a CD-R and booted it in my modchipped system and it worked. I don't think it was OldCrow logic, but either way, it doesn't work in some emulators however. It's checking something in the CD data, but I don't think it's LibCrypt since it booted fine in the ePSXe CD-ROM plugin which offered subcode reading on or off, and it booted fine either way.

[Administrator]

Update. I have tried this with an OldCrow modchip on a PU-8 (SCPH-1002), and it works fine.

Emulators this game fails in is pSX (PSXFIN) and NO$PSX. I will note that the game boots past the security check in PCSXR too, but it also skips many intro videos. I find it extremely odd that the only emulator which actually emulates the original HC05 firmware dump from the Motorola chip (which is NO$PSX) actually fails to boot the game.

The game however, runs perfectly on XEBRA, ePSXe and MEDNAFEN.

I have the source code to PCSXR, and I've tried disabling and playing with the timing of some HC05 commands, but yet, nothing seems to alter the security check.

I've done some reversing in IDA, and one address that seemed like a good area to look at was 0x80020DF8. With that said, LameGuy64 has managed to make a patch which bypasses the first check in NO$PSX (simply enter these instructions at the said address) and manually replace each instruction.

Code: Select all

; Set address 0x80055388
lui a0,$8005
ori a0,$5388

; Write first word
lui v0,$8001
ori v0,$ce38
sw v0,0(a0)

; Write second word
lui v0,$0000
ori v0,$0133
sw v0,4(a0)

; Set the registers
lui v0,$8015
ori v0,$fd4c
lui v1,$0000
ori v1,$0133
lui a0,$8012
ori a0,$94c8
lui a1,$8012
ori a1,$9480
lui a2,$0000
ori a2,$0133
lui t0,$8005
ori t0,$51f0

; Branch to jr instruction
beq zero,zero,$80020ebc
nop

However, once the patch is entered and you've bypassed it, if you keep playing the game up until it asks for the second disc (which is about 4 minutes of video), the second security check takes places and repeats the same error screen in my first post.

My assumption is that the game is checking something to do with the CD access. It could be checking an interrupt response, a certain commands timing or simply the table of contents.

Note that my file versions are as followed:
- NO$PSX V2.0.
- XEBRA 180107 (07/JAN/2018?).
- MEDNAFEN V1.21.2.

[Administrator]

Update. It works in NO$PSX V1.6, but I don't see any change logs...

EDIT: Found them: http://problemkaputt.de/psxnew.htm

[likeabaus]

I find the developer's approach to handling 'piracy' pretty comical in this case lol. Pretty strange that it seems to work fine on real hardware, but some of the emulators fail whatever check is in place. You would think whatever mechanism/check they used would be effective against real hardware modchips and the swap trick maybe, but it certainly doesn't seem that way. Very odd.

[Administrator]

Okay, last and final update. The security check is checking for the "swap trick" since the TOC (table of contents) is not updated. Some emulators do not update this correctly. If we take the emulator XEBRA as an example, it does update the TOC correctly. This is a major bug in NO$PSX 2.0 that needs to be fixed.

[rama3]

So basically, it looks for the correct TOC?

I guess you won't need the tests then?

[Administrator]

So basically, it looks for the correct TOC?

I guess you won't need the tests then?

Yes.

Nope. Haha. Thanks anyway 'rama3'!