kexec is a Linux kernel module that allows to boot another kernel. The idea of this alternative method to creating a recovery system is simply to use the standard Milestone boot and kernel as it were a “fat” BIOS, only to boot another kernel of our choice. According to this link, the kexec attack should be possible, and in fact might be the only way to gain control of the boot process.

Montagnard originally proposed doing something similar to MDijkstra's kexec, but creating a device file with an ioctl matching kexec's system call instead of the technique of patching the system calls table which MDijkstra used. Status: not implemented.

[mbm] once suggested trying this other code. Status: just an idea, nobody tried.

XVilka suggested using a modified version of 2nd-boot for this, and forked it into his own 2ndboot-ng. Status: code is incomplete; has been superseded by more recent attempts.

MDijkstra (a.k.a Mauritsch) put together a kexec module for the Milestone based on the standard Linux kexec. Source code here and precompiled binaries here. Status: it compiles and has been successfully inserted into the Milestone's kernel, but crashes phone upon useage. It is not yet known whether the crash occurs on the parent or child kernel; closed (author is working on Yakk's 2nd-boot attempt).

Ksplice can apply patches to the Linux kernel without rebooting the computer. Ksplice takes as input a unified diff and the original kernel source code, and it updates the running kernel in memory. Using Ksplice does not require any preparation before the system is originally booted (the running kernel does not need to have been specially compiled, for example). In order to generate an update, Ksplice must determine what code within the kernel has been changed by the source code patch. Ksplice performs this analysis at the ELF object code layer, rather than at the C source code layer.

To apply a patch, Ksplice first freezes execution of a computer so it is the only program running. The system verifies that no processors were in the middle of executing functions that will be modified by the patch. Ksplice modifies the beginning of changed functions so that they instead point to new, updated versions of those functions, and modifies data and structures in memory that need to be changed. Finally, Ksplice resumes each processor running where it left off.

To be fully automatic, Ksplice's design was originally limited to patches that did not introduce semantic changes to data structures, since most Linux kernel security patches do not make these kinds of changes. For patches that do introduce semantic changes to data structures, Ksplice requires a programmer to write a short amount of additional code to help apply the patch. ¹⁾

If you know how to use it on a Milestone, please let us know.

KSplice has two main functional parts, the first is ksplice-create that will perform a pre-post matching on the build system and produce an update file, the second is ksplice-apply that read the update file on the target system and perform a run-pre matching to patch the kernel on-the-fly.

The Ksplice paper has described the concept, theory and evaluation. Please take a look if you are seriously going to create a hot patch.

It is not sure whether ksplice-apply can be executed correctly on Milestone and how the second step will be. Someone with Milestone is encouraged to do the test.

1. Assumed directory structure:

   ~/
    android/      # just a place holder, not ASOP.
    kernel/     # The Milestone kernel source.
    out/        # The build output folder generated from a make.

2. Build needed libraries for ksplice (libbfd)

   cvs -z 9 -d :pserver:anoncvs@sourceware.org:/cvs/src login
   {enter "anoncvs" as the password}
   cvs -z 9 -d :pserver:anoncvs@sourceware.org:/cvs/src co binutils
   cd binutils/bfd
   ./configure --enable-targets=arm-eabi --prefix=$HOME/build/cross
   make
   make install
   

3. Install from source and patch:

   git clone http://www.ksplice.com/git/ksplice.git
   cd ksplice
   patch -p0 < ksplice.patch
   ./configure --with-libbfd=$HOME/build/cross/lib/libbfd.a --with-bfd-include-dir=$HOME/build/cross/include
   make
   sudo make install

   ksplice.patch

   --- /usr/local/share/ksplice/kmodsrc/ksplice.c.old      2010-03-07 06:08:43.000000000 +0000
   +++ /usr/local/share/ksplice/kmodsrc/ksplice.c  2010-03-07 06:16:34.000000000 +0000
   @@ -4098,13 +4098,13 @@
           return NULL;
    }
    
   -static inline int within_module_core(unsigned long addr, struct module *mod)
   +static inline int _within_module_core(unsigned long addr, struct module *mod)
    {
            return (unsigned long)mod->module_core <= addr &&
                   addr < (unsigned long)mod->module_core + mod->core_size;
    }
    
   -static inline int within_module_init(unsigned long addr, struct module *mod)
   +static inline int _within_module_init(unsigned long addr, struct module *mod)
    {
            return (unsigned long)mod->module_init <= addr &&
                   addr < (unsigned long)mod->module_init + mod->init_size;

4. Prepare the Milestone kernel and generate the config once if you haven't done so. You should only need to have the .config and System.map generated(although I'm not sure at what stage they're being generated), because everything will be re-built by ksplice anyway.
5. Copy .config and System.map to kernel/ksplice as this is the ORIG_CONFIG expected by ksplice.

   cd ~/android
   mkdir kernel/ksplice
   pushd out/target/pr/generic/obj/PARTITIONS/kernel_intermediates/build
   cp .config System.map ~/android/kernel/ksplice
   popd
   

6. Copy the source file you want to change and append the extension .patched_ext and execute:

   export CROSS_COMPILE=arm-eabi-      # Specify the cross compiler.
   ksplice-create --diffext=.patched_ext kernel          # or ksplice-create --prebuild kernel if you just wanna try.
   

As a last resort, man ksplice-create and read the source! Consult the ksplice online source archive for better code browsing and understanding.

If we make real changes in kernel tree, we see error. Also on ksplice site we can read, that changes, which change many symbols ane not applied in automatic mode. So unusable for us.

This type of attack takes advantage of the root hack in order to alter the normal boot and recovery processes. It allows us to get some degree of backup & restore functionality in order to recover a dead phone. It is not useful for booting a different kernel.

Poseidon has adapted the nandroid script in his ADBrecovery tool for the Milestone. See how to run ADB in Recovery Mode.

vekexasia's proof-of-concept lol.sh method here involved embedding a script in a doctored update.zip which worked via the same mechanism as the Droid rooting (created using the Volez tool following the process outlined here). This has not been developed into a full-blown recovery solution. Use ADBrecovery instead.

A.k.a. the Newton hack. The init.rc script resides in the signed boot CG, so we cannot alter it. But it happens to exec /system/bin/mot_boot_mode, which we CAN change once we run as root, since it's located inside the system CG. By moving mot_boot_mode to mot_boot_mode.bin and creating a shell script as our new mot_boot_mode, we can get the system to run commands of our choice such as mounting partitions, etc. This is the earliest we can tap into the boot process, and it is early enough to let us introduce hacks such as APPS2SD, making better use of /cache, and other useful stuff. We could even branch to load a new kernel using kexec like mechanism.

It simply consists in running the following as root:

mv /system/bin/mot_boot_mode /system/bin/mot_boot_mode.bin
cat > /system/bin/mot_boot_mode <<EOF
#!/system/bin/sh
# Do not modify the following line
/system/bin/mot_boot_mode.bin 
# Append here any commands that you wish to run during the phone boot
EOF
chmod 755 /system/bin/mot_boot_mode

Then you can add any commands to the /system/bin/mot_boot_mode script.

This attack would entail leaving the boot code untouched but changing the execution path on-the-fly with the aid of some hardware modification that should interfere with the front bus. This attack would enable us to boot any kernel, but it would only benefit the modified phone - it would not be useful for unmodified phones.

As proposed by spacefish: “As seen in the boot process, the mbmloader verifies the recovery partition and so on via the CDT Table. This is normally done by hashing the partition and comparing the signature or whatever. After this there should be a simple decision which sets the instruction pointer to the bootloader with “signature failed errorcode” registers set or set the instruction-pointer to a routine that loads the specific partition. So maybe we could use a FPGA that sniffs the address bus between ram and processor and forcefully change to another address if the address of the bootloader failsig is accessed?”