CMS Image Format and Modification Techniques
The main CMS flash ROM image format, as found in cms4.4.03raptor.cru, consists of the following parts:
Header (192 bytes) with version information and other data
ROM image itself, compressed with the standard gzip deflate algorithm
DSA signature applied by Transmeta
The trailing signature is used to ensure only authenticated CMS updates are accepted by the update mechanism (accessible from x86 mode via various MSRs) before being written to the flash ROM. The DSA public key is contained in CMS around address 0x182654, while the private key is known only to Transmeta. This makes it impossible to load unsigned updates, at least if the normal update mechanism is used.
However, there is a back door: if we can alter the running CMS image in RAM, we can simply overwrite the public key with our own, or just patch the signature checking code to skip the verification step. Since the CMS private RAM is not accessible via x86 generated physical addresses, there are two methods of accessing it:
Using dedicated hardware (i.e., DRAM analyzer) or specialized system board with front side bus redirection circuitry. This is obviously not practical without physical access to the machine and appropriate hardware equipment.
Certain common peripheral chipsets (e.g., ethernet DMA controllers or IDE controllers) can be tricked into DMAing directly to/from CMS physical memory due to implementation bugs in the chipsets and the TM58xx processor. Again, this is not practical or possible on all Crusoe-based boards. It can also be very dangerous to wildly redirect DMAs to arbitrary bus addresses, unless you’re an experienced hardware hacker.
Fortunately for Transmeta and its end users, this backdoor is difficult to exploit without the consent of the user, since it does require both x86 kernel level access and in some cases physical access to the machine. However, if you are experienced enough to be reading this, such limitations are unlikely to be a problem.
Discuss (6 comments)