Torin,
It might be useful to investigate Nandroid and related discussion
during its original development.
I haven't tried to pull raw images off in a while (last time was
Android 1.0 or 1.1). I remember having some bizarre corruption, but no
kernel crash. I used /dev/mtd/mtd[0-5]ro and dd from a static busybox
binary someone (maybe Benno?) built for Android.
Also, if my notes are correct the partition layout for the msm_nand on
the HTC Dream is:
mtd0 -> misc
mtd1 -> recovery (environment booted when holding home and power)
mtd2 -> boot (with the kernel image for the normal environment)
mtd3 -> system (/system partition)
mtd4 -> cache
mtd5 -> userdata (/data partition)
The XDA forum might be more insightful for learning out what various
people found right after the G1 was released.
Also, what sort of use case were you thinking of for the verification?
Online? Offline? An example of the offline use case would be for the
user/IT personnel to verify the system is in a known state. If you
would be willing to trust the SPL (hardware bootloader), you could
make use of the "fastboot boot" option, which I believe is enabled on
production HTC Magic phones. You could then modify the default
recovery image in Android's source code to make a special one that
reads the raw partition data (like Nandroid) and print the hashes to
the screen. Then, you can boot that image from your PC using "fastboot
boot custom-image.img", for example. Also, instead of printing the
hashes, you can bake the hashes of known firmware into the image and
just print the version number and a string that says "verified".
Note that it is possible to modify the SPL and apply a custom SPL to a
phone (if you gain root), so this method is not fail proof. However,
you may be able to play games with your adversary, but I haven't
thought about this in depth. For example, if your custom boot image
does something unique in a way that you can be reasonably sure that a
modified SPL can't permit while still changing the hash values, then
you have a leg up in a mini-arms race. That is, the SPL had to be
modified before you get your hands on the device, and you get to
change that unique characteristic after you get your hands on the
device.
-Will
On Nov 3, 2009, at 11:04 AM, Torin Walker wrote:
I am serious about finding an answer, but I am forced to work with
devices in the field which means, at least for the present, no TPM at
my disposal.
Though theoretically a kernel could produce whatever values it wants
through /dev/mtd/mtd1,2, one could trust it to the point that an
attacker would have to perform some minor surgery on the kernel if he
were to spoof the values from a legitimate one. While it's not
foolproof, it does increase the complexity of overriding the security
inherent in performing a hash on the bootloader and kernel values,
which adds *some* level of additional security against casual script-
kiddie attacks. (Unless the script kiddie has an Uncle Torvalds, of
course.)
This brings me back to my original supposition that I should like to
perform a signature on the stream that comes from /dev/mtd/mtd1,2,
which I seem unable to do. I assume that if one can back up the
bootloader and kernal images merely by
cp /dev/mtd/mtd1 /tmp/bootloader_image.backup
cp /dev/mtd/mtd2 /tmp/kernel_image.backup
it stands to reason that I should be able to run the file through an
MD5 or other suitable checksum. Doesn't it? If so, why does it crash
so heinously?
I'm in the process of git'ting the Android cupcake kernel so I can
wade through the /dev/mtd/mtd* code to see why my assumption has
failed. With any luck, someone here will shortcut my efforts with an
explanation.
Torin...
--
On Nov 2, 7:59 pm, "[TH]" <[email protected]> wrote:
This is the Root of Trust (ROT) question, which seems
to be asked again and again. (e.g. how do I know the pre-boot
environment and the loader have not been tampered with, etc etc).
If you are serious about seeking an answer,
I would suggest looking at the work of the folks
in the Trusted Computing Group (TCG), in particular
on using the TPM hardware as a root of trust.
And no, the TCG and TPM is not about DRM :-)
/thomas/
hardjono[at]mit.edu
On Nov 1, 5:12 pm, Torin Walker <[email protected]> wrote:
I'm looking for a way to authenticate the bootloader and kernel
images
to ensure the OS has not been tampered with from some factory
default.
One way I imagined doing this is to perform a cryptographic hash on
/dev/mtd/mtd1 (bootloader image), and
/dev/mtd/mtd2 (kernel image),
but opening up either of these devices into a CheckedInputStream
(for
CRC32 validation, for example) results in an enormous crash. Not
only
does the device stop responding, but the android debug bridge
crashes
and no longer recognizes any attached devices until Windows Vista
(go
figure) is rebooted.
Can anyone suggest a better method for validating that the Operating
System has not changed (i.e. The bootloader and kernel are factory
defaults?)
Torin...- Hide quoted text -
- Show quoted text -
--
William Enck
PhD Candidate
Department of Computer Science and Engineering
The Pennsylvania State University
[email protected]
