Why even bother?
Why couldn't that app just use the microphone?
How a malicious Android app could covertly turn the DSP in your MediaTek-powered phone into an eavesdropping bug
Check Point Research will today spill the beans on security holes it found within the audio processor firmware in millions of smartphones, which can be potentially exploited by malicious apps to secretly eavesdrop on people. The infosec outfit believes as many as 37 per cent of smartphones globally are vulnerable. The flaws, …
-
-
-
-
-
-
Thursday 25th November 2021 08:58 GMT Allan George Dyer
Re: Eavesdropping bug
@HildyJ - Why only microphones? Apart from the obvious example of speakers, we had fibre optic cables sensing vibrations reported here in September.
-
-
-
-
-
Wednesday 24th November 2021 21:27 GMT DarthKegRaider
Re: Eavesdropping bug
Considering you can be talking to you friend/partner about something they/you want to purchase, then within a few hours their facebook/web-browsing adverts are suddenly showing what you were talking about. Without searching the internet previously!!! Now without sounding like I wear a tin-foil hat, it's almost like they record everything now, perhaps 'speech to text' converted, then upload the tiny files to their ML/AI advert-bot. You're not going to notice some text files in your monthly data plans.
All smartphones are bugs, but we keep using them....
-
-
-
-
Friday 26th November 2021 12:48 GMT MrReynolds2U
Re: More Arguments for Memory Safe Languages
It's entirely possible to write unsafe code in Rust.
It's also entirely possible in modern C++ to write safe code. Most of the unsafe issues from C/C++ come from not understanding how what you write accesses memory and other resources, and also from not adapting to newer, safer techniques and language constructs.
-
Monday 29th November 2021 07:48 GMT fg_swe
Re: More Arguments for Memory Safe Languages
1.) By default, Rust and Sappeur assure memory safety. They do not prevent other types of errors, such as SQL injection due to insufficient input parameter checking.
2.) By default, it is very easy to create a memory safety bug in C and in C++. As it apparently happened here.
2.2) It is practically impossible to ensure memory safety for multithreaded C++ programs, as approaches such as RAII and index checked arrays do not protect against accidental MT-sharing of unprotected variables.
-
Wednesday 8th December 2021 18:07 GMT EnviableOne
Re: More Arguments for Memory Safe Languages
however, it is practically impossible to use rust to write a realtime OS that runs at a latency low enough to maintain an audio encoded stream of the required standard to enable lossless compression and encoding. It is not impossible to do this with C
This is the job C was designed for, writing low-level code to manipulate low-level data streams, by all means, write you applications that run on top in Rust or Sappeur, but other than going back to machine code, you cant get the efficiency you need for signals in anything higher level.
It's hardly impossible to create memory safety in C if MediaTek fixed it in a disclosure window.
-
Thursday 9th December 2021 01:51 GMT Charles 9
Re: More Arguments for Memory Safe Languages
"however, it is practically impossible to use rust to write a realtime OS that runs at a latency low enough to maintain an audio encoded stream of the required standard to enable lossless compression and encoding. It is not impossible to do this with C"
What makes you so sure of that since Rust mostly enforces memory safety via semantics and enforced rules which tend to take place at compile time, where optimizations normally take place? Why can't you have an OS that's both fast and memory safe since memory isn't the obstacle it once was (meaning you don't have to be so tight, the third leg of the "safe/fast/tight" trade-off triangle in this case)?
-
-
-
-
Biting the hand that feeds IT
