Posts

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 perk

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

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

Breaking Samsung's Security

Image
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: PDF: https://drive.go