[Android Q&A, Help & Troubleshooting] Delgoth:
This Post is 15.9k Characters :D

****

****

This is awesome. Because after messing with Super SU so much last Night I ended up having to reflash my phone with stock firmware to get it to boot again.

Before the crash, I was using the Full Binary 2 OJ1 5.1.1 AP file, The LP UCE2BP2 Eng Kernel, as well ae The Complete 3 piece Factory N920AUCU3APH1 Lollipop 5.1.1 Bootloader with matching Binary 3 Eng sboot. My Device also had an Unlocked 3BPH4 Modem/Radio CP file, with no CSC file flashed since nand-erasing all while ODIN flashing the full PH1 factory firmware, before mixing the builds listed above.

Then my device crashed while developing an ADB Shell Script to install Chainfire's Superuser.

Sad times too, using the script I'm uploading, along with some of the other applications I'm posting right here, I was able to achieve a real SU Session while using ADB Shell. I'm not talking about having a root su context for the shell user, but being able to execute command line tools as root as well. The Only thing that wasn't quite working correctly, was SU being symlinked and running elevated in enough processes to launch APK's from Touchwiz or NovaLauncher. Getting into the init context is about the biggest hurdle, because that's how CF wrote SuperSU to work & that's how App Developers have made their apps. If I didn't have to start SU at boot time to run it as a daemon, I would have had a fully working SU. Because my terminal emulators could call the su binary and open a root user session, but I had to use the SELinux Enabled Busybox 1.24.1 to change file contexts, and then toolbox to run as contexts, because I don't yet have the guide from Chainfire's Installer Zip update-binary script all the way figured out. But it was awesome having the SU app linked into "/system/xbin" I was able to get the device's native ADB Daemon to start as Root, when this happened I was actually able to use the Device's ADB binary located at '/system/bin/adb' to issue ADB Shell Commands to itself. What's crazy, is when you run the "adb devices" command on the phone, my device listed itself as an emulator(-5554). That being the case, I got that far only using the ADB Shell, that would open a door for the device to automate its own Root Operations, via issuing itself Root Shell Commands to do the work Our Stock Recovery cannot.

However Now. After the crash w/ extra hot bootlooping, Ive upgraded and downgraded at the same time.

I've upgraded my ROM to UCU2BPB2 from OJ1. Ive kept the Eng Kernel because Im now running the same build the Kernel was built from. This should help by only working with 1 build of the sepolicy, instead of trying to decipher between two different builds of the same policy. But WAIT, A HUGE ASS BUT. WAIT. THERE'S M0RE!

Ive downgraded my sboot.bin using ODIN 3.10.6 from Chainfire's N920K CF Auto-Root, from the 3APH1 Factory Eng sboot.bin, to the 2BPB2 Stock User 'sboot'. I succeeded in downgrading my bootloader by flashing the older stock sboot after flashing the factory eng sboot.

I havent yet tried anything fancy since reflashing a configuration that would boot this morning. So I have not downgraded cm.bin or param.bin as of now. Im thinking of using the su context of the root shell to use the 'rm' command to wipe the persistent partitions myself Instead of try to wait for a TWRP Build we can use. Im fairly certain that wiping the partition that houses cm.bin will disable the ability to access download mode unless you put back a bootable download mode partition of some sort. I haven't worked out the format of the bootloader binary images yet.

I've pulled a list of the partitions on my device By-Name & By-Number. You'll see all the partitions are set to "777 permissions". Using the Greyhat Console, Busybox, Toolbox, and a limited SU, I don't see a reason why the fstabs/mount points can't be manipulated using disk partitioning tools as long as tolerances were kept in mind. My device always Fails DM-Verity Verification when I enter Recovery Mode, but that has never really affected operations. Because I can use the "mount" command to remount the /system partition without the 'norecovery' attribute, and I can mount the '/data' partition without the 'nosuid' & 'nodev' attributes. Once those commands are in place, SU should have a much easy time to function properly.

When I run the command "adb shell mount -o remount,rw /" to mount the rootfs R/W, I can make changes to the Kernel filesystem that DM-Verity will not reconstruct when the phone reboots. In the cases where DM-Verity does not undo the changes I've made, the changes actually remain persistent and just prevent the phone from fully booting up. Even a Factory Reset from Recovery cannot fix the problem, only a Reflash from ODIN does the trick. WHICH SHOWS ME, it is actually possible to sometimes get past the filesystem verification process during boot. I'm assuming I was just making the wrong changes at the wrong time. I'll get there. I used the command "adb shell pm disable com.sec.att.usagemanager3" and it actually disabled the AT&T Usage Manager App straight away, that Touchwiz & NovaLauncher won't allow the normal user to do.

But Im thinking that the CPEFS and PERSDATA partitons have a lot a to do with securing the chain of trust for the N920A. As normally when trying to do a full binary revision downgrade of the bootloader results in a failure from ODIN when flashing either the 'cm.bin' or 'param.bin'. This is the infamous "Device 3 : Binary 2" error people have recieved trying to flash a 5.1.1 LP ROM directy over top of a 6.0.1 MM ROM. The exact problem I bypassed this morning. HOWEVER. Even though I was able to downgrade the sboot.bin, "vndnguyen's" Samsung Phone Info App, still shows me having the "FA51_N920AUCU3APH1" bootloader installed. Meaning that, cm.bin & param.bin play a much bigger part in the Samsung bootloader overall than just the sboot.bin alone does.

And, If you've noticed, even after bricking the phone due to an exploit, system, or bad flash issue, we can still reliably reboot to download mode in order to fix our software. Also notice, Samsung's 'sboot' Bootloader, is either partially or fully based on Android's 'aboot' Bootloader. Qualcomm is the originator of 'LK', or Little Kernel. Which is what is Android's aboot Bootloader is built from. Isn't it a coincidence then, that Qualcomm not only made the original source code for our boatloader, while at the time they also originated the QSEE trust zone, Secure Boot, and ODIN mode, features of our bootloader? Qualcomm is almost wholly responsible for the features maintaining a locked state on our Note 5 devices.

This coincidence is what is leading me to believe the param & radio partitions hold one of possibly 2 or 3 keys to unlocking this device. I'm sure there has to be another device that is rootable that also uses the same modem chipset as the N920A. There are plenty of their SoC's in the newer galaxy devices on other carriers. We are gonna have to mix some things up.

I was able to downgrade my sboot.bin from binary 3 to binary by first flashing the combination FW sboot.

Maybe that means the Eng sboot for LP builds doesn't actually have any signature checks itself. Maybe the AP file for the factory binary has some quirks I missed. Or maybe we need that botched check together with an exploit or two inorder to get a custom filesystem in place.

!#?+/

@$&_

Regardless, The description in the 3APH1 Factory ROM, for the 'OEM Unlock' toggle switch in developer settings reads "Allow the bootloader to be unlocked." Versus in the stock AT&T ROMS, that same toggle description reads "Allow the device to be OEM Unlocked."

I know that is merely is a superficIal change to a hard coded string on the backend of the build, but we know that the 'Universal7420' Board is fully Rootable & Unlockable. We also know that AT&T + VzW, had to put extra time and effort to put locks in place above & beyond what T-Mo + Sprint did. The main difference between all the carrer variants, are their Radio/Modem Firmware. And with new SELinux requirements in place, the only place to maintain isolated, controlling authority over the system, is in the radio itself. Since our devices were originally designed around the concept of telephony services, the network modem is naturally one of the first and most integral pieces of hardware in the whole device.

There should be a way to use the 'dd' command to strip all but the last 2048 bytes (or was it 20480?) of the 'userdata.img' file, as well as the Kernel/Recovery.img files. And if there is a command like dd to split data, there should be an equal command to splice it back together again. ESPECIALLY, if it's just a binary stream. This method Would work along with dirtycow under the right context, because we would only need to spoof the images signature signed by the carrier for just an instruction or two. Not the entire process. At least after the initial injection. With the Engineering Kernel, UCE2BPB2, As long as you are using ADB Shell, you are running within the Super User context, as the Root user. I've seen methods used for using 'dd' to strip the header information off of ELF binaries and other files like that, in order to get to offsets with embedded signatures. This is just such the way to whittle down all of the '.img' files in our Firmware to get at the Signatures baked into the Footer bytes of the signed archives. With that signature in hand, if we cannot use it to directly bypass signature verification, there may be a method to analyze the signature values across multiple builds in order to extract a pattern to calculate/decrypt the private key. I say it like that, because We already have an Engineering Kernel and Sboot. We just need a CLI guru to come in and work some keyboard magic on this mini linux system.

With the newest build of the Greyhat Console droidvoider built, we have the potential to take our SU access from the shell, and refire the 'init context' in order to bypass DM-Verity. The Eng Kernel can make any change it wants to the device, except to the mmc/nandflash/initramfs. But as my journey into merging Chainfire's SYSTEM & SYSTEM-LESS Root methods into something like a SYSTEM-"ish" SuperSU root has proved, Root is possible if the chain of processes can intercepted, but then saved by init. The biggest problem preventing me from fully rooting last night, was getting the init context to fire up again once Boot has completed. The stock 'sepolicies' in place really put a blockade up against that context. I'm sure the wall isn't that strong though, I'm just a bumass n00b at a lot of this. I just read constantly anymore. The last 5-6 months have left me feeling like [MENTION=7945178]droidvoider[/MENTION] and myself, are two people working on a project normally reserved for an entire Software Engineering Department's worth of people.

So far I've only seen two groups of systems that have access to the nand. That is, 'init' and its children, as well as well the 'radio interface layers', or 'radio'. You will find a binary application called "cbd", or "CP Boot Daemon" in the Kernel's Ramdisk "/sbin/cbd". Looking through the init.rc files, I've found that the radio user group takes control of these processes as soon as boot starts. It seems that everything in our "/sbin" directory is related to handling the beginning of the boot process. Just adding more fuel to the fire that is me feeling like Qualcomm trying to trying usurp control of android evolution. I have an unlocked "modem.bin" for the CP Slot in ODIN, but it is for the UCS3BPH4 6.0.1 build. It's what I have installed right now even though I'm running a 5.1.1 Build. But it gets rid of the baseband unknown error in the about device menus. I even found some reference to a shared VZW location service AT&T uses to geofence/locate the device in some of the sepolicies.

If we can take over the Radio UID/GID contexts we will get access to both, the early boot stages needed to launch a SU Daemon, and we will get usage rights to the persistent NAND/EMMC partitions that aren't affected by Normal wipes or Factory/Data Resets. Having access to those partitions would allow us some wiggle room when it comes to using applications & running commands to modify the device build, in a pre and/or post Firmware Flash Environment. This is similar in concept to the Maintenance Boot Mode that most Verzion Variants of the S6/Note5 line carry in their bootloader. It gives you the option to enable USB Debugging before the first boot, after a Factory Reset or ODIN Firmware Flash. It would give us the ability to the use the Eng Kernel to make /system modifications to the Stock ROM before the DM-Verity Hash Tree can be generated and checked for the first time. Giving us an opportunity to get a SuperSU 'su.img' into the cache or data partition prior to doing the initial boot into recovery mode after a system upgrade/downgrade. This is how we may be able to get a CF Auto-Root style procedure into a working operation. I hope you got a lot of insights from all this, and the uploads.

-----

Not this moment, but I will be uploading the Three arm64 Android Linux Toolchains I have. The Eng Kernel, or Termux Terminal, can get a lot of use out of them:

* 1.) gcc-arm-linux-gnueabihf-4.7

* 2.) aarch64-rorschack-glibc

* 3.) ndk-aarch64-linux-android-4.9

-----

Some Other Notes:

** I compiled the Greyhat Console for LP & MM builds. I included some edits to the Makefile/Android.mk files. To use arch-arm64 on both builds instead of arch-arm. And api-22 for LP.

** I did wipe my dalvik-cache before the crash. That might have caused my inability to boot back up. Or the fact I was messing with the /fstab.samsungexynos7420, and /fstab.samsungexynos7420.fwup files trying to mount the recovery partition. Hoping to copy parts of the Eng Kernel over to the Recovery Kernel, giving us a Rooted Recovery and solving everything.

** I haven't tried it, but I would venture to say anyone that hasn't updated past the N920AUCS3CPJ1 build, can still downgrade to a 5.1.1 Lollipop AP ROM using the Combination BL file. In order to gain the ability of the Eng Kernel

** Anyone on a Binary 4 Firmware, should try and flash the Combination 4APL1 Bootloader firmware package (ODIN BL File), In order to try and downgrade to a binary 3 sboot. If that is possible, you may just be able to load the PB2 Eng Kernel, if you can somehow boot the 3APH1 sboot. If binary 4 can still downgrade back to LP builds using the factory builds, that big, BIG NEWS. That means we really do have a route towards full unlockage no matter what. Given enough time.

** Im hoping I can easily get back to where I was with su. It worked for everything except apks I launched. I dont know how to open an APK to the foreground from ADB Shell, or else I'd be able to start SuperSU and other root apps directly from the root context.