Sunday, July 13, 2008
anti-cheat for multiplayer games
The ultimate anti-cheat measure for PC games will be a dedicated OS for playing the game.
The "installer" would place binary blobs in C:\program files\vendor\gamename.
The files would be loaded to self-patch the game during boot, but otherwise, the game runs entirely from RAM. Any swap file or data written to a hard drive must be encrypted.
These files would only hold any 'saved data' and digitally-signed patches to the
game image. The game can only be played in multi-player mode by booting the
computer from CD.
The CD would boot the system into the game's dedicated OS.
Completely contained in RAM.
The first stage of the bootloader would verify the integrity of the digitally-signed
OS files on the CD/DVD, and verify that the data is actually being read from an internal
CD drive, and not a USB stick.
It would be responsible for verifying that it was running on real hardware, and not a
virtual machine, and writing back encrypted hardware information to a binary blob.
Any detected attempt to operate the game on say virtual hardware, or specifically
banned hardware, results in permanent
deactivation written to the binary blobs, which the user is not notified about until the last
boot stage (After information about the "deactivation for hacking" is uploaded to
the manufacturer's game servers, to ensure merely "restoring some files from backup"
won't reverse the deactivation).
First OS
would also be responsible for verifying that the C:\ directory containing game patches
resides on an ATA, SATA, or SCSI drive, verifying that the Serial number, volume serial,
and make on the drive matches data in an encrypted header file (in the binary blobs),
proving the files have not been moved to a different drive.
(It is not permissive to restore to a new drive from backup, the software must be reinstalled.)
(The hard drive and other hardware verifications would be repeated at each OS loading
stage, upon any detection of hardware change, and every 30 minutes or so, during gameplay)
The verifications would be at independent codepoints, so a hacker patching the binary would
have more trouble finding all the different places where the verification is done in a different
way.
Next the first "binary blob" would be loaded into the RAMDISK and the patch applied to the game binary. Each blob would be provided by the manufacturer and contain a patch to the game binary.
Patches to the loader OS other than the game binary would be done, but would have to be digitally signed.
The individual patches are signed only with a SHA256 sum, but the binaries being patched have not been started yet.
Each _entire_ patched codebase (game binary, os binary) is signed, and the codebase's SHA256 sum is contained in a binary data blob. The digital signature and then the SHA256 sums will be verified before the second OS, or the game binary is started.
Both OSes will repeat the same verification and load only binaries with a properly-signed digest.
After all digital signatures are verified, the loader OS transfers control to the "second game OS"
(the fully patched OS that has all features such as networking support, that the game will be run under)
The second OS will immediately connect to the game server to upload some feedback
about the verification process: all encrypted with a server's public-key and tied to the
customer's serial number, a special "product key", IP address, and MAC addresses of all NICs:
if there was an attempt to hack something, successful or not, the blob of information will probably indicate it.
(Because the information uploaded will provide many details about the environment, hardware, and even unusual elements not part of the "verify to boot" process)
Periodic binary patches would be released to the game _just_ to move key areas of the
OS and game code around, and adjust protocols, to keep cheaters having to constantly
re-hack the code, if they ever figured out Version X: Version X+1 will be coming out in a few
weeks.
This doesn't need to be done manually: a special compiler can be used that randomizes
the memory areas, or applies slightly different code optimizations.
It doesn't prevent hacking, but it makes automatic patching very hard.
The game binary version and OS version will be checked.
If a new version of either is available, the patch is downloaded.
The binary blobs on the hard drive are automatically updated to combine
all patches into one patch. Then the system reboots.
If all signatures check out, the versions are the latest, then the server will send
an "approval key" (valid for 1 connection and a max lifetime of 5 minutes), which
is linked to user's Serial Number, IP, and E-mail address. The game binary starts.
The game binary will self-validate itself and its host OS (to detect any alterations).
The game binary will connect to the game server.
The game will present its approval ID to the game server.
It will re-run SHA256 checksum and additional checksums of itself, the host OS,
and certain areas of memory, and present those to the game server.
Along with player's e-mail address, and password.
The final step is for the gameserver to approve or reject the connection.
All traffic exchanged with the game server or other players will be over a
TLS-encrypted channel, except for untrusted information (such as chat).
With special monitoring proceduers in place to detect any attempt to tamper with
connections.
(Every client has a unique X.509 certificate for SSL, digitally signed by the game maker,
every server has a similarly verified X.509 certificate, and a specific, strong encryption
algorithm is utilized, completely outside the user's control.) ¶ 12:28 PM
The "installer" would place binary blobs in C:\program files\vendor\gamename.
The files would be loaded to self-patch the game during boot, but otherwise, the game runs entirely from RAM. Any swap file or data written to a hard drive must be encrypted.
These files would only hold any 'saved data' and digitally-signed patches to the
game image. The game can only be played in multi-player mode by booting the
computer from CD.
The CD would boot the system into the game's dedicated OS.
Completely contained in RAM.
The first stage of the bootloader would verify the integrity of the digitally-signed
OS files on the CD/DVD, and verify that the data is actually being read from an internal
CD drive, and not a USB stick.
It would be responsible for verifying that it was running on real hardware, and not a
virtual machine, and writing back encrypted hardware information to a binary blob.
Any detected attempt to operate the game on say virtual hardware, or specifically
banned hardware, results in permanent
deactivation written to the binary blobs, which the user is not notified about until the last
boot stage (After information about the "deactivation for hacking" is uploaded to
the manufacturer's game servers, to ensure merely "restoring some files from backup"
won't reverse the deactivation).
First OS
would also be responsible for verifying that the C:\ directory containing game patches
resides on an ATA, SATA, or SCSI drive, verifying that the Serial number, volume serial,
and make on the drive matches data in an encrypted header file (in the binary blobs),
proving the files have not been moved to a different drive.
(It is not permissive to restore to a new drive from backup, the software must be reinstalled.)
(The hard drive and other hardware verifications would be repeated at each OS loading
stage, upon any detection of hardware change, and every 30 minutes or so, during gameplay)
The verifications would be at independent codepoints, so a hacker patching the binary would
have more trouble finding all the different places where the verification is done in a different
way.
Next the first "binary blob" would be loaded into the RAMDISK and the patch applied to the game binary. Each blob would be provided by the manufacturer and contain a patch to the game binary.
Patches to the loader OS other than the game binary would be done, but would have to be digitally signed.
The individual patches are signed only with a SHA256 sum, but the binaries being patched have not been started yet.
Each _entire_ patched codebase (game binary, os binary) is signed, and the codebase's SHA256 sum is contained in a binary data blob. The digital signature and then the SHA256 sums will be verified before the second OS, or the game binary is started.
Both OSes will repeat the same verification and load only binaries with a properly-signed digest.
After all digital signatures are verified, the loader OS transfers control to the "second game OS"
(the fully patched OS that has all features such as networking support, that the game will be run under)
The second OS will immediately connect to the game server to upload some feedback
about the verification process: all encrypted with a server's public-key and tied to the
customer's serial number, a special "product key", IP address, and MAC addresses of all NICs:
if there was an attempt to hack something, successful or not, the blob of information will probably indicate it.
(Because the information uploaded will provide many details about the environment, hardware, and even unusual elements not part of the "verify to boot" process)
Periodic binary patches would be released to the game _just_ to move key areas of the
OS and game code around, and adjust protocols, to keep cheaters having to constantly
re-hack the code, if they ever figured out Version X: Version X+1 will be coming out in a few
weeks.
This doesn't need to be done manually: a special compiler can be used that randomizes
the memory areas, or applies slightly different code optimizations.
It doesn't prevent hacking, but it makes automatic patching very hard.
The game binary version and OS version will be checked.
If a new version of either is available, the patch is downloaded.
The binary blobs on the hard drive are automatically updated to combine
all patches into one patch. Then the system reboots.
If all signatures check out, the versions are the latest, then the server will send
an "approval key" (valid for 1 connection and a max lifetime of 5 minutes), which
is linked to user's Serial Number, IP, and E-mail address. The game binary starts.
The game binary will self-validate itself and its host OS (to detect any alterations).
The game binary will connect to the game server.
The game will present its approval ID to the game server.
It will re-run SHA256 checksum and additional checksums of itself, the host OS,
and certain areas of memory, and present those to the game server.
Along with player's e-mail address, and password.
The final step is for the gameserver to approve or reject the connection.
All traffic exchanged with the game server or other players will be over a
TLS-encrypted channel, except for untrusted information (such as chat).
With special monitoring proceduers in place to detect any attempt to tamper with
connections.
(Every client has a unique X.509 certificate for SSL, digitally signed by the game maker,
every server has a similarly verified X.509 certificate, and a specific, strong encryption
algorithm is utilized, completely outside the user's control.) ¶ 12:28 PM
