@Serantes Isn't the data encrypted in the hard drive and decrypted as needed in memory? If so, your method will not work. My understanding is you start the game, and the game will access the hard drive decrypting whatever it needs on the fly in the RAM (maybe some swap as well?), so connecting the HDD to another computer will only allow you to see the encrypted data, not decrypted. But I'm not all that knowledgeable, so I probably misunderstood what you said
The hardware encryption will have to be via a HDD key (think xbox 1 and drivelock for laptops) that enables access to the data. Hot swapping like he described should work just fine. Key is given, drive is unlocked and can be used as usual - this is how all PC hardware encryption works - else the computer wouldnt work, as it expects a normal hard drive and to access it normally. If the disk is partitioned like the other user said - his plan sounds completely correct.
That looks like a big fail in the implementation of the encryption... I mean, why implement such encryption, if it'll be that easy to "bypass"? Anyway, thanks for clarifying
I think it is probably because they figure their target audience (operators) aren't technically advanced enough to go through the work of hacking the system and/or duplicating the hardware.
The key isnt supposed to be hardcoded into the machine, laptops etc would prompt for the password. No password, no data. Its not a bug, its how its supposed to work. This is what happens when you reuse PC hardware in a way its not designed to be used. However, Id imagine the SSD could be made to monitor the sata connection and if its disconnected - "unmount" the drive.
Hot swapping the ssd isnt a "bug" thats exactly how sata is supposed to work. It doesnt matter if the hard drive is custom - its a sata device, it works as a sata device does. The type of nand chips or anything else doesnt matter to the sata side of things - thats all handled by the on board controller. I would call it an exploit or loophole, not a "bug" as its working as intended. However, the plan above wasnt about clone ssds to use in a ringwide machine - it was about playing them on the PC.
So does that mean if you unlock the drive by unplugging it after booting the ringedge that it would become unusable if I power down the ringedge before adding the hard drive back in?
You are supposed to unlock the drive by entering a password. If a laptop went missing, the password would be asked for and you wouldnt be able to access the data. This is the issue with having the key provided automatically - be it hot swapping or sniffing the key as its provided by the bios. If you have the machine, you have the password - which is the fatal flaw with this plan. Using the hard drive in a laptop, as it was designed - the password isnt with the drive, its in the users head. This is reusing tech that isnt designed to protect things like this.
Once it boots you can do an attack on the ram and break the tc if you had access to the right equipment. http://www.scribd.com/doc/130070110/Extracting-Encryption-keys-from-RAM
Binary would be in memory ? They would be stupid to have the bios drop it on the SSD unecrypted portion...
I guess there was some misunderstanding to my point. My point was related to the TrueCrypt volumes mentioned by soyandroid. It was my understanding that TrueCrypt encrypts the data and only decrypts the data that is requested on-the-fly to the RAM / Swap, not to the same or another unencrypted volum. Connecting the harddrive to another computer as suggested by Serantes would not grant access to the decrypted data, as this resides in the RAM / Swap where TrueCrypt application is running. That's why I pointed out the implementation is a big fail. I guess this answers my doubts about it.
Yes, but the password to the truecrypt volume has to be on the windows partition to unlock the encrypted partition - as no one enters the key manually. This is why he said to do the hotswap to get access to the Windows Partition, trojan it (basically some remote access of some sort) then boot it as normal and sniff the key that is passed through to truecrypt when it mounts the encrypted volume. This is what happens when you have the lock and the key on the same device
Binary = any file on your machine.The bios doesnt drop it anywhere, it would be a file on the Windows partition. They assumed its safe due to the "hardware encryption". It sounds as simple as something like: truecrypt.exe PATHTOKEYFILE d: Running filemon shows you what file a process uses, so you can see which is the keyfile. Copy that back to your PC and presto.
This is where my confusion came from: I originally understood he was accessing the Truecrypt volume directly during hotswap; not the Windows Partition. Silly me