Monday, July 11, 2016

A rant about OEM lazieness as it pertains to Proprietary Files

Ever wondered why x device slowed down after an upgrade to the newest android version? Or why y doesn't work on a source built ROM?

A BIG part of the issue is OEM's laziness. The bigger part however, is proprietary binaries.

Quite often, proprietary binaries are not updated for feature inclusion, or improvements, and are only updated for the purpose of making the hardware WORK, not WORK WELL. They often go out of their way to actually update the HAL's/RIL's/Proprietary Blobs.


A great example of this is the RIL. The RIL (Radio Interface Layer) is updated EXTREMELY infrequently.

Android's RIL interface is versioned. The current AOSP revision of it is 11. Now, the ril-daemon (Android component that communicates with the RIL) allegedly supports any RIL revision 6=<.

A great example of these components not being updated is in the Nexus S (crespo). It was upgrade to JellyBean, which natively includes RIL version 7. Instead of updating it to get all the perks, bug-fixes, and patches RIL 7 included, they left the prebuilt RIL 6 and just backported code into ril-daemon to support RIL 6. It is no where near optimized for it, and there is often performance degradation due to this. Though this is an old example, it happens on all modern devices (I've seen it on shamu, hlte, etc.) where the OEM's get lazy.


Another common complaint is GPS lag on updated devices. This is due to the same root problem, just more amplified. GPS blobs are commonly static across multiple major android versions. Run a quick MD5 hash on the pre-update version and post-update version, or look at them in IDA (or really, any dissasembler/decompiler). You'll find it rings true.

Name any piece of hardware (including the CPU), and you'll find a case where some OEM decided to back-port old code to avoid doing hard, time consuming work on older devices. For fun some time, grab any OEM's commit log and grep iot for 'hack'. You will be AMAZED how many times they null out functions, or backport archaic paces of code to avoid actually upgrading (and in the process optimizing) their proprietary blobs for new android versions. I'd also image external vendors have some say in this.  Imagine this, you are a Samsung engineer, you have two options;

- Hack together the current proprietary file set to work for the new android version, and ignore optimization.

or

- Contact every one of the external vendors that has devices onboard the device in question, and pay them all to update the blobs, which could also delay the update indefinitely.

Qualcom/Imagtech/Invensense will only update these binaries if they have to/are paid to.


If you read this, you'll pry realize that this problem isn't easily solved, and, to be honest, the way it is currently done is /probably/ the best way to do it in the current world.

Now, you might say, "Can't the community just update the blobs, cause Android is open source?". That question makes me laugh a little to be honest. Android *itself* is open source, as is the RIL. Though, the AOSP RIL will not work on any devices other than AOSP supported devices (excluding a few lucky cases, like some of 2014/15 Moto phone's due to the Nexus 6 being in AOSP and sharing similar hardware). Due to this, most devices don't have an open source RIL. Many people use AOSP-CAF (Qualcom's 'Code Aurora Forums' version of AOSP), which contains a ton of backports, patches, and additional drivers to support a much wider set of devices. This often allows us to update the RIL aftermarket (similar to what was done to bring the OG Moto G up to Marshmallow), but, these don't contain the initial optimizations that OEM's slaved over pre-release on that device, and will always (in all but a few rare cases) perform at least a tad bit crumbier than the OEM blob on its targeted Android version.


Separately, you also have to realize this:

Smartphone's take more physical damage than almost any other high end electronic (yes, even to those of you who take really good care of them). They ride in our pockets being shaken all about for a large portion of their life. They get dropped occasionally, wet, run through a light rain, etc. So, overtime, your hardware takes a real beating. Having opened up many people's older devices for repair, they are FILLED with random crap (excluding certain brands that manage to keep particles out, namely Samsung, which I dislike, as they are the worst offender of the blobs issue described above). They also get dented, etc. Yet we still expect them to last as long as our PC's, which are often treated much better in comparison. Plus, letting the battery (or really, any device in the phone) get above the recommended temperature even once can permanently effect the device's function, or battery's longevity.

And, in all this, I haven't even began to cover NAND/eMMC/UFS aging which slows down I/O read/write speeds, or the aging of other devices, which is amplified in smartphones due to their MASSIVE amount of uptime compared to most devices.

Tl;DR: Just read it, it contains good info.

Friday, April 22, 2016

Guide to Compiling Android on Ubuntu 16.04 (Xenial Xerus) -- OpenJDK7 Installation on 16.04

Another Ubuntu release, another set of instructions to get Android source to compile.



This only applies to the x64 (64 Bit version). It will not compile on the i386 (32 Bit version).

Ubuntu has opted to dump OpenJDK7 in the Xenial Repositories. This just means we will need to add a custom PPA to install JDK7.

Why go with OpenJDK7 and not OpenJDK8?

Well, OpenJDK7 is required to build most popular AOSP 6.0.x ROM Sources as of right now, some examples include: DU, PN, Any Specific AOSP Tag, OmniROM, and Android-x86.

In order to build anything >=4.4.x you will need Oracle Java 6.

The only use case for OpenJDK8 would be those who only build CM (13+), PacROM (or any other CM derivative for that matter), or the 'master' branch of AOSP.


Follow these instructions exactly (don't just throw 'sudo' around either, it is only to be used in specific cases):


1) Remove all traces of Java:

  • sudo apt-get remove openjdk-* icedtea-* icedtea6-*


2) Add Xenial OpenJDK7 PPA & Fetch the new packages index:
  • sudo add-apt-repository ppa:openjdk-r/ppa && sudo apt-get update


3) Install all currently available updates to ensure no packages are broken:
  • sudo apt-get upgrade && sudo apt-get dist-upgrade


6) Install OpenJDK7 and all Android Build dependencies:
  • sudo apt-get install adb fastboot openjdk-7-jdk git ccache automake lzop bison gperf build-essential zip curl zlib1g-dev zlib1g-dev:i386 g++-multilib python-networkx libxml2-utils bzip2 libbz2-dev libbz2-1.0 libghc-bzlib-dev squashfs-tools pngcrush schedtool dpkg-dev liblz4-tool make optipng maven python-mako python3-mako python python3 syslinux-utils google-android-build-tools-installer

# To install OpenJDK8, replace 'openjdk-7-jdk' ==> 'openjdk-8-jdk'
# To install Oracle Java 6, replace 'openjdk-7-jdk' ==> 'oracle-java6-installer'
# You can install all three Java versions, you will just need to select the default using the 'update-alternatives' command below



7) Remove all unnecessary packages:
  • sudo apt-get autoremove


8) Make a user accessible folder, and add it to path:
  • mkdir ~/bin && echo "export PATH=~/bin:$PATH" >> ~/.bashrc


9) Enable CCACHE to speed up builds:
  • echo "export USE_CCACHE=1" >> ~/.bashrc


10) Restart Bash
  • source ~/.bashrc


11) Configure Git (Replace with your Name & Email Address):

  • git config --global user.name "John Doe"
  • git config --global user.email johndoe@example.com


12) Download Repo, make it executable, and put it in our local $PATH folder:

  • curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo && chmod a+x ~/bin/repo


13) Make a folder for your ROM source of choice (in this case 'android'), and initialize the repo:
  • mkdir ~/android
  • cd ~/android
  • repo init -u UrlOfManifestofROM.git -b BranchName


14) Sync the Repo:
  • repo sync -j4 --force-sync


15) Setup your build enviroment:
  • . build/envsetup.sh


16) Choose here:

# If you want to fetch device dependencies, and your ROM officially supports the target device -- goto step 16) a)

# If you want to build using local device tree, repo, and kernel directories -- goto step 16) b)


16) a) Breakfast
  • breakfast RomTag_DeviceCodeName-BuildType

# I'll use DirtyUnicorns on as an example

#'breakfast du_angler-userdebug' (Builds DU for Nexus 6P with userdebug, unless you know what you are doing, use userdebug)

# If you don't know your device codename, Google it, or just run 'breakfast', and look for it in the menu


16) b) Lunch
  • lunch RomTag_DeviceCodeName-BuildType

# I'll use DirtyUnicorns on as an example

#'lunch du_angler-userdebug' (Builds DU for Nexus 6P with userdebug, unless you know what you are doing, use userdebug)

# If you don't know your device codename, Google it, or just run 'lunch', and look for it in the menu



17) Build the ROM:
  • mka -j8 bacon

# mka is a refined make.

# -j8 is a variable number, if you have an Intel processor, take the number of cores and multiply by two, so, on my Quad-Core i5, 4x2=8. As noted by +Drew Walton, the 'mka' command auto analyses cpu availabillity, so the '-jx' arguement is not necessary unless you are building on a device where you want limited resources to be used (I have a server, where I am only allowed to use 4 cores to build, so 2 x 4 due to hyperthreading).

# bacon is most custom ROM's target for a flash-able .zip archive format, if you get an error like "No Target to Make: bacon", try 'make -j8 otapackage'.


18) Collect the ROM:
  • adb push ~/android/out/target/product/ROMNAME-DATE.zip /sdcard/

19) Flash ROM & Enjoy!



NOTES:
- Some ROMs don't sync in vendor repos by default. You'll need to do this by fetching your OEM's vendor from https://github.com/TheMuppets and cloning it into ~/PathToROMSource/vendor/OEMName. You can also do this via local manifest. Look at this one as an example. but I won't be explaining it here: https://github.com/adt1-dev/local_manifests/tree/cm-13.0.

- Getting random Java or Host Binary (build output shows it building in the 'out/host' directory) related errors? Try a lower -j#, or, just exclude that part (it will default to -j1, which will take considerably longer).

- To change your default Java version, use these two commands (Make sure to use them both! Mix and matching Java versions will not go well!):

sudo update-alternatives --config java

# If building LP (Lollipop) - MM (Marshmallow): Select the option for 'java-7-openjdk-amd64'
# If building DN (Donut) - KK (KitKat): Select the option for 'java-6-oracle-amd64'
# If building CM (13+), Pac (Or any other CM derivative), or the 'master' branch of AOSP: Select the option for 'java-8-openjdk-amd64'

sudo update-alternatives --config javac

# If building LP (Lollipop) - MM (Marshmallow): Select the option for 'java-7-openjdk-amd64'
# If building DN (Donut) - KK (KitKat): Select the option for 'java-6-oracle-amd64'
# If building CM (13+), Pac (Or any other CM derivative), or the 'master' branch of AOSP: Select the option for 'java-8-openjdk-amd64'



NOTE: Some AOSP ROM Source trees have been updated to build with OpenJDK8, so, feel free to use it when you can, though, it isn't mandatory.

Getting Random HOST ART Library Errors?

A common error going around right now is the generic 'libart.so' failure to build due to a linker error. This is due to a recent update in the BinUtils package in the Ubuntu and Debian repositories that AOSP hasn't accounted for yet (CM already merged the fix). To fix this, you need to cherry-pick two commits:
  • cd ~/PathToROMSource
  • cd art/build/
  •  git remote add cm https://github.com/CyanogenMod/android_art.git
  • git fetch cm
  • git cherry-pick e5c6b049f3c716be60bc82d79c44c451f49b4ad5
  • git cherry-pick 0299788b7a974841aa3324a573fbf04f49a4f23c
  • # Thats it! Have fun building your ROM of choice from source!

Saturday, May 23, 2015

How a $30 Phone Caused Me a Headache & Write Protection Woes.


How a $30 Phone Caused Me a Headache & Write Protection Woes.


A few months ago while I was playing cards in my Physics class, my friend Quincy Jones comes up to me and said

“Hey, I have a crappy old ZTE phone my grandma gave me, and I know that you like messing around with this kind of stuff. You want it?”


Heck Yeah! Should be fun. Quick/Easy to root, then work on getting TWRP ported, etc. Right? No.


To begin, this phone runs ZTE’s (in my opinion horridly ugly) Jelly Bean 4.1.2. It is labeled Z796C, which, after a quick google search, is called the ZTE Majesty on Straight Talk Wireless (The carrier would later cause me multiple headaches, but we’ll get to that. Upon googling “ZTE Majesty Root” I was greeted by a SINGLE thread about the phone. No big surprise, it’s not a well sold device. The thread was about 8 pages of people complaining about how it hadn’t been rooted. They all said they had tried “every method”, which, at the time, I didn’t believe.


This phone runs 4.1.2, which means that, in theory, this device is vulnerable to hundreds of different local (and even some remote) code execution (root) exploits.

To begin, I tried SafeRoot (originally intended for 4.3), which seemed to succeed, but upon reboot, no root. Huh.

Onto attempt two, Cydia Impactor (Master Key Bug), and although it seemed to work, upon reboot, no root. This should have keyed me off to the problem, but it didn’t.

Onto what should have been my go to for attempt one, TowelRoot. Downloaded the APK and installed, Bang. Root. Or so I thought.


After TowelRoot displayed its success message, I left the app and jumped over to SuperSU, which said that the SU Binary needed to be updated. Sure. I click “Yes”, and left to go for a run.

Got back about 30 minutes later, and it still displayed the “Installing…” prompt! I closed the app, and plugged it into my Surface Pro 3, and pulled up an ADB Shell.


shell@android$

Wow. That’s painfully generic.

I then ran “SU” which returned:

/system/bin/sh: su: not found

Huh? I thought I had root? Maybe I was wrong. Reran TowelRoot, and it rebooted, which is TowelRoot’s way of telling you you aren’t vulnerable/it failed. What the Heck?

I then rebooted the device. Pulled up TowelRoot, and ran it. It reported success. Popped open SuperSU and decided to not update the binary, and just use the one that TowelRoot installs. Seemed like everything was fine. I opened that same ADB shell and ran SU. To which I was greeted with an SuperSU prompt, to which I agreed. Boom.

root@android:/ #

Wow. That’s still painfully generic.

Started surfing around to find where the different partitions lie.


root@android:/ # cat /proc/partitions



root@android:/ # ls -al /dev/block/platform/msm_sdcc.3/by-name

Returns: /dev/block/platform/msm_sdcc.3/by-name: No such file or directory

What? No “By-name” function on a JB era device? That sucks.


root@android:/ # cat /proc/mtd

Returns: dev:    size   erasesize  name

Ugh. No partition listing that sucks.


I tried a few more common methods that I won’t waste time outlining, all you need tt know is that none of them worked.


Next plan of action for me would normally be to examine the Recovery.img and get an fstab, which displays all of a devices mount points. Bad news… after a search, there are no fastboot images for this device! No problem, I’ll just dump the recovery.img from Fastboot. Here we go:

PS C:\Users\Nolen> adb reboot bootloader

I then waited, the ZTE splash screen came up, and then it came up with the Android Boot Logo! What the Heck? I then found out from a quick google search that all Straight Talk phones have Fastboot disabled. This particulat phone also lacks a “Download Mode” to replace Fastboot like what LG does. Wow. This not only prevents disaster recovery, but just made a seemingly easy job much, MUCH harder.


Where to go from here? Not sure honestly. So, I set to work researching it. Couldn’t really find anything relating to the topic.

About 30 minutes into brainstorming, the device randomly rebooted.

When it rebooted, I got back on an ADB shell:

root@android:/ # su

Returned: /system/bin/sh: su: not found

This means war.

Huh!?!?!?! We had Root! Ugh. What’s going on!

For those who haven’t figured it out yet, it was now apparent that not only the phone has Write Protection on /system (prevents writing to a live system, can only be written to from recovery), but also has some form of temp root detector that shuts down root after a certain period of time.

So, I gained temp-root via TowelRoot again, and began brainstorming how to get a partition map again.

Then it hit me.

Recovery knows how to mount the partitions! So, I need to get it to mount all the partition in recovery… Factory Reset!

root@android:/ # reboot recovery

Then, from recovery, I initiated a cache wipe, and then a Factory Data Reset.

After they completed, I reboot to system.

root@android:/ # cat /cache/recovery/last_log


Yay! A partition map!

Now to use an old trick found by Justin Case (@Jcase) to help temporarily remove Write Protection.

We write the boot partition to the recovery partition, and then reboot to recovery, because the recovery partition (when booted) has permission to mount /system read-write. 

Well, now onto the fun stuff.

We back up our boot partition:

root@android:/# dd if= /dev/block/mmcblk0p8 of=/sdcard/boot.img

Now we back up our recovery partition:

root@android:/# dd if= /dev/block/mmcblk0p16 of=/sdcard/recovery.img

Now we write the contents of the boot partition to the recovery partition

root@android:/# dd if= /dev/block/mmcblk0p8 of=/dev/block/mmcblk0p16

Here we go! *crosses fingers*

PS C:\Users\Nolen> adb reboot recovery


Upon reboot, it seems completely normal. All data is intact, and system is booted sucessfully as expected.

Now to test it. We have to first regain temp-root with TowelRoot, then ADB Shell:

root@android:/# mount –o remount,rw /system

Returns: mount –o remount,rw /system

Success! We have RW access to /system!

Now onto perma-root.

Just open up SuperSU and it will ask to Update the SU Binary, select yes, and wait. About 30 seconds later, it displayed the “Success! It is recommended you reboot now.” Message, I then went in and converted SuperSU to a /system app. Then I rebooted to the normal boot image.

I expected the following; to have root access, but to be unable to remount /system due to write protection.

However, upon reboot:

shell@android$su

root@android:/# mount –o remount,rw /system

Returns: mount –o remount,rw /system

What? How are we still able to remount system RW? To make sure I wasn’t still booted to the recovery partition, I ran:

root@android:/# dd if= /sdcard/recovery.img of=/dev/block/mmcblk0p16

root@android:/# reboot

Now to test again:

shell@android$su

root@android:/# mount –o remount,rw /system

Returns: mount –o remount,rw /system

What? Now I am really confused… but I can live with it! We defeated ZTE Write protection permanently! Even if by accident.


Interesting Notes: After booting the stock kernel from recovery, instead of the






Sunday, May 10, 2015

Breaking Samsung's Security

Problem: The Verizon Galaxy S4 is bootloader locked.

Well, what exactly is a Locked Bootloader? A locked bootloader checks for a digital signature on certain images/partitions on the device. This prompted me to begin to research ways to work around this.


The Verizon Galaxy S4 (hereon referred to as VZW S4) checks the integrity of signatures on all of the following partitions;

-          Boot (boot.img)

-          TrustZone (TZ.img)

-          Aboot  (aboot.mbn)

-          RPM (RPM.mbn)

-          SBL1 (sbl1.mbn)

-          SBl2 (sbl2.mbn)

-          SBl3 (sbl3.mbn)

-          The Partition Map (JFLTE_USA_VZW.pit)

-          Recovery (recovery.img)

-          Modem
-          NON-HLOS

 Partitions not checked:


-          System (/system, only checked during OTA Update)

-          Persdata (/Data)

-          Cache (/cache)

-          Hidden.img


Basic Understanding of the boot sequence:

Visio: https://drive.google.com/file/d/0B1rm1VFiz_2FUGV0Nk5FdTg3czQ/view?usp=sharing

Where to start? There are many vantage points to be taken.


1.      One was described in a recent leak: There is a QFUSE on device under the label of TESTBIT. By reverse engineering a Verizon Galaxy S4 (SCH-i545) VRUFNK1 aboot.mbn in IDA, we can follow the decompiled functions down to the function that calls to check the value of TESTBIT in memory.






We can also deduce from here that the value of TESTBIT’s shadow in memory is 0x700438+0x4000. Though, it is worth noting that aboot does not check TESTBIT’s shadow, it checks the base fuse, which makes overwriting the shadow in memory almost entirely useless.

With this info, we can use JTAG to set the fuse value and boot an MDK aboot. This allows us to use a Loki like attack to boot a custom recovery and kernel.

The only way to permanently blow the fuse would be to use a flaw/vulnerability in TrustZone blow the base fuse to our desired value. Dan Rosenberg's QSEE exploit could easily be leveraged. We could even likely apply M0nk's work on the 8974 to get TZ shellcode, and over-write the fuse value in the shared-cache.

Another fuse that would work similarly would be the Commercial bit, however, this fuse has proven extremely hard to find. Though I am sure it exists. This would be the fuse that is read out by aboot, and dictates whether or not the developer edition checks are enforced. Though, from my findings in aboot, some form of CID hash (at the minimum) spoof would also have to be present.



Theoretically Vulnerable Devices:

-          Galaxy S4 (All QCOM Variants) Method: Downgrade to Pre-Knox Bootloader, or to exploitable firmware, i.e. MDK (SCH-i545), MDL (SGH-i337)

-          Note 3 (All QCOM Variants) NOTE: Note 3 has no Loki vulnerable Bootloader, meaning this only disables roll back for these devices.

-          Galaxy S5 (All QCOM Variants) NOTE: Galaxy S5 has no Loki vulnerable Bootloader, meaning this only disables roll back for these devices.

-          Galaxy S3 (All QCOM Variants) Method: Downgrade to “African-Sock-Monkey” leaked Insecure (Unlocked) Bootloader

Likelihood: (WITH JTAG ONLY)  0/10 – EDIT: The TESTBIT check function looks for 0x20, and the ones digit of the increment fuse is already blown to 0x01, meaning if we blew 0x20 to the fuse, it would return 0x21 and brick.*, still working on Commercial BIT - FAILED -- Could still work with the advent of M0nk's shellcode escalation? Still researching.

Likelihood: (WITHOUT JTAG) 0/10, would require a TrustZone Exploit to blow TESTBIT (Dan's TZ, and I can count the amount of public TrustZone Exploits I have seen in my career on two hands (5 HTC Specific, 3 Motorola Specific, 2 Generic TrustZone)



2.       Another method was described in a recent leak: There is a special hardware protected partition on the eMMC called “RPMB” (Not to be confused with RPM.mbn), that stores the roll back information on the QCOM Galaxy S4 variants. This can be theoretically restored to a blank state by removing the eMMC and hooking it up (using the correct pin outs) to a Linux Machine, which would then have to issue several (confidential/not-public knowledge) Toshiba eMMC Vendor Commands to wipe RPMB (or write the lowest known firmware value to it). After placing the eMMC back in the device, the device could theoretically downgrade to any previous firmware.

It is worth noting that all devices released by Samsung after the Galaxy S4 blow a physical QFUSE to signify rollback, meaning that they are not vulnerable (i.e. Note 3, Galaxy S5).

Theoretically Vulnerable Devices:

-          Galaxy S4 (All QCOM Variants) Method: Downgrade to Pre-Knox Bootloader, or to exploitable firmware, i.e. MDK (SCH-i545), MDL (SGH-i337)

-          Galaxy S3 (All QCOM Variants) Method: Downgrade to “African-Sock-Monkey” leaked Insecure (Unlocked) Bootloader

Likelihood:  4/10, would work if we had the correct pin-out for our eMMC, and the Toshiba Vendor Commands, but getting our hands on the latter is unlikely. – Still under research


3.       Yet another method is described below:

KEXEC is a tool used to overwrite the Linux kernel in memory with a new kernel, and then execute the new kernel without ever taking the system down for full reboot (hardware always remains live). It has become increasingly more common to see KEXEC implementations to bypass android device Bootloader security, as many times, it is far simpler than finding a vulnerability that would allow a full unlock.

KEXEC must be loaded in as a kernel module to work correctly. So, to even attempt a KEXEC bring up, we first need root access and the ability to load custom (un-signed) kernel modules. I will be speaking about the Verizon Galaxy S4 almost exclusively here, although this theoretically applies to most Samsung devices.

First step is root, easily attained on all >4.4.4 devices via the Futex bug (originally by Comex, though ported to android by George Hotz in the form of TowelRoot.apk), and as long as the device in question hasn’t been upgraded to Android 5.0 yet, you can always just roll back to a Futex vulnerable firmware and root. We then install BusyBox, and SafeStrap (A boot hijack that allows us to flash ROM’s, and access a terminal before any partitions are mounted originally by HashCode, updated by Muniz_ri), this gives us a base for KEXEC work/debugging, and a place to optimally execute it. Next is un-signed kernel modules, on the S4, the process that checks to see if kernel module signatures are require is called KLSM. There is a known exploit by Jeboo that was initially created for 4.3 (MK2) called BypassLKSM, that was later ported to 4.4.2 (NC5) by Surge1223, and then later to 4.4.2 (NK1) by myself and Demetulth.
EDIT: VZW S4 has Lollipop (5.0.1, OC1), researching BypassLKSM addresses now…
-EDIT 2: Found them.


Now, we build our version of KEXEC using the NC5 kernel source (As Samsung has yet to release the NK1 kernel source 5 months after release, GPL violation? Big time)

Now to actually execute KEXEC! We then boot up to safestrap (a recovery boot hijack, and at that, a special version with devmem2 & viewmem), push the built KEXEC modules, ramdisk, and vmlinuz (kernel) to the root of the device, connect the device to your computer via USB, and run  commands with similar syntax(s) to these:

Adb shell

Su

Insmod kexec_arm.ko

Insmod kexec_machine.ko

Insmod Kexec.ko

Lsmod       #Expected output should list all 3 modules listed above

kexec -l /stock_nk1_zImage --ramdisk=/ramdisk.cpio.gz --append="($cat $cmdline)" --atags-file=/atags

unmount –a #My recommendation would be to unmounts all partitions manually

(In a separate terminal)ADB Shell su –c “dmesg”

(In the first terminal) kexec- e


After the system attempts to soft-boot the kernel (and inevitably fails), we have to pull a last_kmesg, and look at the DMESG we got in the second terminal we pulled up earlier. We then try to debug the problems it is having. Right now, we are hanging at being unable to flush the kernel caches correctly & at the correct time in the KEXEC sequence, as well as the kernel being corrupted in purgatory.

Likelihood:  7/10, will work if we can debug all of the issues, not a question of “if”, as it is “how”, and “when– Still under research.


4.       An alternative idea was to mask TESTBIT in memory using JTAG to disable rollback, and then KEXEC to boot to Download Mode and attempt to do so without emptying the memory. This failed in our attempts, because for one reason or another, we were unable to keep the memory from reverting the value of TESTBIT to the pre-masked version.

Likelihood:  1/10, failed miserably, if we could find a way to retain memory contents after the softboot to Download Mode, it could work.


5.       Another proposed method of attack was using KEXEC Hardboot (a way to KEXEC to a new kernel from a full reboot) – This posed extremely similar results to KEXEC, but provided no logs whatsoever, as last_kmesg had been cleared upon reboot, and the DMESG was of no use, as it just stated that the system went down for reboot, so we had no method to debug it.


Likelihood:  1/10, failed miserably in testing, no way to debug it due to lack of logs.


6.       A proposed method, that has yet to come to fruition, is the potential for a vulnerability in QCOM Download Mode (See the referenced bootchain.pdf earlier in the article for explanation), as it allows you to boot an SBL1 (as long as it is signed and within rollback), from the SD Card. This mode can only be accessed if SBL1 is damaged/not signed/not present.


Likelihood:  1/10, failed miserably in testing, no documentation provided for QCOM mode, hard to work with.


7.        Similar to the above method, is the potential for a vulnerability in QCOM Download Mode itself, and the way it boots SBL1 from the SD Card (via debrick.img).


Likelihood:  3/10, requires more research, no documentation provided for QCOM mode, hard to work with, and would require specially crafted debrick.img. – Still under research


8.       Another proposed potential vantage point is a vulnerability in ODIN that would allow us to modify protected partitions of the device.


Likelihood:  1/10, almost complete chance, would require reverse engineering of ODIN, and a special kind of vulnerability.



9.       Yet another method is to reverse engineer how developer edition devices aboot is signed, though, even if we deduced the algorithm, we would still need access to Samsung’s RSA & Private Key (likely could only happen via a leak).


Likelihood:  0.000000001/10, would require Samsung’s RSA & Private key to be leaked, which is almost impossible.


10.   Another idea to be considered is finding a way to write the CID of the device, allowing us to boot another (developer edition) devices signed, unlocked aboot.


Likelihood:  6/10, Can definitely work, but would be highly illegal, as we legally can’t spoof our device’s CIDs, falls under the same category as IMEI/ESN spoofing, but is much harder to do.





12.   On final idea to consider is that there is a mode known only as “Factory Mode”, this is the mode wherein the manufacturer writes the CID, partition layout, fuse values, etc. It basically serves as a “God-Mode” for the device, but can only be accessed once, and then it is permanently disabled. If we could find a way to get the device to revert to this mode, anything would be possible.


Likelihood:  0.00000000000000001/10, would require a godsend of a vulnerability, would likely have to be at PBL level, and would likely affect all QCOM devices if found.