yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] AnonVendetta:
Pretty soon SN won't matter, google is deprecating it in favor of the Play Integrity API. Which can be spoofed to a degree. That is, until they start requiring hardware backed attestation on all devices, then it's game over.

I don't root just to root, it's not about that. It's about the perceived level of power/control it gives me. Want to delete a file in a protected partition?...root needed. Want to tweak kernel parameters?...sorry, root required. There's still just a lot of things you can't do without it.

And why should root be considered a security risk? Linux distros come with it enabled by default. Good luck doing any admin stuff on Linux without it. Android uses a Linux kernel, Linux filesystems, alot of other concepts from the open source community which have been around since Unix/Linux.

And yet, somehow, having root access on Linux is deemed ok, but on Android it's a no no. That's retarded, backward thinking.

I'll tell you what it's really all about, it's about money and power. They want to control both the hardware and the software, so they put a taboo on anything the user can do to exercise more control. When you buy the device, their mindset is that it's still theirs regardless.

And don't even get me started on the locked/unlocked bootloader thing. Look at PCs, the concept is practically unheard of. If I want to install Linux alongside Windows, or replace it, I can. No bootloader unlocking BS. But if I want a custom ROM on an Android-powered device, unlocking is required. That's BS.
[Android Software/Hacking General [Developers Only]] pndwal:
Actually, without root hiding this does occur, and apparently it's nothing new...

The DroidGuard VM attestation engine that provides device integrity measurements to gsm does various checks (security checkscan detect Magisk, emulators, rooted devices, and even Pegasus) and "busybox" is among keywords searched for to enhance it's predefined su path checks when DroidGuard iterates over the content of certain directories...

These particular detections are simply sent from DroidGuard via gsm (Play Services) to Google's servers, but were used originally by the S/N API backend to generate a basicIntegrity attestation and, unlike hardware key backed measurements (for ctsProfileMatch), were easy to bypass. Now such measurements are used by the new PI API backend to generate a similar basicIntegrity attestation...

MagiskHide was enough to hide all these signs of root originally, but since 24.0 and Zygisk, zy-USNF integrates its own root hiding (used exclusively for hiding these detections from gsm) which is also equal to the task...

The reason we are aware of what checks* the DroidGuard engine (proprietary code) performs is because skilled reversers have published details that give valuable insight.

*Categories include Magisk and root, hooking frameworks (dynamic instrumentation), emulators, bootloader status, conditional checks (on files matching specific keywords).

For example, here's an excerpt from Romain Thomas's whitepaper on reversed DroidGuard VM of a year ago (just prior to Play Integrity API rollout) relating to the above:

https://www.romainthomas.fr/publication/22-sstic-blackhat-droidguard-safetynet/

If we examine Romain's appended list in Annex 8.5 we find busybox among some 30 keywords DroidGuard checked for in May 2022... The list has likely grown since then.

👀 PW
[Android Software/Hacking General [Developers Only]] pndwal:
FWIW, List per post above (as of May 2022):

... The whitepaper is comprehensible even to a lay person like me... I think you'd benefit from and even enjoy reading it. 🤠 PW
[Android Software/Hacking General [Developers Only]] ale5000:
SafetyNet doesn't detect BusyBox but apps using the RootBeer library to detect root will trip on BusyBox.
[Android Software/Hacking General [Developers Only]] pndwal:
True...

But nothing has really changed with PI re. device integrity...

Whereas SafetyNet was simply a device integrity API, Play Integrity API adds Application integrity and Account details attestations to a revamped Device integrity attestation engine.

A strong device integrity verdict was available since evaluationType was added to the labels available from S/N... Banks now had the capacity to demand passing ctsProfileMatch in combination with evaluationType=HARDWARE_BACKED, BASIC, essentially the same as PI strongIntegrity pass...

None did that with S/N and nothing has since changed...

Because it is!... As Shawn Willden said, 'it weakens Google's security model'...

Yup... But Android is Linux adapted as a mobile OS!... It has to complete again IOS in the secure mobile OS space, and it's already losing... Google are really being as good to us modders as they can afford to be while they play 'catch up'...

No, Google support root... They never said it's 'not ok'!

Really they've given you that cake (IOS never will) but have said their banking partners can decide if you can have the cherry they provide on top...

This is only right if you believe like Google that they have the right to determine that their code runs only in an unmodified trusted environment that's CTS/VTS compliant per the rules even OEMs must play by... Both unlocking and root break CTS/VTS compliance and we are already resorting to subterfuge (spoofing expected signals) to enjoy our cherries...

Keeping our moddable OS both competitive and viable in the eyes of app (including security centric ones) makers really is good for this community long term... Samsung's Knox based 'enterprise' security enhancements are an example of an OEM trying to claw back market share already lost due to the perception of IOS as the only properly secured mobile OS...

Only if Google's chosen mobile OS can remain relevant in this arena will we continue to be able to have our cake and eat it to... Cherry or no cherry.

Of course it is! Google is like any other big corporate player... It must make sink-or-swim decisions...

Nah... They've made Android unlockable and rootable by design!... No need for a 'Jail Break' even... except where some OEMs excercise their own right to block OEM unlocking...

Sorry, thought we were discussing Android... Who's mindset; Google's? The OEM's?...

In most instances both entities allow (and don't block) unlocking and rooting...

Nah... The concepts here are merging even if PC's are behind mobile OS's.

To install late windows you need to circumvent hardware TPM 2 requirements... And already you must disable Secure Boot in order to run Linux or even non compliant hardware!... And thankfully, as with Android/Google allowing running without AVB (Green state), Windows/Microsoft allow running without Secure Boot! 👀 PW
[Android Software/Hacking General [Developers Only]] pndwal:
Please see the whitepaper cited and the post above yours:

https://xdaforums.com/t/tools-zips-...tiple-devices-platforms.2239421/post-88606079

As revealed by reversing, droidguard and S/N do indeed check for some 30 keywords incl. busybox although MagiskHide and later root hiding modules bypass these basic checks successfully... PW
[Android Software/Hacking General [Developers Only]] ale5000:
Well, I remember SafetyNet was working with BusyBox on a phone without Magisk but I haven't checked recently.
[Android Software/Hacking General [Developers Only]] ale5000:
Could you please link the source?
[Android Software/Hacking General [Developers Only]] pndwal:
.pdf from site/page linked at end of post above, ie:

https://xdaforums.com/t/tools-zips-...tiple-devices-platforms.2239421/post-88605981 🙂 PW
[Android Software/Hacking General [Developers Only]] HippoMan:
They're only playing "catch up" with regard to people's fantasies about mobile device security and how that might affect purchase preferences between Android and iOS.

Much more fraud (both in terms of the number of incidents and in terms of the amount of money involved) is committed by phishing/hacking/keystroke-capturing attacks on desktop computers than by attacks on mobile devices. And the percentage of mobile phones which happen to be rooted Android devices is tiny.

... and yet, all Windows machines remain rooted. Microsoft isn't trying to "protect" Windows users from root.

And all Linux distros are similarly rooted. The same goes for MacOS.

And yes, it's app developers, not Google itself, who will eventually render rooted Android devices inoperable.

No developers are crippling the use of Windows-based, Linux-based, or MacOS-based desktop machines simply because the OS's on those machines are rooted.
[Android Software/Hacking General [Developers Only]] AnonVendetta:
It's technically true that root is a security risk. Even on Linux, you should avoid invoking root powers if it's not needed for a given task. Security practice these days is to run things with as least privilege as possible, only calling root if it's needed. But it's a double edged sword, like I said, good luck doing admin stuff without it.

I really don't think of mobile Android devices as being any different from PCs. They are just downscaled computers that fit in our hands. Like PCs, the software (OS, kernel, etc) and hardware are interdependent, neither can work without the other. I also consider Apple's devices to be in the same computer category, despite it being locked down by design. I just believe in freedom of software, the ability of the user to do with it as they wish. I bought the hardware, it's my legal property. So to me, this gives me an ABSOLUTE right to tinker with the software in any way I see fit. The software running on the device may be copyrighted, trademarked, etc, but as long as I own the device it runs on...

I partly agree on the security aspect, there is a need for Google to compete with major platforms like Apple. Banks, etc won't trust Google if they perceive Android as being insecure. But there must be a middle ground in which techies like ourselves can be happy, while still maintaining a modicum of security.

It's true that Android is Google's legal code, they own it. But it's also open source. And because of that, we can mod it. Perhaps not legally, but spiritually, it makes it as much ours as it is theirs. And I mean spiritually as in "in the spirit of", not religious.

Which brings me to the point of, they partly seek to keep it secure due to needing to be trusted...but also needing to maintain the power/money aspect. They stand to financially gain, they have to maintain market share against iOS. With Linux, it is open source, but there is no power/money motive, which is why they aren't so keen on being unrooted, requiring an unlocked bootloader to run custom software, etc.

I was referring to both Google and the OEMs, and their desire to control both the hardware and software that runs on it. You may buy the device, but their mindset is, it's still theirs.

I have never needed to bypass TPM to install Windows, or any Linux distros. And the "you must disable secure boot to run Linux", that's flat out incorrect. Most recent distros support SB just fine, and can run with it enabled. Clearly, you haven't tried, educate yourself. Attempt a Linux install with it enabled. It will work, as long as you whitelist the bootloader files in the BIOS. Or you can just use a signed bootloader shim that is SB compatible, no need to manually add anything. The shim itself will need to be added in the BIOS, but it will work regardless.
[Android Software/Hacking General [Developers Only]] HippoMan:
And yet, banks trust millions upon millions of their customers to do their banking via rooted desktop devices. No banks are trying to get us to cripple our rooted Windows, rooted Linux, or rooted MacOS machines before allowing us to connect to their banking software.

Those banks don't even try to force us to utilize anti-virus software nor any other security measures on our rooted desktop machines.

And these same banks gladly issue us customers completely unprotected devices which allow us to access our funds within these banks.

These devices are called "debit cards".

It's just as easy for someone to steal my wallet that contains my totally unprotected debit cards as it is for someone to steal my mobile device which could be running Google Pay and other "banking apps".

I believe that most of the people in banks who make the decisions about "protecting" themselves from rooted Andoid devices (while continuing to gladly allow us to have debit cards and to access their banks via our rooted desktop machines) have made those decisions because of confusion and ignorance.

And I would guess that the small percentage of those decision-makers who actually do understand this just continue to focus on rooted Android devices because these devices are low-hanging fruit, and they can tell their ignorant shareholders, "See! We're serious about security because we have anti-Android-root software in our apps!" ... even though such rooted Android devices are only used by a tiny percentage of their customer base.
[Android Software/Hacking General [Developers Only]] sga999:
@osm0sis, In your post a couple of years ago about payload-dumper-go, you say "so we can now use it to extract payload.bin OTA zips on-device with no Termux/Python overhead!".

We still do need Termux or some terminal emulator, right? Maybe you were just saying we do not need Python, regardless of which terminal emulator we use.

I had been doing this on a Windows PC until I saw this today. It's so much simpler. Great to have it on my Android device, along with your wrapper!
[Android Software/Hacking General [Developers Only]] pndwal:
Yup, but Google's middle ground includes making app Devs happy (as it affects their bottom line), so accomodates this notion:

www.twitter.com/shawnwillden/status/1238126714460483588

... So they don't 'cripple Android' as some assert; they simply allow app makers to opt out where requisite OS requirements aren't met since while the device may be yours the code is licensed to them and reasonably they should be able to stipulate such requirements. Further, to encourage Banks to continue to produce Android app builds they take steps needed to make device integrity measurements and reliable (read fix notorious inadequacies, eg reliance solely on the basic attestation model).

I think CTS/VTS is here to stay, and if Google didn't use available tools like AVB to fix such certification reporting that apps rely on (let's face it, what's the point of AVB and it's chain of trust otherwise?) they would (continue to) be a laughing stock!...

Yup... But don't confuse AOSP releases with proprietary GMS (GApps)... That's NOT spirituality ours; it's Google's bread and butter, although Google allow it's use on modded devices (even uncertified ones) as long as user sideloads these apps/services separately from uncertified ROMs (ie. custom ROMs have no leave to bundle GMS).

Nb. ROMs like LineageOS (official) have long taken pains to comply with Google's wishes by never bundling GApps or any GMS code, and by refraining from spoofing expected signals from GMS components (ie refraining from 'subverting their security model')... Magisk now does the same also.

When they=Google, their security model relies entirely on providing reliable device integrity measurements... They have never indicated a preference re. how users choose to run Android with respect to unlocked B/L or root.

Rather they've facilitated changing boot state from green to orange (unlocked) or yellow (locked with custom keys) easily!

And proprietary GMS is their, 'spiritually' and intellectually...

Thanks for this clarification... I still run Win10 w/o Secure Boot, and went by MS docs... I'd missed that they'd simply stated "If you're running... operating systems such as Linux or previous version of Windows you may need to disable Secure Boot". 👍

Bit harsh... Can we be adults and make allowances here?... You've made a number of 'uneducated' statements too... 😜

FWIW, here's the official doc on Disabling Secure Boot:

https://learn.microsoft.com/en-us/w...desktop/disabling-secure-boot?view=windows-11

Pobody's nerfect...

Thanks for the PC insight...

My point was really just that it's not only mobile OSs that use forms of verified boot, chain of trust, hardware keys etc... Rather than being a 'concept that is practically unheard of', PC architecture is fast closing the gap by utilising these features with Secure Boot and new hardware requirements.

Further, I'd be surprised if bank PC apps don't start requiring attestation to Secure Boot etc in the near future in order to run (if they're not already) regardless of how trustworthy MS makes it... But that's just a wild guess. 🙃 PW
[Android Software/Hacking General [Developers Only]] pndwal:
Nb. Changeling:

Magisk (47d2d4e3) (26102)​

... • [MagiskBoot] Support extracting boot image from payload.bin

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-88569927

New commits:

Support extracting any partition from payload.bin

topjohnwu committed last week

Add zip and payload.bin support to Magisk app

yujincheng08 authored and topjohnwu committed last week

I haven't played with it, but seems Magisk now integrates this as a tool at least... 🤔 PW
[Android Software/Hacking General [Developers Only]] AnonVendetta:
What I said is largely expressing my opinions and experiences, not a statement of facts. If my intention were to pass them off as facts, I would have provided links/documentation to back up what I said. Any smart person would do the same, or risk not being taken seriously.

But the Secure Boot thing, it's a joke. A joke because you can use a signed shim loader to load unsigned components. In some cases they do need to be signed with a custom key, and you enroll those keys in the BIOS too. So an insecure component is able to parade as secure. SB is easily defeatable, there are a # of exploits that target it. Already well documented in the past.

Try installing Linux in a VirtualBox VM with SB enabled. I personally do not use SB myself, and I dont trust TPMs, so i disable them both within the BIOS, and in the OSes.
[Android Software/Hacking General [Developers Only]] abokamel:
outstanding!!
[Android Software/Hacking General [Developers Only]] pndwal:
FWIW, S/N was also a joke before evaluationType labels, and because use of this label or its PI strongIntegrity successor ensures unacceptable 'collateral' damage to bank's customer bases (ie. users of devices launched with pre Android 8 even if running up to date Android, many modern OnePlus devices etc) you might argue that it still is...

Things have evolved very slowly even in Android when it comes to secure boot guarantees.

I think strongIntegrity is actually very unlikely to spell Game Over before this happens:

A couple of months ago I put links to Google documentation about this method unrelated to calls made by gms (with its droidguard VM data) for Google device integrity API attestations, and vvb2060/Rikka's POC app at the end of this post:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-88443625

and more information here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-88448315

With this (entirely different) method any app can reliably discover an Android device's true B/L state. Moreover there's no impact for users of old (or flawed hardware keymaster) devices either... Verified boot still properly gives B/L state as Verified, Locked=true where that's the case so banks can use it now without any 'collateral damage' among customers... 😬

This one's no joke... PW
[Android Software/Hacking General [Developers Only]] enetec:
Hi, I'm trying to install your module on my new Android 12 device but I have some issues/questions...

- latest version is 1.36.1 if I don't go wrong, is it compatible with Android 12 & Magisk 26.1?

- latest Magisk Manager doesn't have an internal repository, apps like Magic Mask repo don't list it and on your Github I haven't found downloadable zips... SO, where can I find latest zip to install it??

Thank you!
[Android Software/Hacking General [Developers Only]] osm0sis:
The post you quoted literally says "to the OP" so check there, they're attachments. 😘

As for your other questions, yeah of course, my zips have the broadest compatibility of any Magisk modules, they support system installs and even still support SuperSU. 👍

KernelSU I don't have a device to experiment with yet, but I know tiann has gone to some lengths to mimic Magisk for module installs so I presume it'll be fine. 🤞
[Android Software/Hacking General [Developers Only]] Johnn78:
I did it on A13 with attached file and it worked. Now it has been created as module in Magisk. Should I delete it now so that to be able to flash it in next time or needn't to remove it now ? In next update, should I flash it again ?
[Android Software/Hacking General [Developers Only]] osm0sis:
Read the instructions in the README/"Update changelog". Also don't repost my attachments, please remove it.
[Android Software/Hacking General [Developers Only]] ale5000:
@osm0sis

I have noticed a very strange issue with this code; apparently if you read the event at least 2 times, when you exit it stuck until you press the volume button again.

Do you know why?

OUTFD="${2:?}"

printf 'ui_print %s\nui_print\n' "Press volume button..." 1>&"${OUTFD:?}"
_var="$({
cat "/dev/input/event1" &
} | hexdump -d -n 32)"
printf 'ui_print %s\nui_print\n' "Release volume button..." 1>&"${OUTFD:?}"
_var="$({
cat "/dev/input/event1" &
} | hexdump -d -n 32)"

printf 'ui_print %s\nui_print\n' "Done, now it should exit without wait" 1>&"${OUTFD:?}"

exit 22
[Android Software/Hacking General [Developers Only]] osm0sis:
Nope!
[Android Software/Hacking General [Developers Only]] osm0sis:
So my replacement WD_Black SSD from MSI appears to have also died like the previous, just took ~1 year instead of ~3 months this time. 🤬😰

I'm out of the warranty period now so we'll see if I can get them to do anything about it... This laptop might be f*cking cursed. 😑
[Android Software/Hacking General [Developers Only]] DiamondJohn:
Now thats just crazy talk.🤪 Everyone KNOWS an inanimate object like a laptop cant be cursed... its you! 👿
[Android Software/Hacking General [Developers Only]] MrDubsstep:
Do i need Busybox for Android NDK, if i want to use Smartpack Kernel Manager?

What if my devices is not compatible? I said this because i can't find it in Fox Module Manager app
[Android Software/Hacking General [Developers Only]] osm0sis:
Not sure what you mean, that wouldn't be normal for an app to rely on a separate Magisk module, but sounds like something you should go ask the Smartpack dev.

It's compatible, installation issues are pretty rare with my modules nowadays.

It's definitely in the Androidacy Module Manager (AMM, formerly FoxMMM) from the Androidacy repo for the initial install, or you can install it manually from the OP attachment, then it handles it's own updates via the Magisk app or AMM.
[Android Software/Hacking General [Developers Only]] MrDubsstep:
Thanks for your answer.

What app do you recommend me if i want to improve the battery. I heard about lower the frequencies of the CPU and GPU. I only know Smartpack Kernel.
[Android Software/Hacking General [Developers Only]] osm0sis:
I don't know your device, but best for battery is usually to cut down on apps that run in the background so your device can deep sleep. Using dark theme and turning off animations in Developer Options can also help. Slowing down your device would be a pretty aggressive step to take.

These are all pretty Googleable answers, with lots of more appropriate places on XDA for you to be looking/asking.
[Android Software/Hacking General [Developers Only]] jmac052002:
This movie a stupid question but I've never had this happen so just had to ask I have a xiaomi mi 11 and I've unlocked the bootloader and rooted and have TWRP installed and the only thing I'm going to ask and it's a pretty simple question here is you know I pass root checker showing root access but and I've never had this happen when I install busy box through your zip file the most current one it says that BusyBox is not properly installed never had this happen before so I'm like stumped?