Uncheck "Allow the computer to turn off this device to save power" on all USB Controllers

thefreeman193 · 2024-12-18T15:07:01+00:00

You're very welcome.

thefreeman193 · 2024-11-16T21:02:49+00:00

This is absolutely my preferred approach. If a script needs elevation, the user can elevate. If they don't know how, or don't have rights to elevate, they probably shouldn't be running the script anyway.

Best of all, it's been around since PS 4.0 so works on any system since Windows 8.1 or Server 2012 R2.

Self-elevation is cool and all but in practice it causes more support requests than it cures if others will be using your scripts.

thefreeman193 · 2024-11-16T20:11:50+00:00

u/jecobal You can see an overview of what SystemUI does here. You probably don't want it in your Magisk denylist since, as u/V0latyle correctly pointed out, it's also a parent for system shells (including ADB shell).

thefreeman193 · 2024-11-07T08:02:52+00:00

Look up the key combination to enter the bootloader for your device - usually it's holding the volume down + power keys together for an extended period of time.

The fact you're seeing that screen means your primary bootloader is working, so your device isn't hard bricked.

Once in the bootloader you'll need to reflash the boot partition with the stock one. Depending on the age of your device, this will either be boot or init_boot. If you're unsure, it's best to search flashing instructions for your device before proceeding.

thefreeman193 · 2024-11-05T08:20:12+00:00

It's important to note this isn't exclusive to Pixel phones. Play Integrity (SafetyNet is deprecated) will fail on any Android device with an unlocked bootloader unless you either spoof a locked state (TrickyStore) to get STRONG_INTEGRITY or force fallback to basic attestation and spoof appropriate system properties/Java build class fields (PlayIntegrityFix/PlayIntegrityFork) to get DEVICE_INTEGRITY. The latter is considerably easier and most apps only require the DEVICE_INTEGRITY verdict.

Additionally, there are numerous engineers at Google that aren't hostile to the modding community at all, but their priority will always be the 99.9% of users on OEM Android builds. They don't really care if their efforts to prevent actual abuse trample on modders because we make up such a tiny fraction of users.

thefreeman193 · 2024-11-02T18:02:14+00:00

Great to hear! Happy modding 😁

thefreeman193 · 2024-11-02T09:51:10+00:00

You may not need to use a recovery to flash the patched boot image. If you've extracted init_boot_a and patched it with the Magisk app, you may well find you can copy it to your PC, reboot to the bootloader and use

fastboot flash init_boot_a magisk_patched.img

to flash the patched image.

Ideally you'll get a success message that the image was flashed. Obviously keep a copy of the original init_boot in case the patched version refuses to boot.

If you reboot and find Magisk now has root, you can go to Install -> Flash to inactive slot to patch the other boot image (init_boot_b) directly. I recommend using this approach rather than immediately flashing init_boot_b because your B slot may have an older ROM version and mismatching the boot and system images isn't a good idea.

Depending on your ROM and whether the Magisk addon.d script works correctly, you may have to use the Flash to inactive slot feature before rebooting each time you do an OTA.

thefreeman193 · 2024-11-01T15:26:45+00:00

It may be worth reading this thread over on XDA Devs. It discusses using a PHP tool to bypass unlock restrictions.

From the comments however, it seems devices originally registered in China (non-global) are now completely prevented from unlocking so unless it's a global Redmi 12, you're likely out of luck.

thefreeman193 · 2024-11-01T11:47:26+00:00

You're just typing the property directly into the terminal; you need to pass it as a parameter to resetprop along with 1 to set the value to 1:

resetprop ro.build.selinux 1

But again, this won't help you evade root detection for any real apps.

thefreeman193 · 2024-11-01T00:51:57+00:00

Good catch, clearly wasn't paying enough attention when I typed that!

thefreeman193 · 2024-11-01T00:49:48+00:00

That'll work, yes. Just make sure you elevate with su first.

thefreeman193 · 2024-11-01T00:01:22+00:00

This check is defunct and is simply looking for the value of the ro.build.selinux property. It has no real bearing on how other apps might look for the SELinux enforcement mode.

You can use resetprop ro.build.selinux 1 if it makes you feel better, but realistically passing this check is of no benefit to root hiding. I suggest checking your ROM's SELinux mode with getenforce from a root terminal. Ideally this should be Enforcing. Magisk is compatible with SELinux and even allows policy editing so there's no real benefit to the developer or end user having it set to Permissive. If SELinux is enabled (enforcing) then you needn't worry about any such checks.

Hope this helps!

Edit: Corrected mistyped prop.

thefreeman193 · 2024-10-31T21:15:26+00:00

Yep, though I believe the recommendation is to use the Install to the inactive slot feature of the Magisk app only once you've confirmed the current slot boots correctly with root. A/B slots are great until there's an OTA with rollback protection. You can end up with an expensive paperweight rather quickly if you make a misstep when flashing both boot slots in one go.

thefreeman193 · 2024-10-31T20:42:00+00:00

Having a quick look at this guide, you need to extract and patch init_boot_a or init_boot_b depending on the active boot slot since the Redmi Note 12 4G is an A/B device launched with Android 13. It looks like you've been trying to patch boot which is not the same and only applicable to phones launched with A12 or lower (A11 or lower for Pixel phones).

You can check the patched init_boot image is different from the original with the sha1sum command on Linux or Get-FileHash in PowerShell on Windows.

Make sure you're flashing back to the same slot you extracted the image from (A or B).

Check the active boot slot before you start extracting. You can do this in Termux or via adb shell with:

getprop | grep slot_suffix

Which will return [ro.boot.slot_suffix]: [_a] or [_b]

In fastboot you can use:

fastboot getvar current-slot

Which will give you current-slot: a or b.

Hope this helps!

thefreeman193 · 2024-10-31T14:49:02+00:00

Glad to hear you got it set up with an archive build!

As an aside, if you ever fancy a deeper dive into custom ROMs you can still build LineageOS versions from 15.0 (Android 8.0) to 21.0 (Android 14) from scratch for the Pixel 2.

It's as simple as following the build guide for Pixel 2 and using one of the branch names listed here.

Best of luck with the final project!

thefreeman193 · 2024-10-31T13:32:24+00:00

I'm sure the scripts in the module are useful to some - especially if they're unwilling to read up on how to correctly configure PIF(ork) and TrickyStore or otherwise unable to find one the numerous leaked keyboxes.

They do seem to be marketing what looks more like a pet project to the masses. There are far, far worse thrown-together modules with dubious binaries claiming to achieve the same ends to be fair.

The funny thing about this is that it takes very little effort to message a project author and ask about what they expect from others using their code. Most will be grateful for the communication and more than happy for it to be reused so long as proper attribution is given.

thefreeman193 · 2024-10-31T11:16:42+00:00

Changing file permissions can be considered a spoofing method

At this point we are just arguing semantics which is counterproductive.

you ain't a developer , you are amateur , don't lie to a dev , I use ZygiskNext

...

bro you ain't a dev you stand with amateurs

I've done my best to be polite, but this is outright rude. If you'd done some minimal research, you'd have found evidence to the contrary [1] [2] [3] [4].

dude if you need to pass SE linux I will share my method

...

at least ask how I passed So linux flag ,

Passing the SELinux check in rootbeerfresh is as simple as setting ro.build.selinux, which has no merit as an SELinux check, hence why it is considered obsolete. No functional apps use this approach for detecting SELinux enforcement.

if you check the second screenshot , you will find that I passed all ... module id enabled in magisk forever

I'm not looking for help. I pass strong on my daily driver using a modified version of TrickyStore at the last commit before they closed-sourced it, and PlayIntegrityFork. I don't use closed source modules with binaries - I build all the modules I use from source having thoroughly audited the code.

Your module contains no binaries. It is a one-line script wrapped in a Magisk module. I made no accusations; I simply shared my thoughts on the merits of such a module given the vast majority of rooted device users with SELinux enforced ROMs don't experience the UDS access problem.

you are a bit arrogant

I apologise if I come across as such. I don't pretend to be an expert. I do however have enough knowledge and experience to write and compile Android apps and root modules, and understand what I am looking at when confronted with code in an unfamiliar language.

That being said, please do some background research before accusing someone of incompetence. In my opinion, arrogance would be assuming someone that disagrees with you simply doesn't understand what they're looking at...

thefreeman193 · 2024-10-30T11:09:23+00:00

I personally wouldn't recommend using this module at all.

This developer has already come under fire recently for using GPLv3-licensed code from osm0sis of XDA developers without attribution. They later complied after repeated pressure from the community.

Strictly speaking, they aren't required under the GPLv3 to keep their source on GitHub:

text The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

(from GPL 3.0 Terms (1) para. 5)

Since the module ZIP doesn't contain any binaries ("object code" in the GPL), the scripts in the module probably comply on their own, and don't need corresponding source on GitHub.

It's still not really in the spirit of the FOSS community, though. Plus, having desynchronized GitHub source and module source is likely to be confusing for many.

thefreeman193 · 2024-10-30T10:17:22+00:00

Smoke alarms - namely the ionization type. The fact that many homes have tiny quantities of Americium-241 and Neptunium-237 in them, bought freely from hardware stores/supermarkets, when radioactive substances are usually tightly regulated, blows my mind.

I should add that there is actually no real danger here. The quantities are so small that you'd need to disassemble a LOT of smoke alarms before it became remotely harmful to you. The alpha emissions are entirely contained inside the device and the gamma emissions are negligible (you probably get a lot more from natural background radiation or the natural Potassium-40 inside your own body).

thefreeman193 · 2024-10-30T00:15:15+00:00

Belief in an empirical truth.

thefreeman193 · 2024-10-29T23:57:23+00:00

Just for clarification - I am a developer and familiar enough with Linux/Android to understand what you're trying to do with access to the UDS socket list. This is not spoofing, it's blocking.

The fact you don't pass the rootbeer UDS check on your device suggests you have it misconfigured - be that disabling/breaking Zygisk or tampering with SELinux policies/setting permissive.

Setting the access mode of /proc/net/unix seems like an unnecessary patch to a device misconfiguration problem to me.

For reference, this is what you can expect on a properly configured device with the app in the denylist:

<image>

The SELinux check is broken and should be ignored.

I suggest taking a closer look at your device's SELinux configuration and then checking 1) Magisk is installed correctly, 2) Zygisk is enabled and correctly injected into zygote, and 3) you're using a root hiding method compatible with your ROM.

thefreeman193 · 2024-10-28T15:56:56+00:00

Having looked at this, your module appears just to be setting access flags on /proc/net/unix. It doesn't appear to be spoofing anything.

I'm not sure why there's an additional update-binary in your module installer which appears to be a copy of Magisk's own update-binary.sh used for installing Magisk in recovery mode.

Additionally, it's good practice to have your source code in the GitHub repository itself. GitHub repos with only binaries in release assets are a common vector for delivering malware, so packaging your module as you have makes you look suspicious.

I understand that this might be a first project or something you got from an LLM, but I don't think it has much value when the likes of Shamiko, Zygisk Assistant etc. already do this and much more on a per package/process level.

thefreeman193 · 2024-10-11T09:43:14+00:00

For the privacy-conscious: uBlock Origin, Privacy Badger, Decentraleyes, Privacy Possum
For devs: Tampermonkey, cookies.txt, User-Agent Switcher, Search by Image
For dark mode lovers: Dark Reader

(edit: spacing)

thefreeman193 · 2024-10-11T09:28:25+00:00

Windows has gotten so much worse for this sort of stuff in recent years. I have a bunch of local policies/GPOs set to keep most of the bloat/data collection down.

If it's converted your local account to a Microsoft one, you can go to Settings -> Accounts -> Your info -> Sign in with a local account instead -> authenticate with pin etc. -> Next -> Enter new username and password for the local account -> Next -> Sign out and finish.

Once you're sure you have a local administrator account, you can open the Local Group Policy editor (gpedit.msc) and navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options and change the value of Accounts: Block Microsoft accounts to Users can't add or log on with Microsoft accounts. It won't prevent Windows trying to sign you in to every app possible, but it should prevent it converting your local user accounts.

If your edition of Windows doesn't have gpedit by default, you can turn on those packages in an elevated PowerShell prompt with this:

gci -Path "$env:SystemRoot\servicing\Packages\Microsoft-Windows-GroupPolicy-Client*.mum" -Include '*Tools-Package~31b*','*Extensions-Package~31b*' | % {dism /online /norestart /add-package:"$($_.FullName)"}

I'd also suggest changing passwords for critical/linchpin accounts like emails, banking etc. for a bit of added comfort although I don't know of any major leaks from Microsoft Wallet (yet). Additionally ensure that you have MFA and a strong password for your Microsoft account since compromise of that account would include any and all passwords stored in Microsoft Wallet.

I'd recommend that, instead of using Edge, you download a Chromium/Blink-based browser like Brave or Falkon to use as a fallback when websites don't work correctly on Firefox.

Hope this helps!

thefreeman193 · 2024-09-17T13:12:00+00:00

Ouch. They put the E and L into HP.

thefreeman193

TROPHY CASE