Database Info

[DEV] Bootloader Signature Bypass

Hello @rbox,
I have implemented a bootloader signature bypass and was wondering if you could help me verify my method.
Because we know this works for the firetv, my plan is:
1. You could send me one of your unsigned custom recoveries for firetv.
2. I would then sign it and send it back to you to check it works.
Hope you don't mind me contacting you this way.
ggow

Woah! Props! I still don't plan on picking up an HDX, but at least it'll get some development now! Now just to get root on KitKat for you guys.

@rbox,
I should add some information which I forgot to include earlier:
I tried the recovery image on the device but failed to boot which is why I need some help to verify my method to find out whether our bootloader is susceptible to this approach, mathematically it looks good (I think). See what you think. I have PM'ed you a link to the modified recovery image as we discussed.

Conclusions
@rbox
In short I found our bootloader is NOT susceptible to the signature bypass method.
I tried first on stock 13.3.2.4 and then on stock 13.3.1.0.
Thanks for your help rbox. I really appreciate you taking the time.
I had some implementation issues in my work which led to to the differences between our output files.
I believe I have fixed those now.

Bootloader question
How much has been done with anyone looking into the unlock code functionality for the bootloader? I have spent a ton of time (mostly wasted time it has turned out), trying to make any kind of sense of the bootloader using IDA Pro with hex-rays decompilation. It seems easy enough to write an unlock code for the device using idme, but not knowing what the code is, and not knowing where in the bootloader decompilation the unlock checking is done has just lead to dead ends. I assume from some posts in much older development threads that some very smart people already spent some time attempting to decompile the bootloader and didn't have much luck. Does anyone think anything can be gained from further muddling around with the decompilation?

gbgadgets said:
How much has been done with anyone looking into the unlock code functionality for the bootloader? I have spent a ton of time (mostly wasted time it has turned out), trying to make any kind of sense of the bootloader using IDA Pro with hex-rays decompilation. It seems easy enough to write an unlock code for the device using idme, but not knowing what the code is, and not knowing where in the bootloader decompilation the unlock checking is done has just lead to dead ends. I assume from some posts in much older development threads that some very smart people already spent some time attempting to decompile the bootloader and didn't have much luck. Does anyone think anything can be gained from further muddling around with the decompilation?
Click to expand...
Click to collapse
I did the same as you and found "unlock_code" can be read from idme, but not without unlocking the bootloader. I can't seem to find it in any partition either.
ggow said:
@rbox
In short I found our bootloader is NOT susceptible to the signature bypass method.
I tried first on stock 13.3.2.4 and then on stock 13.3.1.0.
Thanks for your help rbox. I really appreciate you taking the time.
I had some implementation issues in my work which led to to the differences between our output files.
I believe I have fixed those now.
Click to expand...
Click to collapse
Have you taken a look at the 2nd_init hack? Safestrap uses it to load a recovery, but it can also be used to load new kernels.

r3pwn said:
I did the same as you and found "unlock_code" can be read from idme, but not without unlocking the bootloader. I can't seem to find it in any partition either.
Have you taken a look at the 2nd_init hack? Safestrap uses it to load a recovery, but it can also be used to load new kernels.
Click to expand...
Click to collapse
Hi r3pwn, I looked at 2nd init. I can use it to load a new ramdisk which is great. But I don't think you can load a different kernel. Also correct me I'm wrong, I don't think we can boot kitkat on the jelly bean kernel with a modified ramdisk.
Sent from my Nexus HDX 7 using Tapatalk

ggow said:
Hi r3pwn, I looked at 2nd init. I can use it to load a new ramdisk which is great. But I don't think you can load a different kernel. Also correct me I'm wrong, I don't think we can boot kitkat on the jelly bean kernel with a modified ramdisk.
Sent from my Nexus HDX 7 using Tapatalk
Click to expand...
Click to collapse
Oh. My bad. Meant ramdisk. Not sure why kernel came out. The devs over with the Sony Xperia SP (I think, lemme double check) managed to run Lollipop on their JB 4.3 device using the 2nd init. Let me look some more and report back with (hopefully) useful info.
Edit: Yep, it is the SP. Their rd hijack process: https://bitbucket.org/bagyusz/hijack-ramdisk-huashan/src/20a66537e120?at=cm-10.2_LBL. They list the rest of their sources at the bottom of the post here (Device tree, vendor tree, how to make the ramdisk alone, etc...): http://forum.xda-developers.com/xperia-sp/development/xperiasp-locked-bootloader-lbl-t2947194

Cool, will take a look
Sent from my Nexus HDX 7 using Tapatalk

r3pwn said:
Oh. My bad. Meant ramdisk. Not sure why kernel came out. The devs over with the Sony Xperia SP (I think, lemme double check) managed to run Lollipop on their JB 4.3 device using the 2nd init. Let me look some more and report back with (hopefully) useful info.
Edit: Yep, it is the SP. Their rd hijack process: https://bitbucket.org/bagyusz/hijack-ramdisk-huashan/src/20a66537e120?at=cm-10.2_LBL. They list the rest of their sources at the bottom of the post here (Device tree, vendor tree, how to make the ramdisk alone, etc...): http://forum.xda-developers.com/xperia-sp/development/xperiasp-locked-bootloader-lbl-t2947194
Click to expand...
Click to collapse
@r3pwn,
Thanks for the pointing me in that direction... With the 13.3.2.4 stock kernel I have a build of aosp lollipop 5.0.1 which now boots to some degree. Very early days yet but some progress. I now have adb access. I can see that in logcat services are starting up and then dying.
I can't see the boot animation yet because the video driver / surfaceflinger is not starting. First goal is to get that and full hw graphical support working.
Definitely a way forward

ggow said:
@r3pwn,
Thanks for the pointing me in that direction... With the 13.3.2.4 stock kernel I have a build of aosp lollipop 5.0.1 which now boots to some degree. Very early days yet but some progress. I now have adb access. I can see that in logcat services are starting up and then dying.
I can't see the boot animation yet because the video driver / surfaceflinger is not starting. First goal is to get that and full hw graphical support working.
Definitely a way forward
Click to expand...
Click to collapse
Thanks! Glad I could help! If there's anything you need help with, let me know and I could try to get in contact with the Xperia SP devs and maybe even get a Hangout set up.

I have examined aboot for some time now and I can think of 3 methods to unlock the bootloader:
Provide the unlock code. The code seems to be a 512 byte image, that is flashed by "fastboot flash unlock code.img". The code is somehow verified using a X509 certificate. Writing an arbitrary code to unlock_code won't work, because the code will be verified the same way the code.img is verified.
Overwrite the certificate a custom one and create a custom code. For this approach we have to understand the verification process and we obliviously need to know the location of the certificate and write access.
There is some variable called "production" we would have to change. The variable is obtained by
Code:
MOV R3, 0xFD511004
LDR R0, [R3,R0,LSL#4]
AND R0, R0, #1
R0 has the value 0x5C.
In C pseudocode:
Code:
int production = *(0xFD511004 + 92*2^4) & 1;
The default value of that variable is 1.
Anyone with ideas here?

vortox said:
I have examined aboot for some time now and I can think of 3 methods to unlock the bootloader:
Provide the unlock code. The code seems to be a 512 byte image, that is flashed by "fastboot flash unlock code.img". The code is somehow verified using a X509 certificate. Writing an arbitrary code to unlock_code won't work, because the code will be verified the same way the code.img is verified.
Overwrite the certificate a custom one and create a custom code. For this approach we have to understand the verification process and we obliviously need to know the location of the certificate and write access.
There is some variable called "production" we would have to change. The variable is obtained by
Code:
MOV R3, 0xFD511004
LDR R0, [R3,R0,LSL#4]
AND R0, R0, #1
R0 has the value 0x5C.
In C pseudocode:
Code:
int production = *(0xFD511004 + 92*2^4) & 1;
The default value of that variable is 1.
Anyone with ideas here?
Click to expand...
Click to collapse
I can't answer that, but @Cpasjuste may be revealing something soon according to this thread: http://forum.xda-developers.com/kindle-fire-hdx/development/cm-11-t2971457

I was using some information from this source aboot reverse engineering to try and figure more out about the structure of aboot. The fact that the strings are obfuscated and don't appear through the decompiled functions was the biggest hurdle I was running into starting with this. I tried to use the open source little kernel code to see if a few of these functions could be put into better pseudocode and perhaps crack the string obfuscation to be able to xref more strings throughout the decompilation of the hundreds of functions. Just kept getting stuck.

I've been using this loader for IDA. I see a lot of strings and they have been very useful .
Further I've found the certificate in the aboot partition. This means my 2. suggestion probably wouldn't work.
This leaves me with 2 two possible options:
Brute force the image (unlikely)
Looking at the production variable to see if it can be safely overwriten without a side effect

vortox said:
I've been using this loader for IDA. I see a lot of strings and they have been very useful. [/LIST]
Click to expand...
Click to collapse
Off-topic,
you can use this loader to load sbl1.mbn, sbl2,mbn, sbl3.mbn, aboot.mbn tz.mbn and rpm.mbn?
maybe a debricking solution...

aaronkatrini said:
Off-topic,
you can use this loader to load sbl1.mbn, sbl2,mbn, sbl3.mbn, aboot.mbn tz.mbn and rpm.mbn?
maybe a debricking solution...
Click to expand...
Click to collapse
Nope. It's just to load those files into IDA PRO and helps reverse engineering them.

vortox said:
I've been using this loader for IDA. I see a lot of strings and they have been very useful .
Further I've found the certificate in the aboot partition. This means my 2. suggestion probably wouldn't work.
This leaves me with 2 two possible options:
Brute force the image (unlikely)
Looking at the production variable to see if it can be safely overwriten without a side effect
Click to expand...
Click to collapse
Could you share the certificate? I think there should be no legal problem with that.
@vortox
This article may refer to the production variable your talking about.
http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
Seems to be following CVE: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0974
Besides of that, has somebody tried to insert the kexec module into the kernel? http://forum.xda-developers.com/galaxy-note-3/devs-only/kernel-kernel-execution-loading-custom-t2812650

D0ubl3_X said:
Could you share the certificate? I think there should be no legal problem with that.
Click to expand...
Click to collapse
I will try my best to obtain the cerificate.
@vortox
This article may refer to the production variable your talking about. http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
Click to expand...
Click to collapse
Thanks for the link.
Seems to be following CVE: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0974
Click to expand...
Click to collapse
I will take a look at that.
Edit:
@D0ubl3_X
Here the certificate used for checking the unlock code. http://www45.zippyshare.com/v/82885181/file.html
Edit2 :
The post in the blog does not match the CVE. This is the right one. This exploit hat been patched.
But the CVE you posted seems unpatched. Atleast on my device with .3.2.4. The newer version are probably patched.
Edit3:
Another possible exploit: https://www.codeaurora.org/projects...tion-leads-to-signature-forgery-cve-2014-0973

September 4th - @jcase said : "If you can port it yourself, feel free, more than one of these works on the HDX https://www.codeaurora.org/projects/security-advisories ..."
There are 18 exploits, but at least one of them works!

Android bug: security risk

Android bug: MMS attack affects 'one billion' phones - http://www.bbc.co.uk/news/technology-33689399
Can the patch be manually downloaded from somewhere and manually installed in rooted phones? Where?
Prefer to not go the OTA route because I am rooted and use xposed framework.

Is the patch issued out and available by Google yet?
Running Cataclysm, but don't see an update for it yet for the MMS bug.

Patched stagefright libraries for AOSP 5.1.1
For those who are interested: I patched AOSP 5.1.1 (LMY48B) with the code changes that were submitted to CM by the researcher who detected the flaw, see e.g. here. The attached archive contains the 17 (!) modified libraries. I just pushed the files to my device running stock 5.1.1 and it boots fine. I do not not have any information on whether the patch actually does what it is supposed to do or whether the new libs result in breakage somewhere else.
Update: added three additional patches to libstagefright submitted to CM by the same security researcher (jduck) as detailed here.
Update (August 14): added latest stagefright vulnerability patch as described here

From what I have read this should not really affect our devices. It is more older devices that have issues.

wangdaning said:
From what I have read this should not really affect our devices. It is more older devices that have issues.
Click to expand...
Click to collapse
Well, from what I've read/seen it appears that the Nexus 5 on 5.1.1 is fully exploitable. However, sandboxing and "address space layout randomization" make it a lot more difficult to actually achieve anything with the exploit, but the probability is not zero. We will probably know more after the hacker conference next week.
Note that I have updated the patched libraries that I attached to my previous post. In the update I added three additional patches to libstagefright that have been submitted to CM by the security researcher who has found the exploit back in April, see here

chdloc said:
For those who are interested: I patched AOSP 5.1.1 (LMY48B) with the code changes that were submitted to CM by the researcher who detected the flaw, see e.g. here. The attached archive contains the 17 (!) modified libraries. I just pushed the files to my device running stock 5.1.1 and it boots fine. I do not not have any information on whether the patch actually does what it is supposed to do or whether the new libs result in breakage somewhere else.
Edit: added three additional patches to libstagefright submitted to CM by the same security researcher (jduck) as detailed here.
Click to expand...
Click to collapse
Added the patched libs and my phone didn't blow up so that's a good sign. Too bad there isn't a good way to test it.

chdloc said:
Well, from what I've read/seen it appears that the Nexus 5 on 5.1.1 is fully exploitable. However, sandboxing and "address space layout randomization" make it a lot more difficult to actually achieve anything with the exploit, but the probability is not zero. here
Click to expand...
Click to collapse
Is the rooted nexus 5 on 4.4.4 (with xposed) any safer?
How to sandbox? Is there an app for that?
Thanks.

Anderson2 said:
Is the rooted nexus 5 on 4.4.4 (with xposed) any safer?
Click to expand...
Click to collapse
A rooted device is less secure than a non-rooted device. A device with Xposed is theoretically less secure than that.
Anderson2 said:
How to sandbox? Is there an app for that?
Click to expand...
Click to collapse
Application sandboxing is done by default in Android.

chdloc said:
For those who are interested: I patched AOSP 5.1.1 (LMY48B) with the code changes that were submitted to CM by the researcher who detected the flaw, see e.g. here. The attached archive contains the 17 (!) modified libraries. I just pushed the files to my device running stock 5.1.1 and it boots fine. I do not not have any information on whether the patch actually does what it is supposed to do or whether the new libs result in breakage somewhere else.
Update: added three additional patches to libstagefright submitted to CM by the same security researcher (jduck) as detailed here.
Click to expand...
Click to collapse
Just an fyi; if you're waiting for your rom to be updated, swapping in these patched libs will close the hole (at least according to zImperium's Stagefright check app).

FYI, added latest stagefright vulnerability patch as described here to post #3.
As before, you need to push the libraries manually to /system/lib/, followed by an adjustment of permissions (644), if required.
The latest Zimperium Stagefright Detector app, updated today, returns "not vulnerable" to the (as of today) seven known security vulnerabilities of stagefright.

chdloc said:
FYI, added latest stagefright vulnerability patch as described here to post #3.
As before, you need to push the libraries manually to /system/lib/, followed by an adjustment of permissions (644), if required.
The latest Zimperium Stagefright Detector app, updated today, returns "not vulnerable" to the (as of today) seven known security vulnerabilities of stagefright.
Click to expand...
Click to collapse
Works like a charm... until the next hole is discovered.

chdloc said:
I just pushed the files to my device running stock 5.1.1 and it boots fine. I do not not have any information on whether the patch actually does what it is supposed to do or whether the new libs result in breakage somewhere else.
Click to expand...
Click to collapse
Thanks so much for doing this! I've unzipped these to Dirty Unicorns OFFICIAL-v9.5 (5.1.1) and things appear to be booting/running OK. Zimperium detector also says everything is now good.

I am on rooted nexus 5, version 5.1.1
By manually pushing it do you mean through custom recovery or for example by using flashify app to flash the file, or directly copy pasting it?
And by adjusting permission if required, can you explain how that is done?
Thank you

+1
Are they the same patches for 4.4.4?

persianrisk said:
I am on rooted nexus 5, version 5.1.1
By manually pushing it do you mean through custom recovery or for example by using flashify app to flash the file, or directly copy pasting it?
And by adjusting permission if required, can you explain how that is done?
Thank you
Click to expand...
Click to collapse
To be safe, backup your device before proceeding.
By "pushing files to phone" I mean unpack the archive attached to the third post in this thread and manually copy the resulting files to your device by either using
adb push [...]
or (assuming you use Windows on your host machine)
Explorer
to copy all files to the "sdcard" on your phone.
Then use a file explorer on your phone, such as Root Explorer, to copy the files into place, i.e. /system/lib/
To adjust permissions, again, use the file explorer on your device to verify the "permissions" property of each of the new files. If you don't see rw-r--r, or 644, adjust the permissions appropriately.
Anderson2 said:
+1
Are they the same patches for 4.4.4?
Click to expand...
Click to collapse
No, the patched files posted in the third post of this thread were built on Android (AOSP) 5.1.1. They will not work on KitKat.

Are there similar patched files for 4.4.4?

Anderson2 said:
Are there similar patched files for 4.4.4?
Click to expand...
Click to collapse
Unless patches are forthcoming from Google, I don't think there will be. KK development is essentially dead.

Thank you very much. I followed your steps (used Root Explorer as ES File Manager did not work).
When I run Stage fright detector App by Zimperium INC. and the one by Michael Kohl it says that I am not vulnerable.
But, when I run the one by LookOut Security says I am vulnerable. Any thoughts?

OK, I guess I will move to 5.1.1. May sound easy to pros like you but it's a scary step to users like me. ?

ext2/3/4 filesystem create/fix tools (e2fstools pkg) static build for arm64 devices

e2fstools package, statically built for arm64 devices from Google's googlecode.com Oreo branch
NOTE: These will support ANY version of android's filesystems that use ext2 or ext3 or ext4. I built them from oreo branch as that one was the closest to compiling without any editing of the Makefiles. Don't let the name throw you off
I needed to run a modern fsck on a rooted device I have that I have been doing some hacking on.
The filesystem was in bad shape and the on-device e2fsck absolutely refused to check it while it was even mounted, even with the force option. Out of part desperation part determination I decided I would just build one myself. So I went and dug up the sources from googlecode.com, transfered them to my linux workstation, and after much fighting with gcc for cross compilation, finding a place in the google git repo where they actually build (hence going with orero), and having to tweak the c code even in a few places (mostly fixing includes and whatnot, no actual coding on my part), I succeeded.
As it says in the title, these are all the e2fstools binaries built from Google's googlecode.com source tree in their Oreo release branch. They are also compiled statically (no libraries are needed for them to function) so they should work absolutely fine on any device that has a 64bit arm (aarch64) processor. I have tested a handfull of them and they work perfectly fine on my Samsung Galaxy s8. In fact I used the fsck.ext4 binary to repair my system partition which it did perfectly.
https://www.dropbox.com/s/owb76hohnjzjdwe/e2fstools-oreo-aarch64-static.tar.gz?dl=0
Hope they come in as handy to someone else as they did me.
List of files follows:
Code:
[email protected]:~> tar tzf e2fstools-oreo-aarch64-static.tar.gz
e2fsbin/
e2fsbin/e2undo
e2fsbin/e2image
e2fsbin/badblocks
e2fsbin/mkfs.ext3
e2fsbin/fsck.ext4dev
e2fsbin/e2initrd_helper
e2fsbin/fsck.ext3
e2fsbin/e4crypt
e2fsbin/e4defrag
e2fsbin/mke2fs
e2fsbin/e2fsck
e2fsbin/fsck.ext4
e2fsbin/filefrag
e2fsbin/tune2fs
e2fsbin/e2freefrag
e2fsbin/uuidd
e2fsbin/e2label
e2fsbin/mkfs.ext2
e2fsbin/blkid
e2fsbin/logsave
e2fsbin/lsattr
e2fsbin/uuidgen
e2fsbin/findfs
e2fsbin/mklost+found
e2fsbin/dumpe2fs
e2fsbin/mkfs.ext4
e2fsbin/debugfs
e2fsbin/fsck.ext2
e2fsbin/mkfs.ext4dev
e2fsbin/resize2fs
e2fsbin/chattr
e2fsbin/fsck
PS: Now that I have a working arm64 cross compilation system setup, if anyone else desperately needs a working static binary for anything relatively simple to build (as in not 50 million dependencies for me to track down and install) and can send me or link me the sources for it and its dependencies, I would be happy to oblige.

Unfortunately, my device is armv7

buengeut said:
Unfortunately, my device is armv7
Click to expand...
Click to collapse
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️

partcyborg said:
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️
Click to expand...
Click to collapse
ARMv7 is ARM 32bit, 64bit program will not work on a 32bit system.
Can you build e2fstools for ARMv7.

Sadly your link is down.
would you care to reupload?

LNQ said:
Sadly your link is down.
would you care to reupload?
Click to expand...
Click to collapse
Sure. I'll even make it flashable this time ?

Thanks alot, good sir!

Legend! I'd been dealing with not being able to repair my /data errors for the past few days since my Oreo update. The current TWRP (3.2.3.4) still has an ancient e2fsck that doesn't support the ext4 quota option that LG formats their Oreo data partition with. The updated version in /system/bin works while the OS is running which is why I knew I had errors, but I couldn't get it to run in TWRP to fix them because of the incompatible library files.
I was all set to reinstall my Android SDK and compile another version with inbuilt libraries when I decided to do one last search and found this thread where you'd already done it. So thanks for saving me a few hours of downloading/installing/remembering how to compile for Android all over again
I guess I can also vouch for it working on an LG V20. I don't know if it's just LG's version of Oreo that needs the later e2fsck or others too, but anyone who can't repair errors on their ext4 partitions in TWRP due to needing a newer e2fsck version should be able to use this version. I just copied the file fsck.ext4dev to /cache and ran it from there on my data partition.

Your link is dropbox banned...
Any chance you could attach the zip here...?

quotient said:
Your link is dropbox banned...
Any chance you could attach the zip here...?
Click to expand...
Click to collapse
Seconded!
@partcyborg
Any chance you could put this file somewhere else? The above link is banned.
Thanks!

Hi,
I have a Oneplus 3 that after 3 years of use became sluggish as hell at file system access.
After reading thus document https://www.usenix.org/system/files/conference/hotstorage16/hotstorage16_ji.pdf
I would give a try to your e2fstools build.
Can you repost a link to download?
Thanks in advance

partcyborg said:
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️
Click to expand...
Click to collapse
Late to this thread, great work!
I have the exact same problem.
Could you please post flashable zip and/or instructions how to load this into android?
Thank you

I found a binary on website, tested on Nexus 5 (ARMv7L 32bits)
GitHub - FerryAr/e2fsprogs-arm: Static build of e2fsprogs for Android Magisk Module
Static build of e2fsprogs for Android Magisk Module - GitHub - FerryAr/e2fsprogs-arm: Static build of e2fsprogs for Android Magisk Module
github.com

partcyborg said:
e2fstools package, statically built for arm64 devices from Google's googlecode.com Oreo branch
NOTE: These will support ANY version of android's filesystems that use ext2 or ext3 or ext4. I built them from oreo branch as that one was the closest to compiling without any editing of the Makefiles. Don't let the name throw you off
I needed to run a modern fsck on a rooted device I have that I have been doing some hacking on.
The filesystem was in bad shape and the on-device e2fsck absolutely refused to check it while it was even mounted, even with the force option. Out of part desperation part determination I decided I would just build one myself. So I went and dug up the sources from googlecode.com, transfered them to my linux workstation, and after much fighting with gcc for cross compilation, finding a place in the google git repo where they actually build (hence going with orero), and having to tweak the c code even in a few places (mostly fixing includes and whatnot, no actual coding on my part), I succeeded.
As it says in the title, these are all the e2fstools binaries built from Google's googlecode.com source tree in their Oreo release branch. They are also compiled statically (no libraries are needed for them to function) so they should work absolutely fine on any device that has a 64bit arm (aarch64) processor. I have tested a handfull of them and they work perfectly fine on my Samsung Galaxy s8. In fact I used the fsck.ext4 binary to repair my system partition which it did perfectly.
https://www.dropbox.com/s/owb76hohnjzjdwe/e2fstools-oreo-aarch64-static.tar.gz?dl=0
Hope they come in as handy to someone else as they did me.
List of files follows:
Code:
[email protected]:~> tar tzf e2fstools-oreo-aarch64-static.tar.gz
e2fsbin/
e2fsbin/e2undo
e2fsbin/e2image
e2fsbin/badblocks
e2fsbin/mkfs.ext3
e2fsbin/fsck.ext4dev
e2fsbin/e2initrd_helper
e2fsbin/fsck.ext3
e2fsbin/e4crypt
e2fsbin/e4defrag
e2fsbin/mke2fs
e2fsbin/e2fsck
e2fsbin/fsck.ext4
e2fsbin/filefrag
e2fsbin/tune2fs
e2fsbin/e2freefrag
e2fsbin/uuidd
e2fsbin/e2label
e2fsbin/mkfs.ext2
e2fsbin/blkid
e2fsbin/logsave
e2fsbin/lsattr
e2fsbin/uuidgen
e2fsbin/findfs
e2fsbin/mklost+found
e2fsbin/dumpe2fs
e2fsbin/mkfs.ext4
e2fsbin/debugfs
e2fsbin/fsck.ext2
e2fsbin/mkfs.ext4dev
e2fsbin/resize2fs
e2fsbin/chattr
e2fsbin/fsck
PS: Now that I have a working arm64 cross compilation system setup, if anyone else desperately needs a working static binary for anything relatively simple to build (as in not 50 million dependencies for me to track down and install) and can send me or link me the sources for it and its dependencies, I would be happy to oblige.
Click to expand...
Click to collapse
Hi nice compilation job! I know it's not always easy to compile these binaries from source...
Can you please reupload you archive here as attachment? Thanks!

lebigmac said:
Hi nice compilation job! I know it's not always easy to compile these binaries from source...
Can you please reupload you archive here as attachment? Thanks!
Click to expand...
Click to collapse
There's a Magisk module that does cross-compilation specifically, you should get it.

By the way, the link for that drop box is dead.

LG OpenSource

You can use this link to find your model:
http://opensource.lge.com/osSch/list...ME&search=G710 <<< Find your model, you must use Linux to compile this code.
Models:
LMG710N - USA model (Carrier unlocked model)
LMG710PM - Pre-release codename Judy
LMG710PS - ?
LMG710AWM - Likely this was the AT&T model that was changed to the V35 ThinQ
LMG710TM - T-Mobile model
LMG710VM - Verizon model
The files are coded with R, P, & X which I am guessing is Release Candidate, Production, and scrapped version.
The readme files are really helpful in explaining how to compile the software.
Under the bootloader section:
This product includes cryptographic software written by "EDITED for Psuedo Privacy". This product includes software written by "EDITED for Psuedo Privacy".
I figured that we could either create a custom bootloader that's NOT encrypted, but still follows the same boot up process. If bootup requires an encryption, then we could set the the process to accept anything, for example: if encryption = 1 or 0 then proceed to bootup.
I hope this helps development on this phone in creating a kernel, custom roms, etc...

a) tar -xvzf LMG710TMP_Oreo_Android.tar.gz
- And, merge the source into the android source code
- Run following scripts to build android
a) source build/envsetup.sh
b) lunch 1
c) make -j4
When I get to this section of creating the ROM for the LMG710TM phone, and I run the make -j4 command, I get this error:
./frameworks/base/Android.mk:865: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:874: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:879: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:884: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
[720/988] including ./system/sepolicy/Android.mk ...
./system/sepolicy/Android.mk:107: warning: BOARD_SEPOLICY_VERS not specified, assuming current platform version
[978/988] including ./vendor/lge/external/android-clat-lg/Android.mk ...
build/core/base_rules.mk:238: error: vendor/lge/external/android-clat-lg: MODULE.TARGET.EXECUTABLES.clatd already defined by external/android-clat.
13:43:02 ckati failed with: exit status 1
build/core/main.mk:21: recipe for target 'run_soong_ui' failed
make: *** [run_soong_ui] Error 1
#### make failed to build some targets (53 seconds) ####
Also, when I am trying to make the Kernel for the same phone, based off of the open source files, I get this:
make[2]: *** [sub-make] Error 2
I have never built a ROM before. What am I doing wrong?

https://drive.google.com/open?id=1x0Bhn4qRnYOFdbI1BlghbNb6kS9N_Qy3 <<< Here is the READ ME file that comes with the OS for the LMG710TM.

bigjohnman said:
a) tar -xvzf LMG710TMP_Oreo_Android.tar.gz
- And, merge the source into the android source code
- Run following scripts to build android
a) source build/envsetup.sh
b) lunch 1
c) make -j4
When I get to this section of creating the ROM for the LMG710TM phone, and I run the make -j4 command, I get this error:
./frameworks/base/Android.mk:865: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:874: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:879: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:884: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
[720/988] including ./system/sepolicy/Android.mk ...
./system/sepolicy/Android.mk:107: warning: BOARD_SEPOLICY_VERS not specified, assuming current platform version
[978/988] including ./vendor/lge/external/android-clat-lg/Android.mk ...
build/core/base_rules.mk:238: error: vendor/lge/external/android-clat-lg: MODULE.TARGET.EXECUTABLES.clatd already defined by external/android-clat.
13:43:02 ckati failed with: exit status 1
build/core/main.mk:21: recipe for target 'run_soong_ui' failed
make: *** [run_soong_ui] Error 1
#### make failed to build some targets (53 seconds) ####
Also, when I am trying to make the Kernel for the same phone, based off of the open source files, I get this:
make[2]: *** [sub-make] Error 2
I have never built a ROM before. What am I doing wrong?
Click to expand...
Click to collapse
I've seen this error before. To fix it go to vendor/lge/external/android-clat-lg and find MODULE.TARGET.EXECUTABLES.clatd or something like that. Then just outline it but why are you making a rom for this phone? It supports project Treble

Basically it was just something I was trying to do to learn. If using project Treble has the framework that LG has so that I can use Quick Remote, LG Gallery, & LG Video, I may be set...

LameMonster82 said:
I've seen this error before. To fix it go to vendor/lge/external/android-clat-lg and find MODULE.TARGET.EXECUTABLES.clatd or something like that. Then just outline it but why are you making a rom for this phone? It supports project Treble
Click to expand...
Click to collapse
but treble aosp NEVER is as good as a normal rom

Did anybody managed to compile the kernel for G7?
I have managed to compile the kernel but so far was not able to make it work. I have a boot.img compiled and flashed to a/b partitions but phoen get stuck in fastboot mode. Any clue?

sign this petition to LG if you have a LG G7
https://www.change.org/p/lg-electro...share_options_more.control&utm_term=triggered

umminkug said:
https://www.change.org/p/lg-electro...share_options_more.control&utm_term=triggered
Click to expand...
Click to collapse
Done and shared to FB!

@LameMonster82 What did you mean by outline the MODULE.TARGET.EXECUTABLES.clatd ? I'm like @bigjohnman trying to learn, but Im not entirely hip to the what you mean. Any help would be appreciated!! thanks (I also have the T-mobile LG G7)

Dvalin21 said:
@LameMonster82 What did you mean by outline the MODULE.TARGET.EXECUTABLES.clatd ? I'm like @bigjohnman trying to learn, but Im not entirely hip to the what you mean. Any help would be appreciated!! thanks (I also have the T-mobile LG G7)
Click to expand...
Click to collapse
Hate to break it to you but the open source kinda doesn't work. I already tried it long time ago. Also I don't think you can test it at all with a non European model. If you still want to learn how to build a rom you can Google how to make GSI roms. You can start from here https://github.com/phhusson/treble_experimentations/wiki/How-to-build-a-GSI?

AWM is Canadian in case anyone is wondering

Any update on this?

LameMonster82 said:
Hate to break it to you but the open source kinda doesn't work.
Click to expand...
Click to collapse
Someone asked me to make a custom kernel for G7 so I took a look.
From what I can see it must be a snapshot of a very early development stage. It's not based on any CAF tag because it's actually older
than the very first CAF release for sdm845.
I read Pie might be out soon, maybe that source will be ok.

askermk2000 said:
Someone asked me to make a custom kernel for G7 so I took a look.
From what I can see it must be a snapshot of a very early development stage. It's not based on any CAF tag because it's actually older
than the very first CAF release for sdm845.
I read Pie might be out soon, maybe that source will be ok.
Click to expand...
Click to collapse
Do you think it's possible to merge the source with the latest CAF or at least the first official one? In case the pie source packs the same kernel source.

LameMonster82 said:
Do you think it's possible to merge the source with the latest CAF or at least the first official one? In case the pie source packs the same kernel source.
Click to expand...
Click to collapse
That might be possible, yes. Although there's no telling how far off LG's own code is from current and what effect that would have.
If they do the same with Pie then the best thing would be to simply e-mail them asking for current source drop.
I've done it before with the G5, they responded rather quickly as well. After all they are legally bound to.
I think they're just lazy about it in general. Probably don't expect anyone to care.
Edit: Well, not e-mail but send an inquiry. You'll find an icon next to the download links ("http://opensource.lge.com")

askermk2000 said:
That might be possible, yes. Although there's no telling how far off LG's own code is from current and what effect that would have.
If they do the same with Pie then the best thing would be to simply e-mail them asking for current source drop.
I've done it before with the G5, they responded rather quickly as well. After all they are legally bound to.
I think they're just lazy about it in general. Probably don't expect anyone to care.
Edit: Well, not e-mail but send an inquiry. You'll find an icon next to the download links ("http://opensource.lge.com")
Click to expand...
Click to collapse
Hi, unfortunately the pie kernel is also not working. J0sh1x tried it. I already send an email to LG but it takes so long for them to respond I got an automatic email reinsuring me that they will eventually respond.
Do you think that the pie kernel can run on Oreo?

LameMonster82 said:
Hi, unfortunately the pie kernel is also not working. J0sh1x tried it. I already send an email to LG but it takes so long for them to respond I got an automatic email reinsuring me that they will eventually respond.
Do you think that the pie kernel can run on Oreo?
Click to expand...
Click to collapse
What did he try exactly?
I'm building it now, there are many compilation errors and I have a slow pc, but I'm getting there.
I was imagining that after if successfully completes, it should work. This is considering I checked out the source beforehand,
and this time there's no pre-caf weirdness going on at least. It's based on LA.UM.7.3.r1-06100-sdm845.0
But ofc, if there is something else going on, like incomplete LG patchset...
Don't know about Oreo, or I don't know what kind of changes there are in Pie and if they can cause troubles.
Edit: Oh, I assume he tried it on Oreo then... I thought first someone could try it on Pie but only Korean variant has the beta ?
I don't have a G7 so...
The source seems ok. Probably doesn't work on Oreo because it's a Pie kernel, and/or changes done.

askermk2000 said:
What did he try exactly?
I'm building it now, there are many compilation errors and I have a slow pc, but I'm getting there.
I was imagining that after if successfully completes, it should work. This is considering I checked out the source beforehand,
and this time there's no pre-caf weirdness going on at least. It's based on LA.UM.7.3.r1-06100-sdm845.0
But ofc, if there is something else going on, like incomplete LG patchset...
Don't know about Oreo, or I don't know what kind of changes there are in Pie and if they can cause troubles.
Edit: Oh, I assume he tried it on Oreo then... I thought first someone could try it on Pie but only Korean variant has the beta ?
I don't have a G7 so...
The source seems ok. Probably doesn't work on Oreo because it's a Pie kernel, and/or changes done.
Click to expand...
Click to collapse
I also tried compiling it and it went buttery smooth. BTW any ideas of how to test it without opening the phone itself?

LameMonster82 said:
I also tried compiling it and it went buttery smooth.
Click to expand...
Click to collapse
Sure, if you use gcc 4.9... (or perhaps an older version of clang).
EDIT: I've built a test for anyone interested. (Just a stock kernel basically, sans exfat, for now)
I don't know how/what exactly LameMonster82 or J0sh1x did, but perhaps I've done something different...
Anyway, I did not really consider to build this for Oreo. For Pie it probably works, when that get's released.
This thing flashes modules as well (assumed to be /system/lib/modules), so if you test on Oreo you should back up those,
as it'll likely not work and then you'll be without working modules.
Finally; there's a lot of new stuff that's completely new to me now I see. Like vendor partition, dtbo, new ramdisk layout etc...
so maybe I've done something wrong, or did not do something necessary.

General (OPEN DEV) BruteRoot - A collection of Root Tactics (Possibly Force Bootloader unlock on NA Samsung S22?)

Devices & Linux Versions I or other Testers have Successfully Gained Root on:
(Likely All) MTK CPU Based Android devices UP TO 11 (Maybe 12? I haven't tested) (I.e LG, Sony, Select Samsung devices)
Android Devices with LINUX KERNEL VERSIONS - 5.8 - 4.14 - Maybe More? (Needs Testing)
-THIS GUIDE IS NOT BEGINNER FRIENDLY - BASIC UNDERSTANDING OF PYTHON, UNIX/LINUX ETC WILL BE REQUIRED!-​
If you have been holding off updating your device, well here's some good news, your device may still be vulnerable to a method to gain root access (and subsequently, possibly the ability to edit Build.prop and therefore allow the ability for OEM unlocking on USA based devices.) <- correct me if I'm wrong, but this should be possible, and once done, should persist across updates, correct?
As of the time of writing this, there is not currently a simplified APK method, but, still this process is relatively straight forward.
Alot of the methods used HAVE been patched from what I understand, but there have got to be plenty of devices out there still which are not updated. This project aims to compile all current, former and future Root methods into an APK that will do all the leg-work. If its able to find a working method, the GUI will pop a root shell for the end user. This SHOULD work, regardless of the setting of the "OEM UNLOCK" option in the dev options. A bypass, essentially.
Regardless, The project linked below uses a myriad of known exploits & vulnerabilities and looks to find one that will work.
Methods used are:
Nearly all of GTFOBins
Writeable docker.sock
CVE-2022-0847 (Dirty pipe)
CVE-2021-4034 (pwnkit)
CVE-2021-3560
It'll exploit most sudo privileges listed in GTFOBins to pop a root shell, as well as exploiting issues like a writable docker.sock, or the recent dirty pipe (CVE-2022-0847). More methods to root will be added over time too.
There is also an alternative (Dirty Pipe) injection method the uses @topjohnwu 's Magisk , this should be implemented into the apk. See this Github repo, Here.
I would imagine this could be implented in a way to target devices that have stopped being supported for updates, aswell, that do not have TWRP, such as the SM-T307U.
One big note - I am betting there are still ALOT of devices that are in inventory at retailers that remain on the vulnerable OS. So keeping that in mind, I'd say this is worth building.
What needs to be done:
TESTING!
Build APK - HELP NEEDED WITH THIS!
Deploy
Main Goals:
Get bootloader unlock ability for devices normally not unlockable (I.e North American Samsung Galaxy S22, Etc)
Above can be achieved by getting temp root via methods detailed here or otherwise, then editing build.prop, altering the below settings (The settings may be worded differently or simply not present at all, depending on device and Firmware version):
sys.oem_unlocking_allowed to 1
ro.oem_unlock_supported to 1 (most devices are set to 1 by default.)
ro.boot.flash.locked to 0
ro.secure to 0
ro.debuggable to 1
I think there may be one or two more that pretaint to Flash.locked. I.e flash.locked.other--or something very close.
Locally, gain temp root (System preferred, but any root will do.) on as many device types as possible.
Give device control back to end user.
Stay up-to-date on new exploits for root access & update apk accordingly.
STAY ETHICAL!!!! This is, in the end, a research project. Meaning all work preformed in the context of this project could result in a damaged or bricked device. By participating in this project you acknoledge these risks and accept them, and agree to not hold me, XDA, or anyone else responsible if you do some dumb ****. - k0mraid3
Github Project link: HERE for my fork & HERE for the original project.
My fork will incorporate the original project, as well as other found root access methods, such as the magisk injection method mentioned above - my repo is mainly used as a hub for the APK's dev - i don't have enough time to work on it at the moment but all are welcome to help.
July 15th 2022 (UPDATE) (SAMSUNG DEVICES ONLY): A new Escalation method has been found via the Galaxy app store (Versions BEFORE Galaxy Store 4.5.41.8). No details known yet, but it is said to be very easy. See CVE-2022-33708 (July132022). Unknown if downgrading the app to 4.5.0.0 will enable the method again or not.
Cred: liamg
One method to run Traitor on device - Thanks @DevinDking for sharing this.
Steps to get script on phone.
//
#!/bin/sh
set -e
dir=/data/local/tmp
adb=${adb:-"adb"}
$adb push traitor ${dir} //This puts file on phone make sure to run the terminal where its located
$adb shell chmod 755 ${dir}/traitor"
//
Now to run script start a new terminal
//
adb shell
#!/bin/sh
set -e
dir=/data/local/tmp
adb=${adb:-"adb"}
${dir}/traitor //script opens
//
But I assume this wouldn't work right, and isn't right.
Idk trying my best here xD
Click to expand...
Click to collapse
Tools & References:
Linux (and Android, FTMP) Privilege Escalation Techniques
Dirty Pipe - Magisk Injection
Traitor - Main Repo
GTFOBins
CVE Database (Public Database for exploits, vulnerabilities, etc.)
Windows Subsystem For Linux (Great for Dev)
ADB App Control - Cred @Cyber.Cat
Leaked Samsung Source Code ***Mod Edit: Link Removed***
Crontab Root Template script (File Attached - you still must edit crontab with "crontab -e" and point it to this file, see comments for guide, I will add one to post later)
Android Image Kitchen Used to create custom image's etc.
MTK Client
MTK Meta Utility (Source-???)
Will add more as time goes on and more found.
Interesting Attack vectors -
GFX Componets of a system.
Issues with Linux itself (i.e Dirty Pipe)
Privilage escalation via any means (I.e GTFOBins)
unprotected system process - Hijack them if possible (i.e RILService Mode, and a wide range of other OEM apps left on devices after ship)
7/24/22 - Samsung, LG & Other OEM's obfuscating (Intentionally Hiding) Fastboot and ADB Bootloader interfaces on PC
So over the last week or so i dived head first into USB Dev - ill save you the time and sum it up.
Vendors and OEM's are actively obfuscating the USB connection between your smartphone and the PC to keep you from Rooting. As far as im aware, there is no Universal way to fix this as each OEM screws with the USB drivers differently. THIS needs to be a point of focus for the rooting community. However, i have found a few tools for Dev if you wish to screw with this. (I'll upload them tonight)
7/24/22 - MTK (MediaTek) based Exploits
I Will try to compile a few methods for FORCING Bootloader Unlock on MTK based Devices as well as a way for manipulating said devices. I will attach two tools to this thread, these tools are EXTREMELY POWERFUL and can completely **** up your device. When i say REALLY F*CK UP your device, I mean to the point you cant even access recovery, Download OR bootloader mode. I'm Talking a blank DEAD device. So use with caution.
With that said, lets talk about the tools. You will need a basic understanding of Python to make use of MTK Client
First up, we have MTK Meta Utility (Currently Version 44) (Download Below)
Next we have MTK Client (Github Link)
So what can you do? Well, you can crash the Preloader to Brom with MTK Meta Utility while at the same time using MTK Client to send any payload you like to the device via Fastboot.
I know, vague right now, but ill add detail over the coming days.
I will continue to update the below list as new methods are discovered.
If you find Guides, tutorials or new exploits, please link them in the comments so I can include them in future development!
Telegram Channel: Here.
Information on Vulnerabilities, exploits & methods - CVE-2022-0847 (Jfrog) - The Story Of "Dirty Pipe" - XDA - Dirty Pipe - PWNKIT (CVE--2021-4034) - CVE-2021-3560 - Docker Breakout / Privilege Escalation - CVE-2022-33708 (July132022) - CVE-2022-33701 (July122022) - CVE-2022-22268 (Unlock Knox Guard with DEX) (JAN2022) - MTK Client -
Dev Team & credit to -
@topjohnwu - LiamG - @wr3cckl3ss1 - bkerler -
UPDATED - 7/29/22

There is also a new vulnerability exploit by Zhenpeng Lin that allows for privilege escalation on Pixel 6 and and Galaxy S22 devices running 5.10 kernel.

Don't update... destroyer of worlds

I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?

olivehue512 said:
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
Click to expand...
Click to collapse
Lol, everybody already updated the patch

blackhawk said:
Lol, everybody already updated the patch
Click to expand...
Click to collapse
This is just sad panda. I'm gonna skip next update anyways unless it comes with an actual other phone that is BL unlocked. I feel like everyone wants this so bad it can't be that far out before it happens.
Does the Magisk injection method work after July patch? I was reading through the work they did to get it done. Props to those guys.

sierratango88 said:
There is also a new vulnerability exploit by Zhenpeng Lin that allows for privilege escalation on Pixel 6 and and Galaxy S22 devices running 5.10 kernel.
Click to expand...
Click to collapse
Has it got a fancy number yet?! Eager to try this!!!! Maybe it can be put in with the others.

olivehue512 said:
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
Click to expand...
Click to collapse
Well, because they are known and accepted vulnerabilities and exploits. A very few have even been marked as "WONTFIX" such as the TTY method.

olivehue512 said:
This is just sad panda. I'm gonna skip next update anyways unless it comes with an actual other phone that is BL unlocked. I feel like everyone wants this so bad it can't be that far out before it happens.
Does the Magisk injection method work after July patch? I was reading through the work they did to get it done. Props to those guys.
Click to expand...
Click to collapse
Honestly, it's worth a shot but I doubt it.
One of the goals behind building the APK compilation of all these different tactics is to enable the end user to "give it a shot" easily on different devices, without having to know how to run all of this manually. Basically imagine an apk that just tries all the above methods and if ones successful the gui will pop a root shell open. From there, the possibilities are endless. Edit Build.prop, SELinux, Verity, Etc.

FYI even you applied the July update, seems like the Kernel version is still from June 21st, is still 5.10xxxx so we could still benefit from this exploit. Very interested in how we can get root here in the US.

K0mraid3 said:
Has it got a fancy number yet?! Eager to try this!!!! Maybe it can be put in with the others.
Click to expand...
Click to collapse
There hasn't been a CVE assigned to it yet that I am aware of.

xgerryx said:
FYI even you applied the July update, seems like the Kernel version is still from June 21st, is still 5.10xxxx so we could still benefit from this exploit. Very interested in how we can get root here in the US.
Click to expand...
Click to collapse
Go to the Github linked and try the different methods, see if you can pop a root and nano build.prop to allow OEM unlocking?

sierratango88 said:
There hasn't been a CVE assigned to it yet that I am aware of.
Click to expand...
Click to collapse
GREAT news for us! LEts get this temp root! lol

Looks like another new one! CVE-2022-33708

Another Samsung Exclusive - CVE-2022-33701

So, ive just spent my entire friday and friday night MANUALLY testing all the GTFOBins & reproducing some of the newer CVE's on Samsung Galaxy S7 Edge (Android 9) -Galaxy tab A 8.4, (Android 11), Galaxy S21 & S22 (Android 12) --- A little bit of progress made. Again, ill need someone with better working knowledge on APKs & Java to really move forward. All i can say so far, is this all must be awk for sammie, because cronie is looking promising
"crontab -e"

interesting find. not "New" but still new-ish enough some may be able to use. CVE-2022-22268 (Unlock Knox Guard with DEX)

New to this all but not rooting. Anyone recommend a way tutorial on how to try these methods on Win 11?

I don't have a deep understanding of Linux, I have tried, debian and unbuntu. I get traitor to run but it's detecting the Linux kernel and not my phones. How can I get the program to search for vulnerability on my phone not my Linux. I would love a more in depth guide and I'd love to give feedback on methods.

DevinDking said:
I don't have a deep understanding of Linux, I have tried, debian and unbuntu. I get traitor to run but it's detecting the Linux kernel and not my phones. How can I get the program to search for vulnerability on my phone not my Linux. I would love a more in depth guide and I'd love to give feedback on methods.
Click to expand...
Click to collapse
i had the same issue but cant remember how i worked that out. let me see if i can find out what i did on win11