New Android Security Flaw Discovered

An article regarding a serious security flaw having been discovered in Android phones, particularly with Google and samsung brands.


errm, not exactly new, it was patched in July! 9news needs to keep up.


Heh only on those phones that were able to get the patches. Really a lot of other manufacturers phones basically didn’t get their default camera app updates and the risk in these still remains. It’s old news for Google & Samsung phones but perhaps new news for other brand phones?? Google has advised this “A patch has also been made available to all partners”…so perhaps still a current threat for some?


Is the answer here in a more general approach.

If you choose Android only buy from one of the big two or three, and churn your phone every 12-24 months to be sure your updates don’t stop coming? Who wins most from the poor software development and security?

Typically many of the cheaper Android phones also appear to be last years model and may nor even come with the most recent version of Android, update status uncertain.

I wonder how many less tech savvy and older consumers buy on blind faith and confidence in the sales staff?


… is it ‘terrifying’ or ‘alarming’? or just simply bad journalism, which is almost a tautology on that site :wink:


A new set of flaws in Android phones that may or may not have been patched in the Snapdragon SoC. Numbers of affected phones could be around 1 Billion.

Check Point in a blog post on August 6, 2020 stated they had discovered over 400 flaws in the code on the Qualcomm Snapdragon chips, some allowing bricking of the phones. These flaws may not have been patched in all cases as manufacturers are the ones who need to release the fixes and some phones do not get patched any longer.

This should at least be a warning about keeping the Phones patched and being aware that once a phone does not get patches that it’s time as a safer device might have been passed. Is this a form of built in obsolescence (intended or otherwise)?


With inherent flaws in software, and sometimes hardware, it almost seems ridiculous to worry about security since for every fix or few there might be one or more new faults introduced.

Knowing a Chinese company might be watching? Or accepting 400 hacker opportunities already exist that might be exploited by the same or other mobs.

Is it winnable?

1 Like

Winnable? I don’t think it is, but keeping head above water maybe slightly more possible with the occasional (or more often) slip beneath the waves to be taken in stride. How long has it taken for these flaws to become noticed by others looking into the code? How many lines and the possible impacts each might have on security need to be assessed? The number is such that I would hazard only a machine could perform that task in a timely manner (only perhaps as well) and only if it was flawless itself, how likely is that?

1 Like

Further details in our Webinar on August 13 (tomorrow Australian time). At the moment we just have scary headlines, and the knowledge that you need to install the wrong app to be affected.

I would expect that to the extent possible, Google has extended its app review process - which is as far as I know almost totally automated anyway - to check for apps seeking to exploit these vulnerabilities.

Remember that if someone can get malicious code onto your device - whether phone, PC, smartwatch or anything else - you have already lost.

Today? Not a chance. But keep in mind that security researchers are going where no researcher has gone before. In the last few years they have looked at attacks on physical RAM, device drivers, CPUs and now SoCs (CheckPoint appears to have adopted its own vocabulary for these, referring to them as DSPs).

With these complex attacks and previously unexplored attack vectors, hardware and software makers are being given a heads-up that they need to think about security first - it is no longer an optional add-on.

Large companies are adjusting future products now, to fix the exposed security holes. They will have to be awake to the dangers in any popular product, and will lose market share if they do not improve.

Smaller companies are likely to continue to skate by on low margins and ‘hopes and prayers’ regarding security. Ultimately, this is likely to result in a few major makers in each supply market that can be trusted to ‘do it right’ - or at least ‘fix it fast’, since we do not yet have any idea how to create a perfect complex system.

If you would like some idea about just how buggy a single market segment can be, I would encourage you to look at the Router Security website’s bug page. Then look over at that little black box in the corner and have a mild panic attack. (Hint: Cisco, D-Link, TP-Link and Netgear all feature prominently.)


To clarify their vocabulary, which is basically industry standard:

The SoC (System-on-a-Chip) is a single chip that implements an entire computer system (possibly and typically excluding the system memory i.e. RAM, and generally excluding the permanent storage i.e. ‘disk’).

The SoC may contain several different functional modules. The most important module is the general purpose CPU (which may have one or more cores). Another common module is the GPU (Graphics Processing Unit). Another module is the DSP (Digital Signal Processor).

The DSP typically exists because the general purpose CPUs in compact, low power devices (such as mobile phones) are not fast enough to do speech recognition, image/video/audio compression, etc. in real time - and also not without the consumption of so much power that the battery would drain in no time. Ultimately the DSP is just another CPU, but a special purpose one that does a few things very quickly and very efficiently.

Given the scrutiny of Intel CPUs (and to a lesser extent AMD and ARM CPUs) in recent years, it is not surprising that researchers have turned their attention to ancillary CPUs, particularly as those CPUs often execute in rather constrained or primitive environments by comparison with the general purpose CPUs.

The obvious next target after that would be the GPU. And then the CPUs that are running the mobile network modem and the CPUs that are running the WiFi and Bluetooth.

Should keep them busy for 10 years at least. :wink:

1 Like

I understand all of this, but what CheckPoint is talking about in its article appears to be the SoC.

A DSP (Digital Signal Processor) is a system on a chip that has hardware and software designed to optimize and enable each area of use on the device itself, including:

  • Charging abilities (such as “quick charge” features)
  • Multimedia experiences e.g. video, HD Capture, advanced AR abilities
  • Various Audio features

Simply put, a DSP is a complete computer on a single chip – and almost any modern phone includes at least one of these chips.

A single SoC (Software on Chip) may include features to enable daily mobile usage such as image processing, computer vision, neural network-related calculations, camera streaming, audio and voice data. Additionally vendors can optionally use these “mini computers” to insert their own functionality that will run as dedicated applications on top of the existing framework.

And their reference to SoC is clearly not industry-standard.


Yes, you are right. I didn’t read their text carefully enough. I stand by what I myself wrote as far as what these terms mean however.

In the “good old days” the DSP was probably a discrete chip but in the case of the referenced Snapdragon SoC (albeit they don’t specify a model number or numbers) the DSP is just one of many modules inside the whole.

In the text that you quote, I think the last paragraph should be talking about the DSP and the penultimate paragraph should be talking about the SoC.

So, yes, they thoroughly confused everyone. Unfortunately this doesn’t get any of the bugs fixed. :smile:

PS (in regards to the title of this topic) This isn’t exactly just an “Android” security flaw. Mobile phones aren’t the only (network-connected) devices using Snapdragon SoCs. And I wouldn’t mind someone running the same kind of tests on an iPhone …


To get full ‘security tester’ access to an iPhone you have to sign all sorts of things confirming that you will never tell anyone but Apple what you found. It is possible that testers who have not signed up to the Apple ‘program’ are able to hook up the chips in fancy ways, but it is probably quite a lot more difficult than with an Android SoC.


… which amounts to security through obscurity for Apple.


Of the flaws found perhaps as easy as running the exploits against the phone to see if they “take”.

iPhones don’t use the Snapdragon SoC. Apple uses its own SoC.

So you would be starting again in finding out what the hardware interface to any ancillary CPU looks like, what the software API looks like, what the operating system and software running inside the ancillary CPU is, …


Sometimes though a “Brute Force” approach can yield gems of “wisdom”, without needing to have a blueprint of the innards.

As long as you can figure out how to connect to those innards. If they are encrypted decently (as Apple claims), then how do you find an output port that gives you anything but garbage? Similarly, trying to input anything will fail if you cannot beat the encryption.

1 Like

You are both right.

I wouldn’t underestimate the difficulty of attempting to security test a completely undocumented CPU.

If you can communicate with it at all, something may be gained by fuzzing it with random crap. Even if all communication is encrypted (with authentication) by the sender, the ancillary CPU may have unchecked conditions that cause it to crash or fail on particular bad inputs. (However you are never going to be able to test even 1% of what you could test if you could send it valid encrypted messages.)

1 Like

Also run the same tests on Facebook, Tinder, Tiktok and Instagram. Perhaps the results will never be released?