Related
Greetings,
I tried to ask this in the NexusRoot Toolkit thread, but I need 10 posts.
My question has to do with Nexus 7 Security and Rooting. Can I turn the developer options back off after rooting, and still have the 'rooted' experience? I'm concerned with any malware infections, and also exploiting the device using a Cellebrite UFED:
w w w .cellebrite.com/mobile-forensics-products/forensics-products.html
I will be encrypting the entire device using Android encryption. Anything to watch out for when enabling encryption, in relation to rooting? Is the max unlock/encryption length still 16 characters on Jelly bean?
Thanks,
RF
Well, you are defending against two different things there.
ufed goes through the usb client mode while you would be defending installed software from the network for whatever malware concerns you might have.
I don't know if anything in user space can defend against a ufed if they want your data bad enough. I have seen it suggested that if you put something like Ubuntu on the device the ufed wouldn't know what to do with it. But I am sure they have plenty of tech specialists who they could then turn the device over to.
A check at a traffic stop might be something you could defend against. But if they have a subpoena and time...well the laws protect them not us.
You could use PDroid to stop apps from having permissions. That seems like the best defense to me for regular everyday data mining. We have not brought it to Jelly Bean yet, but it shouldn't be long.
mateorod said:
Your post
Click to expand...
Click to collapse
Thanks Sir. This is my first Tablet, and my first 'DIY' Unlock & Root. I do currently run Whispercore on a Nexus S though, but that was one click rooting from the installer and I don't touch it. As long as I can power down at a stop, UFED is spinning in the wind with WhisperCore. I want the same functionality from Jelly bean, but am unfamiliar with exactly how it works compared to Moxie's solution. I know that USB Debugging Enabled is an exploitable hole that devices like UFED use, that's why I wanted to know if I can disable all the developer options again, after rooting, with no ill effect.
I also block Android GPS Daemon from communicating, with Whisper Monitor, so hopefully Jelly Bean will have some firewalls able to do this soon.
Thanks for your reply,
RF
You should be alright with malware as long as you're careful what applications and ROMS you're downloading and from where.
Ronaldo Forenucci said:
Thanks Sir. This is my first Tablet, and my first 'DIY' Unlock & Root. I do currently run Whispercore on a Nexus S though, but that was one click rooting from the installer and I don't touch it. As long as I can power down at a stop, UFED is spinning in the wind with WhisperCore. I want the same functionality from Jelly bean, but am unfamiliar with exactly how it works compared to Moxie's solution. I know that USB Debugging Enabled is an exploitable hole that devices like UFED use, that's why I wanted to know if I can disable all the developer options again, after rooting, with no ill effect.
I also block Android GPS Daemon from communicating, with Whisper Monitor, so hopefully Jelly Bean will have some firewalls able to do this soon.
Thanks for your reply,
RF
Click to expand...
Click to collapse
Yes after rooting you can turn it off. (In fact you can turn off developer options completely, and install apps from unknown sources is labeled under security). Only thing you won't be able to do is side load apps or use like titanium backup to restore apps.
Sent from my LG-P999 using xda app-developers app
Ronaldo Forenucci said:
Thanks Sir. This is my first Tablet, and my first 'DIY' Unlock & Root. I do currently run Whispercore on a Nexus S though, but that was one click rooting from the installer and I don't touch it. As long as I can power down at a stop, UFED is spinning in the wind with WhisperCore. I want the same functionality from Jelly bean, but am unfamiliar with exactly how it works compared to Moxie's solution. I know that USB Debugging Enabled is an exploitable hole that devices like UFED use, that's why I wanted to know if I can disable all the developer options again, after rooting, with no ill effect.
I also block Android GPS Daemon from communicating, with Whisper Monitor, so hopefully Jelly Bean will have some firewalls able to do this soon.
Thanks for your reply,
RF
Click to expand...
Click to collapse
I thought whispercore got purchased (by twitter, I think? Maybe?) and is only available for the nexus s. Maybe you plan to sideload it? I haven't personally found a way to try it yet.
But yeah, you can shut off adb mounting. I have actually spent a good chunk of my day looking into how to require a passcode for USB mounting in the kernel, for an unrelated project.
I haven't determined whether the multiuser claims are sufficient. I have muktiuser through botbrew, but that is a little more complicated than what I need there.
You are correct, I have a Nexus S also, running WhisperCore. The N7 will have to run Google's built in implementation of encryption. Thanks for all the replies. I'll Unlock & Root, and then disable Developer Options again. In the 'off state' Google's encryption should protect from UFED type attacks. I'll probably install Avast! (if it runs on the N7) for malware protection.
RF
Yeah from my understanding of UFED your pretty well protected as long as you don't have USB debugging on; so while not ideal, only turning it on when you need it would be the easiest way to secure the device. (along with all the normal stuff like having an actual password etc)
Considering how much apple fanboys tout the iphone's security, its fairly ironic that UFED can still pull some of their info regardless of settings whereas on android if USB debugging is off and a password is used UFED is useless.
I know, right :good: Is max password length still 16 characters? It is on Gingerbread. I wish this thing had a USB slot...I'd love to be able to use my Yubikey with it. I wonder if the NFC Yubikey version would work on the Lock Screen?
RF
Does someone unlock Windows Phone 8 OS ?
Will someone do it ?
Thanks for info.
Yeah, when they have bootlevel 0 access, maybe it could be done
As I have heard, and understood, the chips are hard-encoded, for every device, so the JB cannot be achieved Will it ever be? Who knows, this is quite a challenge, but I am no optimist.
Hard coded?? Wow those SOBs. They really need to rethink as to why they are not selling as many phones as they would love to.
LOL. 99% of earth's population does not know or care about the "hard coded" chip (it is not hard coded, it is analogical thus it cant be reprogrammed)
Scumbag Microsoft
Just a question on this. So, boot level stuff is not posable because of encryption. So as of now, Custom roms are out, not possable, YET.
With this being known, what most of us would be happy with is a suto Interop unlock. This would allow max unsigned apps and maybe some minor system level apps (think Advanced Config type apps) maybe bosted with a root tools type of app (almost a custom rom but, not). This stuff will all run on the OS, not the boot level. Shouldn't this be possable once someone finds a hole someplace ?
So, full unlock with custom roms will not be possable but, at least we can have a step there to have some fun with out phones till someone actually figures it out (slim chance if it's encrypted)
mcosmin222 said:
LOL. 99% of earth's population does not know or care about the "hard coded" chip (it is not hard coded, it is analogical thus it cant be reprogrammed)
Click to expand...
Click to collapse
And I agree, becides hobbiests and hackers (and XDA readers ), no one really cares about a unlock, that is about 98% of of the Windows Phone users. That does not mean we (the 2-3%) dont want it...
MSFT clearly does not care about hackers like us. Otherwise they would give us more APIs to program with.
They care about the bad type of hackers.
In WP7 we only had Full Unlock on devices that had a Custom ROM flashed onto it. This does not mean that it is not possible to exploit other loopholes but the NT Kernel is kind of a harder nut to crack than the old CE Kernel powering WP7. Basically you would need a vulnerability in a system App to get your code running. Then that code would have to escape from it's jail and acquire a higher permission level. Then I guess the first step would be to write something to the registry that would allow:
a) to sideload apps (basically what the developer unlock does)
b) to elevate permissions on those sideloaded apps (similar to what the Root Tools were able to do)
We only had two ways ever to get any Unlocks without flashing a CustomROM on WP7. The first was the original ChevronWP7 and the second was Window Break which only worked on certain Samsung devices and was quickly patched. Aside from that everything concentrated on the CustomROM route or on how an Unlock achieved previously could be conserved through system updates (Nodo to Mango).
So it might be quite some time before we even see something like the Interop Unlocks. Even most Android devices were routed by flashing a modified kernel.
It's been a while, has there been ANY progress on a Unlock even if interop or something for Windows Phone 8 ? I have a dev unlock and it limits me to 3 apps but, what I miss the most is apps like Advanced config giving me unlimited options for colors...
I do not believe so.
Code:
Sooner or later it will be hard to get a rootable Chromecast. The community is limited by the number of people able to root their own devices. A remote exploit is desirable to expand the community. Please brainstorm and post progress in exploring the targets.
Targets:
Web interface
Chromecast executes commands to start netflix etc with user specified arguments. Arguments are sent through dial interface. From app.conf:
Code:
{ "app_name": "Netflix",
"external": true,
"command_line": "/bin/logwrapper /netflix/bin/netflix_init --data-dir /data/netflix/data -I /data/netflix/AACS -D QWS_DISPLAY=directfb -D LD_LIBRARY_PATH=/system/lib:/netflix/qt/lib -D NF_PLAYREADY_DIR=/data/netflix/playready -D KEYSTORE=/data/netflix/AACS -D KEYBOARD_PORT=7000 -D ENABLE_SECURITY_PATH=1 -D DISABLE_SECURITY_PATH_VIDEO=0 -D DISABLE_SECURITY_PATH_AUDIO=1 --dpi-friendlyname ${FRIENDLY_NAME} -Q source_type=12&dial=${URL_ENCODED_POST_DATA}",
"allow_empty_post_data": true,
"dial_info": "<port>9080</port><capabilities>websocket</capabilities>"
},
FFMPEG vulnerabilities
Intercepting updates (I know, the signatures would likely prevent this.)
Cable based attacks similar to current root methods
Soldering based attacks
Post your ideas and progress.
My chromecast is not rooted, so I can't get logs from netflix being run with different URL_ENCODED_POST_DATA, but we might be able to fork the command.
TVRemoteExploit said:
Code:
Sooner or later it will be hard to get a rootable Chromecast. The community is limited by the number of people able to root their own devices. A remote exploit is desirable to expand the community. Please brainstorm and post progress in exploring the targets.
Targets:
Web interface
Chromecast executes commands to start netflix etc with user specified arguments. Arguments are sent through dial interface. From app.conf:
Code:
{ "app_name": "Netflix",
"external": true,
"command_line": "/bin/logwrapper /netflix/bin/netflix_init --data-dir /data/netflix/data -I /data/netflix/AACS -D QWS_DISPLAY=directfb -D LD_LIBRARY_PATH=/system/lib:/netflix/qt/lib -D NF_PLAYREADY_DIR=/data/netflix/playready -D KEYSTORE=/data/netflix/AACS -D KEYBOARD_PORT=7000 -D ENABLE_SECURITY_PATH=1 -D DISABLE_SECURITY_PATH_VIDEO=0 -D DISABLE_SECURITY_PATH_AUDIO=1 --dpi-friendlyname ${FRIENDLY_NAME} -Q source_type=12&dial=${URL_ENCODED_POST_DATA}",
"allow_empty_post_data": true,
"dial_info": "<port>9080</port><capabilities>websocket</capabilities>"
},
FFMPEG vulnerabilities
Intercepting updates (I know, the signatures would likely prevent this.)
Cable based attacks similar to current root methods
Soldering based attacks
Post your ideas and progress.
My chromecast is not rooted, so I can't get logs from netflix being run with different URL_ENCODED_POST_DATA, but we might be able to fork the command.
Click to expand...
Click to collapse
what if somehow we were able to attack it like jailbreakme used to. Looking at the developer options in chrome you could write a program for your phone that has the cast button when you click it, it'll tell chrome cast to go to the apps domain where it automatically roots for you. I'm no developer, so i don't even know if that kind of hack would even be possible. I did download the cast app for windows and it has a button for factory reset. Would it be possible to hack that chromecast program and change the factory reset to use a hacked pulled firmware?
scarygood536 said:
what if somehow we were able to attack it like jailbreakme used to. Looking at the developer options in chrome you could write a program for your phone that has the cast button when you click it, it'll tell chrome cast to go to the apps domain where it automatically roots for you.
Click to expand...
Click to collapse
This would be extremely difficult to pull off, as you would need to both escape Chrome's sandbox and find a privilege escalation vulnerability in the Linux kernel or a setuid binary. Both Chrome and Linux are extremely mature and secure pieces of software, so vulnerabilities are few and far between and get patched quickly when they are found.
I tried tacking commands onto the tail of the netflix commands like this:
Code:
curl ****192.168.1.126:8008/apps/Netflix -X POST -d "intent=play&titleid=***%3A%2F%2Fapi.netflix.com%2Fcatalog%2Ftitles%2Fmovies%2F70138593;reboot"
, however I can't see the log file without root.
tchebb said:
This would be extremely difficult to pull off, as you would need to both escape Chrome's sandbox and find a privilege escalation vulnerability in the Linux kernel or a setuid binary. Both Chrome and Linux are extremely mature and secure pieces of software, so vulnerabilities are few and far between and get patched quickly when they are found.
Click to expand...
Click to collapse
so is our best bet to find a vulnerability within the hardware level we could utilize and wouldn't have the chance of being patched?
In all honesty, the best method of attack would be to figure out the JTAG port. with that, you could then simply just flash back on the rootable bootloader on any device, and go from there. I doubt any software methods will be found, and even if one is found, it will be patched by google within a month. The JTAG port however is at a hardware level, and unless it actually does signature checks (like the USB method does on updated devices), it would allow a person full control of the flash chip.
EDIT: To clarify, if the UART port is hardware based (like normal JTAG ports on wireless routers and such), then there should be no security checks. If, for whatever reason, it is software based though (so like fastboot, or Samsungs ODIN mode), then there is a chance it checks image files.
ddggttff3 said:
In all honesty, the best method of attack would be to figure out the JTAG port. with that, you could then simply just flash back on the rootable bootloader on any device, and go from there. I doubt any software methods will be found, and even if one is found, it will be patched by google within a month. The JTAG port however is at a hardware level, and unless it actually does signature checks (like the USB method does on updated devices), it would allow a person full control of the flash chip.
EDIT: To clarify, if the UART port is hardware based (like normal JTAG ports on wireless routers and such), then there should be no security checks. If, for whatever reason, it is software based though (so like fastboot, or Samsungs ODIN mode), then there is a chance it checks image files.
Click to expand...
Click to collapse
Unfortunately (although I don't believe anyone has confirmed this on the Chromecast), all known GTV devices with this SoC ship with their JTAG port disabled. It may be possible to re-enable it in software, but (of course) that requires running your own kernel. The only hardware hack I know of that is sure to work is manually soldering a NAND flasher up to the memory chip and rewriting the partitions that way, which is expensive, error-prone, and extremely tricky to do right.
tchebb said:
Unfortunately (although I don't believe anyone has confirmed this on the Chromecast), all known GTV devices with this SoC ship with their JTAG port disabled. It may be possible to re-enable it in software, but (of course) that requires running your own kernel. The only hardware hack I know of that is sure to work is manually soldering a NAND flasher up to the memory chip and rewriting the partitions that way, which is expensive, error-prone, and extremely tricky to do right.
Click to expand...
Click to collapse
The more you know.
Well, while looking through the chromecast's "fts" partition in a hex editor, I found the following variable show up in multiple places.
Code:
device_configured=true
makes me wonder what happens if this is flipped to false. I will look through the bootloader source more to see if it is used at a software level.
EDIT: Doesn't look like it does anything for us, seems to just enable the crash counter.
tchebb said:
Unfortunately (although I don't believe anyone has confirmed this on the Chromecast), all known GTV devices with this SoC ship with their JTAG port disabled. It may be possible to re-enable it in software, but (of course) that requires running your own kernel. The only hardware hack I know of that is sure to work is manually soldering a NAND flasher up to the memory chip and rewriting the partitions that way, which is expensive, error-prone, and extremely tricky to do right.
Click to expand...
Click to collapse
ddggttff3 said:
The more you know.
Well, while looking through the chromecast's "fts" partition in a hex editor, I found the following variable show up in multiple places.
Code:
device_configured=true
makes me wonder what happens if this is flipped to false. I will look through the bootloader source more to see if it is used at a software level.
EDIT: Doesn't look like it does anything for us, seems to just enable the crash counter.
Click to expand...
Click to collapse
ddggttff3 said:
In all honesty, the best method of attack would be to figure out the JTAG port. with that, you could then simply just flash back on the rootable bootloader on any device, and go from there. I doubt any software methods will be found, and even if one is found, it will be patched by google within a month. The JTAG port however is at a hardware level, and unless it actually does signature checks (like the USB method does on updated devices), it would allow a person full control of the flash chip.
EDIT: To clarify, if the UART port is hardware based (like normal JTAG ports on wireless routers and such), then there should be no security checks. If, for whatever reason, it is software based though (so like fastboot, or Samsungs ODIN mode), then there is a chance it checks image files.
Click to expand...
Click to collapse
Maybe I'm missing something, possibly am, but couldn't we dual boot firmwares? Have the normal factory firmware on the eMMC chip, then, install a rooted image to a USB stick. Next solder a different wire to each side of pin 26, finally solder a switch in between. This should force the device to load off the USB rather than eMMC. On paper it works. On the physical device? That could be a bit different. If you do try this, I'll do my best to help you and point you in the right direction.
The switch is to choose between the two firmwares, if however, you only want to boot from the USB, you could, possibly, just have a permanent jump of pin 26. That should force booting from the EMMC to fail every time forcing it to boot from USB.
NOTICE: none of these suggested ideas have been used and or tested. They work on paper only! The real device may, and possibly is, different! Attempt at your own risk.
OP, XDA, nor I am responsible for anything that happens to your device. If anything does happen it's completely on you! This is a dangerous hardware mod, I don't recommend if you don't know how to solder. Also, the points for pin 26 are very very small, smaller than some solder iron's tips. All of mine are way too big, and I have bought small tips to use on other mobile devices. If you mess this up there is none to very little chance of going back.
SECOND NOTICE: constantly jumping the 26th pin of the CPU could cause permanent hardware problems. If such problem does happen, it is not known at this time. Once again, this is a dangerous hardware mod that should not be attempted by those who aren't good with soldering.
The good news: if you do attempt this and it works, we could have a hardware way to be rooted. More good news is that if you mess up and can't fix it, then it's only $35 to get a new one.
Aaron Swartz, Rest in Pixels.
jamcar said:
The switch is to choose between the two firmwares, if however, you only want to boot from the USB, you could, possibly, just have a permanent jump of pin 26. That should force booting from the EMMC to fail every time forcing it to boot from USB.
Click to expand...
Click to collapse
Just to let you know, a permanent jump to pin 26 will cause the device to not boot, at all. It causes a read interrupt to the EMMC, so if jumped permanently the device will not see the flash, so it wouldn't even load the bootloader. Jumping the pin should ONLY be used if the standard button hold boot process does not work.
jamcar said:
Maybe I'm missing something, possibly am, but couldn't we dual boot firmwares? Have the normal factory firmware on the eMMC chip, then, install a rooted image to a USB stick. Next solder a different wire to each side of pin 26, finally solder a switch in between. This should force the device to load off the USB rather than eMMC. On paper it works. On the physical device? That could be a bit different. If you do try this, I'll do my best to help you and point you in the right direction.
The switch is to choose between the two firmwares, if however, you only want to boot from the USB, you could, possibly, just have a permanent jump of pin 26. That should force booting from the EMMC to fail every time forcing it to boot from USB.
NOTICE: none of these suggested ideas have been used and or tested. They work on paper only! The real device may, and possibly is, different! Attempt at your own risk.
OP, XDA, nor I am responsible for anything that happens to your device. If anything does happen it's completely on you! This is a dangerous hardware mod, I don't recommend if you don't know how to solder. Also, the points for pin 26 are very very small, smaller than some solder iron's tips. All of mine are way too big, and I have bought small tips to use on other mobile devices. If you mess this up there is none to very little chance of going back.
SECOND NOTICE: constantly jumping the 26th pin of the CPU could cause permanent hardware problems. If such problem does happen, it is not known at this time. Once again, this is a dangerous hardware mod that should not be attempted by those who aren't good with soldering.
The good news: if you do attempt this and it works, we could have a hardware way to be rooted. More good news is that if you mess up and can't fix it, then it's only $35 to get a new one.
Aaron Swartz, Rest in Pixels.
Click to expand...
Click to collapse
This wouldn't work with any post-12072 bootloader, since the USB image's signature is still checked. The signature verification would simply fail and the device would fail to boot, same as if.you tried to boot from USB with a button press.
Apparently the ONLY version of Android that is vulnerable to Heartbleed is 4.1.1. I ran a check on my phone, and sure enough I'm running that version, and heartbeats are definitely enabled. I used the Lookout security app to verify this. Is there a way I can patch my system myself and somehow disable the heartbeats feature without having to wait another 3 years for Motorola to come out with a fix? My phone is rooted, but something tells me that OpenSSL probably needs to be essentially recompiled with a flag set to disable heartbeats?
I was hoping there would be a quick config file for OpenSSL that can be modified, but I'm not usually lucky. Based on everything I've seen thus far, a recompile with a flag set is the only way to fix this. Figured i'd give it a shot and ask on here.
I've been thinking about the same thing.
If memory was encrypted that could solve all or part of the problem.
If the Chrome https browser cache were turned off, which I think requires an APK edit there would not be any clear text data in the browser cache.
What do you think?
dosmac said:
Apparently the ONLY version of Android that is vulnerable to Heartbleed is 4.1.1. I ran a check on my phone, and sure enough I'm running that version, and heartbeats are definitely enabled. I used the Lookout security app to verify this. Is there a way I can patch my system myself and somehow disable the heartbeats feature without having to wait another 3 years for Motorola to come out with a fix? My phone is rooted, but something tells me that OpenSSL probably needs to be essentially recompiled with a flag set to disable heartbeats?
I was hoping there would be a quick config file for OpenSSL that can be modified, but I'm not usually lucky. Based on everything I've seen thus far, a recompile with a flag set is the only way to fix this. Figured i'd give it a shot and ask on here.
Click to expand...
Click to collapse
Yep, 4.1.1 is vulnerable to this. 4.1.2 has the no heartbeat fix added in and 4.1.1 took the update that was bugged. That said, we DO have TWO 4.1.2 Stock roms, Mexican Retail and Bell are both 4.1.2 and should have that fix -- needs confirmation. Our Stock ICS roms are all from before this bug was added in and are safe. In reality, only stock, locked AT&T Atrix HD's are vulnerable to this since all the other roms* have this fix.
Normally I'd say something around the lines of give me a few days and I'll look into this more, but I've been busy lately, and when I'm not busy I'm either tired or sore; did some heavy lifting a few weeks ago and my back is still sore from that day.
*Our 4.1.2 roms are untested, but 4.1.2 AOSP has the fix so our 4.1.2 stocks should too
I was just thinking that ther eis no such thing as security. Security is achieved by being harder to exploit than the other computers. Even 3-DES can be cracked with enough computing power.
So encrypting memory and stopping https caching would close two big holes. I'm now wondering what holes would remain to be exploited by the heartbeat exploit on a 4.1.1 device if this were done?
stevep2007 said:
I was just thinking that ther eis no such thing as security. Security is achieved by being harder to exploit than the other computers. Even 3-DES can be cracked with enough computing power.
So encrypting memory and stopping https caching would close two big holes. I'm now wondering what holes would remain to be exploited by the heartbeat exploit on a 4.1.1 device if this were done?
Click to expand...
Click to collapse
If I was on a stock phone running 4.1.1 and I was that worried about heartbleed, I'd unlock the bootloader and install Bell or Mex Retail because both are 4.1.2. I might even be possible to just swap the exploited binaries with the ones in our 4.1.2 roms, that's something someone else worried about this can do. Hell, it might even be possible to run the 4.1.2 roms with safestrap and the AT&T kernel...again, that's a someone else thing...I have no intention of dicking with SSR.
Think about Wifi being hacked....when it first came out a crappy password like 12345678 was good enough because computing power wasn't that good for consumers yet; nowadays, a basic gaming laptop can check 500,000 wpa2 passwords a second, a decent desktop with multiple GPU's can do over a million a second. All wpa2 hacking is sniffing out the verification md5*, then the tools generate passwords and their md5 and compare it against the sniffed out one, eventually you'll find one that matches, especially so if the password sucks. If you know how certain telecoms set up their wifi passwords, you can shorten the amount of time taken by limiting to the characters they use -- for example, AT&T U-Verse** uses 10 digit numeric passwords, so all you'd have to do is limit the tools to use numbers and start with 10 digits....hint: there are only 1 million codes if you use 10 numbers only....10 to the power of 10 and all....
That isn't a wifi hacking tutorial, just an example of how overtime good security unchanged becomes very bad security and how eventually an exploit will be found and security compromised, like how wpa2 for a split second sends out a the verification md5 unencrypted.
*not sure if WPA2 uses md5, but most of us know what md5's are
**last time I read about that service that's what I saw...and I read that a few months ago
Wondering if there's a public exploit available for the mali gpu bug?
what I want to do with it is temporarily root my device so I can modify the dialer db that controls ability to record conversations and the like, without need to unlock my phone. my logic is that if an exploit existed, I'd be able to to run it, get root, perform the neccessary sqlite commands / modifications to the db, reboot phone and it should just work and OTA updates should also just continue to work without an issue.
see exploit code from github security team for similiar issue on pixel 6 from a year or so ago, but wondering if anything exists for this new issue?
also, one can correct me if I'm wrong about what I want to do and that it wont work, even if there was an exploit.
Mali MMU exploits are extremely powerful, and kept under the wraps for now. Most vendors started patching these things only very recently.
Some one-click-root will be dropped like it's 2015 after all this is said and done (or some malware using it shows up first). But doing it sooner would wreak too much havoc.
If your device is Mali, you might want to defer security updates if you wish to use soft root in the following months - provided you're ok with leaving your device vulnerable till then.
Its not actively being used at the moment, so that's fine. Being patient (with that said, pixel devices are easy to downgrade) the