how are daemon-tools able to emulate a bad copy of a safedisc-protected cd? i always thought, the bad sectors contained a key that is necessary to decrypt the encrypted executable file of a game? how do the daemon-tools know this key?
Announcement
Collapse
No announcement yet.
Emulation and safedisc key
Collapse
X
-
SafeDisc1 was created in a time only few writers were able to write RAW sectors (at least before SAO-RAW write mode was used)
so backups of SafeDisc created with a so-called cooked write mode made the bad sectors good - so no errors were reported and the protection knew it wasn't the original cd - that's it but then almost all newer writers were able to write DAO-RAW96 and that was SafeDisc1's dead, also old SecuROM's dead (sub-channel based).Everybody be cool! You, be cool!
They'll keep fighting! And they'll win!
Comment
-
ok about the raw mode (but you need raw-96 only for correct writing of all 8 subchannel-bits, not needed for sd).
but sd1 definitely encrypts the original executable file of a game, which is then called xxx.icd. the xxx.exe file is only the safedisc loader, which decrypts the xxx.icd using the tea algorithm and a key stored on the cd. and if as i already mentioned, i thought this key is calculated from the position of the bad sectors. if you copy in raw mode, the bad sectors are present on your copy, so also the key is. but if you copy in cooked mode (corrected ecc)
the key is gone. so how does emulation work, how can the xxx.icd file be decrypted when the needed key is not present?
Comment
-
well, of course i understand that. the only thing i want to know is: do daemon-tools store a key for every game / every version of sd? this is the only reasonable explanation, since there is no key on the copied cd.
and concerning macrovision: you can bet they know a lot about that, guess they spend a lot of time analyzing daemon-tools. hopefully without success :mrgreen:
Comment
Comment