Android emulator abused to introduce malware onto PCs | Hacker News Reader

Android emulator abused to introduce malware onto PCs

blog.malwarebytes.com

116 pointsmiles42 comments

I knew nox has been adware for a while and I'm surprised it's still being used. Literally go to r/noxappplayer and you'll see most of the top posts are about it being malware. If anyone's need a good android emulator, genymotion is probably the best and it's free for personal uses https://www.genymotion.com/fun-zone/

99% of games I play doesn't run on genymotion, shows "your device isn't compatible with this version". Some say it's because they don't emulate ARM CPUs. Anyway around it?

Edit: I tried the ARM translation tool on Android 7.1/8.0, it's better now but still have lots of games don't work. I guess I have to stick with Nox/LDPlayer etc. for now since they just work. Don't know how they achieve it.

I would like to know as well.

I'd suggest trying MSI's app player. It should play everything, but it's not as granular controlled as LDplayer. Based on Bluestacks

Bluestacks seems to be more aimed at gaming emulation. Genymotion is meant to be used for development.

What does "literally" mean here?

It is a way to catch trolls.

Why do you think genymotion is probably the best? I've compared genymotion and the Android Studio's default emulator, and found Genymotion to be buggy and has fewer features. Have you compared them recently, or are you speaking with older experience? There has been a lot of development and optimisation for the Android Studio emulators.

I guess we're not both Android developers, and you use the emulator for gaming?

Genymotion seems to be fine from me, I don't remember having zero bugs from my experience. However as you pointed, yes I'm speaking from past experiences from like 5 months ago. I know that android studio has an emulator but I remember it being more suited for development than personal gaming compared to genymotion

Nox has been known to be adware and there are multiple guides on creating firewall rules so it doesn't phone home or update. I wouldn't be surprised if the developers themselves did this on purpose for monetary gain, if I remember correctly Nox's subreddit hates them already.

ESET's article has more details, and also a list of files to check if you happen to use Nox: https://www.welivesecurity.com/2021/02/01/operation-nightsco...

Doesn't Google give out a free Android emulator?

It is incredibly nonperformant. Even with HAXM. Developers use real devices. This is marketed for people who want to run android games on their PC.

I recently tested Android Emulator [1] on Apple M1 computer and it is finally a performant emulator from Google. I can finally use android emulator on my computer for development.

[1] https://github.com/google/android-emulator-m1-preview

Not to mention testing a mobile app with a mouse is... well, not the intended use case, to say the least.

Android app dev since 10 years here - performance is absolutely fine. I have it running all the time. Granted, performance was abysmal before the accelerated Intel images, but that was many years ago.

Devs complaining about Android emulator performance usually have problems with their setup, common culprits: Not enough ram (it is a VM in the end), slow machine (eg. MacOS is bad for Android dev), broken VM acceleration (AMD was a problem for a while IIRC).

Accelerated intel images require you to be running an Intel Android install, not ARM like the vast (>95%? 99%?) majority of devices. We had a bug around the byte-size of "long" that only showed up on real hardware.

Speaking from experience, unless one has a desktop gaming rig, Android development is plain awful.

Only doing WebSphere 5 with RAD comes close as bad experience, and even in 2005 it was faster than doing Android builds.

Also the emulator is unusable for any kind of graphics programming testing.

Performance is perfectly fine as long as you pick an image with your computer's native instruction set and have hardware acceleration. Performance through QEMU (ARM on x64, x64 on M1) is terrible, of course, but that's to be expected with software instruction translation. With proper acceleration (which may be unavailable on Windows without some tweaking, even after installing HAXM!), Android will run similar to a standard Linux VM, at near native speeds.

One problem I've run into has been that Android relies heavily on GPU acceleration. If that's unavailable on your platform (because, for example, your driver is considered buggy by the emulator devs (common on Linux with proprietary drivers) or if all you've got is an integrated Intel GPU that already has its hands full rendering to your 4k screen), your experience will be terrible with any Android emulator. Android with software rendering won't be a bit slower and choppier like you see in desktop VMs; it will be absolutely unusable for anything but a cursory check to see if the software even runs at all.

There's also the addendum that many Apple products sporting an Intel CPU have had their power/performance curve and fan curves tweaked to be silent and super performant in short loads (compiling a single file, opening a browser, loading a page, etc.) but clocking down hard and long if you run a sustained load on them, especially with a multi core load. This can make a system that normally feels snappy and fast run terrible slow with an emulator. Similar problems also exist with cheap netbooks that just have insufficient cooling on the processor. I do believe the M1 designs are better suited for sustained loads, so with the new Apple stuff this problem should be gone.

When I was still running the emulator off of a hard drive, performance was severely lacking because Android is not built with HDD seek times in mind, but after switching to an SSD that quickly became irrelevant.

In my experience, running Android on a 12 core i7 with an NVMe SSD is actually running the entire system way too fast for a realistic development experience. Your average dev machine is much faster than whatever your customers will most likely be running your code on, so you still absolutely need to test on real devices.

Emulators are great for debugging because you get to test in an environment with close-to-stock Android (so you don't accidentally write code that only works on Samsung or on Pixel), but for performance and usability testing you need a physical device.

That said, I don't think running the Android dev emulator to play games is very efficient. It'll work and perform absolutely fine, but there's been no effort put into making controllers work or into optimizing controls for desktop.

Most shops have i5 and i7 laptop devices with 8GB, so....

Some of these emulators support binding keys to click certain points (and even bind WASD to a directional pad), which is pretty nice for certain games. One could probably write AutoHotkey scripts to do the same thing, but it's just more convenient to have it built in.

I haven't used AVD to play games before, but while installing a game to test I noticed that it's using 1.3GB instead of 300MB consumed by the other emulator I use (MuMu). I can imagine that mattering for some players.

Edit: These emulators are also somewhat convenient for some mobile game developers, who can package them up with their game to create a PC installer. As far as I know you can't package up AVD like that.

The article's focus on it being an emulator feels misleading. They compromised an auto-update feature, it can happen to any software that offers updates. Even manual updates.

Feels clickbaity. I was interested because this implied they somehow broke outside both Android's sandbox and the emulator's hypervisor but nope, it was way more mundane (but not less severe of course). The magic is in not knowing.

it's 2021. updating apps should not be something every developer has to write themselves. it should be part of the operating system, separate from the app stores...

I'm not entirely sure what you mean by "part of operating system, separate from the app stores", but in this case a server was delivering tainted updates, so having an OS-based update mechanism/package manager by itself wouldn't have prevented this. Unless you also mean that this update should have gone through the OS's repositories (which I feel is close to app store).

A quick search showed compromised packages in arch aur repos: https://www.bleepingcomputer.com/news/security/malware-found...

You only change the focal point, but a centralised package manager is good for reasons other than security. Sure, a central tool will keep your whole system updated and improve security overall, but it won't prevent supply-chain attacks from happening.

Reading mailing lists and being careful with what you install will take you a long way in preventing malware.

I trust packages that comes from official repositories.

> Warning: AUR packages are user produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.

In other words AUR is not much safer than `curl to | sh`.

Sure, but it is centralised in the os distribution package manager, if you use helpers like yay. I am just pointing out that centralisation is not solution to the attack mentioned.

I assume AUR includes hashes, which could at least hint to deterministic builds. `curl to | sh` can change from build to build and there's no way to find out from which source other users built.

This is one of the biggest advantages of linux.

Security by obscurity?

https://www.bleepingcomputer.com/news/security/malware-found...

Imagine how many more attacks there would be if Linux was much more popular.

The AUR isn't officially supported by Arch, it's just a collection of community scripts. In fact "AUR helpers" aren't present in Arch repos.

It is only used in ~80% of some of the most valuable targets on the internet, the servers, and it is only by far the most used operating system with more than 50% compared to the huge target that is the ~15% that is Windows. Security by obscurity is more fitting for Windows than Linux. Imagine how many more attacks there would be if Windows was much more popular. Windows in on par with iOS. Stop being a troll.

https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...

>it is only by far the most used operating system with more than 50%

So you're counting Android as Linux, that means Linux has a big malware problem right? Or do you only count Android to pad Linux's numbers and then discount Android malware?

Servers are managed by relatively much more tech savvy folks who install programs carefully. Not so much on PCs that aren't locked down like iOS, and where there is developer freedom.

iOS is only more secure than Windows at the cost of developer freedom, sad to see people on a techie site praise iOS and insult Windows based on that.

Anyone can upload stuff to the AUR, so it's only to be expected that there's some malware there. At the very top of the wiki page for the AUR[0], it warns:

> Warning: AUR packages are user produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.

If you want to stay malware-free and aren't able to vet the packages you're installing, just stick to the official repositories and you'll be fine. This page[1] documents the role of each official repository, and this page[2] is a list of the people who can modify the official community repository.

[0]: https://wiki.archlinux.org/index.php/Arch_User_Repository

[1]: https://wiki.archlinux.org/index.php/Official_repositories

[2]: https://archlinux.org/people/trusted-users/

The repos are basically an App Store. The only advantage is you can add multiple repo sources.

Kinda like f-droid

It is, but then you come to places like HN and everyone is bashing against App Stores.

The problem lies in Unix/Windows style app packaging, or lack thereof in Unix as originally conceived. /etc, /usr, and so on.

Exactly like what I thought. Any connected devices (via USB cable, WiFi, the Internet, etc) can be a (potential) vector (Postulate 1).

You've misunderstood the article. The vector has nothing to do with "connected devices".

The vector is like a mosquito, attack vector. Here software updating infrastructure is a kind of that, connected with your emulator and PC via the Internet.

Reply on news.ycombinator.com