yashsingh1/xdaforums huggingface dataset:
[SuperSU] The-Kevster:
Mine won't let me oem unlock using the latest tools.

C:\Users\Kevin\Downloads\Nexus 5x>fastboot oem unlock
...
FAILED (remote: oem unlock is not allowed)
finished. total time: 0.017s

C:\Users\Kevin\Downloads\Nexus 5x>fastboot flashing unlock
...
FAILED (remote: oem unlock is not allowed)
finished. total time: 0.014s

C:\Users\Kevin\Downloads\Nexus 5x>fastboot flashing unlock_critical
...
FAILED (remote: oem unlock is not allowed)
finished. total time: 0.011s

C:\Users\Kevin\Downloads\Nexus 5x>fastboot flashing get_unlock_ability
...
(bootloader) get_unlock_ability: 0
OKAY [ 0.020s]
finished. total time: 0.022s
[SuperSU] Pecata:
Did you have the OEM Unlock option enabled in settings?
[SuperSU] ikelos:
Ah, so I guess that's something I spotted on my own, but didn't know what effect it would have. You need to enter developer mode (7+ taps on the build number under Settings > About), then enter Developer Options and there's a switch you can flick called OEM unlocking. If you allow OEM unlocking, then you should be able to do the normal fastboot oem unlock.

Also, watch out when you apply the mdb08i update, I tried flashing it (and then all the earlier images to try and recover) and they all failed with a Java warning saying it ran out of space with the zip file, which leaves a corrupted system.img and no vendor.img (and then may reformat your user partition from 27Gb down to about 12Gb). If you boot like that, it might unlock your disk but then say it's corrupted and will offer to factory reset for you. The broken install will just play the boot animation seemingly infinitely (at least 15+ minutes) without starting adb, so no way of knowing what's going on behind the scenes.

The phone's recoverable at least (luckily), just run flash-base.sh and manually unzip the image file and flash each of the partitions as necessary. If you userdata partition was shrunk, it needs reformatting and fastboot should figure out how big it is, so just run fastboot format userdata before flashing the userdata.img to it. Hope that helps!
[SuperSU] The-Kevster:
Wow unlocking the OEM unlock. That's new to me but very secure. Thanks for the tip!
[SuperSU] garyd9:
So, I decided against putting the full script back up. Not only for the reasons that you stated, [MENTION=631273]Chainfire[/MENTION], but for an additional reason: I'm a horrible teacher, but I still remember the "old days" of XDA when people posted information of HOW instead of (or in addition to) posting finished products. I really appreciated that information back then, and it's my (probably futile) hope that others also would rather learn than just get canned stuff.

So, rather than posting a script, I've edited that post to detail the changes needed for the samsung n920 (note 5) images in order to fix the stock boot image to make a rootable SEAndroid enforcing kernel image. Each step encourages the user to search for more information and learn if they don't already know how to do something.

Oh, and there's also now a big red warning. :D
[SuperSU] egingell:
OT: I hate video how-tos. I need a bulleted list with screenshots. I can't watch a 20 minute video on how to do something that should take two minutes.

Sent from: SGS2 - JB 4.1.2 GB27 / SGS4 - JB 4.2.2 MF9
[SuperSU] Manh_IT:
You can see what I do, please help me check !

https://github.com/ManhIT-CMB/SpaceX-Pure/commits/master

Thank
[SuperSU] DjDiabolik:
Some member has a OnePlus One whit latest COS12.1 ?? Can suggest to me if this .zip can be flashable normally from stock CM recovery or not ??

If yes i can obtain the root access and only after if i want i want back to use flashify for flash the TWRP img (i need to remove twrp for installing the last recent ota)..
[SuperSU] andip71:
No, you need a custom recovery for it.

Andi
[SuperSU] ikelos:
TWRP for bullhead appears to be available but doesn't mount /data, so the update-binary seems to fail (even though that's only necessary to clear off old user-land installs). A little jiggering via adb to remove references to /data seems to have gotten it working and rooted. No significant problems found yet, but I'll shout here if I find any.
[SuperSU] Rektifying:
I just wanted to drop by and say thank you! I have successfully rooted my Nexus 6 and Nexus Player thanks to your custom boot.img's and SuperSU v2.52. All is well and I am currently having no issues / noticed any issues as of yet.

This right here is one of the main reasons I made the move from Apple / IOS / iPhone / Apple TV! (The Nexus 6 and Nexus Player are my first Android devices) I have learned so much so far through tons of reading / research. So far I had only manually flashed 6.0 stock images to my N6 / NP. Now I can add flashing custom boot images and recoveries to the list. I am loving the Android world and I will not be returning to IOS! Although I can never see myself buying a non-Nexus device either!
[SuperSU] ig88b:
I was able to get my Nexus 5x rooted using the following procedure:

1) Unlock bootloader (don't forget to enable unlocking first via developer options from the booted device)

2) Flash modified boot image

3) Install TWRP

4) Format data in TWRP (Wipe -> Format Data)

5) Flash supersu
[SuperSU] Rektifying:
How necessary was step 4? I did what you did, in the same order without step 4 and I successfully rooted my Nexus 6 and Nexus Player. I am an Android / Unlocking / Flashing / Rooting Noob so I am just wondering. Thanks
[SuperSU] ig88b:
Are those devices encrypted? My understanding is step 4 is needed because of the encrypted data partition. It may work without doing that, but I wanted to run unencrypted anyway for the (possible) performance increase.
[SuperSU] ikelos:
Ah, yep, forgot to mention EITHER step 4, OR modifying the update-binary script such that it doesn't touch /data is necessary if you have an encrypted data partition. It is however possible to root without losing encryption, it just requires manual intervention.
[SuperSU] Hayth:
After flashing the boot.img I was unable to wipe data in TWRP as it wasn't able to mount the partition properly. Did you encounter any such problems?

EDIT: I think it might've been due to the fact there's 3 different builds - I'm on MDA89E so I'll wait for a modified boot.img for that before trying again.
[SuperSU] ig88b:
You have to format data, not wipe it. I made that mistake initially too.
[SuperSU] Hayth:
Ah ok thanks, what build are you on? I'm afraid to try again, already had to restore my phone 4 times since last night [emoji14]
[SuperSU] ig88b:
I'm on MDB08I
[SuperSU] Hayth:
Thanks :)

Right, I took the plunge and tried again. This time formatting data (rather than trying to wipe) through TWRP. I managed to root successfully but I still get the issue where Security under Settings force closes and therefore am unable to set up any Pattern/Use Fingerprint scanner and allow apps to be installed from Unknown Sources.

I'm assuming this is due to differences in the boot images between builds so I'll wait for the modified image for my build.
[SuperSU] Criton30:
Iam now on 2.49 how can I update ? Just flash in the recovery? Should I Clear something? Cache etc..? Thanks in advance!
[SuperSU] Megaflop666:
Just download the latest, drop to recovery and flash it. All done. No wipes necessary.
[SuperSU] Criton30:
If I want to flash in the twrp recovery, then the recovery reboots every time

Solved, download was corrupt
[SuperSU] mtw4991:
I'm currently rooted on 6.0 with CFs' modified boot.img and SuperSU 2.52 installed, then FranciscoFrancos' kernel r32 installed. As I understand it, selinux policy is set to enforcing on both CF modified img and Francos' kernel. Can I just reflashed the mod boot.img, then flash a permissive kernel, like DespairFactors or will it bootloop, etc?
[SuperSU] DA6030:
To clarify, this is only due to the (hopefully temporary) constraint that TWRP 2.8.70 for bullhead cannot mount encrypted data partitions. Once an update to TWRP is released, this modification should no longer be necessary, and all other devices can safely ignore this warning. Correct?
[SuperSU] ikelos:
Yes, that would be my guess. Team Win left the following note on the device page for the Nexus 5x:

NOTE: Decrypting data is not currently supported on the Nexus 5X. We do not have the money to buy one at the moment. Feel free to donate some money to help buy one if decrypting data is something you would like to see. Otherwise, you can format data and find and install a boot image with forceencrypt disabled and use TWRP as normal.

So my guess is they're willing to, but they need a device for testing, and they're hoping for a donation.
[SuperSU] garyd9:
[MENTION=631273]Chainfire[/MENTION] (or anyone else) - this is a bit off topic, but you seem to be one of the few people on XDA familiar with SEAndroid... (and if you don't give me an a Brand New Infraction for the effort, at least I'm fairly certain to get your eyeballs on the question.)

I'm working on getting a custom compiled kernel that currently requires SEAndroid in permissive to work as SEAndroid enforcing. (On a samsung device.) Can you suggest a resource that would help me identify where the "permissive" violations in the policy are occurring, and then how to deal with them? (I have no idea where to even begin on writing policies and such - however I'm starting with a purely "stock" samsung firmware, so I'm fairly certain that any place I find a violation, it should have a policy added to permit that action/access.)

My efforts with google so far have resulted in mostly people complaining about SEAndroid or writing entire platforms from the bottom up (as opposed to a custom boot/kernel for an existing /system.)

Thanks

Gary
[SuperSU] tetakpatak:
Flashing SuperSU 2.52 caused me bootloop with Nexus 7 flo / freshly updated to factory image 6.0 via fastboot.

Actually I first tried with SuperSU 2.46 with TWRP 2.8.7.0 and bootloop has occured right after that. Then I've flashed SuperSU 2.52 but the bootloop was still there. I did no other modifications.

My logcat during bootloop shows up some problems with the camera. Well, now I remember the problem of Lollipop: possibly the stock kernel cannot "digest" the SuperSU?

Don't worry about my bootloop, I only have posted the logcat for the case that it has any use for the development.
[SuperSU] Ja_som:
[MENTION=5051515]tetakpatak[/MENTION]

Do you flashed boot.img from Chainfire before you flashed SuperSU?
[SuperSU] tetakpatak:
Thank you, mate. No, I didn't as I haven't taken notice of that.

But there is no more problem, I have meanwhile flashed ElementalX kernel and SuperSU 2.46 and the tab has booted perfectly fine.
[SuperSU] paulr24:
I tried installing BusyBox using this method, but I get the following errors:

"We could not verify the integrity of the binary selected..." flashes for a moment, then:

"BusyBox installer was not allowed root access. This may be an issue with Superuser, open Superuser and make sure that you are allowing root access. This application will not work without root access."

I've made sure that it's allowed root access, and have also tried deleting it from SuperSu so it would prompt me and I could grant it access again, but still the same issue. Any ideas?
[SuperSU] bigknowz:
BusyBox

That method was for someone with issues gaining root. If root is working correctly, uninstall BusyBox and then reinstall. Good luck and keep me posted.
[SuperSU] paulr24:
Thanks for the quick response! I just tried uninstalling and reinstalling BusyBox, but I'm experiencing the same issue. The BusyBox version I installed is the one in the Play Store by Stephen (Stericson).

It's kind of weird, I appear to have root since I am able to use TiBu, but something seems funky. For example usually when I open FKUpdater it says "FKUpdate has been granted super user access..." and then "Unable to acquire ROOT access." Other times it only says "Unable to acquire ROOT access." I haven't tried flashing a kernel with it because I don't want to at the moment while I figure this other issue out, so I'm not sure if it's falsely reporting the root error.
[SuperSU] elotan:
Hi all

a newbie question, since it is difficult to search in more than 230 pages of the thread:

Does "modified boot image" mean "modified kernel"?

Or did chainfire change other things in his boot image other than the kernel?
[SuperSU] ashyx:
No, just the Ramdisk.

By the way you can always search any forum thread using the search function.
[SuperSU] Chainfire:
You were infracted for asking questions before? I may be a bit short tempered of recent but I don't infract...

You wouldn't develop the policy from source if you're basing on a non-source firmware. You'd take the existing sepolicy file from the ramdisk, and use the supolicy tool, exactly as described in the WIP thread for 6.0. The supolicy tool makes all the modifications necessary for su to work, and you can also add your own (supolicy --file infile outfile "policy rule" "policy rule" ...). The exact list of changed rules is not documented (it's a moving target), though instead of whining about that like somebody felt necessary to do last week, you can use supolicy's --dumpav option to dump the rulesets and diff between them.

In permissive mode, most violations are logged. Logging occurs to logcat, dmesg, or a custom log file (/data/misc/audit/audit.log), depending on the kernel's setting when compiled. On some kernels it is hard to find the violations, sometimes the logging is disabled completely. Also note the sepolicy can include rules to specifically skip logging certain violations.

See How-To SU ( http://su.chainfire.eu/ )'s SELinux section to figure out how to interpret the logged violation and how to write a policy rule to allow. Instead of the --live option, you can use the "--file infile outfile" option of the sepolicy tool.

Figuring out which violations you should and shouldn't "allow" is the tricky part. Any rule that allows something with "*_app" for example is generally not something you should do.
[SuperSU] ashyx:
[MENTION=631273]Chainfire[/MENTION] any chance I could dare to ask you a question regarding sepolicy not related to supersu?

Basically I can successfully compile a kernel from samsung source code for the Galaxy Tab A. However it seems it hangs on the boot logo and doesnt boot, but investigating with adb it seems the kernel boots in the background.

I have tried building the kernel both permissive and enforcing.

Now heres the strange thing if I swap the SEpolicy from the stock ramdisk with one from a twrp recovery ramdisk or even a from a cyanogenmod kernel ramdisk the kernel boots just fine, however there is no baseband and no wifi. Obviously this is due to the SEpolicy.

Can you shed any of your knowledge on how to overcome this, modifying the SEpolicy maybe?

Is this due to Qualcomm secure boot and if it is why does swapping SEpolicy allow the Kernel to boot?

I know its a bit off topic, but this has been driving me nuts for weeks with no answer. My apologies and any input is appreciated . :confused:
[SuperSU] garyd9:
Oh, no. My statement was meant to suggest that I was willing to risk any possible infraction for straying too far off topic just to get your eyes on the question. (I've found it extremely difficult to get an infraction here on XDA...)

That might be what I need. Can --dumpav be used in combination with --file to dump the policies of the specified sepolicy file? (of course, as I typed that, I realize that it'd be significantly faster for me to try it and see...) If not, can this be added?

(Edit: it appears that it's NOT supported. It appears that "--file" is only usable for patching.)

Perhaps I should explain what, exactly, I'm trying to get working.. The context might help...

I have a "i" variant Note5. I've successfully modified that firmware stock kernel ramdisk to boot enforcing and allow rooting when using the 'i' variant /system partition (samsung's android 5.1.1.) I've also done the same thing for the 't' variant note 5.

What I'm trying to do now is to get the 't' variant /system to work with an 'i' variant kernel image. If I try this with the kernel forcing seandroid permissive, it works fine. However, when I try it with the kernel forcing seandroid enforcing, zygote dies 3 times in a row forcing init to reboot the device within 30 seconds of the kernel startup (as shown from a last_kmsg.) There's nothing in the kmsg showing WHY zygote is dying.

Being that it works fine with permissive, I'm convinced that the problem must be some difference in the sepolicy (but using the 't' image sepolicy on the 'i' image doesn't solve the problem.) Oh, and I don't have access to an actual 't' variant device.

So, if supolicy can dump the vectors from a FILE (instead of the active policy), I could hopefully find the differences between the 'i' sepolicy and the 't' sepolicy... and use that information to add any missing allowances to the 'i' policy.

Yes, there are a LOT of "ifs" and "I hopes" in this. That's one of the (sadistic) things I enjoy about trying to work with samsung firmware/kernels. That sadistic streak in me is also why I really want to get this working with a samsung compiled kernel. It's kind of my way to spit in their eye. :)

(Oh, and in case anyone is curious... The reason I'm trying so hard to get the 't' variant (tmobile) firmware working is that the 'i' variant (open Australia/Singapore/NZ) seems to have problems with reading SMS messages via android auto.)
[SuperSU] dankoman:
Even after all that delicious BBQ? ;)
[SuperSU] paulr24:
So I've looked into things further and it seems like I may have some sort of permissions issue. I tried using JRummy's BusyBox installer, but that fails also and just tells me to try installing a different version of BusyBox. It also includes a script for fixing permissions, and when I run it I get "error: only position independent executables (PIE) are supported" and "/data/user/0/com.crummy.busybox.installer/files/temp.sh[118]: sync: can't be executed: permission denied."

Permissions for /data/user/0/com.crummy.busybox.installer are set to drwxr-x--x, as is /system. Also /system is only showing 58 MB free but I don't think that's a problem...
[SuperSU] Chainfire:
Try "supolicy --dumpav filename"

The violations should still be logged in permissive mode, zygote just won't die because of it.
[SuperSU] garyd9:
Ah! this works. The 't' variant does have 14 more lines in the resulting file. Now I just need to figure out how to understand what I'm seeing. Time to start reading up on seandroid (again)!

I'm starting to suspect that I might have taken on a big can of worms. Some of these lines don't correspond to things I'm seeing in the supported supolicy policy statements. For example, here's a couple of the additional lines:

[TYPE] 473: imsd_socket (ENFORCING) [file_type imsd_socket newAttr58 newAttr59 newAttr53 newAttr54 newAttr55 newAttr56 newAttr57 newAttr60 newAttr61 newAttr62 newAttr63 newAttr64 newAttr67 newAttr18 newAttr19 newAttr16 newAttr17 socket_file_type]
[AV] 3074: ALLOW system_app-->imsd_socket (sock_file) [append write ioctl getattr read lock open]
[AV] 8461: ALLOW imsd-->imsd_socket (sock_file) [append create write link unlink ioctl getattr setattr read rename lock open]

Of course, I'm referencing this stuff without having a clue what I'm looking at. So, if I'm coming across as a Clueless Newbie, there's a good reason.

My first guess is that the first statement is defining something that the next two statements are being "allowed" access to. (A "target"?) I don't see a way with supolicy to create new targets... If I can't use supolicy to create that new type (imsd_socket), can I at least use supolicy to set "system_app" and "imsd" to run permissive?

Perhaps. ...and that might be much easier to deal with. I think I might have to compile a new kernel to do that, however, as I can't find any violations being logged in the last_kmsg OR /data/misc/audit after the reboots. Anyway, the 17k lines in the dumpav are something New and Interesting to me, so I might very well spend the next couple of days (weeks?) absorbed in trying to understand that stuff.

Sure, its frustrating and annoying.. but it's also fun.

I imagine you had to not only understand seandroid/selinux, but also reverse engineer quite a bit of this on devices in order to get supersu working (without cheating and making everything permissive.) For that, you have my most sincere respect.
[SuperSU] HipKat:
I don't know how you've managed that because I have a long list of them lol
[SuperSU] deusfaux:
" Please note that the current method will not be officially supported. Future roots may require a clean system: we are at a very early stage of root for 6.0, methods used are subject to change."

(N5 user) What is the suggestion here when [MENTION=631273]Chainfire[/MENTION] says "clean system"? I really wouldn't mind any flashing at all, apart from wiping the user data partition. I feel I can no longer wait for a different root method to be revealed, so I'm looking at jumping in with the modified boot.img method we have available.

However if someone could identify there's a strong likelihood that'll set me on a path that will someday result in wiping my user data, I suppose I can justify holding off for longer.
[SuperSU] Raj d:
What's the Changelogs for Su v2.52beta than stable?

Thanks.
[SuperSU] Ch3vr0n:
Read the first post and find out.

Verstuurd vanaf mijn Nexus 7 met Tapatalk
[SuperSU] ashyx:
[MENTION=631273]Chainfire[/MENTION]

Anything for little old me? :(
[SuperSU] Chainfire:
You can't use supolicy to create a new type at this time. Which might limit what you can do. You can switch an existing type to permissive though (supolicy --file infile outfile "permissive system_app") will make system_app permissive (generally a bad idea).

I'm not that into kernel devving myself so I'm not sure how you'd fix this, to be honest. The SELinux in the kernel needs to sync up very well with the current setup in /system for everything to work. This makes matching kernels and system partitions much more of a hassle than it used to be before SELinux, I think.
[SuperSU] Chainfire:
Please see my response to the other posts regarding how supolicy can be used to manipulate the sepolicy file and figure out what policies are breaking and how to fix it.

I've seen nothing in your posts that suggests baseband/wifi not working is obviously due to sepolicy. Samsung is quite bad with keeping their kernel sources up to date, and the slightest mismatch between the baseband/wifi drivers inside the kernel and the binary blobs on /system will result in nothing working.

There isn't really much more I can say or do to help you, I am not a kernel dev, and this process usually takes quite some trial and error to get working.

Seriously?
[SuperSU] ashyx:
No worries, I appreciate the effort and your input.
[SuperSU] Elancastro:
What should I do?

:llorando:

What is going on here it has root authorization and still doesn't work, stock 6.0, rooted, supro root
[SuperSU] MrKaon:
Clear data of the app and try again.
[SuperSU] ashyx:
Does anyone else have issues with getting a root shell in adb or terminal with v2.52?

When I do the su command it just hangs for ever as if it's waiting for an input.

It seems the pop up box doesn't appear to grant permission but if I change the setting to always grant su works just fine. No issues with v2.49
[SuperSU] Pandages:
[MENTION=631273]Chainfire[/MENTION] thanks so much for your continued work on this front. I understand it's stressful.

Is there anything we, the community, can do to assist your current efforts on the Marshmallow front? How are things progressing? I've been following the changelogs.

Do you keep a personal blog about SuperSU development?
[SuperSU] Daniella3:
nvm
[SuperSU] trawel:
I have a question/problem. Not sure what might cause that. From time to time I have a problem with root - after some time of not rebooting my phone (like few days, but I guess it happens rather randomly), superSU app stops responding - when I try to open it, it just hangs also apps that require root stop working and I have to reboot my phone. Maybe someone knows a reason for that.

I'm on Android Marshmallow (Ubermallow) + SuperSU 2.52 + blu_spark r30 (I flashed supersu as in instructions).