The secret behind “unkillable” Android backdoor called xHelper has been revealed | Hacker News Reader

The secret behind “unkillable” Android backdoor called xHelper has been revealed

arstechnica.com

>Triada gives them an immutable attribute, which prevents deleting, even by superusers. (Interestingly, the attribute can be deleted using the chattr command.)

Interesting if you've never used chattr I guess

If its contacting the server after infecting, Why is it hard to track the owner of dns address or the ip owner since running a server is impossible without the leaving a trail to real world id.

It's a terrible design to make a "factory reset" that leaves an entire partition completely intact, and to compound the problem by attempting to paper it over with regressive DRM. The obvious good design is to simply rewrite the entire flash image over USB, but apparently that was just too straightforward for Android.

The especially frustrating thing about bespoke special/hidden state is that it doesn't straight up fail hard enough to get scrapped, but rather causes ongoing pain for the lifetime of the implementation. Every additional bit of unnecessary complexity is another layer of knowledge and "tricks" that someone needs to know to competently maintain a device.

Leaving the partition during a reset is fine if you hash all the contents of the partition and check it matches a known good factory config. If it doesn't, download whatever files are needed to make the hash match.

Androids file signatures stuff is so close to achieving this - I think they'll finally implement it within a year or two, and that will finally allow reclaiming space when built in apps are deleted or upgraded while keeping the ability to factory reset.

You're really just describing a bespoke scheme to create an ad-hoc good image. It's much simpler (and therefore secure) to just do a bit-for-bit full image copy.

Hashes etc are the DRM direction I was talking about. A continuing push to lock phones to some remote root of trust under the guise of security, while making them tougher to actually secure by making them less transparent.

True, but the image approach requires special equipment (a usb stick, fast internet to download many gigabytes, and/or a usb otg adapter).

That makes it inaccessible for most users.

That same "special equipment" required to charge the phone - a micro USB cable.

Where downloading a 1GB image or needing an actual computer is prohibitive (eg the developing world), then community will fill the role. If the user really just wants to delete their own data, then rename the current feature to something appropriate rather than the current misleading "factory reset" that doesn't actually do a factory reset.

It's generally fallacious to say that a higher layer needs to be created to make things more "accessible", when that new system just addresses one specific case and punts on most other issues. Taking systematic feedback into account, people not needing a JTAG interface for most phone flashing actually creates a problem whereby these devices get into states that require now-specialized tools and now-arcane knowledge, rather than having been designed as legible/transparent/user-serviceable up front.

3rd-party recovery images (TWRP, ClockworkMod, ...) offer an option to "format" or "wipe" (mkfs, really) the /data partition. This should be much closer to what you seem to be expecting from a "factory reset".

Well TWRP can only erase. What you want is fastboot/heimdall/etc flash all partitions from a stock image, to restore everything [0] to a known good state.

I know enough to do this, but obviously most people think a "factory reset" is sufficient. That is a problem - defaults matter.

[0] modulo further hidden state that I am not aware of or in touch with. For example my S4-i9500's emmc firmware which got corrupted somehow and bricked the device.

> Well TWRP can only erase.

No? TWRP can flash images to any partition you like iirc. has an ADB sideload feature too... Or am I misunderstanding?

Yes TWRP can flash any (non-recovery) partition. But I was thinking in terms of being able to flash the entire device, which TWRP "can't" do because it uses data on the device itself as the source image. More importantly, malware could modify the recovery partition to reinstall itself after such flashing.

If libc.so is infected, wouldn't it be possible to create a statically linked cleaning program that directly uses syscalls to talk to the kernel?

Makes you wonder what happened to the first nine helpers.

Reply on news.ycombinator.com