Slot check security: Difference between revisions

From NeoGeo Development Wiki
Jump to navigation Jump to search
(Fixed link to MAME source code)
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
[[File:S3warning.png|frame|Warning screen as shown by [[Sengoku 3]] when booting on MVS hardware with BIOS_MVS_FLAG set to 0 (AES mode).]]
[[File:S3warning.png|frame|Warning screen as shown by [[Sengoku 3]] when booting on MVS hardware with BIOS_MVS_FLAG set to 0 (AES mode).]]


Slot checking is a cartridge system security measure introduced by some games produced after 2000 due to the emergence of [[bootleg MVS boards]], which displays a warning screen and locks the game up if some checks fail.
Slot checking is a MVS security measure added in some games produced after 1998 due to the emergence of [[bootleg MVS boards]]. It displays a warning screen and locks the game up if some checks fail.


Someone who would want to bypass this check will typically search for the warning text in the [[P ROM]] and references to it in the code. Such text can't be found because the checking routine uses a NOT'ed version of the same text instead, probably to confuse hackers.
Someone who would want to bypass this check will typically search for the warning text string in the [[P ROM]] and references to it in the code. Such text can't be found because the checking routine uses a XORed version of the same text instead, certainly to confuse hackers.


The checking code first sets one out of two values in VRAM at the unused address $7FFF depending on two checks:
=KOF 98=
*The calendar data location in the [[BIOS RAM locations|BIOS RAM]] ($10FDD2 and up) is cleared, then BIOSF_READ_CALENDAR is called. If BIOS_MONTH($10FDD3) is greater than 13, the check fails.
*If BIOS_MVS_FLAG($10FD82) is zero (AES mode), and bit 7 of REG_STATUS_B($380000) is set (MVS hardware), the check fails.


That VRAM value is then read back and compared to set $10FCEF or not. The last check is done with the [[FIX_CLEAR]] bios call, which sets $10FCEF and makes the game pass the test.
If the game figures out it is being run for the first time on the system (thanks to [[backup RAM]] data), it forces a [[watchdog]] reset. If the system doesn't reset itself after a certain amount of time (due to the eventual absence of the watchdog circuit), the game displays the warning screen and locks up.
 
=Other games=
 
*The calendar data zone in the [[BIOS RAM locations|BIOS RAM]] is cleared, then [[READ_CALENDAR]] is called. If {{BR|BIOS_MONTH}} is greater than 13 (should be 12 ? Is that a bug ?), the check fails. This causes bootleg boards with no [[RTC]] to trigger the security.
*If {{BR|BIOS_MVS_FLAG}} is zero (BIOS in AES mode), and bit 7 of {{Reg|REG_STATUS_B}} is set (MVS hardware), the check fails. This causes bootleg boards using a copy of the AES system ROM or those that don't handle REG_STATUS_B reads to trigger the security.
 
Depending on the result of those checks, the value $8B55 (pass) or $9DBD (fail) is written to [[VRAM]] at $7FFF. This furthermore verifies that the board has full VRAM.
 
That VRAM value is then read back and added to $74AB (=$10000 if checks passed) to set the byte at $10FCEF (fail) or not.
 
A later version of this procedure also times the Z80 reply to command $01. $10FCEE = $FF if Z80 was too slow.
 
Todo: Add more details.


==Use by games==
==Use by games==


As seen in MAME's source ([[http://mamedev.org/source/src/mame/drivers/neogeo.c.html neogeo.c]]), a few games are known to do this check:
As seen in MAME's source ([[https://github.com/mamedev/mame/blob/master/src/mame/drivers/neogeo.cpp neogeo.cpp]]), a few games are known to do this check:


*[[Nightmare in the Dark]]
*[[Nightmare in the Dark]]

Latest revision as of 22:40, 23 June 2017

Warning screen as shown by Sengoku 3 when booting on MVS hardware with BIOS_MVS_FLAG set to 0 (AES mode).

Slot checking is a MVS security measure added in some games produced after 1998 due to the emergence of bootleg MVS boards. It displays a warning screen and locks the game up if some checks fail.

Someone who would want to bypass this check will typically search for the warning text string in the P ROM and references to it in the code. Such text can't be found because the checking routine uses a XORed version of the same text instead, certainly to confuse hackers.

KOF 98

If the game figures out it is being run for the first time on the system (thanks to backup RAM data), it forces a watchdog reset. If the system doesn't reset itself after a certain amount of time (due to the eventual absence of the watchdog circuit), the game displays the warning screen and locks up.

Other games

BIOS_MONTH ( $10FDD3) is greater than 13 (should be 12 ? Is that a bug ?), the check fails. This causes bootleg boards with no RTC to trigger the security.

  • If

BIOS_MVS_FLAG ( $10FD82) is zero (BIOS in AES mode), and bit 7 of REG_STATUS_B is set (MVS hardware), the check fails. This causes bootleg boards using a copy of the AES system ROM or those that don't handle REG_STATUS_B reads to trigger the security.

Depending on the result of those checks, the value $8B55 (pass) or $9DBD (fail) is written to VRAM at $7FFF. This furthermore verifies that the board has full VRAM.

That VRAM value is then read back and added to $74AB (=$10000 if checks passed) to set the byte at $10FCEF (fail) or not.

A later version of this procedure also times the Z80 reply to command $01. $10FCEE = $FF if Z80 was too slow.

Todo: Add more details.

Use by games

As seen in MAME's source ([neogeo.cpp]), a few games are known to do this check:

Sengoku 3: Checks M1 ROM too, displays "M1-ROM ERROR." if Z80 doesn't reply to command 1 in $7FFF iterations loop.

Retrieved from "https://wiki.neogeodev.org/index.php?title=Slot_check_security&oldid=5701"