Hacker News Reader

It never ceases to amaze how malicious manufacturers can get, installing so many anti-features, without breaking some law and going to jail.

Imagine if a real-estate agent kept breaking into houses he sold (through extra doors only he has the key to), and when people complained, he'd point to some fine print on page 23 of a contract you didn't even sign - it was just posted on the door, after you bought the house, stating that entering the house constitutes agreement.

There'd be a million laws against it in a heartbeat.

Even companies that used to be considered trusted by most people are doing it --- just look at Windows 10 for example... full of ads and telemetry which are nearly impossible to disable, thanks to that backdoor known as "Windows Update" which can easily revert all your changes (and is itself Hydra-like to disable.)

Until data storage becomes recognized legally as a kind of real property, your outrage won't matter. Most law is concerned only with computers as an extension of simpler technology, and the data as IP. There isn't any concept of people's "lives" being on these devices.

IANAL, but I've always wondered if one good way to approach this is as a "micro-theft" of user resources. Specifically, network bandwidth, battery capacity, and screen size.

An additional theft, which is your attention, can also be priced according to "the market", and indeed, if an ad obscures another sites ad then there is, in fact, another (large) set of people the manufacturer is stealing from. Moreover, that last class of people have some powerful advocates in the way of the networks, to wit, Google. But this theft is less straight-forward, I think.

I would argue that the most important theft, which is your right to be secure in your computer mediated dealings, is hardest to argue. But that's there, too.

It's entirely possible that this theory has already been tested, and lost, in US courts.

Without touching on legality of such things, it's interesting also in that these things probably have have a very clear record dollar amounts involved for such an act in terms of revenue generated, CPMs for ads, etc.

This scene from Office Space comes to mind.[1]

[1]https://www.youtube.com/watch?v=yZjCQ3T5yXo

There's already lots of laws against breaking into computer systems - they just don't get applied if the one doing the breaking-in made the device.

Your outrage won't matter once a law even does exist. Do you really think China is going to give a shit about some Western law? Lol.

And in my case the backdoor (Cosiloon) wouldn't do anything if the tablet was in China (don't remember how it detected the country, maybe by IP address or language).

It is illegal and does break laws, but the enforcement of laws is very selective, and is usually limited to a single device. So, even if you were to sue the manufacturer, and win the case, the worst that can happen to the manufacturer is a slap on the wrist fine and the device being barred from selling in that country. Which is ridiculous because devices are sold for a few months, the cheaper ones even less, and are quickly replaced by newer models. The fines are offset by the revenue in selling user data and also direct payment for inclusion of third-party apps in the phone's OS image.

> the worst that can happen to the manufacturer is a slap on the wrist fine

Maybe that's the worst that does happen, but, when an individual hacks someone, they do jail time.

I get your point and I agree with you, but to be fair, spotting a physical backdoor would be a little easier than a software one, and I think that’s why there are no laws against it—people have no idea this is happening.

But once those backdoors are found and reported, nothing happens. Unless you're a regular schmuck who 'hacks' by guessing a URL - then you get raided by the FBI and do hard jail time [1].

[1] https://en.wikipedia.org/wiki/Weev#AT&T_data_breach

I'm more impressed in how much effort they do and money they spent to be able to put ads.

Amazon sells a Kindle with ads on the lockscreen. Is that malicious?

I share your concern and findings.

Famously, Nokia (HMD Global), also had apps that could perform such functions, developed by Evenwell Digitech Inc. I wrote about it here -- https://news.ycombinator.com/item?id=17329825, though it didn't gain much traction for a while.

In the end, Nokia (HMD Global) appologised, and said that the apps were mistakenly included in global phone versions (they're supposed to be China-only), but they are being investigated by the Finnish DPO. -- https://uk.reuters.com/article/uk-finland-telecoms/finland-t...

The Nokia phones you investigated [0], were they on Android One?

[0] https://news.ycombinator.com/item?id=19449824

No. Officially, no (i.e. not branded as such).

When people buy a cheap Android phone, I always recommend that you take a look at the xda-developers form [1] to see if there is a custom rom available.

For some cheap phones even without the backdoor the some system components are unstable leading to a subpar experience.

[1] https://forum.xda-developers.com

Did anybody have a look at those custom ROMs, with sources from random repositories, modified by anonymous people, build on public build servers, distributed on random file hosting services?

Are they trustworthy?

The community is not stupid, it only takes one person to find out and tell everyone, and then the one doing it gets quickly ostracised.

The centralised (corporatocracy) version of "trust" that is prevalent today one of the biggest obstructions to freedom IMHO.

This is what I like about LineageOS. I may not have the time or inclination to build it myself, but it's "open enough" to meet my standards, especially compared to the closed ROM supplied by my phone's manufacturer (OnePlus, FWIW).

I'm not implying they are, my question was honest. I once tried to see where the binary ROM actually came from, and met an astonishing lack of information. Granted, it's a model that isn't really supported.

But it felt that the community is far away from having plausible sources and builds.

I can understand that ultimately this begins with kernel sources that are already just a ZIP archive on some website.

> Are they trustworthy?

Most are, yes, and the community is pretty good at pointing out the ones that aren't.

But the real question is are they any less trustworthy than Google itself and the phone manufacturers? From what I've observed, they are more trustworthy that that crowd.

Note that a custom rom will only get you "don't tell my roommate" levels of safe and secure, not "please don't inform foreign governments" safe. Backdoors can (and probably do) exist in bootloaders, recovery firmware, drivers and so on.

A lot of roms require you to use TWRP as a recovery. So that's where you get your recovery.

Most ROMs are based off of either AOSP or lineage. The list of unofficially supported devices is huge. Since, most devices share the same SOC's they're usually just forked off of each other with gradual tweaks. The Sony open device project is semi supported by sony but doesn't share any code with the stock images.

So, that really just leaves the bootloader. How much attack surface does the boot rom actually provide? I feel like most vendors would probably just assume a backdoored system or boot partition. Your boot rom would have to accommodate for all kinds of potential Android versions. It sounds like a lot of effort for a corner case so not really worth the effort.

Just to clarify, not many ROMs require a specific recovery, they simply expect certain functionality for updates. You can use many other forks of TWRP, which include backwards compatibility, without issue.

RedWolf [0] and OrangeFox [1] are both forked from TWRP and provide more features than upstream. Cyanogen and Lineage recovery are based on AOSP, again, with more features than upstream.

[0] https://redwolfrecovery.github.io/

[1] https://orangefox.tech/

How's the device support with those recoveries you linked?

It's very limited, definitely. Usually limited to a few devices that people specifically build for.

Don't forget all the binary blobs you need to get full functionality, the monstrous size of the codebase (and corresponding attack surface), the baseband processor, etc.

Also, don't get me started on the terrible security hygeine of the actual ROM distribution practices.

Yep. I had a Nomu S10 which got a Triada infected OTA (!) from the manufacturer.

For those unfamiliar with this: Triada, and it's relatives infect zygote, the java bootstrap system on Android. From there on rooting on it's own can't help, because the process binary is changed, so unless you can replace it with an uninfected one, it's gone. If there are ROMs out there without the infection, flashing helps.

It's also kind-of not fair to blame only the brand/manufacturer, they are complicit -- yes -- but no the only party to blame.

I work for a company that, in between other things, develops and sells Android devices (TVs, tablets, phones, watches, etc.)

We buy a design from a Chinese developer, customize it, add apps and other "value-add" bulls*it, and then import the manufactured products and sell them.

The problem is, we recently found malware in the OS images which were provided by the manufacturer/developer, and traces back to Mediatek themselves, but we were not made aware of it. On request, the developer removed the malware and we sent an OTA to all devices of most models that removes the malware.

The point I'm making is that in many cases, the backdoors and spyware aren't even provided by the company that sells the phones, they are usually secretly put in much closer to the actual manufacturer/developer of the device and/or SoC.

>It's also kind-of not fair to blame only the brand/manufacturer, they are complicit -- yes -- but no the only party to blame.

I blame the manufacturer for two reasons. First, because they're the highest level in the chain that's likely to have any knowledge of this stuff.

Second, because they're the one selling it to consumers, and they have a responsibility to their customers to perform due diligence regarding the software they're including with the device.

If batteries start exploding, the device manufacturer can't just throw up their hands and blame their suppliers. The same is true of software. Yes, that probably means accepting huge binary blobs from the ODM or SoC manufacturer puts the company selling it at risk. They can choose to accept that risk, or they can demand better. They have a whole lot more influence on the process than us consumers do.

(There are precious few options for consumers. I'm holding out hope for the Librem 5 and PinePhone here.)

Okay, that is a fair point. In the EU, thankfully, we have laws that protect consumers from such incidents, including malware and faulty software, and the party selling the device is the responsible one, no matter what the EULA/TOS/LOL/etc. say.

I blame automatic OTA, not the manufacturer. There should be rigorous virus scanning of each OTA before sent to the customer and even then it shouldn't be allowed to be automatically installed.

Google actually serves the OTA for most devices, meaning they can "see" and check for malware. The files are stored on and downloaded from their serves. Given the "rigorous" testing the apply to devices before they get Google Play certification, I assume they could revoke the certification remotely if malware is detected in an OTA, or even reject the OTA binary.

Seriously, Google should act more harshly on those devices, to the point of making them lose their Google Play certification and trigger a SafetyNet non-compliance..

This kind of shit shouldn't fly.

I don't think that cheap tablet had any certification, but it had Google Play.

> I examined a cheap Android tablet's ROM dump

Can I ask how you did this? Did you have to physically remove the ROM from the board and read it with some sort of chip reader? Or is there an interface to read the ROM into a dump without any damage to the board

Honestly, the easiest way is to simply download the ROM or a full non-delta update from manufacturer, unpack it, and start decompiling.

Another option if you are able to unlock the bootloader is, using a custom recovery, to create a tarball of each partition and unpack and start decompiling.

I found suspicious application (with name like ePlayService or eVideoService, don't remember exactly) in app list, then connected using ADB and examined the filesystem, and decompiled suspicious packages. Then I downloaded ROM from manufacturer's site to make sure that the backdoor was there too.

Also I checked signatures on applications to exclude unmodified third party apps like Youtube and check only those with unknown signatures. This is where I found that the manufacturer signed their system applications using publicly available Android test key (which means device is vulnerable because anyone can make an app signed with that test key and gain high privileges on device).

Also, some chipsets (like MediaTek) allow downloading storage contents to PC using proprietary Windows application.

Huh, I'm surprised that manufacturers of cheap android even bother providing downloadable firmware,I might pick up a cheapo android and play around with it.

Honestly curious, how would one examine their phone's ROM dump? Asking as a non-expert on this here.

It is often available for download at the manufacturer's site. In my case, I first connected to the tablet using ADB and examined files in the filesystem, found suspicious packages, decompiled them and later checked ROM dump to verify that the backdoor is pre-installed.

Some chipsets (like MediaTek) support "uploading" data from device storage to PC using a proprietary Windows utility and USB cable.

> using ADB

...Presumably that's not the very-obsolete Apple Desktop Bus, but what ADB is this?

The Android Debug Bridge

https://developer.android.com/studio/command-line/adb

Thanks! I've seen the abbreviation a few times before and been a bit puzzled.

ADB is a CLI tool made by Google [1]. You download the tool and Windows driver from Google, then you edit USB VID/PID in driver's config so that it matches your device, then you install drivers, conenct device using USB and use adb command line tool.

[1] https://developer.android.com/studio/command-line/adb