View source for Custom recovery:alternative methods

{{:motovergleich.jpg|}}

All of these methods now deprecated.

{|
! Method
! Usefulness
! Difficulty to attempt
! Chance of success
! Status
|-
|[[alternative_methods|IP attack]]
|Low
|Very hard
|Very high
|Hardware modification needed.
|-
|Hardware modification
|Low
|Medium
|Very high
|Modifying the DEVICETYPE pinstrap, to change recognition from High Security mode to General Purpose mode (to disable signature check over mbmloader). See the tech. reference manual for OMAP for details.
|-
|[[pr_attack|PR attack]]
|Maximum
|Hard
|Low
|Awareness of this issue should be much higher for this to have any impact in Motorola's policy.
|-
|[[Mbmloader_replacement_attack|mbmloader replacement]]
|Maximum
|Very hard
|Low, it seems.
|Now that we have a method for determining bootloader compatibility, we're waiting to find valid and signed mbmloaders that are compatible with the Milestone's hardware-stored hash key, but that do not enforce the chain of trust in the loaded mbm. It's unlikely that we will find such thing. If that were solved, we would also be waiting for someone to risk bricking his phone to test it **again**, after we do some more reverse engineering on the ECC NAND writes((Before this, somebody might want to build a module to change the RAM refresh rate. For safety, we should know it works before flashing the Droid CH+MBMLOADER+MBM+MBMBACKUP+CDT on the Milestone since the Droid CH uses a lower refresh rate.)). Total of bricked phones so far: 1 (janneg).
|-
|[[Legal_Attack|Legal attack]]
|Medium
|Very hard
|Low, it seems
|Usefulness would not be very high because it would take several years. Waiting for some kernel hacker, preferently in Germany, to sue Motorola (possibly with the guys at http://gpl-violations.org).
|-
|[[Cryptographic_attack|Crypto attack]]
|Maximum
|Easy
|Practically zero
|Private key is required. Only a hash of the public key is stored in hardware, and we are now able to extract it. But finding a sha1 collision on a new public key would be very hard and there is still the problem of finding pairing private key for such public key.
|-
|[[MBM_backup_attack|mbm backup attack]]
|Maximum
| 
|Zero
|Discarded after static code analysis by yakk.
|-
|[[alternative_methods|ksplice]]
|Medium
| 
|Zero
|Apparently done: a ksplice module has been compiled by XVilka. It worked with a trivial patch, but not with a large one. So, unusable for us.
|}


==== kexec Attack ====

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 [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17953.html this link], the kexec attack should be possible, and in fact might be the only way to gain control of the boot process.


=== First kexec attempt ===

'''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.

=== Second kexec attempt ===

'''[mbm]''' once suggested trying [http://git.openinkpot.org/contrib/reloaded-2.6.git/tree/main.c this other code]. Status: just an idea, nobody tried.

=== Third kexec attempt ===

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

=== Fourth kexec attempt ===

'''MDijkstra''' (a.k.a. '''Mauritsch''') put together a kexec module for the Milestone based on the standard Linux kexec. Source code [http://aegir.org.uk/~maurits/kexec-mod.tar.gz here] and precompiled binaries [http://aegir.org.uk/~maurits/kexec-bin.tar.gz 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 Attack ====

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. (( From http://en.wikipedia.org/wiki/Ksplice ))

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 [http://www.ksplice.com/doc/ksplice.pdf 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.

=== Quick start for the first half (ksplice-create) ===

* Assumed directory structure:
<pre>
~/
 android/      # just a place holder, not ASOP.
 kernel/     # The Milestone kernel source.
 out/        # The build output folder generated from a make.
</pre>
* Build needed libraries for ksplice (libbfd)
<pre>
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
</pre>
* Install from [http://www.ksplice.com/install source] and patch:
<pre>
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
</pre>
<pre>
--- /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;
</pre>
* [[Compiling|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.
* Copy .config and System.map to kernel/ksplice as this is the ORIG_CONFIG expected by ksplice.
<pre>
cd ~/android
mkdir kernel/ksplice
pushd out/target/pr/generic/obj/PARTITIONS/kernel_intermediates/build
cp .config System.map ~/android/kernel/ksplice
popd
</pre>
* Copy the source file you want to change and append the extension .patched_ext and execute:
<pre>
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.
</pre>

As a last resort, man ksplice-create and read the source!
Consult the [http://ksplice.sourcearchive.com/documentation/0.9.9/ ksplice online source archive] for better code browsing and understanding.

=== Some problems with working ===

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.

==== Script Attack ====

This type of attack takes advantage of [[Root_attack|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.

=== ADBrecovery ===

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

=== lol.sh ===

vekexasia's proof-of-concept lol.sh method [http://www.megaupload.com/?d=SWAZ4CF4 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 [http://www.alldroid.org/viewtopic.php?p=14474#p14474 here]). This has not been developed into a full-blown recovery solution. Use ADBrecovery instead.

=== Open Recovery ===

This is based on the mankind's custom update and poseidon's ADB recovery. It uses the doctored update.zip to switch into custom recovery application able to apply custom update zips. See [[recovery_mode|how to run Open Recovery]].

=== mot_boot_mode hack ===

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 [[Hacked_Features|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:
<pre>
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
</pre>
Then you can add any commands to the /system/bin/mot_boot_mode script.


==== Hardware attacks ====

=== IP (Instruction Pointer) attack ===

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?"