Smartphone Hackability, Or, A Pocket Computer That Isn’t

Smartphones boggle my mind a whole lot – they’re pocket computers, with heaps of power to spare, and yet they feel like the furthest from it. As far as personal computers go, smartphones are surprisingly user-hostile.

In the last year’s time, even my YouTube recommendations are full of people, mostly millennials, talking about technology these days being uninspiring. In many of those videos, people will talk about phones and the ecosystems that they create, and even if they mostly talk about the symptoms rather than root causes, the overall mood is pretty clear – tech got bland, even the kinds of pocket tech you’d consider marvellous in abstract. It goes deeper than cell phones all looking alike, though. They all behave alike, to our detriment.

A thought-provoking exercise is to try to compare smartphone development timelines to those of home PCs, and see just in which ways the timelines diverged, which forces acted upon which aspect of the tech at what points, and how that impacted the alienation people feel when interacting with either of these devices long-term. You’ll see some major trends – lack of standardization through proprietary technology calling the shots, stifling of innovation both knowingly and unknowingly, and finance-first development as opposed to long-term investments.

Let’s start with a fun aspect, and that is hackability. It’s not perceived to be a significant driver of change, but I do believe it to be severely decreasing chances of regular people tinkering with their phones to any amount of success. In other words, if you can’t hack it in small ways, you can’t really make it yours.

Can’t Tinker, Don’t Own

In order to tinker with your personal computer, you need just that, the computer itself. Generally, you need a whole another computer to hack on your smartphone; sometimes you even need a custom cable, and it’s not rare you can’t do it at all. Phone tinkering is a path you explicitly set out to do, whereas computer-based hacking is something you can do idly.

A Nokia N900 in hands of a user (by Victorgrigas, CC BY-SA 3.0)

There’s good reasons for this, of course – first, a phone was generally always a “subservient” device not meant or able to be used as a development bench unto itself. Then – phones started really growing in an age and an environment where proprietary technology reigned supreme, with NDAs and utter secrecy (particularly for GSM modems with their inordinate amount of IP) being an especially prominent fixture in the industries surrounding phones. Even Android’s open-source technology was mostly for manufacturers’ benefit rather than a design advantage for users, as demonstrated by the ever-worsening non-open-source driver situation.

Only a few phones ever bucked these trends, and those that did, developed pretty devoted followings if the hardware was worthwhile. Just look at the Nokia N900 with its hardware capability and alt OS support combo, Pixel phones with their mainline kernel support letting alternative OSes flourish, or old keypad Motorolas with leaked baseband+OS source code. They’re remembered pretty fondly, and it’s because they facilitated hacking, on-device or even off-device.

Hacking starts by probing at a device’s inner workings, deducing how things work, and testing the boundaries, but it doesn’t happen when boundaries are well-protected and hidden away from your eyes. A typical app, even on Android, is surprisingly non-explorable, and unlike with PCs, again, if you want to explore it, you need a whole another device. Does it benefit app developers? For sure. I also have a strong hunch it doesn’t benefit users that we could otherwise see become developers.

Part of it is the need to provide a polished user experience, a respectable standard to have, especially so for producing pocket computers to be used by millions of people at once. However, I’d argue that modern phones are suffocating, and that the lack of transparency is more akin to encasing an already reliable device in epoxy for no reason. A device designed to never ever challenge you, is a device that can’t help you grow, and it’s not really a device you can grow attached to, either.

Of course, complaints are one thing, and actionable suggestions is another.

What Do?

If I were asked how to fix this, I wouldn’t limit myself to opening filesystems back up to a user’s exploration habits, beyond the way they were open even in early Android days. I think modern phones could use a pre-installed Python interpreter, with a healthy amount of graphics libraries, a decent amount of control over the system, snappy well-configured autocomplete, and a library of example scripts you could edit in place; essentially, an Arduino IDE-like environment.

In other words, let people easily program phones to flash the screen every time an SMS from a specific person is received, or start audio recording when the user taps the touchscreen three times as the phone’s locked, or send accelerometer movements into a network socket as fast as the OS can receive them. Then, let them wrap those programs into apps, share apps easily with each other, and, since the trend of fast obsolescence requires regular collectie infusions of cash, transfer them from phone to phone quickly.

By the way, if days of Bluetooth and IrDA transfers evaded you, you missed out. We used to stand next to each other and transfer things from one phone to another, a field previously handled, but nowadays these things are somehow relegated to proprietary technologies like Airdrop. This isn’t a problem for personal computers, in fact, they somehow keep getting better and better at it; just recently, I transferred some movies between two laptops using a Thunderbolt cable during a flight, and somehow, this was one of the few “wow” moments that I’ve had recently with consumer-grade tech.

The idea is pretty simple on its own – if phones are to be personal computers, they should be very easy to program.

The Doohickey Port

What about a bonus suggestion, for hardware customization? USB-C ports are really cool and powerful, but they’re relatively bespoke, and you only ever get one, to be unplugged every time you need to charge or sync. Plus, even if you have OTG, all that 5V step-up action isn’t great for the battery, and neither are USB hardware/firmware stacks.

I like I2C. Do you like I2C? I know most of you do. I enjoy I2C a lot, and I like how it’s decently well standardized, to the point things tend to just work. It’s not as great at as many things as USB can be, but it’s also comparably low-frills, you don’t need a software stack or a hefty bespoke board. For the most part, with I2C, you can just send bytes back and forth. It’s a low-bandwidth yet high-impact bus, with a healthy amount of devices you can attach to it. Also, CPUs tend to have plenty of I2C ports to go around, often leaving a good few to spare.

What else? Keeping up with the times, these days, you can manufacture flex PCBs decently quickly, with stiffener at no extra cost, and for dirt cheap, too. On a physical level, phones tend to come with cases, overwhelmingly so. In a way, there’s suddenly plenty of free space on the back of a phone, for those with the eyes to see, and that’s after accounting for the ever-increasing camera bump, too.

My bonus idea to make phones more customizable at low entry level, would be an I2C accessory port. In effect, a latch-less FFC socket with exposed I2C, and some 3.3V at non-negligible power. Of course, protect all lines electrically, current-limit the 3.3V and make its power switchable. With modern tech, you don’t need to compromise waterproofing, either, and you can add a whole bunch of protection to such a port.

From there, you can get GPIOs, you can get PWM, and so much more. You could have a reasonably simple GPIO expansion, but also a fully-fledged board with DACs and ADCs bolted on, or a servo control board, or an extra display of the kind phone designers like to add once in a generation, only to find it never be used by third-party apps as sales numbers never really reach the point of wider adoption. Experimental chording keyboards, touch surfaces, thermal pixel sensors,

Does it feel like you’ve seen that implemented? Of course, this resembles the PinePhone addon scheme, with FPCs wedged between the back cover and a set of pogo pins. Notably though, this kind of standard is about having compatibility between models and even manufacturers. You also shed a lot of Bluetooth cruft generally required when developing accessories for modern phones. It requires a flex PCB, sure, but so do pogopin schemes, and there’s barely any mechanics compared to a pogopin array. Is it more fragile than a pogopin array? Yes, but it’s fragile addon-side, not as much phone-side, whereas pogopin arrays tend to be the opposite.

A Sketch And A Dream

Of course, this also relies on the aforementioned Python interpreter, and a decent exposed I2C API. If the only way to tinker with yours and others’ accessories is through bespoke intransparent apps you need a whole different device to make (or modify, if you’re lucky), the hackability aspect wanes quick. In essence, what I’m proposing is a phone-contained sandbox, not in a security sense, but in an educational sense. Personal computers have been serving as sandboxes for decades now, and yet, phones could never really fulfill such a niche.

I think one of the big problems with modern phones is that a phone is barely ever a sandbox, all for mostly historic reasons. Now, if that’s the case, we should make it one. If it’s a sandbox, then it can be molded to your needs through hacking and tinkering. If it can be molded to your needs, then it belongs to you in a whole different way. Will this happen? Quite unlikely, though, I do feel like making some prototypes. Instead, it’s about highlighting a significant aspect that contributes to tech alienation, and imagining how we could solve it given enough market buy-in.

70 thoughts on “Smartphone Hackability, Or, A Pocket Computer That Isn’t

  1. You’re confusing user hostile with hacker/tinkerer/nerd friendly. The olden days of personal computing felt pretty hostile to the 99% of normies.

    Would I love to hack on my iPhone? Sure! But then I think of the can of worms this would open for my less technophile relatives. If I need something more hackable, I can use a Raspberry Pi, discarded and rooted Android device, or buy one of the few phone-ish devices targeted at our market.

    Though I do think there’s an argument to be made about user/customer hostility of modern capitalism in general as preached by Cory Doctorow.

    1. You can have both worlds combined: grant the “hackers” access to the device by breaking some kind of fuse, be it software and/or hardware and make sure: everything you break beyond this line is your fault.

      The normal user wouldn’t care (especially opening the device and e.g. remove a zero ohm) and the hacker can do whatever he wants to do.

      Prusa did this with one of their printer mainboards. I know the complexity/liability is something different between companies and products, but still…

    2. The olden days of personal computing felt pretty hostile to the 99% of normies

      They just don’t want to learn. Especially not it there is someone they can use as unpaid helper. I don’t think normalizing being lazy should be allowed. When I wanted something, I learned. Is changing your own tires in the scope? Yes. Get a cheap safe hydraulic lift, a torque wrench and check the handbook on the required torque for your car and type of rims.

      I don’t know what the average Joe does in that meantime. I feel that time spent on spectator sports is wasted. Maybe I am not normal, but I will never accept that being lazy can be accepted as normalcy either. Especially not when asking friends for help is expected to cost them $0.00, and they could just invite you to a BBQ (which my real friends do).

      1. “time spent on spectator sports is wasted”

        I’m with you on that. However, it should be noted that my agreement in no way, shape, form, or measure of any sort indicates that you are normal.

      2. The worst is when they insist on ‘paying you’.

        $20 bucks for 5 hours of unnecessary work…
        ‘You can’t pave it over, I’ve set it up just the way I like it.’
        ‘You like it infested w Viruses?’

        That was the last IT work I did for anyone but immediate family.
        I’m more user hostile than MacOS6 these days.
        My ‘give a shit’ process is emulated 68K code.

      3. I don’t think normalizing being lazy should be allowed. When I wanted something, I learned.

        People don’t have unlimited energy and time. It’s becomes a question of choosing your battles when you have other motives, such as getting your actual job done.

        I could get a hydraulic jack, a torque wrench, a tarp, etc. and rent a storage unit to store my winter/summer tires and the tools to do it myself, since I don’t have a garage – or – I could just drive to a tire hotel and pay $100 to save me the trouble. It’s also much cheaper.

        1. Bonus. They’ll impact wrench the tires on so tight you’ll never be able to change a tire on the roadside.

          Fun fact: Torque sticks on impact wrenches only work with wrenches that have the same # of impacts/second they were designed for.
          But tire monkeys don’t understand this, tire store managers even less so.

          Hence stretched wheel studs, bent tire irons and cheater bars.

          1. If they do that on alloy wheels, they’ll ruin the rims first and you claim their insurance on it. If they keep on breaking their customers’ wheels, it’s gonna cost them more than it costs them to train their monkeys properly.

            Tire store monkeys are a different matter, because they only see the customer once. Tire hotels get return customers, and the customers don’t return if the service is bad.

      1. Yep.

        Like removing the three menu buttons and replacing them with gestures in an Android device. First of all, the gestures don’t work reliably and consistently, and there’s no clues as to what gestures you should be making in the first place. What sort of an idiot thought that was a good idea?

        Some UI/UX designers – especially the engineer/hacker types – seem to think that the users enjoy “discovering” features of their devices and twist every knob and look behind every menu out of curiosity, so obviously they’d figure it out in five minutes. If not, then “the user is stupid”.

        1. “First of all, the gestures don’t work reliably and consistently, and there’s no clues as to what gestures you should be making in the first place.”

          Android as used by Google devices do not have this issue.
          Android that is overlayed by proprietary GUI skins drive me into a rage.

          Tablet (very cheap) that I am writing this note on is plain-ol’ Android-15 with no manufacturer GUI mods or app bloat … Works identical to my Pixel smartphone also on Android-15.

          Google provides online and on-device demos of gesturing usage; to the point of almost getting in my face, but they do provide a “Not Now” escape option on the automatic first page that pops-up after set-up or software update.

          1. Android as used by Google devices do not have this issue.

            Yes they do. I have one, and I don’t know whether it’s my fingers or the system not working properly, but it’s a hit and miss to get the correct gesture to register every time.

            And the online demos and tutorials only prove the point: you need to be trained to use the gestures because there’s no clues to what you’re supposed to be doing. No aid for memory and recognition. For instance, in my mother’s tablet, there’s always a morass of applications and web pages stuck in the background because she doesn’t remember the gesture to bring them up again, and even when she’s told, she can’t always reliably reproduce it either.

          2. even when she’s told, she can’t always reliably reproduce it either.

            The problem being, when the gesture doesn’t work, as it is either not recognized correctly or she’s not doing it properly, she gets confused and goes “Oh no, that wasn’t it. Now I don’t know what to do.” There is no indication or even a hint to the reason of the failure – whether it’s the system not responding or the user making incorrect inputs. Worse, something else might happen because the gesture was subtly wrong or misinterpreted, and that adds to the confusion.

            If it was the original three buttons, if the system was lagging or the touch wasn’t recognized properly, the buttons would still be there and nothing else would happen. Memory says “press this button” and if nothing happens, she’d tap the button again until it does something.

      2. “seem friendly only because there is a lot of people, books and online materials…”

        Retired EE/IT here:
        I only do support for my wife because she can mess-up any computer beyond a simple “fix.” She is a brilliant woman but the issue essentially distills to insisting that computers (all models: Kindle, smartphone, SmartTV, desktop, laptop…) should intuitively work the way she “thinks.” There is no setting or hidden option that will hold her back from attempting to wrangle the device into submission to her will.
        My God bless me if she realizes that her fancy new SmartPhone has AI capabilities.

  2. oh man…i do have tons of complaints about modern smartphones. but this article, man! i disagree in every single detail.

    “idly hacking” vs “tinkering is a path” is a distinction without a difference. pure nostalgia without content.

    using a separate machine to hack a phone is no big deal. i always used a separate machine to hack on portable computers, which i’ve eagerly done for as long as i’ve been able to afford them. my laptop is ‘a super computer’ by my standards and even so i build its custom kernel on a big pc.

    i never had the nokia n900, i just had an n810…and good riddance. what an absolute piece of garbage ‘maemo’ was. worst of all worlds. i recently took it out again to see if i could use it as a wifi-to-3.5mm audio gateway, and it was even worse than i remembered. to access its audio hardware you had to use a proprietary closed hacked version of esd, which was extremely buggy. as maemo evolved into whatever it is today, it constantly dropped one poorly-thought-out solution for another one. so you had more churn than android, and a lower quality at every stage. i’m sure people remember it fondly, but i doubt many of them hacked on it!

    you don’t need python to come pre-installed from the factory. if you want python on your android phone, just go to the play store and download it. “doctor, it hurts when i don’t download the apps i want to play with.”

    the list of things that should be easy is absolutely incoherent. messing with notifications and the lock screen is not simple, it’s going to be hard anywhere you go. it’s fundamentally a hard problem, and one that’s going to require centralization. and one that open source solutions have a real struggle to get a handle on.
    but sending accelerometer data over the network is easy! just download the android SDK and you can do it from cutting and pasting stackoverflow examples in an afternoon. i know because i made an android app to stream touchscreen and camera data over the network.

    and usb is a fine peripheral interface for a phone, and gives you access to just as many GPIO opportunities as I2C does.

    i am super frustrated by where android development is heading. and i’m pretty bummed about how hard it is to re-purpose old phone hardware. but this article is astonishingly wrong. if you want to hack a phone, just hack a phone. if this article was complaints coming from someone who had hacked a phone, i’d be nodding along. but instead it’s just pointing fingers of blame at other people, when it’s the author who decided not to hack the phone.

      1. I had (and still have) the N770, the predecessor to the N800. It was sloooooooow as heck and really no fun to use. That resisitive touch screen was dim and very “not so responsive”. Without the stylus it was trash haha. Wi-Fi was okay but drained the device quickly. Charging port was a super tiny barrel jack instead of the then standard mini USB…

        Man I should get a new battery for that thing and fire it up :)

  3. I want to phone that I can use whatever software I want on it, and more importantly, remove software I do not want or need from it.

    Try removing Facebook or YouTube from most Android and Apple phones. It will tell you it can’t. And next time there’s an update of the OS (which you probably didn’t want anyways), it’s back.

    The only reason for this is because they sell your data and tracking you is too important. Maybe it would be a lot better for humanity if we just make data brokers illegal.

    1. i’ve had 8 phones and i’ve never seen factory-installed facebook. i’ve never tried removing the ‘g suite’ apps (youtube, gmail, etc) but generally it’s as easy as clicking ‘disable’. they’re sometimes in a read-only partition but you can ask the OS to ignore them.

      vendors do often stick a bloatware skin over android that you will struggle to remove, but generally you win if you hack at it. for example, my nvidia shield tv updated to have an awful home screen UI and it took me a couple hours to get flauncher on it instead. i haven’t seen the stock one in years and i have let it upgrade.

      i think the word ‘most’ is interesting there. i’ve had a few samsung devices that were pretty locked down and also intolerable in their factory configuration. but every other android device i’ve owned, i’ve generally been able to unlock it pretty thoroughly. in fact, despite all the hacking i’ve done on phones, most of the phones i’ve had, i have kept in relatively stock configurations. for example, my oneplus nord n20, you can fully unlock its bootloader but i haven’t bothered. anecdotally, the “chinesium” android devices you can buy for unbelievably low prices on ebay or temu all seem to be factory-unlocked…i’ve got a 10″ tablet that even came with SuperSU pre-installed! literally 0 effort to get to a root shell.

      sorry :) i’m still just railing against “i can’t be bothered to hack my phone” being misconstrued as something it isn’t. i think people too easily go from “i once struggled with xxx a decade ago” to “the struggle against xxx is infinite and unwinnable.” are we not hackers?

  4. A smartphone could host its own development platform, but should it? If I’m typing a bunch of code, I want the keyboard and big screen of a PC. I would say if you want a development environment on a smartphone, something graphic based like a more powerful version of Scratch might make more sense than a more conventional IDE.

    When the smartphone is all you have, putting some onboard development can make sense. But otherwise this makes only slightly more sense than putting a development platform on an OpenWRT router.

    As for ports, a smartphone looks like a better candidate for interfering with something over a wireless connection or maybe sending serial over USB. It’s not an Arduino or even a Raspberry Pi. A smartphone works better as the user interface with something else handling low level tasks.

    I suppose when all you have is a hammer…

    1. an anecdote to back you up…i went through an absurd effort to get self-hosted gcc on one of my ipaq palmtops. after all that work, i used it exactly once. haha before that i wrote a self-hosted compiler for a novel language on my psion revo / mako, and i used that exactly once as well. like you say, just not a compelling experience.

      the funny thing is i actually code on the thing all the time (to get work done in the odd leftover moments from parenting) but these days i just use ConnectBot to ssh into my big pc. the network is the computer.

    1. I was thinking the same. I recall reading something a while ago that one reason for originally restricting user access to phone firmware & hardware was related to telco and government approvals.
      I guess we moved on from this? Pinephone is a thing now so there must be a way to avoid this issue?

  5. The reason why you don’t want easily hackable phones is because you want to maintain the fragile trust on the platform that banking and identity service providers need.

    It’s the reason why your bank can offer you an app on your phone that authenticates your online presence, and the reason why such software commonly refuses to run if you have rooted your phone.

    1. The trust is fragile because it’s based on the assumption that your phone is not compromised because it’s running the stock operating system and software packages curated by a trusted party, such as the OS vendor (Google/Apple). That’s not saying it cannot be compromised, it’s just that it’s unlikely to be, and it’s unlikely that users would willingly compromise their devices in attempts to “cheat”, e.g. to fake a bus ticket because it’s difficult and leads to some major inconveniences.

      If the system was totally open to hacking, like a PC is, then the trusted device or method of authentication would have to be something else than your phone. A printed list of keys for example, just like in the old days.

      And you’d probably have a lot more mobile malware floating around anyways, which is an inconvenience by itself.

    2. Really not true – even a compromised device can be used for something of the same level or perhaps even greater security inherent to that ‘fragile trust of the platform’. As if anything because the expectation is the locked down platform is safe with all the OS vendors actually pushing the secure updates and no backdoors etc that the security and verification of your device and you being the one using it is laxer than it should be. Nothing can be perfectly secure and actually functional, always holes somewhere, and as soon as you and in this case the Bank have to take it on faith but can’t actually verify…

      For instance the fairly standard 2FA type app with rotating codes to log in with is pretty much equally secure in a ‘not easily hackable’ phone as a more friendly one – the requirement for you to unlock the 2FA app and decrypt it (or even each individual instance it handles 2FA for seperately) first, the time windows each key is valid for etc means even if your device is fully screwed and reporting to some hostile everything they still have a pretty narrow window if they are just getting time limited code, and even if they have the password to unlock the app, they also need a copy of your keys – which should be logged when made if the app actually allows vaults to exist on multiple devices, which not all do – some seem to be migrate and wipe the old in the process and show lots of angry warnings if the file has been touched by anything else. But either way that log I’d hope would be noticed. Or alternatively they would have to remotely use your device as its the one the keys are on every time they want something, which means it has to actually be online – you’d probably notice the battery drain…

      And for more usual levels of failed security with a bad app sniffing at out of bounds memory or getting to see the encrypted 2fa vault file location and file but not the decrypted content…

      It is way easier to get the $5 wrench https://xkcd.com/538/ or as the password to the app might well be face/fingerprint these days use that method to be let into the real device – a ‘hackable’ or not device really doesn’t matter then.

      1. Really not true

        Tell that to my bank. If I root my phone, their app stops working.

        That’s the difference between what ought to be in theory, and what it is in practice. They don’t trust rooted phones, and I have to deal with it.

        1. I agree in practice Banks seem to be rather happy to take the lazy way out and assume its actually secure, which isn’t certain at all – which is rather my point it isn’t really secure, as they can’t verify the chain of trust at all.. Do you really trust all those cheap chinesium phone brands to have used the Android Core and not added anything beyond the required hardware hacks… Plus if your phone BIOS/OS actually tells the app the phone is rooted is an arbitrary check box outside of the apps control to prove…

          But that isn’t the point you seemed to make or I was making – that point is you can have secure as computer networks can be even on a compromised device if you put in the work. So a smartphone that is as open as PC really shouldn’t be a big deal at all.

          1. It’s not really secure, but it’s close enough so the banks trust it. So far there hasn’t been too many problems – so the system works.

            The alternative isn’t close enough to secure. That’s why the banks don’t offer you an authentication app for your desktop/laptop PC. They don’t trust it. Instead, they trust your phone, or a chip card reader, or a key generator widget, or even a printed paper list – anything else than the PC itself.

            That’s the reality of the situation. If you made phones/tablets “more hackable” by default like your PC is, then the banks and authentication providers would lose trust in them. That was my point.

          2. If you made phones/tablets “more hackable” by default like your PC is, then the banks and authentication providers would lose trust in them. That was my point.

            Plausible, but I think you are wrong there if these more open platforms became a normal – as it is all about user convenience and cheapness for them to implement it with very little care for security really – as long as it doesn’t majorly harm the bank they don’t care about a little criminal activity or the harms to the little people…

            The smartphone tech was already there and in wide use by the time the internet banking type stuff like this starts to seriously develop into banking app type concepts, so simply taking the easier way out and being able to put all the blame on Google and Apple was probably floating in their minds… Also early android wasn’t nearly as effectively locked down, and stealing and using a phone is way way easier than a computer, and yet they still put it on those platforms without any real challenges to authenticate! Rather proves security really isn’t important enough to them as long as the bank isn’t going to be liable for too much.

            So if capable smartphones had taken another decade to really become mainstream desirable/affordable than they did…

            The only reason we don’t have it on desktops and laptops is because they don’t have to bother and never did – As everyone has and always had their darn nearly mandatory tracking and data hoovering device with them at all times since the ‘always’ connected internet age began years earlier.

          3. if these more open platforms became a normal

            Look to the past.

            Online banking and authentication existed before smartphones. They were a normal, and the solution offered by the banks and authentication providers was to not trust them. This is why we have the chip card readers, the key generator widgets, and the printed password lists in the first place.

          4. “Look to the past.”

            Actual history is not exactly relevant to the point of what can be done, or would be done with one slight difference to that history – card readers are an obvious starting point, as they work, even for folks with potato barely able to run a webbrowser PC, are easy to get everyone to understand etc – remember this is trying to consider it from the POV of the past, when people’s expectation, and the evolution of ideas, more performant hardware, high speed internet, and better/more idiot operable UI development hasn’t happened yet.

            So when those new concepts start to happen so society as a whole kinda wants internet banking but smartphones are either more open, or too expensive/rare…

          5. card readers are an obvious starting point

            And an obvious dead-end that has been attempted multiple times, but the phone as a trusted identifier has always come on top. It’s personal, it’s always with you, and it doesn’t require extra stuff like a card or having to insert it in a reader…

            The point is, the phone is good, the phone works, and if the phone no longer works because the banks stop trusting it, then we’re forced to roll back to a previous state that was less good. We could operate like that if necessary – but we don’t want to.

          1. And in both cases the App is at the mercy of the OS – as it doesn’t have to let them see anything outside of its allowed sandbox, and if the thing behind the API is borked it can’t be relied on to actually tell the truth – all an API really does is give you a way to ask something to a black box and get a result, you generally can’t verify that API is talking to blackbox that tells the truth, its just a leap of faith…

          2. he App is at the mercy of the OS

            If the app is trying to detect whether it’s running on stock Android, all it has to do is ask the OS to prove itself using some cryptographic key that cannot be faked by others, or which cannot be obtained from Google/Apple if the OS is rooted or hacked otherwise.

  6. My solution is just use a cheap smartPhone … as a phone/text device. No banking, no McD app, no, no, no… Ie. A vendor provided throw-away device providing a simple service… There are many SBCs that are open to hacking, well, programming friendly and to have fun with. From full blown RPIs, Beagle Bones, (and all the Asian knock-offs) down to Arduino, Pico, Feather, Teensy, etc. for the fun stuff. And ‘lots’ of peripherals to choose from for a pocket computer or anything else… Why pick on locked-in vendor supplied cell phones?

    1. Because they are wonderfully powerful all in one self contained hardware packages, that usually even for the flagship expensive options are sold at a price you couldn’t come close to matching even if you only need half the features – They are so full of compute, and these days often GPU/AI focused compute power too, sensors and communication and all while generally having really really great energy efficiency compared to the more dev/hacker friendly options.

      So if you are actually able to freely use what is in the shiny box…

      1. I rely on my phone: to guide me when I’m lost, to pay my bills and rent, public transportation, car parking, to authenticate into services, to contact people and be available for contact, and keep my calendar and important memos.

        I don’t want to hack it and potentially mess it up. I need it to always work.

        1. Which is fair enough, but if you are going to buy a Raspi or other SBC and all the accessories to get the functions you need for your project you’d be so much better off if you could just use a smartphone in many cases – between your old ones, second hand markets, and the cheap stuff that you’d not want to daily drive exists great devices that will mash the SBC in price and/or performance at many tasks if only they would let you (or you don’t mind bashing your head against the wall for the days it might take just to get the darn thing to boot again). For instance as a low power consumption, battery backed up home assistant, file server, etc etc…

          1. If I was to carry a second device, then I’d rather have it be some SBC than a smartphone, because that’s more hackable in the hardware sense. I cannot easily interface with other electronics using an old smartphone because it lacks the GPIO pins.

          2. For instance as a low power consumption, battery backed up home assistant, file server, etc etc…

            In my experience, smartphones are only power efficient when they’re idle. As soon as I start to do something with it, the battery won’t last half a day.

          3. In my experience, smartphones are only power efficient when they’re idle. As soon as I start to do something with it, the battery won’t last half a day.

            Probably true, but then as that same battery size on a pi even if its only at idle probably doesn’t last half as long as the phone did doing something – much as I love the Pi if phones where more open and hackable they would be a better brain for most things as they are potent and much more energy efficient by design.

            I cannot easily interface with other electronics using an old smartphone because it lacks the GPIO pins.

            that is almost the only reason to pick something like a Pi should this scenario ever happen, and in many cases you can fake it with a small microprocessor on the phones USB port or via BT/Wifi as your project doesn’t absolutely have to be so directly linked so the phone remains plausible as the heavy lifting main brain to the ESP32/Pico etc.

            Though the SBC or SOM is also much easier to integrate properly into whatever you are building, and makes for a much more replicable project (if that matters to you) as the SBC/SOM even if there are hardware revisions puts effort into staying drop in compatible, where the smartphones, laptops etc do not so it isn’t unusual for the connectors, case geometry etc to change.

          4. but then as that same battery size on a pi

            In both cases you’d be running them off of a relatively large power bank or a wall adapter anyways, so it makes little difference.

            And adding IO to a smartphone via an intermediate chip on the USB port does three things: adds power consumption, adds work/complexity, adds extra problems to your project. What you end up doing is using your smartphone to program a bridge chip to act as your IO controller. Why torture yourself?

          5. In both cases you’d be running them off of a relatively large power bank or a wall adapter anyways, so it makes little difference.

            Maybe, but some folks like efficiency as their electric already costs too darn much, or they are off grid. Or maybe they just like a system they can actually move easily and it will stay running for hours/days.

            Don’t get me wrong I’ve argued before a Pi is great for these sort of projects, as building your own anything lets you make those choices and compromises and despite all the negativity on its power consumption here for a very capable computer it is still decently energy efficient as a general rule – it just doesn’t hold up well against the smartphone chips at all, so if you could really use them…

            What you end up doing is using your smartphone to program a bridge chip to act as your IO controller. Why torture yourself?

            Is that really a torture? I’d have to argue for many projects it would actually be the best way to approach the task – that crucial PID loop or 8 on your self balancing robot unicycle is something that really needs to run in ‘realtime’, and by that separate chip method all the higher brain functions can be handled by the other device while the essential stuff keeps on working in the hind brain taking in new orders as they come, having any data packets to go the other way fresh and ready to report (or spitting them out constantly with no care if the other side is listening). Obviously won’t always be better, but it sure would be nice to be able to make that choice, rather than have to take the Pi type option as its the only thing that actually works…

          6. as their electric already costs too darn much

            Now that’s just grasping at straws. We’re talking about devices that consume single Watts, which is a lot in terms of mobile battery powered devices, but completely negligible in terms of your power bill.

            is something that really needs to run in ‘realtime’, and by that separate chip method

            Yes, but now you’re using “that other chip” which we already had in the first place. You’re just adding the second non-essential smartphone into the equation for the sake of adding a smartphone that you didn’t need in the first place.

  7. You can get BT to serial modules that use the standard AT commands – so you have a fixed standard that requires less software, and people made software to employ that, or you can use a terminal which is also available.
    Point being that once you got a serial connection on your phone you got a start.
    And of course you can get a ESP module or some such and then BT/WiFi to the phone and get access to various things like I2C, and program it to accept serial (including AT) commands if you wish to avoid more tricky software than a terminal on the phone.

    And phones also accept HID input over BT, including mouse and gamepad, which also opens possibilities because you can also use that to automate things for instance.
    And then there is the audio output, you could encode data and commands that way. And lots of stuff has optional alert tunes, so if you have an external micro controller that can recognize something set as alarm/ring tone then you can make it do things using existing software.
    I’m just spit-balling here, but the point is that there are ways hackers can do things that are not part of the google/apple plan.

    I wonder though, can you output BT audio and speaker audio at the same time on phones/tablets?
    Or is there software to force that if it’s not part of the default functionality?

  8. this is a huge reason i dont use smart phones. the tiny screen and need to carry readers around everywhere is the primary issue, i dont like touchscreens, and i seldom make actual phone calls. anything else i can do with the phone i can do on my computer better and faster. except maybe take pictures, i dont keep a camera and mic plugged into my computer for a reason and if i need a photo i use a dedicated digital camera that is over a decade old at this point.

    as a gadget its not compelling at all. its more of an accessory really. too much lock in and too much control over everything by the manufacturer/cell provider. this is why windows 11 gets so much hate because its doing everything phones currently do, spy on you, farm data, push ads, etc. computers can avoid that if the user is careful what they install.

  9. The real reason we don’t have hackable phones is because 99.999% (or more) of users simply won’t use the hacking features, most won’t even know those features exist to start with.
    Heck, I’m in a vanishingly small minority already just by using adbshell to get in there and excise a bunch of otherwise uninstallable bloatware from my phones.

    Why would a phone manufacturer spend any time or resources adding a software feature that almost no users will even know is there, let alone know how to use, let alone using more than once and thinking ‘that’s cool I guess’.

    Is anyone going to volunteer to piss into the wind trying to propose to the smartphone manufacturer that they sbould blow holes through their system by opening up to attack by bad actors, all to appease the idle curiosity of a handful of people inamongst the billions of users who don’t care about such a thing?

    We can’t even get a headphone jack, and ‘lots’ of people complain about that, but a debug or I2C port and open software stack!?! No way, no how.

    And then who is going to provide the ongoing support for these features that are almost never used?Someone has to pay the wages of the engineers doing that work… And who is going to support the clueless ‘normie’ who stumbles on these features and inadvertently bricks their phone with all their photos and messages and precious high scores lost to the void? Statistically it will happen more than once, we have a couple billion monkeys banging away with their black slab typewriters, thd these monkeys posess intent….

    If you want to hack on your phone, get the SDK that the developers use and write an app, it’s all available.
    If you want to hack the hardware, get to reverse engineering. Nvidia and Intel ain’t letting their IP out to the casual joe PC user, why would Google/Samsung/etc do the same? Especially seeing that basically ‘no-one’ wants it.

    1. If you want to hack the hardware, get to reverse engineering. Nvidia and Intel ain’t letting their IP out to the casual joe PC user, why would Google/Samsung/etc do the same? Especially seeing that basically ‘no-one’ wants it.

      big difference – the Intel, AMD and Nividia PC markets are full of standards that make things interoperable simply by plugging them into each other, with mature software stacks that already know how to use the hardware. The secret sauces (which are also usually optional – as you don’t have to use them though performance would suffer if you don’t) are all behind an interface you can actually just use. Where all the hardware on your phone is generally not even going to be bootable at all with anything but the original vendor’s kernel, as even the device tree to define where the hardware is so you might just be able to boot something else using the existing opensource drivers isn’t published anywhere etc.

      For instance I can’t put a different model of display on a phone board and have it work without deep secret knowledge, shockingly good fortune or serious reverse engineering. Where to take the AMD powered steamdeck as an example all I have to do is desolder the awful WIFI chip it came with and drop in a better say intel one, make sure the right driver is available and it will just work, and with Valve being Valve even though the display on the steamdeck LCD isn’t of of these just plug and play standards they have made the platform open enough that you can look at their BIOS source and put in the changes required to make the DeckHD (or any other compatible electronically but needs configuration) screen work, and nothing about doing so would upset using the machine…

      1. The thing with phones is that they’re highly power and cost optimized, so even the CPUs aren’t exactly standard in the sense of how PC CPUs are standard. It depends on what features the manufacturer decided to license and include all the way down to the actual silicon, which depends on what features it was actually designed to use. It’s a naturally heterogeneous platform, which is why Android runs all the apps on a virtual machine just to be able to run them.

        So if you want it to be more “plug and play”, you need to standardize, but then you lose optimization and add cost, which would make them worse as mobile phones.

  10. What really kills hacking is that there are too many phone models and they become obsolete too fast. Even though LineageOS supports hundreds of devices, I generally won’t find my phone on the list.

    Though operating system and application lockdown doesn’t help either. It’s hard to use alternate distribution for your main phone when bank and payment apps refuse to work on an unlocked phone.

  11. You can use a (linux) container on pixel phones and Samsung DeX is quite usable.
    I think we should keep the bottom layers alone and use something on the top of the stack.

    1. To me that is fairly backwards as most phones get abandoned from a software POV really really fast, and where usually rather behind even while they did get updates. Using a container of sorts on top is fine, even a good idea in many cases but it doesn’t do you much good if the foundations are rotten and you can’t deal with that.

  12. adding software and hardware features to a device potentially raise hardware cost, reduce reliability and maintainability, impact mechanical design, impact aesthetics, reduce security and increase customer support cost. manufacturers, i’m sure, include features that benefit the greatest number of customers. they can’t please everyone. i’d suggest, if you want to develop novel features and have a completely programmable device, to start with an existing open source device and build on it.

  13. My HTC HD2, now that was a hackable smartphone. Hours spent just flashing random Winmo 6.5 or Android 2.3 roms. Or hell, even Windows Phone 7.
    That phone has always felt like I owned it. However, like many of these devices, it was due to the excellent community of like-minded individuals who cracked open this powerful egg.

    I wish something like that returned. In the meantime I just use my phone for communication and have plenty of devices at home for hacking stuff.

  14. I love the I2C idea. It does feel like the minimum needed to interface with simple hardware.

    My concept for “smartphone extender” was going to be a USB hub in the case. Expose the pads of the USB hub so the user can solder any device like microSD adapter, kinda like a console mod kit made of separate PCBs.

Leave a Reply to cplambCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.