Webserver Runs On Android Phone

Android, the popular mobile phone OS, is essentially just Linux with a nice user interface layer covering it all up. In theory, it should be able to do anything a normal computer running Linux could do. And, since most web servers in the world are running Linux, [PelleMannen] figured his Android phone could run a web server just as well as any other Linux machine and built this webpage that’s currently running on a smartphone, with an additional Reddit post for a little more discussion.

The phone uses Termux (which we’ve written about briefly before) to get to a Bash shell on the Android system. Before that happens, though, some setup needs to take place largely involving installing F-Droid through which Termux can be installed. From there the standard SSH and Apache servers can be installed as if the phone were running a normal Linux The rest of the installation involves tricking the phone into thinking it’s a full-fledged computer including a number of considerations to keep the phone from halting execution when the screen locks and other phone-specific issues.

With everything up and running, [PelleMannen] reports that it runs surprisingly well with the small ARM system outputting almost no heat. Since the project page is being hosted on this phone we can’t guarantee that the link above works, though, and it might get a few too many requests to stay online. We wish it were a little easier to get our pocket-sized computers to behave in similar ways to our regular laptops and PCs (even if they don’t have quite the same amount of power) but if you’re dead-set on repurposing an old phone we’ve also seen them used to great effect in place of a Raspberry Pi.

Android-Powered Rigol Scopes Go Wireless

The Rigol DHO800 and DHO900 series use Android underneath, and as you might expect, this makes them easier to hack. A case in point: [VoltLog] demonstrates that you can add WiFi to the scope using a cheap USB WiFi adapter. This might seem like a no-brainer on the surface, but because the software doesn’t know about WiFi, there are a few minor hoops to jump through.

The first issue is that you need a WiFi adapter the built-in OS already knows how to handle. The community has identified at least one RTL chipset that works and it happens to be in the TP-Link TL-WN725N. These are old 2.4 GHz only units, so they are widely available for $10 or less.

But even with the correct hardware, the scope doesn’t have any menus to configure the WiFi interface. To solve that, you need to temporarily use a USB hub and a USB keyboard. Once you have everything plugged in, you can use the Super + N keyboard shortcut to open up the Android notification bar, which is normally hidden. Once you’ve setup the network connection, you won’t need the keyboard anymore.

Or maybe not — it turns out the keyboard does allow you to change a few other things. For example, [VoltLog] used it to increase the screen brightness more than the default maximum setting.

The only other issue appears to be that the scope shows it is disconnected even when connected to WiFi. That doesn’t seem to impact operation, though. Of course, you could use a WiFi to Ethernet bridge or even an old router, but now you have a cable, a box, and another power cord to deal with. This solution is neat and clean. You bet we’ve already ordered a TP-Link adapter!

WiFi scopes are nothing new. We suspect Rigol didn’t want to worry about interference and regulatory acceptance, but who knows? Besides, it is fun to add WiFi to wired devices.

Continue reading “Android-Powered Rigol Scopes Go Wireless”

Android: Coming Soon To A RISC-V Processor Near You

In the roughly decade and a half since the Android mobile operating system appeared on the scene it has been primarily sold on devices with an ARM core at their heart, but along the way it has also appeared for other architectures. If you had a MIPS Android phone you may have been in the minority, but Intel phones enjoyed some popularity, and the up-and-coming new kid in the world of Android is RISC-V. For anyone interested in this last architecture it’s worth looking at the Google Open Source blog, in which they’ve published an overview of the current status of the project.

In short, it’s full steam ahead — as the development environment and emulation is in place for RISC-V Android. It’s certain we’ll start seeing RISC-V phones on the market soon, but perhaps that’s not the part which should interest readers the most. Over the last decade we have seen an explosion of inexpensive ARM single board computers, and though some of them such as the Raspberry Pi owe their heritage to set-top-box SoCs, it’s fair to say that a strong driver for this trend has been the proliferation of powerful mobile chips. A take-up of RISC-V driven by Android would mean a similar explosion of powerful SoCs with those  cores, leading we hope to much more accessible and powerful RISC-V computing. Sadly we expect them to still come with proprietary peripherals leading to plenty of closed source blobs, but we can’t have everything.

If you’d like to read more about the whole blob situation and RISC-V, we’ve got you covered.

DOOM On IPhone OS, On Android

So you want to play some games from the early days of 32-bit iPhone OS that no longer run on recent OS versions? [Hikari-no-yume] wrote a sweet high-level emulator, touchHLE, to do so on modern iOS phones. But maybe you don’t have an iPhone? [Ciciplusplus] has your back. He ported the iPhone OS emulator, written in Rust, to Android, and then ported a version of DOOM that runs on iPhone OS to go with it.

[Ciciplusplus] also made a video (embedded below) where he documented the trials and tribulations of porting Rust code to the Android platform – an intensely Java environment. It doesn’t sound like it was at all trivial. Of course, this couldn’t have been accomplished without [Hikari-no-yume]’s original work on touchHLE, which was made essentially to fulfill [Hikari-no-yume]’s long-time obsession with the game Super Monkey Ball.

So for now, touchHLE can boast the ability to run a few old 32-bit games on Android and desktop operating systems. What other games from the first years of gaming on smart phones (and iPods) do you need to see ported? Get involved in the project if you’ve got an itch you need scratched.

Continue reading DOOM On IPhone OS, On Android”

An Android Phone Powers A Self Driving Car

As auto manufacturers have brought self-driving features to their products, we’re told about how impressive their technologies are and just how much computing power is on board to make it happen. Thus it surprised us (and it might also surprise you too) that some level of self-driving can be performed by an Android phone. [Mankaran Singh] has the full details.

It starts with the realization that a modern smartphone contains the necessary sensors to  perform basic self-driving, and then moves on to making a version of openpilot that can run on more than the few supported phones. It’s not the driver-less car of science fiction but one which performs what we think is SAE level 2 self driving, which is cruise control, lane centering, and collision warning. They take it out on the road in a little Suzuki on a busy Indian dual carriageway in the rain, and while we perhaps place more trust in meat-based driving, it does seem to perform fairly well

Self driving features are codified into a set of levels for an easy reference on what each is capable of doing. We’ve taken a look at it in the past, should you be interested.

This Week In Security: ACME.sh, Leaking LEDs, And Android Apps

Let’s Encrypt has made an enormous difference to the landscape of the web. The protocol used for authenticating and receiving certificates, ACME, has spawned quite a few clients of various flavors. Some are written in Rust, some in Python or Go, and a few in straight Bash shell script. One of those last ones, acme.sh, was doing something odd when talking to a particular “Certificate Authority”, HiCA. This pseudo-CA only supports acme.sh, and now we know why. The folks behind HiCA found an RCE exploit in acme.sh, and decided to use that exploit to do certificate issuance with more “flexability”. Oof.

The nuts and bolts here is that HiCA was working as a CA-in-the-Middle, wrapping other CA’s authentication services. Those services don’t support ACME authentication at all, and HiCA used the acme.sh vulnerability to put the authentication token in the place SSL.com expected to find it. So, just a good community member offering a service that ACME doesn’t quite support, right?

Well, maybe not so innocent. The way it appears this works, is that the end user sends a certificate request to HiCA. HiCA takes that information, and initiates a certificate request off to SSL.com. SSL.com sends back a challenge, and HiCA embeds that challenge in the RCE and sends it to the end user. The end user’s machine triggers the RCE, which pushes the challenge token to the well-known location, and bypasses the ACME protection against exactly this sort of CA-in-the-middle situation.

The last piece of the authentication process is that the signing server reaches out over HTTP to the domain being signed, and looks for the token to be there. Once found, it sends the signed certificates to HiCA, who then forward them on to the end user. And that’s the problem. HiCA has access to the key of every SSL cert they handled. This doesn’t allow encryption, but these keys could be used to impersonate or even launch MitM attacks against those domains. There’s no evidence that HiCA was actually capturing or using those keys, but this company was abusing an RCE to put itself in the position to have that ability.

The takeaway is twofold. First, as an end user, only use reputable CAs. And second, ACME clients need to be hardened against potentially malicious CAs. The fact that HiCA only supported the one ACME client was what led to this discovery, and should have been a warning flag to anyone using the service. Continue reading “This Week In Security: ACME.sh, Leaking LEDs, And Android Apps”

This Week In Security: GTA, Apple And Android, And Insecure Boot

When we first saw tweets about a security issue in Grand Theft Auto V, it sounded a bit like a troll. “Press ‘alt and f4’ to unlock a cheat mode”, or the hacker that claims to be able to delete your character. [Tez2]’s warning tweet that you shouldn’t play GTA Online without a firewall sounds like another of these online urban legends. But this one actually seems legit. NIST is even in on the fun, assigning CVE-2023-24059 for the exploit.

When playing an online game, other users send a “join request” to join the active session. This packets can contain malformed data which has been observed to crash the game client remotely. It’s believed, though not publicly confirmed, that it’s also a Remote Code Execution (RCE) vulnerability. It seems likely that this aspect will be added to some of the various cheat panels that are already widely used for this 10-year-old game. So now, rather than just giving your own character infinite ammo and health, you can inflict some havoc on other players, possibly up to corrupting their character files and getting them banned.

But why stop there? If we have code execution inside the game, what stops another player from launching a real attack? A video game isn’t sandboxed like a browser, and there’s nothing preventing a disk wiper attack or even a worm from compromising a bunch of players. The worst part is that it’s an old game, and even though there’s a large playerbase, it’s not guaranteed to get a fix. There’s at least one project aiming to be a firewall to prevent the issue. Continue reading “This Week In Security: GTA, Apple And Android, And Insecure Boot”