Paul Crowley asks: > I'm informed that malware authors often go to some lengths to prevent > their software from being disassembled. Could they use Palladium for > this end? Are there any ways in which the facilities that Palladium > and TCPA provide could be useful to a malware author who wants to > frustrate legitimate attempts to understand and defeat their software?
Palladium provides a "curtained" memory area where software is supposed to be relatively free from being accessed or modified. (Apparently it can be configured to be debugged when in this area by the use of "test keys".) If disassembling a program requires access to it in memory, then this curtained memory region could present an obstacle to disassembling. However in most cases the memory would be loaded from the disk so having access to the program on disk would allow you to disassemble it just as well as if it were in memory. From what has been said about Palladium, it will not support encrypted programs. However that might not stop a determined malware author from having the program encrypt itself when it first runs (using the "virtual vault" concept) and store the encrypted version on the disk, deleting the original plaintext version. The Palladium vault technology would then make it impossible for any other software to decrypt that data. The malware might not be able to use the regular Palladium program loader to run its encrypted portion, but conceivably it could "manually" load that encrypted data into the curtained area, decrypt it using a key accessible only to itself, and then run. This would still leave the program vulnerable until the first time it runs, but afterwards it would be impossible to get at the program text in the clear. A program could reduce its window of vulnerability if it were distributed in encrypted form, using a key that would be provided by a remote server - which could even be any other infected computer! The program stub would start up, use Palladium attestation to connect reliably to another virus-corrupted instance of itself on the net, and receive a global, system-wide key. This key would be kept locked in the "virtual vault" and would decrypt the remainder of the program, which could then run in the curtained area. Even if all instances of the virus shared the same key or set of keys, it would be impossible for non-virus programs or programmers to get access to the key except by hacking their hardware, scraping out a key, and creating a virtual Palladium system. So the main question at this point is how program code and/or data gets loaded into the curtained area, and whether it would be possible to load encrypted data into that area, decrypt it and then run it as code. There is a computer design called the Harvard architecture which has a strict separation between code and data space, and conceivably Palladium could use a similar approach to make it impossible to run decrypted code. Adopting this approach would add credibility to Microsoft's promises not to use Palladium for software copy protection. But if they don't go to such an extreme, it is likely that Palladium would allow the use of various techniques to help malware hide from its opponents. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
