Why an unhackable mobile phone is a complete marketing myth

http://motherboard.vice.com/read/the-black-market-dealers-se...

They basically give external control to all the baseband processors functions (read mic, control signal, read gps chip etc.)

It's why snowden made: https://www.wired.com/2016/07/snowden-designs-device-warn-ip...

because if your phone is in airplane mode, it shouldn't be transmitting - and they can all be made to.

(Oh, and I have friends who served in Afghanistan, so found out about all this around 2002)

"We're going to address privacy concerns of non-free modem firmware by ensuring that the modem has access to no more data than absolutely necessary, so it won't be able to spy on anything that's not already available on carrier side. On Neo900 one can be sure that the modem is actually turned off when requested, not just pretending to be. Users will be notified in case of the modem wanting to do something without their consent. Unlike some other smartphones do, Neo900 won't share system RAM with the modem and system CPU will always have full control over the microphone signal sent to the modem. You can think of it as a USB dongle connected to the PC, with you in full control over the drivers, with a virtual LED to show any modem activity."

It might be possible to attack the phone from the USB connection to the baseband, https://news.ycombinator.com/item?id=12673735

and linfone or equivelent.

Just need a 3d printer so i can print the case. A bit of a brick. but a quite the "swiss army knife" of comms.

I also dont know how many people are aware just how sensitive the mic is on modern phones. I wrote a little app that turns android phones into bugs (broadcasts sound from the mic over wifi) a few years ago. It can pick up a whisper from 40m away, while when using it as a phone there is never any background noise.

As an example, a SOC for feature phones having both GSM and WiFi might be reused in a cheaper "wifi adapter" that still has GSM circuitry but not visibly. Whether if can be used against you depends on whether it's a hard or soft switch they used to disable/hide it plus whether it's reversible or one-time (eg antifuse).

For example, a while loop code in a Turing Machine is unhackable; the state repeats forever.

This sounds like an attempt to combine intuitions about the pumping lemma with memory corruption vulnerabilities: that "any system" must have some inputs that are "too much" for it to interpret correctly (for many programs written in C, that could be a single input string that's "too long").

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

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

These intuitions are founded on good reasons because every computing system has different kinds of limitations, and some kinds of distinctions that it can't make correctly, and some kinds of failure modes if it's expected to make arbitrary distinctions.

But there are ways out:

* If we narrow the definition of the task that the system has to do, it may be possible for the system to do it perfectly, and it may even be possible to make a formal proof that the system performs that task perfectly, even though there are other more general tasks that it doesn't perform, or performs imperfectly.

* If we allow the system to "give up" or indicate that it refuses or fails to answer certain questions, then it doesn't have to be "wrong" or exhibit wrong or unpredictable behavior. It can just say "sorry, not sure", which may be annoying but isn't a mistake and isn't necessarily a security vulnerability. (Maybe this is akin to those movie robots saying "does not compute" all the time.)

Within these frameworks, a kind of perfection, or at least a kind of correctness, is possible for many computing tasks -- including some that involve Turing-completeness, either as a property of the environment they're implemented in or as a property of the machine they implement.

Just because it is Turing complete does not imply that it uses a stack.

Consider:

look_for := "some string"; n := len(look_for); send_out := "other string"; i := 0; while(true){ c=getInputChar(); if(c==None){ i=0; continue; } if(c==look_for[i]) { i+=1; continue; } if(i==n){ output(send_out); i=0; continue; } //else i=0; continue; }

(Pseudo code. No specific language intended.)

I see no reason that the above would require a stack (provided that the input and output features are hardware built ins rather than function calls. Just reading or writing from/to a pair of registers.)

I see no way that such a program could be exploited (short of flaws in the machine).

Causing the stack to dump wouldn't work, as it has no stack. It just cycles through a small number of states based on input.

Now, some other program which is much more complicated could be written for the same machine, as the machine is Turing complete, but this particular program would not be vulnerable.