7 ms·

Now Niantic's decision to disallow root devices, imo, is pretty regretful, as serious botters will likely be able to get around that restriction regardless. Thi

by pwnna 10y ago

Now Niantic's decision to disallow root devices, imo, is pretty regretful, as serious botters will likely be able to get around that restriction regardless. This only serves to punish users who are stuck between having a root-enabled custom ROM or a stock ROM where critical root exploits may exist. One thing that I observed is that no one seems to be interested in producing a ROM that is both stable, has a variety of features, do not rely on root, and supports the device for a long time. This is a shame really, because root itself breaks the security mechanism for android and users probably are not fully aware what it means when they grant applications root. I personally got around this problem by compiling a build of CyanogenMod without root enabled, but with things like FDroid (with PrivilegeExtension) and adblock built-in to the ROM itself (albeit the update mechanism is to update the ROM it self). This is not a solution for the mass majority of users. This problem is pretty difficult to solve and it is pretty deep, much deeper than what I'm willing to type in a single comment, so I'll stop here.

djsumdog 10y ago
I wrote this about Android a while back: http://penguindreams.org/blog/android-fragmentation/ http://penguindreams.org/blog/android-fragmentation/ The TLDR is that it'd be nice if Android was more like Windows/Intel: install the OS (i.e. AOSP), drivers (or binary driver package format and an SDK to auto-build it) and boom you're done. Clean, stock, standard. Same with many Linux distros on x86/64. I need to write an update to the article though. Lately I've been struggling with a Clearfog ARM board, and coupled with Torvald's recent comments on Intel vs ARM, I wonder if a huge chunk of the problem is ARM itself. I've noticed for every distro there are really specific images, not just for each ARM chipset, but for individual boards, even when those manufacture patches make it into the mainline kernel. I haven't looked closely at Android and I'm really curious at the build system/workflow used by things like Cyanogen and Omnirom. Are kernels really specialized per device? Does the ARM architecture itself make it difficult to have general purpose kernels that will boot on all of them like in the x86/64 world? Any ARM hardware people care to chime in?
- cheiVia0 10y ago
  Debian is shipping one Linux kernel build that runs on a bunch of different ARM devices that are supported by the mainline version of Linux: https://wiki.debian.org/DebianKernel/ARMMP https://wiki.debian.org/DebianKernel/ARMMP Unfortunately most mobile devices are not supported by mainline Linux (N900 is best supported, but not fully), usually only server/desktop/laptop vendors have any incentive to mainline their drivers.
  - voltagex_ 10y ago
    The 2013 Nexus 7 was, at some point, 50 patches away from running mainline [1]. I know, single datapoint, but it gives me hope that there's some way out of the tabletification of computing. 1: https://wiki.linaro.org/LMG/Kernel/FormFactorEnablement https://wiki.linaro.org/LMG/Kernel/FormFactorEnablement
- pjmlp 10y ago
  It is like the old days of home computers. We had Z80, 6509, 68000 and so so, but everything else that was plugged into their pins was different. So it doesn't matter if the Assembly is the same, the kernel also needs to talk to the hardware. Also ARM just resells the base designs, each company usually adds they own set of Assembly instructions or fine tunes the designs in some other way. The IBM PC clones were the only ones that had some kind of standardization going on, and even that seems to be gone now, with OEMs going to the same kind of hardware designs we used to have (everything bolted on the board).
- cheiVia0 10y ago
  Some related posts: https://cascardo.eti.br/blog/GNU_on_Smartphones_part_II/ https://cascardo.eti.br/blog/GNU_on_Smartphones_part_II/ http://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/ http://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/ https://wiki.debian.org/Mobile https://wiki.debian.org/Mobile
- exDM69 10y ago
  > Any ARM hardware people care to chime in? It's not really about the CPU architecture, but the peripherals of the devices. In the x86 world, the peripherals are governed by the "PC" standard, which these days is implemented by the chipset on your motherboard. They all have similar functionality, although you still do need some chipset-specific drivers in your kernel. In the ARM world, the landscape is different. There has never been a de facto standard configuration of an ARM computer like the PC was/is for x86. There are ARM computers that are more like a micro controller and there are tablet/mobile devices based on ARM that have a system on chip (SoC) that's got all the peripherals, including GPUs, network adapters, etc. Every SoC is pretty different, there's a bunch of devices connected with i2c, spi and other buses. These are required to control the power and clock management and all the I/O devices. ARM (the company) doesn't really design these, they just license ARM (the architecture) to a SoC manufacturer and call it a day. This leads to a very diverse and fragmented landscape. The ARM world has been making strides to reduce the amount of chip-specific code. One good example is the device-tree configuration which, in theory, allows running the same kernel binary on different devices. With device-tree, you pass a config file from the bootloader to the kernel, which contains configuration (i/o memory maps, etc) of the peripherals (which you'd query from the hw/firmware in a x86 machine). This is a huge improvement over what was before it, but there's still a long way to go. And there's still plenty of older ARM SoCs out there that don't support this. But yes, it's pretty much a mess. There's a lot of duplicate work that every ARM SoC manufacturer has to go through. Given that the mobile world is financed by a planned obsolescence cycle where they expect customers to upgrade every few years, I find it unlikely that this issue will be solved any time soon.
tedmiston 10y ago
They've gotta stop the GPS spoofers somehow. It's not like this was the first solution they jumped to to stop cheaters. Maybe this was the 80/20 solution over more advanced location anomaly detection methods against their database.
- lini 10y ago
  The problem is that you don't need root for GPS spoofing. Botters also don't care about SafetyNet (used to detect root before the game starts), since they reverse engineer the API and make REST calls directly. Furthermore, there are ways around the root check - mostly involving hiding the su binary and some additional tweaks.
  - deanclatworthy 10y ago
    Furthermore, you can buy GPS spoofing devices anwyay which you can just carry around with you in your pocket.
    - foota 10y ago
      To be fair, that's probably highly illegal if caught by the fcc.
      - seszett 10y ago
        The FCC only has business in the US though.
        lucb1e 10y ago
        Almost every country has something like that. The Dutch Agentschap Telecom will hunt you down for transmitting a fake GPS signal too. The thing is, nobody cares if you send a signal too weak to go beyond a meter of your pocket. That's why it's totally legal to send FM on registered frequencies as long as your output is under a certain amount. Same with WiFi even. I heard about someone looking into GPS spoofing once in the context of catching drones, even nearby ones (e.g. fly near to it). It takes a lot of energy to do that and was basically not practical outside of military settings.
tombrossman 10y ago
> I personally got around this problem by compiling a build of CyanogenMod without root enabled, but with things like FDroid (with PrivilegeExtension) and adblock built-in to the ROM itself... I just bought a Nexus 5x and loaded CopperheadOS on it, and to my dismay I see Ad-Away from F-Droid requires root to function (plus a couple other apps I really like). How much of a hassle is it really, because I absolutely want system wide ad blocking and I worry that I will be defeating the purpose of using a hardened OS in the first place? Do you rebuild and flash each OS update as a new ROM? Is all your data on the phone persistent or backed up & restored each time?
- pwnna 10y ago
  > How much of a hassle is it really, because I absolutely want system wide ad blocking and I worry that I will be defeating the purpose of using a hardened OS in the first place? Ad-away works by using a host file to block. The hosts file is generally not writable by the user without root as it lives on a read only partition (/system). Another way to block ads is to connect to a VPN that blocks thoses hosts for you, however that is more cumbersome to setup. While hosts blocking is not perfect... my thought on this was to expose a limited API that allows apps to update the hosts file without having root. This could be sketchy and a security risk on its own tho, because you're essentially hijacking DNS... In addition, I don't think the community is interested in this because they all love root.. > Do you rebuild and flash each OS update as a new ROM? Every month, immediately after the security bulletin and a resync. > Is all your data on the phone persistent or backed up & restored each time? So android has a /system partition and a /data partition. When you reflash your system, the data partition (where all your apps, settings, what not are stored) is left untouched. Android will detect this and perform an upgrade operation on the /data partition, if applicable.
  - nradov 10y ago
    Apple added specific ad blocking features to iOS 9, and I don't think those rely on editing the hosts file. So in principle a similar design could work for Android, although I doubt Google would ever support that.
legulere 10y ago
A few botters don't hurt Pokémon go. But when it's easy to bot, lots of people will bot. It's easy to circumvent anti root, but it's impossible to use the same way for lots of devices without niantic being able to block it again. So it really makes sense for them to go this way IMO.
- Drdrdrq 10y ago
  Not really. It doesn't matter if the phone is rooted or not, what matters is whether it is feeding false gps data or not. Bots will soon find a way around this (non-rooted) restriction anyway. That said, proper protection against cheating would involve using markers (other phones?) in vicinity, so it should be possible too.
  - rickyc091 10y ago
    Yes, bots will most likely always find a way, but I think it's more about thwarting the casual users. If you could gps hack by simply installing an app more people would do it. By making it extremely tedious, the causal user won't be as inclined to do it since the time it takes to figure it out won't be worth it. I don't condone Niantic's behavior, but I understand it.
    - mynameisvlad 10y ago
      To me, it would make more sense if they weren't also banning users their auto-detection system thinks are spoofing GPS. A system which is fairly overzealous, might I add. I was banned for being in Japan, for example. One day out of the blue on my vacation, got the ToS violation notification which still hasn't been reversed, two weeks later.
  - evilDagmar 10y ago
    The spoofers have had a way around this for some time now, as GPS spoofing simply does not require root privileges. Niantic is not actually making any attempt to look for GPS spoofing software. They simply invoke Android's SafetyNet which doesn't care about GPS at all but does care about other things which happen to coincide with what's on some cheater's phones. It will never be anything like an effective measure against GPS spoofing.
on_and_off 10y ago
> This is not a solution for the mass majority of users. root is not used by the mass majority of users.
lewisl9029 10y ago
I honestly would be very happy with a ROM that copies stock Android entirely, without any added features or customizations, rather focusing solely on stability, security, supporting a wide range of devices, and tracking the official Android release schedule as closely as possible. Can someone point me to a ROM like this if one already exists?
- RDaneel0livaw 10y ago
  I was going to point you to the Pure series of roms by Beanstown, but I don't understand your question... You don't want ANY custom stuff at all or features, then what's the point? Just install stock android...?
  - ferbivore 10y ago
    "Stock Android" is only stock Android on Google-branded devices.
    - RDaneel0livaw 10y ago
      I don't understand this sentence. Google only has a single phone that has only been out for like 1 day now, the Pixel. And it's not even stock Android, it's got extra features that the stock Nougat doesn't have. Again though, I think this whole thing is moot, because lots of phones have roms on xda that is basically just stock android with no customizations, so just install that and be done with it.
      - ferbivore 10y ago
        I said Google-branded, not Google-manufactured. The Nexus line is what people typically understand by "stock Android". The point isn't that there are no vanilla AOSP ROMs for most devices. The point is that they usually suck, and a reputable well-supported one that actually worked properly would be a massive innovation.
      - nucleardog 10y ago
evilDagmar 10y ago
You literally didn't need to do any of this (and I'm astonished someone would wait through a CM build rather than do ten minutes of research). Also, I'd like to remind you that SEAndroid (i.e., SELinux) doesn't give a fig about "root" so your statements about that are quite wrong. You can simply rename your su binaries through the recovery environment to disable them, which neatly disables "root access" and makes the SafetyNet check Niantic is invoking pass with flying colors. Should you need them again, they're only a reboot and couple of mv invocations away.
- pwnna 10y ago
  > You literally didn't need to do any of this. For me personally, this is not the reason for me to build CyanogenMod. I will occasionally modify certain things inside android to suit my needs and there are enough of these things that are not merged upstream that it's more convenient for me to just build my own version every month/week/whenever. > Also, I'd like to remind you that SEAndroid (i.e., SELinux) doesn't give a fig about "root" so your statements about that are quite wrong. This is an area i'm not quite informed, so maybe you can elaborate further. The core issue that I wanted to express is that barely any community ROMs are CTS compliant, which is ultimately what SafetyNet checks. > You can simply rename your su binaries through the recovery environment to disable them, which neatly disables "root access" and makes the SafetyNet check Niantic is invoking pass with flying colors. Should you need them again, they're only a reboot and couple of mv invocations away. Doing a bunch of mv's is a hassle (esp over multiple devices) as I rarely ever need root on my phone. The only times when I need it nowadays is host based ad blocking, which I just integrated into my ROM. So this way I can just get rid of root all together, which is one more step towards CTS compliance.
  - xorcist 10y ago
    How do you non-root using people backup your phones, without running the backup software as root?
    - colejohnson66 10y ago
      If you never change any files outside of the ones you own (i.e. the ones owned by "root"), you don't need to back them up, right? For example, if I never touch any of the files under C:\Windows, I have no need to back up that folder (especially the files owned by SYSTEM that you can't access).
lern_too_spel 10y ago
Yes, the author makes the fundamental mistake of thinking that custom ROMs and having root access are the same thing. It is possible to have a custom ROM that does not give the user root access, and such a configuration is more secure for the user.
kyled 10y ago
Root by itself does not break security entirely. Selinux policies and capabilities assigned to binaries can be used to drastically mitigate privileged processes from doing much harm.

by pwnna 10y ago

djsumdog 10y ago

I wrote this about Android a while back: http://penguindreams.org/blog/android-fragmentation/ http://penguindreams.org/blog/android-fragmentation/ The TLDR is that it'd be nice if Android was more like Windows/Intel: install the OS (i.e. AOSP), drivers (or binary driver package format and an SDK to auto-build it) and boom you're done. Clean, stock, standard. Same with many Linux distros on x86/64. I need to write an update to the article though. Lately I've been struggling with a Clearfog ARM board, and coupled with Torvald's recent comments on Intel vs ARM, I wonder if a huge chunk of the problem is ARM itself. I've noticed for every distro there are really specific images, not just for each ARM chipset, but for individual boards, even when those manufacture patches make it into the mainline kernel. I haven't looked closely at Android and I'm really curious at the build system/workflow used by things like Cyanogen and Omnirom. Are kernels really specialized per device? Does the ARM architecture itself make it difficult to have general purpose kernels that will boot on all of them like in the x86/64 world? Any ARM hardware people care to chime in?

cheiVia0 10y ago
Debian is shipping one Linux kernel build that runs on a bunch of different ARM devices that are supported by the mainline version of Linux: https://wiki.debian.org/DebianKernel/ARMMP https://wiki.debian.org/DebianKernel/ARMMP Unfortunately most mobile devices are not supported by mainline Linux (N900 is best supported, but not fully), usually only server/desktop/laptop vendors have any incentive to mainline their drivers.
- voltagex_ 10y ago
  The 2013 Nexus 7 was, at some point, 50 patches away from running mainline [1]. I know, single datapoint, but it gives me hope that there's some way out of the tabletification of computing. 1: https://wiki.linaro.org/LMG/Kernel/FormFactorEnablement https://wiki.linaro.org/LMG/Kernel/FormFactorEnablement
pjmlp 10y ago
It is like the old days of home computers. We had Z80, 6509, 68000 and so so, but everything else that was plugged into their pins was different. So it doesn't matter if the Assembly is the same, the kernel also needs to talk to the hardware. Also ARM just resells the base designs, each company usually adds they own set of Assembly instructions or fine tunes the designs in some other way. The IBM PC clones were the only ones that had some kind of standardization going on, and even that seems to be gone now, with OEMs going to the same kind of hardware designs we used to have (everything bolted on the board).
cheiVia0 10y ago
Some related posts: https://cascardo.eti.br/blog/GNU_on_Smartphones_part_II/ https://cascardo.eti.br/blog/GNU_on_Smartphones_part_II/ http://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/ http://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/ https://wiki.debian.org/Mobile https://wiki.debian.org/Mobile
exDM69 10y ago
> Any ARM hardware people care to chime in? It's not really about the CPU architecture, but the peripherals of the devices. In the x86 world, the peripherals are governed by the "PC" standard, which these days is implemented by the chipset on your motherboard. They all have similar functionality, although you still do need some chipset-specific drivers in your kernel. In the ARM world, the landscape is different. There has never been a de facto standard configuration of an ARM computer like the PC was/is for x86. There are ARM computers that are more like a micro controller and there are tablet/mobile devices based on ARM that have a system on chip (SoC) that's got all the peripherals, including GPUs, network adapters, etc. Every SoC is pretty different, there's a bunch of devices connected with i2c, spi and other buses. These are required to control the power and clock management and all the I/O devices. ARM (the company) doesn't really design these, they just license ARM (the architecture) to a SoC manufacturer and call it a day. This leads to a very diverse and fragmented landscape. The ARM world has been making strides to reduce the amount of chip-specific code. One good example is the device-tree configuration which, in theory, allows running the same kernel binary on different devices. With device-tree, you pass a config file from the bootloader to the kernel, which contains configuration (i/o memory maps, etc) of the peripherals (which you'd query from the hw/firmware in a x86 machine). This is a huge improvement over what was before it, but there's still a long way to go. And there's still plenty of older ARM SoCs out there that don't support this. But yes, it's pretty much a mess. There's a lot of duplicate work that every ARM SoC manufacturer has to go through. Given that the mobile world is financed by a planned obsolescence cycle where they expect customers to upgrade every few years, I find it unlikely that this issue will be solved any time soon.

tedmiston 10y ago

They've gotta stop the GPS spoofers somehow. It's not like this was the first solution they jumped to to stop cheaters. Maybe this was the 80/20 solution over more advanced location anomaly detection methods against their database.

lini 10y ago
The problem is that you don't need root for GPS spoofing. Botters also don't care about SafetyNet (used to detect root before the game starts), since they reverse engineer the API and make REST calls directly. Furthermore, there are ways around the root check - mostly involving hiding the su binary and some additional tweaks.
- deanclatworthy 10y ago
  Furthermore, you can buy GPS spoofing devices anwyay which you can just carry around with you in your pocket.
  - foota 10y ago
    To be fair, that's probably highly illegal if caught by the fcc.
    - seszett 10y ago
      The FCC only has business in the US though.
      - lucb1e 10y ago
        Almost every country has something like that. The Dutch Agentschap Telecom will hunt you down for transmitting a fake GPS signal too. The thing is, nobody cares if you send a signal too weak to go beyond a meter of your pocket. That's why it's totally legal to send FM on registered frequencies as long as your output is under a certain amount. Same with WiFi even. I heard about someone looking into GPS spoofing once in the context of catching drones, even nearby ones (e.g. fly near to it). It takes a lot of energy to do that and was basically not practical outside of military settings.

tombrossman 10y ago

> I personally got around this problem by compiling a build of CyanogenMod without root enabled, but with things like FDroid (with PrivilegeExtension) and adblock built-in to the ROM itself... I just bought a Nexus 5x and loaded CopperheadOS on it, and to my dismay I see Ad-Away from F-Droid requires root to function (plus a couple other apps I really like). How much of a hassle is it really, because I absolutely want system wide ad blocking and I worry that I will be defeating the purpose of using a hardened OS in the first place? Do you rebuild and flash each OS update as a new ROM? Is all your data on the phone persistent or backed up & restored each time?

pwnna 10y ago
> How much of a hassle is it really, because I absolutely want system wide ad blocking and I worry that I will be defeating the purpose of using a hardened OS in the first place? Ad-away works by using a host file to block. The hosts file is generally not writable by the user without root as it lives on a read only partition (/system). Another way to block ads is to connect to a VPN that blocks thoses hosts for you, however that is more cumbersome to setup. While hosts blocking is not perfect... my thought on this was to expose a limited API that allows apps to update the hosts file without having root. This could be sketchy and a security risk on its own tho, because you're essentially hijacking DNS... In addition, I don't think the community is interested in this because they all love root.. > Do you rebuild and flash each OS update as a new ROM? Every month, immediately after the security bulletin and a resync. > Is all your data on the phone persistent or backed up & restored each time? So android has a /system partition and a /data partition. When you reflash your system, the data partition (where all your apps, settings, what not are stored) is left untouched. Android will detect this and perform an upgrade operation on the /data partition, if applicable.
- nradov 10y ago
  Apple added specific ad blocking features to iOS 9, and I don't think those rely on editing the hosts file. So in principle a similar design could work for Android, although I doubt Google would ever support that.

legulere 10y ago

A few botters don't hurt Pokémon go. But when it's easy to bot, lots of people will bot. It's easy to circumvent anti root, but it's impossible to use the same way for lots of devices without niantic being able to block it again. So it really makes sense for them to go this way IMO.

Drdrdrq 10y ago
Not really. It doesn't matter if the phone is rooted or not, what matters is whether it is feeding false gps data or not. Bots will soon find a way around this (non-rooted) restriction anyway. That said, proper protection against cheating would involve using markers (other phones?) in vicinity, so it should be possible too.
- rickyc091 10y ago
  Yes, bots will most likely always find a way, but I think it's more about thwarting the casual users. If you could gps hack by simply installing an app more people would do it. By making it extremely tedious, the causal user won't be as inclined to do it since the time it takes to figure it out won't be worth it. I don't condone Niantic's behavior, but I understand it.
  - mynameisvlad 10y ago
    To me, it would make more sense if they weren't also banning users their auto-detection system thinks are spoofing GPS. A system which is fairly overzealous, might I add. I was banned for being in Japan, for example. One day out of the blue on my vacation, got the ToS violation notification which still hasn't been reversed, two weeks later.
- evilDagmar 10y ago
  The spoofers have had a way around this for some time now, as GPS spoofing simply does not require root privileges. Niantic is not actually making any attempt to look for GPS spoofing software. They simply invoke Android's SafetyNet which doesn't care about GPS at all but does care about other things which happen to coincide with what's on some cheater's phones. It will never be anything like an effective measure against GPS spoofing.

on_and_off 10y ago

> This is not a solution for the mass majority of users. root is not used by the mass majority of users.

lewisl9029 10y ago

I honestly would be very happy with a ROM that copies stock Android entirely, without any added features or customizations, rather focusing solely on stability, security, supporting a wide range of devices, and tracking the official Android release schedule as closely as possible. Can someone point me to a ROM like this if one already exists?

RDaneel0livaw 10y ago
I was going to point you to the Pure series of roms by Beanstown, but I don't understand your question... You don't want ANY custom stuff at all or features, then what's the point? Just install stock android...?
- ferbivore 10y ago
  "Stock Android" is only stock Android on Google-branded devices.
  - RDaneel0livaw 10y ago
    I don't understand this sentence. Google only has a single phone that has only been out for like 1 day now, the Pixel. And it's not even stock Android, it's got extra features that the stock Nougat doesn't have. Again though, I think this whole thing is moot, because lots of phones have roms on xda that is basically just stock android with no customizations, so just install that and be done with it.
    - ferbivore 10y ago
      I said Google-branded, not Google-manufactured. The Nexus line is what people typically understand by "stock Android". The point isn't that there are no vanilla AOSP ROMs for most devices. The point is that they usually suck, and a reputable well-supported one that actually worked properly would be a massive innovation.
    - nucleardog 10y ago

evilDagmar 10y ago

You literally didn't need to do any of this (and I'm astonished someone would wait through a CM build rather than do ten minutes of research). Also, I'd like to remind you that SEAndroid (i.e., SELinux) doesn't give a fig about "root" so your statements about that are quite wrong. You can simply rename your su binaries through the recovery environment to disable them, which neatly disables "root access" and makes the SafetyNet check Niantic is invoking pass with flying colors. Should you need them again, they're only a reboot and couple of mv invocations away.

pwnna 10y ago
> You literally didn't need to do any of this. For me personally, this is not the reason for me to build CyanogenMod. I will occasionally modify certain things inside android to suit my needs and there are enough of these things that are not merged upstream that it's more convenient for me to just build my own version every month/week/whenever. > Also, I'd like to remind you that SEAndroid (i.e., SELinux) doesn't give a fig about "root" so your statements about that are quite wrong. This is an area i'm not quite informed, so maybe you can elaborate further. The core issue that I wanted to express is that barely any community ROMs are CTS compliant, which is ultimately what SafetyNet checks. > You can simply rename your su binaries through the recovery environment to disable them, which neatly disables "root access" and makes the SafetyNet check Niantic is invoking pass with flying colors. Should you need them again, they're only a reboot and couple of mv invocations away. Doing a bunch of mv's is a hassle (esp over multiple devices) as I rarely ever need root on my phone. The only times when I need it nowadays is host based ad blocking, which I just integrated into my ROM. So this way I can just get rid of root all together, which is one more step towards CTS compliance.
- xorcist 10y ago
  How do you non-root using people backup your phones, without running the backup software as root?
  - colejohnson66 10y ago
    If you never change any files outside of the ones you own (i.e. the ones owned by "root"), you don't need to back them up, right? For example, if I never touch any of the files under C:\Windows, I have no need to back up that folder (especially the files owned by SYSTEM that you can't access).

lern_too_spel 10y ago

Yes, the author makes the fundamental mistake of thinking that custom ROMs and having root access are the same thing. It is possible to have a custom ROM that does not give the user root access, and such a configuration is more secure for the user.

kyled 10y ago

Root by itself does not break security entirely. Selinux policies and capabilities assigned to binaries can be used to drastically mitigate privileged processes from doing much harm.