I am relatively new here, but was reading some threads and a couple people have said that the community hasn't found the 13.3.2.7 update to manually force a rollback. A couple days ago I called Amazon because I had updated to 4.5 and needed to go back to root.
Since then I have been looking around for where the patch was saved to and found the scripts that setup for the OS update and the scripts to run it. The scripts show where it is and what commands are called to do the update, but the actual 13.3.2.7 OS seems to be hidden. I know where it says it should be, but its hidden somehow. If this is something anyone wants copies of my files on let me know, if this isn't something the community needs I apologize, just trying to help get this tablet further along.
Either post here or message me if you want/need what I have.
Why don't you just post your findings so far on this thread?
I was under the impression that OTA files are downloaded to the /cache folder, therefore inaccessible without root.
Either way, updates are still verified (see: /system/app/otaverifier.apk) by the system, so I'm not sure how you'd get around that.
EncryptedCurse said:
Why don't you just post your findings so far on this thread?
I was under the impression that OTA files are downloaded to the /cache folder, therefore inaccessible without root.
Either way, updates are still verified (see: /system/app/otaverifier.apk) by the system, so I'm not sure how you'd get around that.
Click to expand...
Click to collapse
I see, that part is already known then. Other posts I read people were still looking for it, but I was sure if i found it many others have too. I'm still looking around though, I found the verification coding also, thanks for that. I am thinking about updating my tablet again, and having them roll it back again, but this time running a packet sniffer. Might possibly get some really good info about the verification process or at least the steps it takes to make the rollback. I did a search but haven't seen anyone try this, it's probably heavily encoded though.
Another thing I noticed while looking around... They put a kill switch fuse in it? That's pretty rough, and what causes it to activate? Software modification or Hardware like Jtags?
Eclipsys said:
I see, that part is already known then. Other posts I read people were still looking for it, but I was sure if i found it many others have too. I'm still looking around though, I found the verification coding also, thanks for that. I am thinking about updating my tablet again, and having them roll it back again, but this time running a packet sniffer. Might possibly get some really good info about the verification process or at least the steps it takes to make the rollback. I did a search but haven't seen anyone try this, it's probably heavily encoded though.
Another thing I noticed while looking around... They put a kill switch fuse in it? That's pretty rough, and what causes it to activate? Software modification or Hardware like Jtags?
Click to expand...
Click to collapse
once rooted again .it may be possible to modify your build.prop like we were on past firmware to achieve rollback just to initiate download ,it will ultimately fail once it downloaded it and trys to install it will check a few more things it will fail and erase it ...the trick would be not too let the device idle..or to have the battery below I believe 30 percent it may be as high as 40 I'm not sure but I believe under 30 it will refuse to install update delay till charged ,anyway it may buy you time to find it
jimyv said:
once rooted again .it may be possible to modify your build.prop like we were on past firmware to achieve rollback just to initiate download ,it will ultimately fail once it downloaded it and trys to install it will check a few more things it will fail and erase it ...the trick would be not too let the device idle..or to have the battery below I believe 30 percent it may be as high as 40 I'm not sure but I believe under 30 it will refuse to install update delay till charged ,anyway it may buy you time to find it
Click to expand...
Click to collapse
That is actually a very good idea, something I am testing right now is getting the FireOS to run in VMware. I have a standard Android KitKat OS running, but getting the Kindle's OS to run is giving me a few issues. I am very skittish to try this stuff on my actual device as it's brand new and I don't have a backup... But if I can I will give you idea a shot. Might be able to save it before it deletes. Also if I can get it going in VMware it might be possible to use a debugger to examine the ASM code in great detail.
Eclipsys said:
That is actually a very good idea, something I am testing right now is getting the FireOS to run in VMware. I have a standard Android KitKat OS running, but getting the Kindle's OS to run is giving me a few issues. I am very skittish to try this stuff on my actual device as it's brand new and I don't have a backup... But if I can I will give you idea a shot. Might be able to save it before it deletes. Also if I can get it going in VMware it might be possible to use a debugger to examine the ASM code in great detail.
Click to expand...
Click to collapse
I didn't have any problem doing the modifications myself and I'm no Pro that's for sure. Never written a line of code in my life. I just tend to thoroughly research and understand before I attempt things and I've been practicing here for a while if you go to the, rollback .0.1 and safestraped thread there is quite detailed instructions serval times throughout the thread I would skim it.you will just be substituting version numbers and kind of a inverse idea compared to what we were doing there but it should accomplish it. I used rOM Toolbox lite I believe as an editor and saved each timeI didn't have any problems with the permissions getting screwed up while tampering with it rOM Toolbox took care of that issue. I have seen tons of people brick trying to make these modifications. But I don't think they understood completely what they were attempting to do it's actually very simple and as long as you do it thoroughly and get all of them changed I have not seen any problems other than maybe having to repeat the process.there are a couple of lines that only use the last section of your version numbers I even changed those back then.
Eclipsys said:
I am relatively new here, but was reading some threads and a couple people have said that the community hasn't found the 13.3.2.7 update to manually force a rollback. A couple days ago I called Amazon because I had updated to 4.5 and needed to go back to root.
Since then I have been looking around for where the patch was saved to and found the scripts that setup for the OS update and the scripts to run it. The scripts show where it is and what commands are called to do the update, but the actual 13.3.2.7 OS seems to be hidden. I know where it says it should be, but its hidden somehow. If this is something anyone wants copies of my files on let me know, if this isn't something the community needs I apologize, just trying to help get this tablet further along.
Either post here or message me if you want/need what I have.
Click to expand...
Click to collapse
Please upload the file somewhere (preferably to mega). If it doesn't pass the version check we can use my hack to bypass it.
p1gl3t said:
Please upload the file somewhere (preferably to mega). If it doesn't pass the version check we can use my hack to bypass it.
Click to expand...
Click to collapse
https://mega.co.nz/#!wlQl2bZD!Kk-rcWtcMPWxoEH5VcHrtZb7nOsJet9si1pm5FYhT44
5.2 build prop file
Hi Devs,
I've just joined and am uncertain of the proper place for this thread. Apologies if inaccurately posted.
I have the T337A, which I have rooted on ANF4, but I cannot find a recovery. I have read and read but am not finding the solution to my little project. I would like to get a safestrap on this locked bootloader so that I can install and learn to write custom ROMs. I have tried a safestrap but it was not for this specific device and did not work. I have also installed and purchased CWM Recovery and TWRP Recovery, in my learning process. The problem with the recovery is that there is no custom recovery written for this device and the bootloader is locked, as this is the AT&T WiFi/LTE version. So it looks to me like I need to figure out the partitioning image somehow in order to make a safestrap work on this device...as step 1. Is there anything else that I can do with this locked bootloader? I would love to have some help in writing a custom recovery and ROM for this device but I am a tiny tiny noob here and not a hard core programmer. If I could get some feedback on places to start for such a daunting task, it would be great. I guess one thing that I do not understand is why I cannot make my current rooted ROM the default recovery in TWRP. It asks me to choose from the list of supported devices. I understand that it goes: NAND --> aboot.img/bootloader --> recovery/or/kernel --> OS/or/ROM? If this is close to accurate then I would have to write something to the NAND?, which I'm not sure what is yet, in order to hijack the factory bootloader and then write the partitions on the sdCard for the ROM, like the safestrap folks wrote? It looks to me like they also included a version of TWRP touch which I used on the S4 yesterday and was really cool, so I guess that would be needed as well and is also why TWRP does not work for me now...it cannot hijack the locked bootloader. How do I hijack this hard headed thing? fastboot does not work to this device. In the process of this project, I have also run into a roadblock trying to update the /system/framework/framework-res.apk, in the manner that a flash needs to be done, I think. I want to change the /res/values/bools/bools.xml switch "voice_capeable" to true. AT&T or Samsung disable this on this version of the tablet, I guess to sell tethering or something else I'm not familiar with...but the way it looks to me, everything is configured on the device and I have a phone number provisioned for data at least. Why can't I turn on this switch and use the phone portion of the device? Any time I tickle the running framework-res.apk, it kills the OS. I tried compiling an update.zip aligned and signed with test keys or something like that but when I flash it, it fails with wrong footer and invalid signature...then it wipes me back to the stone ages. I warned I was a noob..! ...but not scared to brick some shtuff in order to learn this and write some custom solutions. An after thought...is there a solution for a bootable extSdCard for Android? This might lead to some options if it is possible.
Gathering phone info...
Collecting information. Be patient! Do NOT disconnect the phone!
Model: SM-T337A
Android Version: 4.4.2
Sales Code: ATT
PDA Version: T337AUCU1ANF4
Phone Version: T337AUCU1ANF4
CSC Version: T337AATT1ANF4
Product Code: SM-T337AZWAATT
HIDSw Version: T337AUCU1ANF4/T337AATT1ANF4/T337AUCU1ANF4/T337AUCU1ANF4
Board Platform: MSM8226
Serial Number: R32FA00PMRF
Imei: 3534.............
Unique Number: C1604.......
Connections: AT,MTP,MTP
Battery Status: 4.28V (94%)
Network Type: GSM
SuperSU Pro v2.40
TWRP donate latest
CWM donate v5.5.3.7
BusyBox Stericson donate v1.23.0
Titanium Backup Pro latest
xPosed v2.7.1
Wanam xPosed v3.3.1
NinjaMorph Pro v2.8.2
ROM Toolbox Pro v6.0.6.5
RootLogger Pro v1.9
Nandroid Backup v4.4.5
Next Launcher 3D Shell v3.20
Root Firewall Pro v2.1
SetCPU v3.1.2
w/respect. PitPin
Sir,
Please wait until mods will move this thread to the device specific forum for more relevant answers.
Stand by
Good luck
We had a dev working to get safestrap, but he struck out. So if you can get it, I'll test. I too have the 337a. Sucks to have a locked bootloader and no dev interest.
pre4speed said:
We had a dev working to get safestrap, but he struck out. So if you can get it, I'll test. I too have the 337a. Sucks to have a locked bootloader and no dev interest.
Click to expand...
Click to collapse
Thanks pre4speed. I am taking a look at the two tasks again tonight and decided to take the res/bool = voice_capable issue on first since this will determine how brickable this device can be for me. If I can use it as a regular modem phone then I might be a bit more careful with the bootloader project I did some more tinkering with the framework-res.apk ...specifically the /res/values/bools/bools.xml resource and tried the following:
-------
Factory wipe
Flashed sammobile.com T337AATT1ANF4 firmware
Rooted
SuperSU
Busybox
Froze AT&T update service and others involved
Titanium backup and pulled a good backup
Online Nandroid and pulled a good backup
Installed my XDA app. of course..!
-------
Framework-res.apk:
Used total commander to copy the running apk off to the sdCard and then my PC.
Decompilled in APKStudio2.0.3b-Windows (I am also using Ubuntu 14.04 if there is a better way here..also Android Studio on both OS...just learning).
Edited my value.
Recompiled with zip align/sign option.
***Now here in lies the problem, if I haven't already created one above ***
The random article I dug up said that in order to get past the wrong footer and signature issue, and stone-age wipe, when attempting this via abd sideload with an update.zip, is to now copy the edited file back into the original APK using 7zip in order to retain the original signing keys. When I open the original APK archive, it does not show the resource folders deemed "important and I should not jack with them" in the compiled APK (mainly values/* folder). The article mentioned the resource folders such as res/values/bools are compiled and hidden and that I needed to copy over the new resources.arsc file. I see this in the newly compiled APK I made but it also put the Manifest.xml and /res folder in there. Do I need to copy all of that or just the compiled resources.arsc file? I did all and it boot looped me so I'm guessing that I either did something wrong or this was not the right answer. The last part was to chmod the new APK, use total commander to mount the folder as rw, copy over the file, and reboot. All of that worked and I had to reboot many many times...loop.
That is where I am on the modem part and am going to attempt copying just the resources.arsc in a few. I will post more on the bootloader side soon, as I've been researching what goes on from the time I push the power button until the time I swipe the first screen. Lots of reading
w/respect - PitPin
Copying only the resources.arsc file from within the newly compiled apk back to the original framework-res.apk made some progress. Now I have the phone dialer app icon in my apps drawer... but it is failing complaining about contacts. On to the next round of research..!
PitPin said:
Copying only the resources.arsc file from within the newly compiled apk back to the original framework-res.apk made some progress. Now I have the phone dialer app icon in my apps drawer... but it is failing complaining about contacts. On to the next round of research..!
Click to expand...
Click to collapse
Stalled out temporarily on the tab project as laptop hard drive bought the farm. Back in action and made some progress on the tab voice_capable issue. Everything appears to be there and in working order but the SMS modules. I think this has something to do with why the contacts app is blowing up but not sure yet. GoSMS and EXDialer seem to work together without blowing up but the dialer taps the modem and then dies. Taking a break from this to start a thread on rooting the AT&T Alpha. I'm about half way through the exploit on that project. Any input on what might be my SMS problem on the tab 4 would be appreciated. Attached are a few screens.
Does anyone know how to removed the caution sign on the left corner it keep telling me unauthorized action have been detected.
I am in the same boat, I so wish this would come through because I do love this little tab.
same boat
/baker said:
I am in the same boat, I so wish this would come through because I do love this little tab.
Click to expand...
Click to collapse
so did you finally get it going or what?I have been wanting to get my Tab going as well. I've Rooted it and paid for an unlock even, which worked fantastic by the way...Thanx XDA!!! The rooting guide I got from here was right on point,no problem at all!!But anyways, I have it on metro pcs now on the unlimited $60 plan which is awesome (.REAL unlimited internet with NO THROTTLING ) for me because now at home I run pda.net, which gives me very good, fulltime, internet for my home computers as well as the ability to stream everything onto a large screen or even via windows when we want to watch with all the bells and whistles! No lag at all usually,and I don't use my hotspot because of the usb internet connect on pda.net. When I do use the wireless connect, it doesn't take any of the allotted hotspot usage up either!!All in all it's a great deal for me. I just got a new sim for it, called in the imei to metro ,which in turn gave me a phone number and data account, and presto!Been on the net ever since! Now that I've had it for over a month ,I wanna get the voice capability to work as well, being that I am paying for 2 lines now. Although I can use the old trusty hangouts dialer with the GoogleVoice easily enough. I want to be able to use my metro number mainly because these phone companies charge and charge and charge, never caring about us,or our need to have communication at our disposal at all times.Cell phones are by far not inexpensive and the internet wasn't started for us to pay aan arm and a leg to use.Anytime I come out good while dealing with a wireless company. it's a stupendous event,I'm telling you!! Heck ,I'm writing from my home computer now, going through the Tab at this very moment! Nevertheless, I'm wanting for the devs, to come through as well. With maybe even a new rom,sans the at&t stuff, of course, since I do now have a different carrier? Heck, the Tab is even great for when we travel! 24/7 unlimited internet /streaming , and the screen size is much better than the phone screen ever was!I just really wanted to thank XDA for the work they put in to help us part - timers out,Ive been rooting and unlocking and bricking and un-bricking for quite some time now,I even repair phones now actually,but the programming and the putting it all out here for guys like me to have fun and tinker with these phones would be entirely impossible without the DEV'S and their hard work for SURE...Thanx Guys!!You ROCK!
LG G5 VERIZON VS987
Unofficial bootloader unlock
In-Progress
This is a project to disassemble and rebuild an unlocked aboot that passes the sbl loader test, thus allowing installation of custom kernels, read/write access to system, TWRP recovery, and custom ROMs. You can follow the progress or ask questions about it here, or offer your help to make my life a little easier. Donations help, too, especially to maintain the machine these VMs and tools run on.
PHASE 1 - RAMDISK EXTRACTION: DONE
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
PHASE 3 - CERTIFICATE EXTRACTION: IN-PROGRESS
Extracting and parsing the PCS data. It's needed for verification by the sbl to avoid security fail when booting a modified aboot.
PHASE 4 - UNLOCKING NEEDS DONE
Re-coding aboot to accept a bootloader unlock, and access to fastboot.
PHASE 5 - RECOMPILATION AND TESTING (ABOOT)NEEDS DONE
Re-building the aboot binary and testing it.
PHASE 5 - LITTLEKERNEL AND SYSTEM ACCESS (BOOT)NEEDS DONE
Puling apart stock kernel, grabbing needed modules, disabling SELinux and dmverify.
Analysing system image, removing boot-time LG security checks, applying root.
PHASE 6 - TWRP BUILD (RECOVERY) NEEDS DONE
Building user-friendly recovery image.
PHASE 7 - BUILD TOT FILE NEEDS DONE
Package it all into an LGUp Flashable TOT and release.
If you would like to help with this project, please make yourself known.
If you would like to donate to show thanks, the button is underneath my name or in my profile.
If you have a comment or can leave documentation or advice, do so below
Nice.. Hoping for the best
LupineDream said:
LG G5 VERIZON VS987
Unofficial bootloader unlock
In-Progress
This is a project to disassemble and rebuild an unlocked aboot that passes the sbl loader test, thus allowing installation of custom kernels, read/write access to system, TWRP recovery, and custom ROMs. You can follow the progress or ask questions about it here, or offer your help to make my life a little easier. Donations help, too, especially to maintain the machine these VMs and tools run on.
PHASE 1 - RAMDISK EXTRACTION: DONE
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
View attachment 4016279
View attachment 4016280
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
View attachment 4016278
PHASE 3 - CERTIFICATE EXTRACTION: IN-PROGRESS
Extracting and parsing the PCS data. It's needed for verification by the sbl to avoid security fail when booting a modified aboot.
PHASE 4 - UNLOCKING NEEDS DONE
Re-coding aboot to accept a bootloader unlock, and access to fastboot.
PHASE 5 - RECOMPILATION AND TESTING (ABOOT)NEEDS DONE
Re-building the aboot binary and testing it.
PHASE 5 - LITTLEKERNEL AND SYSTEM ACCESS (BOOT)NEEDS DONE
Puling apart stock kernel, grabbing needed modules, disabling SELinux and dmverify.
Analysing system image, removing boot-time LG security checks, applying root.
PHASE 6 - TWRP BUILD (RECOVERY) NEEDS DONE
Building user-friendly recovery image.
PHASE 7 - BUILD TOT FILE NEEDS DONE
Package it all into an LGUp Flashable TOT and release.
If you would like to help with this project, please make yourself known.
If you would like to donate to show thanks, the button is underneath my name or in my profile.
If you have a comment or can leave documentation or advice, do so below
Click to expand...
Click to collapse
Nice to know there is people working on an unofficial bootloader unlock for the lg g5 good job !
I would also like to ask a question if you don't mind : once done, does this variant of the g5 is similar enough to some variants to be able to "port" the unlock or the approach is too specific to the variant ?
Im currently grabbing a more android build-friendly release of Xenial. Google does not support building from a x86 OS. When I tried to git the "official" google toolchain in consideration of doing things 100% correct in a VM, I ran into the dreaded "x86 build host unsupported" problem. The VM host I am grabbing is here: https://forum.xda-developers.com/chef-central/android/guide-how-to-setup-ubuntu-16-04-lts-t3363669 I am going to need the google build source for the kernel, plus the makefiles for the generic arm v7a neon arcitecture. Best do it all the right way instead of having to re-do it all later.
In the meantime, I am cramming some thumb-2 tutorials. La la la~
nalf3in said:
Nice to know there is people working on an unofficial bootloader unlock for the lg g5 good job !
I would also like to ask a question if you don't mind : once done, does this variant of the g5 is similar enough to some variants to be able to "port" the unlock or the approach is too specific to the variant ?
Click to expand...
Click to collapse
I'd have to check the aboot and boot / kernel to see if there's any major differences. Since this is a direct aboot disassembly, it's varient specific, but I will surely be checking if the approach can be applied to different varients' booters via scripting or some such thing. It would mean coding of a patchfile and a TOT builder, adding an entire extra level of complexity, but I'll get to your answer as soon as I have finished with this model.
Howdy there,
Looks like you're attempting to modify an element in the Qualcomm Secure Boot chain (aboot in this case) - unfortunately what you're trying to do won't work.
I don't want to rain on your parade here, or discourage you from learning something for the sake of learning it but simply modifying a component of the boot stack by recompiling it and slapping the same signatures on it isn't possible.
I'd recommend you take a look at any of the awesome posts on XDA about how the Secure Boot 3 (is there a newer version?) process works as you'll see that each step in the boot process (pbl -> xbl -> {tz, rpm} -> aboot) is verified using RSA public/private key signatures.
You won't be able to simply extract the certificate chain from the old aboot (LK) image and append it to your source-built LK, as the hash embedded in the certificate chain won't match the computed hash of the LK application.
Your next thought would be "what if I could find where the validation function is called and replace it?", but you'll find that each step in the boot process calls TrustZone's secureboot verification functions which rely on data stored in qFuses.
Even then, the function TrustZone itself calls is actually provided by PBL and is burned into the chip itself.
Essentially, the path you're trying to take is one that Qualcomm has thoroughly hardened the boot process to protect against.
I'm not trying to discourage you from learning, since doing this sort of reverse engineering is very fascinating and a fun learning exercise - I just want to let you know that if you try to flash a modified aboot image that you'll end up with a brick (and no way that I'm aware of to recover short of soldering up some UFS lines and reflashing like that since iirc even JTAG is disabled now and we lack signed programmers for USB recovery).
Check out one of the Secure Boot PDFs that are available on Google/XDA and you should see what I mean.
Best of luck to you, and happy learning!
LupineDream said:
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
View attachment 4016279
View attachment 4016280
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
View attachment 4016278
Click to expand...
Click to collapse
Like thecubed said, by flashing a modified aboot you'll brick the device, but the fact that you figured out how to extract the aboot image is EXTREMELY impressive! If you wouldn't mind it would be very helpful if you make a guide on how you did that or if you could post your extracted aboot files that would be much much appreciated An insight on how aboot for the G5 works would be something very nice to have
thecubed said:
Howdy there,
Looks like you're attempting to modify an element in the Qualcomm Secure Boot chain (aboot in this case) - unfortunately what you're trying to do won't work.
I don't want to rain on your parade here, or discourage you from learning something for the sake of learning it but simply modifying a component of the boot stack by recompiling it and slapping the same signatures on it isn't possible.
...
[ removed in quote ]
...
Best of luck to you, and happy learning!
Click to expand...
Click to collapse
Thank you for the inspiration. The task has been a thorough crash-course in arm v7a NEON Cortex technology and thumb-2 assembler. I was concerned when I saw the TrustZone documentation from ARM and the ACEP (Arbitrary Code Execution Prevention) stack. Your mention of qfuse brings back memories of the Samsung "Golden Routines" folly.
Unfortunetly I wasn't a backer of the Raspberry PI, but there are other PCBs with GPIO pins. My reason for mention this is the JTAG connundrum you mentioned. It is null and void to a soldering gun, a few resisters ($2-$3, and the on-chip ARM debugging interface included in most integrated ARM chipsets. PCBs that run Linux with a GPIO pin array are the cheapest and most flexable solution to an expensive piece of lab / R & D equipment (JTAG), and the impact on the bank account is a fraction of what it would cost the end-consumer.
Hash collisions and backprop neural nets. What? OK, I'll explain. Most reverse engineering begins with monitoring the usual operation of the device as you are aware. Approach 1 involves training a backpropping neural network to recognize (within a reasonably less amount of computation) a hash collision. Of course, you aren't going to be getting to these pre-coded hashes without breaking the RSA chain (thats 100 zeros O__O ) , this is fixed by monitoring the debug interface we both mentioned earlier, at power-on. ARM processors work such that they cannot do DMAC (direct memory access computation), so the values need to be pushed into registers and acted on as plain byte, then pushed back to memory. Sniff, find out what's coming to/from the qfuse memory bus area into registers, dump the data, and you'll have your root CA with luck. You'll be looking for the in operand, that is, the one that is to be acted on in the cipher that is incoming from qfuse. Cycle-timing to ignore the rest of the computations for this byte, you're basically waiting until qfuse pushes the next byte of its keys into a register and grabbing it in the same cycle the instruction is working on it.
That said, with a $100 and a soldering gun and a laptop, you have your RSA key direct from CPU memory via the debug interface. After you've got your root CA, would it be feasable to start decrypting the intermediate CA chain for each component of boot until you get the hash? In theory this should work without brute-force, but a lot of time in a code window and with an oscilliscope. Once you've had the decrypted hash, you can begin to look for a hash collision. There are open source tools that will find hash collisions in an hour or less using neural nets. Write an aboot that complies to this hash collision, flash it, and qfuse will not be able to tell the difference.
Thats my theory on exploiting the fact ARM needs to do its computations in an area that is accessable to the debug interface. Of course my theory falls apart if the TrustZone chipset has its own processor.
Honestly Annoying said:
Like thecubed said, by flashing a modified aboot you'll brick the device, but the fact that you figured out how to extract the aboot image is EXTREMELY impressive! If you wouldn't mind it would be very helpful if you make a guide on how you did that or if you could post your extracted aboot files that would be much much appreciated An insight on how aboot for the G5 works would be something very nice to have
Click to expand...
Click to collapse
I'd be okay with writing such guide as long as it followed community guidelines. I should not be posting disassembled code and analysis if it's against the rules to do so. If a mod could clear this for me....
After searching around I located the true specs for the G5. It's a Snapdragon 820 SoC. It runs the new ARM v8A instruction set.
More detailed information here -> http://www.tomshardware.com/reviews/snapdragon-820-performance-preview,4389-2.html.
More specifically, it's on the msm8996 platform: http://system-on-a-chip.specout.com/l/1170/Qualcomm-Snapdragon-820-MSM8996
Phones with this arcitechture: https://www.kimovil.com/en/list-smartphones-by-processor/qualcomm-snapdragon-820-msm8996
Xiaomi Mi5 has official bootloader unlock via a tool (reverse engineer to work with our platform?)
HTC 10 bootloader on certain models can be oem-unlocked.
Lenovo ZUK Z2 bootloader can be oem-unlocked
LG V20 bootloader can be oem-unlocked, and is the closest in hardware to our G5!
Perhaps stealing a kernel and boot from a similar varient that allows it, signing it with our key, hash-matching it? It all runs on the same platform with the same instruction set. Most of these phones have unlockable bootloaders.
I'd say the best target would be that unlock tool by Xaoimi. Its usually the third party vendor's tools you can find the biggest security holes in. xD From their documentation, it isn't an "enable OEM unlock" switch in Developer Options used to enable the unlock, the tool itself actually works on the bootloader. Perhaps the tool uses a feature of the MSM8996 we aren't aware of. It's worth looking into.
LupineDream said:
Thank you for the inspiration. The task has been a thorough crash-course in arm v7a NEON Cortex technology and thumb-2 assembler. I was concerned when I saw the TrustZone documentation from ARM and the ACEP (Arbitrary Code Execution Prevention) stack. Your mention of qfuse brings back memories of the Samsung "Golden Routines" folly.
Unfortunetly I wasn't a backer of the Raspberry PI, but there are other PCBs with GPIO pins. My reason for mention this is the JTAG connundrum you mentioned. It is null and void to a soldering gun, a few resisters ($2-$3, and the on-chip ARM debugging interface included in most integrated ARM chipsets. PCBs that run Linux with a GPIO pin array are the cheapest and most flexable solution to an expensive piece of lab / R & D equipment (JTAG), and the impact on the bank account is a fraction of what it would cost the end-consumer.
Hash collisions and backprop neural nets. What? OK, I'll explain. Most reverse engineering begins with monitoring the usual operation of the device as you are aware. Approach 1 involves training a backpropping neural network to recognize (within a reasonably less amount of computation) a hash collision. Of course, you aren't going to be getting to these pre-coded hashes without breaking the RSA chain (thats 100 zeros O__O ) , this is fixed by monitoring the debug interface we both mentioned earlier, at power-on. ARM processors work such that they cannot do DMAC (direct memory access computation), so the values need to be pushed into registers and acted on as plain byte, then pushed back to memory. Sniff, find out what's coming to/from the qfuse memory bus area into registers, dump the data, and you'll have your root CA with luck. You'll be looking for the in operand, that is, the one that is to be acted on in the cipher that is incoming from qfuse. Cycle-timing to ignore the rest of the computations for this byte, you're basically waiting until qfuse pushes the next byte of its keys into a register and grabbing it in the same cycle the instruction is working on it.
That said, with a $100 and a soldering gun and a laptop, you have your RSA key direct from CPU memory via the debug interface. After you've got your root CA, would it be feasable to start decrypting the intermediate CA chain for each component of boot until you get the hash? In theory this should work without brute-force, but a lot of time in a code window and with an oscilliscope. Once you've had the decrypted hash, you can begin to look for a hash collision. There are open source tools that will find hash collisions in an hour or less using neural nets. Write an aboot that complies to this hash collision, flash it, and qfuse will not be able to tell the difference.
Thats my theory on exploiting the fact ARM needs to do its computations in an area that is accessable to the debug interface. Of course my theory falls apart if the TrustZone chipset has its own processor.
I'd be okay with writing such guide as long as it followed community guidelines. I should not be posting disassembled code and analysis if it's against the rules to do so. If a mod could clear this for me....
Click to expand...
Click to collapse
Hello again!
Regarding your points:
JTAG is disabled on most production devices, as in 100% inoperable. No amount of soldering will enable it. I'm sure there are some exceptions to the rule, but in this case I'm fairly confident in saying that the JTAG interface on the G5 is unusable.
...even if JTAG was enabled, the Qualcomm Secure Boot stack is designed to protect itself from the exact type of attack you're describing here. The component of TrustZone that is doing the verification of boot images is not running in anything that is JTAG-accessible, and to my understanding it's not even running in the main ARM core.
Re: hash collisions and neural nets... What you're describing sounds neat in theory, but in application (again, to my knowledge) won't work. I suggest you read up on how RSA works.
RSA is public/private key cryptography - in this case, the certificates contained on the phone are the public component, and LG/Qualcomm are the only ones with the private component. "Extracting the CA" will yield the public portion that is only useful for verifying signatures, not signing them.
The only way you'd be able to sign anything and have the phone trust it is to either a) replace the CA on the phone (not possible, it's burned into qFuses) or b) obtain the private component of the CA or any of it's subsidiaries (also burned into qFuses)
CA chains aren't encrypted, they're just a list of things that the device will accept a signature for. In our case it's Qualcomm as the Root CA, then LG as an intermediate (and possibly a few other intermediates to allow OTA updates to come from differing builders/engineering teams within LG). Again, extracting the 'hash' of a CA will do no good here, as there's no meaningful collisions that can be generated and still be a valid boot image. I'm not the best person to explain RSA in depth, so I'd really recommend doing some further research on it.
LupineDream said:
After searching around I located the true specs for the G5. It's a Snapdragon 820 SoC. It runs the new ARM v8A instruction set.
More detailed information here -> http://www.tomshardware.com/reviews/snapdragon-820-performance-preview,4389-2.html.
More specifically, it's on the msm8996 platform: http://system-on-a-chip.specout.com/l/1170/Qualcomm-Snapdragon-820-MSM8996
Phones with this arcitechture: https://www.kimovil.com/en/list-smartphones-by-processor/qualcomm-snapdragon-820-msm8996
Xiaomi Mi5 has official bootloader unlock via a tool (reverse engineer to work with our platform?)
HTC 10 bootloader on certain models can be oem-unlocked.
Lenovo ZUK Z2 bootloader can be oem-unlocked
LG V20 bootloader can be oem-unlocked, and is the closest in hardware to our G5!
Perhaps stealing a kernel and boot from a similar varient that allows it, signing it with our key, hash-matching it? It all runs on the same platform with the same instruction set. Most of these phones have unlockable bootloaders.
I'd say the best target would be that unlock tool by Xaoimi. Its usually the third party vendor's tools you can find the biggest security holes in. xD From their documentation, it isn't an "enable OEM unlock" switch in Developer Options used to enable the unlock, the tool itself actually works on the bootloader. Perhaps the tool uses a feature of the MSM8996 we aren't aware of. It's worth looking into.
Click to expand...
Click to collapse
Bootloaders for other phones will not work on our phone, as of course it'll fail the Secure Boot check.
Bootloader unlock tools for other phones will not work because they're relying on manufacturer specific unlock code that's compiled into aboot (LK). Qualcomm's CAF version of LK doesn't include any unlock code checking functionality, so most manufacturers add that themselves.
LG, in this case, is not even including the code for a bootloader unlock in the US model bootloaders. If you're familiar with C, essentially LG has `#ifdef`'d the entire section of code out (including fastboot).
The V20 bootloader does indeed contain oem-unlock code, but Secure Boot will prevent you from flashing the V20's bootloader (even if it magically was code-compatible with the G5) because Secure Boot checks the hardware ID that's burned into qFuses.
This means, to add a bootloader unlock, you'd have to modify aboot, which can't be done because of Secure Boot. Secure Boot components can't be modified because of RSA, and the RSA verification can't be altered because the keys are burned into qFuses.
thecubed said:
Hello again!
Regarding your points:
JTAG is disabled on most production devices, as in 100% inoperable. No amount of soldering will enable it. I'm sure there are some exceptions to the rule, but in this case I'm fairly confident in saying that the JTAG interface on the G5 is unusable.
...even if JTAG was enabled, the Qualcomm Secure Boot stack is designed to protect itself from the exact type of attack you're describing here. The component of TrustZone that is doing the verification of boot images is not running in anything that is JTAG-accessible, and to my understanding it's not even running in the main ARM core.
Re: hash collisions and neural nets... What you're describing sounds neat in theory, but in application (again, to my knowledge) won't work. I suggest you read up on how RSA works.
RSA is public/private key cryptography - in this case, the certificates contained on the phone are the public component, and LG/Qualcomm are the only ones with the private component. "Extracting the CA" will yield the public portion that is only useful for verifying signatures, not signing them.
The only way you'd be able to sign anything and have the phone trust it is to either a) replace the CA on the phone (not possible, it's burned into qFuses) or b) obtain the private component of the CA or any of it's subsidiaries (also burned into qFuses)
CA chains aren't encrypted, they're just a list of things that the device will accept a signature for. In our case it's Qualcomm as the Root CA, then LG as an intermediate (and possibly a few other intermediates to allow OTA updates to come from differing builders/engineering teams within LG). Again, extracting the 'hash' of a CA will do no good here, as there's no meaningful collisions that can be generated and still be a valid boot image. I'm not the best person to explain RSA in depth, so I'd really recommend doing some further research on it.
Bootloaders for other phones will not work on our phone, as of course it'll fail the Secure Boot check.
Bootloader unlock tools for other phones will not work because they're relying on manufacturer specific unlock code that's compiled into aboot (LK). Qualcomm's CAF version of LK doesn't include any unlock code checking functionality, so most manufacturers add that themselves.
LG, in this case, is not even including the code for a bootloader unlock in the US model bootloaders. If you're familiar with C, essentially LG has `#ifdef`'d the entire section of code out (including fastboot).
The V20 bootloader does indeed contain oem-unlock code, but Secure Boot will prevent you from flashing the V20's bootloader (even if it magically was code-compatible with the G5) because Secure Boot checks the hardware ID that's burned into qFuses.
This means, to add a bootloader unlock, you'd have to modify aboot, which can't be done because of Secure Boot. Secure Boot components can't be modified because of RSA, and the RSA verification can't be altered because the keys are burned into qFuses.
Click to expand...
Click to collapse
So in this case, what would be the next image in the stack that would allow any kind of modifications? Should I be looking at boot.img instead? Would there be a method of tricking the signed and secure boot chain into believing what it sees isn't executing as root?
had been looking through some old methods of root, like causing a boot error by zeroing laf or flashing over it, causing the bootloader to drop you into fastboot, booted securely from there you could call a kcal perameter of the stock kernel that allowed a sort of debugging mode with systemwide root. That exploit was in the G2 era, and how that device obtained root.
I've seen a method that causes Knox to lock up on some Samsung devices by overloading its memory addresses or repeatedly zeroing certain bits of RAM.
I'd really need to find out what method works. If you can't make any modification, maybe there's a workaround to make it THINK everything is legit beyond the boot chain.
aboot decription
Ok I have been working on an lg g5 vs987 myself and I got to the recoding the aboot part and was totally lost its all encrypted and I have no idea where to start to even see what the code is really saying I am new to this website and I am also new to coding on android if you can guide me in the right direction I might be able to help. I have always dreamed of being a part of a development like this and now I might have a shot. Thank you so much for your work and I hope to hear from you soon!
alphawolves said:
Ok I have been working on an lg g5 vs987 myself and I got to the recoding the aboot part and was totally lost its all encrypted and I have no idea where to start to even see what the code is really saying I am new to this website and I am also new to coding on android if you can guide me in the right direction I might be able to help. I have always dreamed of being a part of a development like this and now I might have a shot. Thank you so much for your work and I hope to hear from you soon!
Click to expand...
Click to collapse
Dissembling and recoding aboot wont work no matter even if it is not encrypted..
It is already mentioned above by @thecubed ..
The secure boot will always verify the signature and dissassembly will generate no signature.
We need to find the private keys used for generating the public hash.. but that is not possible unless leaked from lg which is also very unlikely..
What a hacker can do is find a bug/vulnerability in aboot that can bypass secureboot..or a hardware loophole..
Plus there is a trustzone that itself secures the secureboot process.. so we have to find ways to exploit the bootchain so that we can somehow make the bootloader load unsigned ramdisks/recovery and such..
experienced people could do it.. but i guess there has been a lot of fuss between devs and wannabees..
Also if we can get debug build of aboot/ramdisk we can flash them to get unlock or at the very least root..
I am not expert on this but that how its simply put
A brave member sent me a very useful PDF specification on the TSF. The TSF is the official name for the portion of the integrated circuitry that controls the storage of the secure boot chain. The hardware routines are there to allow root to happen, but as stated before by @thecubed, LG commented out the entire section of a boot at compile time that allows anything to occur. Now the approach is to disassemble HOW the code that LG commented out works in the international variant that has an OEM unlock. Hardware routines exist that place the TSF into non-commercial mode, disabling functionality of certain enterprise software and deauth-ing the root CA in qfuse, allowing the user to flash their own signing certificates to the TSF (TrustZone) when a request to switch off CC mode is sent. There are all kinds of virtual memory protections, ACE protections, malicious code protections, and other things that the TSF handles. Trying any kind of unauthorised write to protected areas of memory results in blow of qfuse write fuse. It's actually a physical microscopic fuse that when pushed a specific voltage pops at a microscopic level kind of like a big fuse blowing only at a very tiny level. At this point write access anywhere is gone. This happens at the same time a full wipe of the system happens. That is why they say once qfuse blows your phone becomes a very expensive cup holder. Because after the qfuse blows there is no way of software recovery.
The only way to be able to disable commercial (CC mode) and be allowed to do anything to put your own boot chain in is to place the device in debug mode. The international varient contains code how to accomplish this, our devices don't. You would need to compile an app that runs in normal mode, causes a flag to be set that places the device into debug mode, then reboot. While in debug boot, you should be able to execute a CC unlock manually. The PDF I got says it's very specifically timed when this can happen, what parts of boot the TSF allows it to happen, and a rough explanation if what disabling CC mode means. The only way of getting root is to use the TSF-approved method but all this code is removed. The TSF does not stop you from executing code if booted into factory debug mode. The new approach I propose is to find an exploit to get into userdebug, and manually write an unlock routine with disassembled information from the international varient., pushing it directly into execution memory while in userdebug, being absolutely sure to give the TSF what it asks for, when it asks for it, at the exact timing for it.
LupineDream said:
A brave member sent me a very useful PDF specification on the TSF. The TSF is the official name for the portion of the integrated circuitry that controls the storage of the secure boot chain. The hardware routines are there to allow root to happen, but as stated before by @thecubed, LG commented out the entire section of a boot at compile time that allows anything to occur. Now the approach is to disassemble HOW the code that LG commented out works in the international variant that has an OEM unlock. Hardware routines exist that place the TSF into non-commercial mode, disabling functionality of certain enterprise software and deauth-ing the root CA in qfuse, allowing the user to flash their own signing certificates to the TSF (TrustZone) when a request to switch off CC mode is sent. There are all kinds of virtual memory protections, ACE protections, malicious code protections, and other things that the TSF handles. Trying any kind of unauthorised write to protected areas of memory results in blow of qfuse write fuse. It's actually a physical microscopic fuse that when pushed a specific voltage pops at a microscopic level kind of like a big fuse blowing only at a very tiny level. At this point write access anywhere is gone. This happens at the same time a full wipe of the system happens. That is why they say once qfuse blows your phone becomes a very expensive cup holder. Because after the qfuse blows there is no way of software recovery.
The only way to be able to disable commercial (CC mode) and be allowed to do anything to put your own boot chain in is to place the device in debug mode. The international varient contains code how to accomplish this, our devices don't. You would need to compile an app that runs in normal mode, causes a flag to be set that places the device into debug mode, then reboot. While in debug boot, you should be able to execute a CC unlock manually. The PDF I got says it's very specifically timed when this can happen, what parts of boot the TSF allows it to happen, and a rough explanation if what disabling CC mode means. The only way of getting root is to use the TSF-approved method but all this code is removed. The TSF does not stop you from executing code if booted into factory debug mode. The new approach I propose is to find an exploit to get into userdebug, and manually write an unlock routine with disassembled information from the international varient., pushing it directly into execution memory while in userdebug, being absolutely sure to give the TSF what it asks for, when it asks for it, at the exact timing for it.
Click to expand...
Click to collapse
Thanks for that post @LupineDream ! I unfortunately doesn't understand most of the things you explained but perhaps I can save you a bit of time (your last post looks like you aren't aware of that exploit but thats maybe only me misundertanding) ; as far as I know the adb root method develloped by @HonestlyAnnoying include a userdebug kernel so (afaik) we already know an exploit to get into userdebug on marshmallow(dirty santa) and the fact that the users needs to run marshmallow shouldn't matter as (afaik) once the bootloader unlocked, the userdebug kernel is no longer needed and it is possible to change it.
Edit: just saw your post on the adb root thread, so I guess you are now aware of the exploit Sorry for the post, I just wanted to be sure you didn't missed it.
nalf3in said:
Thanks for that post @LupineDream ! I unfortunately doesn't understand most of the things you explained but perhaps I can save you a bit of time (your last post looks like you aren't aware of that exploit but thats maybe only me misundertanding) ; as far as I know the adb root method develloped by @HonestlyAnnoying include a userdebug kernel so (afaik) we already know an exploit to get into userdebug on marshmallow(dirty santa) and the fact that the users needs to run marshmallow shouldn't matter as (afaik) once the bootloader unlocked, the userdebug kernel is no longer needed and it is possible to change it.
Edit: just saw your post on the adb root thread, so I guess you are now aware of the exploit Sorry for the post, I just wanted to be sure you didn't missed the exploit.
Click to expand...
Click to collapse
Yes thank you for affirming that, but not to worry, I got it. LG has an sbl module called anti-rollback that prevents flashing older software. If we look at the boot chain:
Code:
recovery
| /------------------ laf (fastboot)
__________________|__|_________________________________________ laf (security fail screen)
/ / / /
pbl -> sbl > aboot > boot (kernel/ramdisk) > system
^ ^
| |
| \-- IS_UNLOCKED and sig_Check()
Anti-rollback
I beleive anti-rollback was updated to a new version that prevents this on Nugout. Correct me if I'm wrong. I've tried every LG hidden menu code I could find to see, but can't even seem to get the hidden menu working... And the reason they did this is because of the worldwide alerts about dirtycow, which affects not only Android, but the whole of Linux, so we need a nogout kernel. A marshmallow kernel with the new anti-rollback would theoretically end up in the red triangle of death.
We need someone that has an engineering model with a userdebug kernel. LG makes you apply. Their program is called "LG GATE", and they are very picky. I think that's what helped out the Sprint community. Someone got a hold of a developer / engineering model with a marshmallow kernel.
Well, I already heard of that strange issue with the hidden menu and I always though it was a code 18 but after googling, it looks like it some carrier potentially disabled it.. Anyway, I can confirm you that the anti-rollback version is still 0 on my h831 running the latest nougat unless the hidden menu is "lying". (And most variant I know except sprint, which did triggered the counter with the update, stayed at their rollback version). I still encounter the same issues most people on nougat experienced with the adb root (wasn't able to get past reboot and needed to flash with uppercut a fresh 7.0 ) so I guess the issue is somewhere else.
Also, if you need any information that is on the hidden menu, feel free to ask me
http://m.imgur.com/gallery/fTwgSUF
Very exciting, gl
finally they are working on it
What about this line in the aboot.bin
(from canadian aboot)
LOAD:0F960100 aBootVerificati DCB " : boot verification skip ",0xA,0
Is there any way to disable boot verification? no need to go with full bootloader unlock.. if it's possible to just disable boot verification, right?
Hello and thank you to anyone that can point me in the right direction.
I was recently given a Note 3 from a friend and for whatever reason it will not detect any SD card. The SD cards are fine and work in my other Android phones, Windows computers and anything else. So aside from that, is there any way to unlock the bootloader on this phone without the use of an SD card? All the methods I've come across mention one is needed. Thanks.
NM. I think I found what I was looking for here.
riotstarter said:
NM. I think I found what I was looking for here.
Click to expand...
Click to collapse
Possibly* a lesser-effort way - same thread, but here.
I say "possibly" because you didn't state which OS release was on the phone. (I can assume MI9->NC4, OB6, or OF1 as you must be rooted. NJ6, NK1, and PL1 are - as of this time - problematic for easy rooting).
There were some dependencies of the exploit code on OS version due to the location of the "CID" value moving around inside the kernel volatile filesystem /sys. You might have to take account of that in building/modding the code. (Either that or just get rid of the CID check if you know that you have a 0x15 eMMC chip device). Unfortunately, you need to thoroughly read about the first 350 posts in that thread to completely understand the discoveries that were made.
Anyway, some pointers to version compatibility are here.
* @beaups code is very straightforward. (@donc113 's mods of that code have the correct binary patching blob for the SM-N900V - beaups's github code was for the AT&T version of the phone) You probably will have more troubles setting up a toolchain than actually modding or compiling the code if you go that route.
good luck.
ps good to see someone in here that's not afraid of a compiler
bftb0 said:
Possibly* a lesser-effort way - same thread, but here.
I say "possibly" because you didn't state which OS release was on the phone. (I can assume MI9->NC4, OB6, or OF1 as you must be rooted. NJ6, NK1, and PL1 are - as of this time - problematic for easy rooting).
There were some dependencies of the exploit code on OS version due to the location of the "CID" value moving around inside the kernel volatile filesystem /sys. You might have to take account of that in building/modding the code. (Either that or just get rid of the CID check if you know that you have a 0x15 eMMC chip device). Unfortunately, you need to thoroughly read about the first 350 posts in that thread to completely understand the discoveries that were made.
Anyway, some pointers to version compatibility are here.
* @beaups code is very straightforward. (@donc113 's mods of that code have the correct binary patching blob for the SM-N900V - beaups's github code was for the AT&T version of the phone) You probably will have more troubles setting up a toolchain than actually modding or compiling the code if you go that route.
good luck.
ps good to see someone in here that's not afraid of a compiler
Click to expand...
Click to collapse
Thanks I appreciate the response. Yes I am on OF1 with a 0x15 chip. I've downloaded donc113's file and Android SDK/NDK. Does donc113's mod of the code already include what I'd be needing the SDK/NDK for? I'm definitely not afraid of trying something unfamiliar, I just want to ensure I'm doing it right. I'll do some more digging and see if I can figure things out a little more.
riotstarter said:
Does donc113's mod of the code already include what I'd be needing the SDK/NDK for?
Click to expand...
Click to collapse
Should be. Really the only thing you should check to see is if the path in /sys to the CID file on your OF1 phone is one of the paths that he is checking for. You can use the "strings" command for that.
OK, I just downloaded his code and did that ("strings" command). Here are the paths he is searching:
Code:
/sys/devices/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/cid
/sys/devices/platform/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/cid
/sys/class/mmc_host/mmc0/mmc0:0001/cid
/sys/devices/msm_sdcc.1/mmc_host/mmc1/mmc1:0001/cid
If OF1 uses one of these, then you don't even need to compile anything, just run the binary.**
**there is a brutal form of "avoid compiling" hackery where you simply perform a binary edit of an executable file in order to change a constant value in the code such as a string. So long as the replacement string is shorter than the original, you can just replace the string and null-pad the unused length (as strings are assumed to be null-terminated in C). For example, if there was a pathname in a .bss or .rodata segment such as
Code:
/foo/original/path/filenameX
/bar/replacement/myname\0\0\0\0\0
this works so long as the replacement string's bytelength is less than or equal to the length of the original string. (And the code is not performing a signing or other integrity check of itself.)
Only to be used when you don't have the code to be compiled or emergencies such as when you are in a hurry LOL.
(Obviously you can not shorten or lengthen the file at all doing this: all the byte offsets in the file must remain unchanged).
https://forum.xda-developers.com/showthread.php?p=71448959
Sent from my SM-N900V using Tapatalk
Am on Sm-n900v (Rooted)
Android 5.0
0B6.
Want to unlock bootloader but need some strict instructions