[HN Gopher] What is AT&T doing at 1111340002?
___________________________________________________________________
What is AT&T doing at 1111340002?
Author : mperham
Score : 1003 points
Date : 2021-11-07 01:26 UTC (21 hours ago)
(HTM) web link (scribe.rip)
(TXT) w3m dump (scribe.rip)
| 0cVlTeIATBs wrote:
| When I read about "binary blobs" present in electronics like in a
| SIM, a baseband processor, or DDR memory controller or CPU
| management engine, the risks they pose seem distant. This opens
| my eyes a bit to that they actually do phone home, hidden from
| and unblockable by the OS.
| jcun4128 wrote:
| > binary blobs
|
| Was a concern with Pinephone but doesn't seem to be the case
| anymore from what I saw. (referring to modem)
| tmzt wrote:
| Does it allow disabling STK apps out of the box or just with
| modified Linux on the Quectel? Are there any details?
| lxgr wrote:
| You can't disable STK applications: They are an integral
| part of the SIM card. If anything, you could hide the user-
| facing icon, but that wouldn't do anything about any
| background processing the applications might be doing.
|
| However, they can only interact with the baseband in any
| case: While that still allows extensive tracking and
| potential mischief (like making expensive calls on your
| behalf), this is nothing your phone provider can't already
| do, i.e. knowing where you are and bill you arbitrary
| amounts for services you might not have initiated (when on
| postpaid).
| jcun4128 wrote:
| I don't know about that, here is more info:
|
| https://www.pine64.org/2020/01/24/setting-the-record-
| straigh...
|
| > In short, unless you explicitly send data to the modem,
| it is never in contact with the blobs running inside it.
| The modem cannot send any data to the phone unless phone is
| willing to receive it
|
| I guess there are some legal concerns with open source
| modems
|
| http://wiki.openmoko.org/wiki/Open_GSM_modem
| marcan_42 wrote:
| The Pinephone is just like every other phone in this respect.
| The baseband runs a closed blob that talks to the SIM and can
| send arbitrary SMSes of its own accord.
|
| There are no viable fully open source phones in existence
| today, particularly the baseband.
|
| The more practical question is around whether those binary
| blobs can _take over_ your OS, not just do things behind its
| back. This is what sets apart devices like the Pinephone and
| Apple M1 Macs (which make an effort to isolate blobs from the
| main OS running on the AP) from typical Android phones and
| Intel PCs (which have blobs in hyper-privileged positions
| that have full access to the entire system).
|
| Yes, I'm putting Apple M1 machines on a similar level as the
| Pinephone in this respect. How well designed a device is from
| a security/privacy perspective is tangential to whether the
| manufacturer markets themselves as an open source friendly
| company. It turns out Apple have done a great job making sure
| even their own blobs aren't allowed to take over the system.
| Once you run you own OS on an M1 machine, you're in a similar
| security position as on a PinePhone (though not exactly the
| same; M1s run more blobs, e.g. the display controller, so in
| principle a colluding set of malicious blobs could do more
| damage that way, but they still wouldn't be able to directly
| compromise your OS's execution).
| myself248 wrote:
| I would put the Librem 5 in this category too. The baseband
| is treated as untrusted, and isolated in every possible way
| from the application processor.
| robbedpeter wrote:
| Can that closed source blob be bypassed and still allow
| compatible communication with carrier networks? Or is there
| some ip or contract nonsense that allows Qualcomm this
| stranglehold?
|
| This seems like exactly what we dealt with in requiring
| phone companies to allow dialup modems to connect to
| whoever the customer wants, and so on. Seems shady as hell.
| marcan_42 wrote:
| There are significant regulatory issues involved. In
| principle it's possible (see osmocombb), but the legal
| hurdles around actually having user-controlled basebands
| in a shipping product are significant.
|
| Of course, nothing says the baseband couldn't be open
| source, and even if codesigning is involved, the
| manufacturer could sign verifiable builds that can be
| reproducibly built. That should solve all regulatory
| concerns while still allowing users to inspect the
| baseband firmware for flaws or backdoors.
|
| But, of course, no actual baseband manufacturer cares
| about that.
| judge2020 wrote:
| Most likely the blobs are signed/encrypted and the modem
| ensures that before running them, so without them it
| wouldn't work.
| robbedpeter wrote:
| I guess I was thinking more in line with SDR or foss
| hardware and not using Qualcomm at all. I need to do a
| deep dive, but it looks like there's a couple FOSS 4g LTE
| and 5g modems around - maybe running a soft phone and
| personal voip setup would bypass a lot of the security
| concerns.
|
| It sucks that any time you start to inspect almost any
| tech, there are assholes trying to exploit every last bit
| of data and microamp of processing power to screw you in
| some way.
| marcan_42 wrote:
| SDRs are for research and base stations. Trying to do a
| mobile phone based on an SDR stack would eat through your
| battery in minutes. You need dedicated silicon.
| userbinator wrote:
| I believe mobile radios _are_ effectively narrowband
| SDRs, optimised for the application. Hence the concerns
| around firmware and FCC certification.
| marcan_42 wrote:
| Kind of, but they are built around DSP architectures with
| dedicated hardware accelerator blocks. It's not the same
| thing as GNURadio.
|
| _Base stations_ are often built out of more generic SDR
| tech, and those do chew power like crazy.
| nucleardog wrote:
| Besides the technical difficulties (trying to reverse
| engineer the modem internals and reimplement the firmware
| with no clear reference; likely encrypted and signed
| firmwares; etc) there's a good chance there's also legal
| issues.
|
| If the hardware itself is capable of operating outside of
| its license (frequencies, modulations, etc), then various
| certifications from the FCC would likely be invalidated
| by replacing the firmware and it would become illegal to
| operate.
| boppo1 wrote:
| How do you know this for certain about M1s?
| nulbyte wrote:
| > what a telecom engineer would call an "NANP E.164".
|
| NANP and E.164 are standards. NANP stands for North America
| Numbering Plan. E.164 is the international analog to NANP for
| public numbers. No telecom engineer would call a number an "NANP
| E.164." The number of a network element like an SMSC is simply
| called an address.
| daneel_w wrote:
| As a former software developer in telecom who worked a lot with
| SMPP, I'd just call it a special-purpose MSISDN.
| nulbyte wrote:
| That sounds entirely reasonable.
|
| I just wish authors would stop trying to add random (and
| wrong) technical information to sound cool. The topic was
| interesting on its own without embellishment.
| djbusby wrote:
| Author is in Romania, and those two items are each unique
| links to their respective Wikipedia articles.
|
| It's not embellishments, it's information
| sdoering wrote:
| I am wondering if this is also happening in the EU or with
| customers from the European Union. The provider would probably
| put something to the effect of "we can do what we want" into
| their fine print.
|
| But I am not sure if this is legally clear cut under the
| regulations of the GDPR.
| p_l wrote:
| > I am wondering if this is also happening in the EU or with
| customers from the European Union. The provider would probably
| put something to the effect of "we can do what we want" into
| their fine print.
|
| > But I am not sure if this is legally clear cut under the
| regulations of the GDPR.
|
| > I am wondering if this is also happening in the EU or with
| customers from the European Union. The provider would probably
| put something to the effect of "we can do what we want" into
| their fine print.
|
| > But I am not sure if this is legally clear cut under the
| regulations of the GDPR.
|
| Those messages are part of the original reason for SMS
| existence, and yes all networks use them - both remotely
| triggered and unsolicited like in the article. They are vital
| to operation of the network. Allowing end users to message over
| this channel was a relatively late addition to the spec.
|
| Effectively, for many good reasons, the demarcation point
| between _your_ part of the device and _provider part_ is the
| interface between application processor (what runs Android /iOS
| etc) and the baseband processor which handles the stuff you
| need a license for, with the licensed party being effectively
| the provider.
|
| When it comes to GDPR, what actually happens is that the
| providers can't escape handling PII anyway, as it is crucial
| for their operation. Usually it means that there are some heavy
| safeties on access to PII, both practical and legal, but
| operations crew has a lot of capability and thus
| responsibility.
|
| Main difference seems to be that in EU, the carriers can't get
| away with as much monetization of this as they can in USA.
| lxgr wrote:
| The mechanism described does not give any information to the
| network that it doesn't already have: The IMEISV is part of the
| regular network sign-on procedure.
|
| This is probably just an optimization so that they don't have
| to keep track of changing IMEISV/IMSI-pairs in their database,
| for whatever they do with that.
|
| In fact, it might be even more GDPR-respecting than the
| database alternative: If the purpose is to trigger some updates
| that should happen with every phone switch, it removes the need
| to track this data server-side.
|
| Realistically, it will be stored anyway, as mandated by many
| countries' data retention laws.
| Scoundreller wrote:
| Now somebody needs to create a shim/blocker board.
|
| Some shims already exist that intercept phone<->SIM comms for
| carrier unlocking and ???
|
| https://www.geveypro.com/
|
| https://www.dhgate.com/product/ios14-x-5g-unlocking-turbo-si...
| mike_d wrote:
| There are all sorts of carrier specific messages that phones
| communicate. Carriers have systems that detect anomalous
| activity and blacklist them from towers because they assume the
| handset is broken and they don't want it to cause problems for
| other subscribers.
| fortran77 wrote:
| It's interesting that this message even came up when the user's
| messages were subpoenaed. This was not in the set of "user
| messages" and a case could be made for not including it at all.
| daneel_w wrote:
| I bet they bill for it, on purpose, like with so many other
| "mystery charges". It's after all hundreds of millions of
| dollars per year worth.
| KennyBlanken wrote:
| Not sure why you got downvoted. All the carriers make a lot
| of money on charges related to subpoenas and warrants from
| LEO.
| easton wrote:
| I was wondering how AT&T knew I got a new phone when I just moved
| my SIM over. That seems like a over complicated way to do that.
| Seems like when it does the initial handshake with the network
| the different IMEI would be enough (unless this _is_ the initial
| handshake).
| kevingadd wrote:
| Just looking at the IMEI would require AT&T to look stuff up in
| a database, this way the SIM itself can report the phone change
| instead
| ChrisMarshallNY wrote:
| It should be interesting to see what voice-sent messages will do
| to "driving while txting" charges/lawsuits.
|
| I have an iPhone. I often send "Siri-texts" while driving ("Hey
| Siri, send a text to my wife, saying that I will be home in
| fifteen minutes.").
|
| There's no way to tell, upon reviewing the conversation, whether
| or not the text was sent by hand, or by voice.
| thrwyoilarticle wrote:
| Yet another win for Android users whose wives receive:
|
| 'Only way home no change on my way home yes send'
|
| No jury would convict.
| robniep wrote:
| iMessages dictated through Siri are labeled as "Sent by Siri"
| for recipient. I'm not sure why Apple doesn't display it for
| the sender.
| marcellus23 wrote:
| Yep, there must be some kind of flag on the message payload
| to indicate Siri dictation. I wonder if that flag gets sent
| through SMS at all though, if the recipient is not on
| iMessage. My guess is there's nothing in the SMS spec for
| arbitrary user data like that, but maybe I'm wrong.
| [deleted]
| WaitWaitWha wrote:
| It is always a pleasure to watch the young ones _rediscover_ the
| world. :D
|
| Yes, carriers should be more transparent. Yes, even in general IT
| circles, this is not well known. This is known and not surprising
| in digital forensics circles. You should have seen the SS7
| shenanigans!
|
| I have a special corner in my heart for AT&T. The dark, dank,
| where all-my-monsters-live corner. Once, I have asked them to
| send me telco logs, they sent me 30 some CDs with the logs, but
| only origination details. Then, on further legal nudging they
| send me the other half, again in 30 some CDs. 60 CDs. They didn't
| even fill the discs, so the entire DB ended up to be ~17GB.
| numair wrote:
| Ahh this is so useful that it's at the top of HN.
|
| We've (probably) arrived at one of those "hidden" dominant
| operating systems out there in the world: JavaCard OS. It's not
| just (probably) in your cell phone SIM, it's also (probably) in
| your credit cards. Add all of those devices up, and you realize
| that, in a weird way, if aliens were to inspect the activity of
| humans, they'd say, "the humans seem to be using some sort of
| weird thing they call 'JavaCard OS' to run their society."
|
| If anyone is a JavaCard OS master, shoot me an email -
| numair@numair.com. I'm having some IC card issues that could use
| some external input...
|
| In terms of the linked article, I think this part makes it clear
| what's going on, if we are to take an innocent view on things:
|
| > After the lab work, deposition of an AT&T employee revealed
| that the only other trigger is a firmware update of the baseband
| processor. That is also consistent with the SIM requesting the
| IMEISV, since the "SV" part means "software version", and it is
| updated every time the baseband processor loads new firmware. In
| this particular case, the phone had recently downloaded an update
| that included new baseband firmware. That was almost certainly
| the trigger for this message.
|
| If I was a network engineer, I'd probably want a way to figure
| out whenever someone's putting new equipment on my network. This
| is a brilliantly sneaky way to do it. There's probably other uses
| for this, though, and you can imagine that your favorite
| intelligence agencies have thought about it long before it showed
| up in a Hacker News article...
| lxgr wrote:
| Not a Java Card expert by any means (more of an interested
| party), but are you able to share what you're working on? I'm
| always curious about new smart card use cases :)
| numair wrote:
| It's the next thing on my list of things to write -- and
| related to a very weird security vulnerability I've found in
| a lot of corporate workflows -- so, it should be done
| sometime this month.
| exikyut wrote:
| !!
|
| I opened https://numair.com in a new tab so I could stumble
| on it in a bit (figuring this info would turn up there),
| only to discover a parking page (and TLS cert Chrome did
| _not_ like). Double-checked the spelling twice.
|
| Is it just an email domain? Where can I eventually read
| about this? Very idly curious :)
| numair wrote:
| Yikes, sorry -- this is one of those domains that got
| registered in the InterNIC days and transferred off years
| later, so I never bothered to move the A record to an IP
| that doesn't use an obnoxious parking page. I'll add that
| to the to-do list. It is very much email-only at this
| point.
|
| I'll probably publish the paper on my company website,
| once that's up -- having a bit of an identity crisis at
| the moment to figure out whether everything gets done in
| English, or Japanese, or both -- probably both...
| exikyut wrote:
| Ah, I see! Very cool. (And also cool to learn that
| domains showing parking pages can send/receive legitimate
| email. I would never have expected that!)
|
| It would make a lot of sense to translate to Japanese if
| the issue is Japan-specific, but I can also see good
| justifications in simply releasing papers in _all the
| languages_ :). That being said, if I had to pick a
| language to prioritize, well, it 'd be the language with
| the widest security audience. Yep.
|
| Look forward to seeing the paper :) (thanks for the
| email)
| ganzuul wrote:
| If the SIM can act as a TPM for the binary blobs and report
| tampering, it could be the TLAs have actually been doing what
| they are supposed to be doing: securing infrastructure.
| TheRealDunkirk wrote:
| Is this the card "technology" that ran DirectTV tuners as well?
| I had a friend who was, at one point, running 7 hacked systems,
| and recording everything he could to burn to DVD, but I never
| got into that.
| zionic wrote:
| >a friend
|
| uh huh! :)
| TheRealDunkirk wrote:
| If I had hacked 7 units -- and hacked scores of cards for
| other people -- I wouldn't had to have asked that question.
| cronix wrote:
| All cable systems in the US are mandated to supply users with
| those "CableCards" if they request them to decrypt cable tv
| channels, so you can use your own tuners and not be forced to
| rent one forever from the cable company. So, it wasn't just
| Dish. TiVo also uses them. The first one was free and the
| second one was $1.50/mo. Each could decrypt 4 simultaneous
| channels. I used them for about 15 years until cancelling
| cable earlier in the year. $1.50 vs a $30 cable box saved
| quite a bit over the years.
|
| Here's the page on xfinity for them. They're just PCMCIA
| cards, which used to be popular. My first laptop had a PCMCIA
| port which I used for a GPS device in the 90s before they
| were all-in-one chips.
| https://www.xfinity.com/support/articles/about-cablecards
| Bellyache5 wrote:
| And before CableCards some cable settop boxes had
| FireWire/IEEE1394 ports on them that provided the raw video
| stream. You still had to rent the cable box though.
| _joel wrote:
| A long, long time ago it was possible to decrypt the
| original VideoCrypt with a serial connection attached to a
| smart card that ran software like 'Voyager' that could
| decrypt or bypass the keys/locks necessary to decode. This
| was running on a 286 laptop. Seems like an absolute
| lifetime ago now.
| _joel wrote:
| They use C.A.M.s with smart cards that are embedded with a
| microcontroller.
|
| https://en.wikipedia.org/wiki/Conditional-access_module
| bobberkarl wrote:
| I worked on javacard for 2 years. I was working on bringing iso
| 14443 bus cards to the mobile with nfc. (Previous failed
| startup)
| numair wrote:
| Can you send me an email? Your bio on HN is empty...
| kgermino wrote:
| Not for nothing: so is yours. The email field isn't
| publicly visible, so you need to put it in the about field.
| numair wrote:
| Thanks for the reminder!
| raybb wrote:
| Given the importance you stated, the Wikipedia page could use
| some love https://en.wikipedia.org/wiki/Java_Card_OpenPlatform
| unethical_ban wrote:
| This is something at home in the pages of 2600 Magazine. I didn't
| know the SIM could send things without the main OS knowing.
|
| Could that SimTrace2 device could be used as a kind of firewall
| to prevent the SIM from acting independently of the phone?
| emodendroket wrote:
| This seems like a terrible series of individually reasonable
| decisions that could easily lead to wrongful legal outcomes.
| jaclaz wrote:
| Side question:
|
| >The RP destination number, +14047259800, is a normal-looking US
| number, what a telecom engineer would call an "NANP E.164". A
| Google search turns up documents showing that this number is
| associated with an AT&T "service control point" (a sort of
| server) that was made by Sun Microsystems. This is most likely a
| Sun Solaris server running an Oracle SMSC package, physically
| located in Atlanta, GA. Interestingly, this is not the SMSC
| number that AT&T uses for normal texting (+13123149810). This is
| a special SMSC that is used for special applications.
|
| How many SIMs has AT&T around? (I assume millions.)
|
| A single Solaris server (which I imagine to be a little dated)
| can manage the whole stuff?
|
| It must be pretty much efficient or these data must be
| transmitted very seldom.
| lxgr wrote:
| In this case, it would be transmitted only when a SIM is turned
| on in a new device for the first time. Probably still a lot of
| traffic, but a drop in the bucket compared with the remaining
| signalling traffic a large mobile network sees every day.
|
| These systems can probably also be scaled almost without
| limitation for the same reason.
| jaclaz wrote:
| >In this case, it would be transmitted only when a SIM is
| turned on in a new device for the first time.
|
| But this is seemingly not what happened in the case at hand.
|
| >In this particular case, the phone had recently downloaded
| an update that included new baseband firmware. That was
| almost certainly the trigger for this message.
|
| So, every time the baseband firmware is updated, likely
| millions of devices need to send that SMS to that single
| server, unlesss the updates are deployed somehow
| sequentially.
|
| And if these firmware updates happen not very often, which
| probabilities were that just after such an update the person
| (suspected of distracted driving) crashed with the car?
|
| Like 0.00000000001 or very, very, very rare chance.
| lxgr wrote:
| That's a very valid concern, and maybe there was just such
| an "event flooding prevention" mechanism at play, deferring
| the IMEISV report by a random time?
| skissane wrote:
| > A single Solaris server (which I imagine to be a little
| dated) can manage the whole stuff?
|
| I don't know what they run, but Oracle still sells some quite
| beefy hardware. SPARC M8-8 servers can have 8 CPUs of 32 cores
| each, for a total of 256 cores. The CPUs are clocked at 5 GHz
| and use a 20nm process. Maximum 8TB of RAM. The CPU and the
| process are somewhat dated but still can do a lot.
|
| Fujitsu has even beefier SPARC servers - the M12-2S has 12
| CPUs, 384 cores, max 48TB RAM, albeit only at 4.25GHz. Fujitsu
| SPARC servers run Solaris too and Oracle resells them.
|
| So I'm sure SPARC can handle this use case, just not very cost-
| effectively-whatever it can do, an x64-based solution is likely
| to be able to do the same cheaper. And it is a technological
| dead-end - Oracle plans no further CPUs or major OS versions,
| but they'll keep selling their current lines as long as people
| are willing to buy them. Fujitsu is moving away from SPARC too.
| Rumour has it Oracle and Fujitsu were negotiating for Fujitsu
| to buy the SPARC hardware business, but they couldn't agree on
| terms, and now Fujitsu has decided to move away from
| Solaris/SPARC and towards Linux/ARM instead. Fujitsu still have
| a new SPARC CPU release this year on their public roadmap, not
| sure if it is happening, but if it does it is probably their
| last.
| numair wrote:
| That Oracle-Fujitsu SPARC acquisition rumor is fascinating.
| Do you think Fujitsu's A64FX line can hold its own against
| Ampere's stuff and the AWS Graviton CPUs?
| jaclaz wrote:
| Thanks.
| tata71 wrote:
| https://grapheneos.org/faq#cellular-tracking
| rsync wrote:
| Even in relatively technical circles, like HN, many people are
| not aware of this and I use every opportunity I have to
| reiterate:
|
| A SIM card is a _full blown computer_ with its own CPU and
| memory.
|
| Your carrier can upload and run _arbitrary code_ without your
| consent or knowledge. They can do this at any time.
|
| This means that your "phone" is actually _three_ different
| computers running in concert - the actual phone itself (iOS or
| Android or Symbian), the baseband processor running the baseband
| code, and the SIM card.
| sydthrowaway wrote:
| I thought SIM was just memory (RAM/ROM). What CPU architecture
| does it use?!
| helsinkiandrew wrote:
| These defcon slides give a good overview of one
|
| Atmel AT90SC25672RU, 8-bit AVR, 256KB ROM, 72 KB EEPROM, 6 KB
| RAM, Between 20 & 30 MHz
|
| https://media.defcon.org/DEF%20CON%2021/DEF%20CON%2021%20pre.
| ..
| userbinator wrote:
| That's one example, but they are usually an 8-bit
| architecture with special tamper-resistance features,
| similar to what's found on payment cards.
| lxgr wrote:
| That's definitely still true for many existing cards, but
| newer ones are switching to ARM-M based architectures, as
| far as I know.
| barrenko wrote:
| So next question, is a credit card chip also a computer?
| monocasa wrote:
| Yeah, most of this applies there too.
| PeterisP wrote:
| Yes, a very limited one but you can put a bunch of
| interesting things there, the EMV standard documents how
| other apps should be put there so that the customer can
| have a card that works both as a credit card in CC
| terminals and also have additional features that are
| accessible either in specialized terminals or custom CC
| terminals with explicit support enabled e.g. some loyalty
| card or discount scheme.
|
| Here's a list (IMHO not exhaustive) of some apps put on
| EMV cards https://www.eftlab.com/knowledge-base/211-emv-
| aid-rid-pix/ - there are various identity card solutions
| both from governments and companies like Microsoft,
| there's https://en.wikipedia.org/wiki/OpenPGP_card ,
| there's various solutions for store loyalty cards.
|
| However, I don't consider this aspect as any risk to the
| user, since when using the standard payment card
| functionality your card payments already have no privacy
| or security whatsoever from the issuer of your card, from
| a technical perspective the issuer will (by design) see
| and manage (authorize, revoke, etc) all the transactions
| and the card + terminal is just one of the channels for
| sending cardholder-initiated transactions to them. It
| would be technically appropriate to treat it not as "your
| card" but "issuer's card" that the cardholder uses as a
| token to use when the merchant communicates with the
| issuer about the bill.
| fulafel wrote:
| A good rule of thumb is that nothing is just memory
| wothout a processor. Including stuff that is sold as jyst
| memory (eg SD cards).
| kreeben wrote:
| My SIM card has 30x more horsepower than my C64. Mind
| blown.
| sydthrowaway wrote:
| Thats a joke..
| DeathArrow wrote:
| Every device can do things behind the users back. Intel
| Management Engine runs even when the computer is turned off,
| contains a full blown operating system and has access to tcp/ip
| stack.
|
| If privacy is a concern, no device should be trusted. By device
| I mean anything that contains a chip.
|
| What's worse, people might suspect their phone or PC might be
| leaking data to third parties, but they will be less suspecting
| about their TV, their fridge or their car. But since anything
| is becoming smart these days, one can assume that anything that
| runs out of electricity is a potential privacy problem.
| csomar wrote:
| Shouldn't that be necessary if you want to boot your PC from
| the network?
| tentacleuno wrote:
| Realistically, how many real people actually use PXE? It
| must be tiny. Seems strange to include what is essentially
| a business function in a product for normal people.
| saltminer wrote:
| Any IT department that images devices, for starters. The
| number of people who actually use it is quite small, but
| the number of devices those people image with PXE is
| massive.
| jiggawatts wrote:
| The NSA specifically orders motherboards without these
| management components. No one else can typically get them,
| they're not available to people like you and me.
|
| I think some things are overblown and unjustified paranoia.
|
| Other things? Justified paranoia.
| raverbashing wrote:
| The IME is just a "smarter than needed" addition, so it's
| probably not too hard to take it out
|
| But every PC has a SMC which deals with things like power-
| on, WOL, etc
| _kbh_ wrote:
| You can remove "modules" of the management engine but
| it's responsible for booting the x86 cores so you cannot
| entirely turn it off.
| ranma42 wrote:
| > No one else can typically get them, they're not available
| to people like you and me.
|
| Isn't that just setting the HAP (High Assurance Platform)
| bit in the ME blob to disable it after bring-up? For Intel
| platforms it is possible for the end-user to modify the
| firmware themselves in many cases.
| https://hackaday.com/tag/hap-bit/
| RalfWausE wrote:
| My approach as an practicing paranoic: Use retro Computers.
| coldacid wrote:
| This is the avenue I've started taking, myself.
| DeathArrow wrote:
| How much retro are we talking? If retro enough we can't
| use them for any modern use case.
|
| Maybe something like a RISC-V core written to a FPGA by
| yourself is pretty safe.
| RalfWausE wrote:
| It all depends on the one question: What IS your use
| case?
|
| Mine is as an tutor on an evening college, casual writer
| and some dabbling into some embedded projects. For THIS
| use case my (very retro) Atari 520 ST with 4 MB Ram is
| totally working. Is it nuts? Yup, but i can be sure that
| no state trojan is monitoring my totally boring
| behaviour.
| cliffj wrote:
| I think you were most likely right, coz you just reminded me
| one incident that I talked with my colleagues regarding solar
| power one day and just one day after that I received a cold
| call trying to sell me some solar solutions. There were 3 ppl
| in the conversation, I was the only one without solar at home
| and I was the only one received the call too. How likely that
| would be a coincident?
|
| Such things are so scary but what can we do? For most of the
| ppl, they cannot prove something like that happened. For me,
| I might be able to prove it but I cannot easily do it without
| significant efforts.
| gambiting wrote:
| >>How likely that would be a coincident?
|
| People say this all the time but literally no one has been
| able to prove any kind of secretive listening-based
| advertising.
|
| The best explanation is that either you or someone else in
| your household has searched for something related and now
| it's appearing in your ads, or actually more likely,
| advertisers are incredible at linking cookies to actual
| users, and it's enough if your friend searched for solar
| panels and then his interests were associated with you.
| Like, advertisers can figure out all your friends have
| solar panels but you don't - so they show you ads for them.
| It's far easier to do than listening and to your
| conversations covertly.
| ThunderSizzle wrote:
| If you have "OK Google" or whatever it is turned on, it
| is indeed listening to you.
|
| I've seen it with my parents. They will talk about it,
| not to their phones, but around their phones, and they'll
| start seeing ads for something they talked about.
|
| I've always had that featured turned off (I have to press
| the button), and I don't notice it.
|
| My wife also sees it with her iPhone with siri turned on.
| I talked to her about, for example, Jordan Peterson, and
| her phone starts blowing up with Jordan Peterson on
| Instagram.
|
| I dont think it's pure coincidence.
| gambiting wrote:
| >>I talked to her about, for example, Jordan Peterson,
| and her phone starts blowing up with Jordan Peterson on
| Instagram.
|
| And why did you talk to her about Jordan Peterson? Is it
| perhaps because you read an article about Jordan Peterson
| earlier? If so, I assume you both share the same IP at
| home - so she starts seeing things you viewed or browsed.
| Facebook owns Instagram too, so if you look at something
| on Instagram it's not that wild that your partner's
| Instagram starts showing her things that interest you -
| it's just association.
|
| >>If you have "OK Google" or whatever it is turned on, it
| is indeed listening to you.
|
| Sure, and that's what I meant in the first paragraph - no
| one has been able to prove that this feature is sending
| your voice to Google/apple/Amazon servers unless you
| trigger the key word. Recording and sending voice would
| create some trace and no one has been able to prove this
| exist. That's not me saying it doesn't exist, just that
| for what is supposedly wide spread phenomenon, we have no
| proof it's actually happening other than anecdotal
| stories which can be easily explained by other means.
| ricardobayes wrote:
| Not sure why it's downvoted, it's been proved many times
| addingnumbers wrote:
| Professionals and hobbyists who analyze smart phone app
| behavior with APK decompilers, reverse engineering
| suites, personal cell towers, SDN radios, SIM dongles,
| mobile device emulators, etc: "Facebook apps are not
| listening to your conversations in the background, if
| they were we'd have seen it here, here, here, and here."
|
| People with anecdata about which ads they see, who think
| of cell phones as inscrutable magic: "No, they definitely
| are. I can't (won't) think of any other way they'd infer
| my interests in these topics. You can't see it happening
| because they are too smart."
| VRay wrote:
| Yeah, I hate Facebook as much as anyone, but they'd have
| way too much to lose by deploying some sort of zero day-
| based hidden listening tools
|
| I guess the financial incentive might be there for some
| shady ad network to do it, but that's just so much risk
| to take on for such a tiny gain per infected phone..
| ricardobayes wrote:
| I was talking about youtube. They do listen to show more
| relevant videos. I live in a very quiet household and if
| we say something out loud low and behold it will be in
| our recommended later.
| gambiting wrote:
| Again, anecdotes are not data. YouTube is _extremely_
| good at guessing things you might be interested in, you
| could try being completely mute in your household and
| then after a week you will have to arrive at only one of
| two conclusions
|
| 1) YouTube can read minds and they know what you just
| thought about
|
| 2) with statistical data from literally billions of
| people it's not so weird to guess what you might be
| thinking about and show you a video about it.
|
| Again, if they(your phone? Watch? Toaster?) were
| listening _someone_ would have found some evidence by
| now, a trace of voice recordings being sent or even
| something that looks like it might be voice recordings.
| Yet we have zero. It 's not happening, the much easier
| and much more probable explanation is that we're already
| tracked through every online service we ever touch, but
| also we are linked to people we live with or people we
| interact with, and for a company that possesses exabytes
| of data it can analyse it's easier to trawl that than try
| to sneak out voice recordings out of your phone.
| stagger87 wrote:
| Link?
| VRay wrote:
| Nothing like this ever happens to me with Alexa or Siri
| always listening, but I have all my web browsers locked
| down and I don't use any Facebook apps/sites
|
| I think you need to look into how pervasive and creepy ad
| network tracking is: https://www.nytimes.com/interactive/
| 2019/12/20/opinion/locat...
| boppo1 wrote:
| I, a layman, have had similar experiences. It seems
| tinfoil-tier to think my phone's mic is always on and
| running some NLP. If I wasn't loosely technical I would
| dismiss it as such.
| ThunderSizzle wrote:
| But why is it tinfoil-tier?
|
| It's basically common knowledge that if you turn on "hear
| me say OK Google" that it needs to always be listening to
| hear "OK Google". That's a green light to start parsing
| everything said all the time, which will be turned around
| for advertising. Because that's how Google makes money.
|
| Expecting Google to use data to advertise isn't tinfoil?
| theelous3 wrote:
| The tinfoil part is the parsing.
|
| Actual nlp parsing all audio, or even a tiny subset of
| devices, is far beyond Google's capabilities. It's not a
| trivial task to process.
|
| Your phone locally has some extremely basic recognition
| for "ok google", after which selective actual nlp parsing
| takes place.
| wizzwizz4 wrote:
| But detecting "oh, this is voice" is easy. Recording the
| time where that happens is also easy. Knowing when people
| are chatting around the phone, and roughly what the
| fundamental frequency of their voice is, could make
| $0.001 per person. At Google's scale, that's worth it.
|
| So long as they don't get caught, anyway, because that's
| all sorts of illegal. Especially at Google's scale. (I
| don't think Google does this... probably.)
| BenjiWiebe wrote:
| The fundamental frequency of the voice doesn't tell you
| what words they were saying.
| bruce343434 wrote:
| It's probably that psychological effect where if you buy a
| red car, all you can see is red cars. How many times have
| you received a completely random, unrelated cold call?
| tim-fan wrote:
| I think that's the the Baader-Meinhof phenomenon.
|
| From Wikipedia: Frequency illusion, also known as the
| Baader-Meinhof phenomenon or frequency bias, is a
| cognitive bias in which, after noticing something for the
| first time, there is a tendency to notice it more often,
| leading someone to believe that it has a high frequency
| of occurrence - a form of selection bias.
|
| https://en.wikipedia.org/wiki/Frequency_illusion
| thrashh wrote:
| It's probably a lot more than 3.
|
| As an EE, plenty of chips you can get are built-in computers.
| You're not going to write code that you make your users run
| (what a support nightmare!). You build your chip and provide an
| API.
|
| And as a user, do you really want to figure how to run someone
| else's code? Or do you just want a self contained unit that you
| slap onto your board that you just control via API?
|
| Think of chips as microservices.
| LeifCarrotson wrote:
| One familiar chip that end users might not expect to contain
| a computer is the IMU or accelerometer. Take a look at this
| flyer from a recent Bosch smartphone IMU:
|
| https://www.bosch-
| sensortec.com/media/boschsensortec/downloa...
|
| You might think an accelerometer just outputs acceleration
| data. I've used some that were purely analog; as an
| acceleration moved a mass, a strain gauge or piezo element
| flexed; the output wires were simply analog signals. But
| these excerpts:
|
| > ...combines precise acceleration and angular rate
| measurement with intelligent on- chip motion-triggered
| interrupt features.
|
| > The IMU provides highly accurate step counting, motion
| detection
|
| > provides an intelligent power management system enabling
| motion-triggered always-on features to run inside the ultra-
| low power domain of the IMU
|
| That ultra-low power domain of the IMU doesn't have dedicated
| logic to do step counting, it has a processor. The GPS IC has
| a processor. The power management IC is not just a voltage
| regulator, it contains a processor. The uSD card or UFS flash
| IC contains a processor. The camera sensors contain
| processors. The display controller contains a processor.
| Looking at a teardown, I can't see too many more ICs on a
| smartphone motherboard...oh, I suppose the noise-
| cancelling/speak to wake functions of the microphone ADC are
| probably also implemented by a processor. Some of those,
| depending on the manufacturer's vertical integration and the
| age of the device, are inside the SoC, but many of those
| functions that you might imagine to be hard-wired are
| actually running in firmware.
| surajrmal wrote:
| Yeah, basically everything that you consider a peripheral is
| a full blown computer with its own CPU and memory. Your nvme
| controller, your NIC, your USB hub, etc. They main thing
| people need to care about is whether or not they can connect
| to the internet without going through the main CPU on the
| system. I'm not worried about storage controllers for that
| reason, but I'm relatively afraid of my modem.
| beambot wrote:
| Even the microSSD card likely has an ARM core that can be
| hacked:
|
| https://www.bunniestudios.com/blog/?p=3554
| SavantIdiot wrote:
| Funny that you needed to use microservices as the base
| analogy for embedded MCUs. It illustrates how large the gaps
| are between hardware engineering, software engineering, and
| programming, compared to when I entered the field in the
| 80's. It was possible for one person to have principal-level
| knowledge in all three fields. The 90's broke that.
| praptak wrote:
| My friend owns his grandfather's "engineering encyclopedia"
| from the era before WWI. At that time it was possible (and
| expected) for a single person to have principal-level
| knowledge in the whole field of "engineering".
| robflynn wrote:
| That reminds me of a book I had in the early days of the
| web which contained a list of the websites at the time!
| MrDresden wrote:
| I remember seeing those address books in my university
| c.s library back in '07.
|
| Many a late night was spent in the library looking up
| those addresses and seeing if some where still available.
| aspenmayer wrote:
| Yahoo was hand curated in the early days. Wildest
| timeline.
| dmd wrote:
| How about a list of all the email addresses in the world?
| https://openlibrary.org/books/OL1635233M/%21_a_directory_
| of_...
| MrFoof wrote:
| "The Internet Yellow Pages." You weren't the only one to
| have it.
| noefingway wrote:
| "The Network Information Service (NIS) was formerly known
| as Sun Yellow Pages (YP). The functionality of the two
| remains the same; only the name has changed. The name
| Yellow Pages is a registered trademark in the United
| Kingdom of British Telecommunications PLC, and cannot be
| used without permission."
| bsenftner wrote:
| A former coworker wrote that book. When it came out he
| had a little party where he declared it obsolete already.
| dylan604 wrote:
| Reminds me of the old quip "how do you know if the spec
| requirements are out of date?" - the ink is dry.
| [deleted]
| thrashh wrote:
| There's a huge gap but at the same time, each layer is
| still very similar to each other.
|
| Hardware engineering might be floor 1 of a building and
| microservices might be floor 19. Yes, they are very far
| apart, but one day, you realize that every floor has a
| bathroom. When you go down to floor 1, you might not know
| where the bathroom is but you know that it exists and how
| it will probably function. You are already 80% of the way
| there.
| jeffrallen wrote:
| Hardly.
|
| The shitter of microservices is JSON marshalling. The
| shitter of hardware is clock jitter.
| aprdm wrote:
| Yes absolutely. I've worked from chip design in vhdl to
| coding microservices and devops. It's IMO all the same
| shit with different flavours.
| Cederfjard wrote:
| Where are you drawing the line between software engineering
| and programming?
| baq wrote:
| There's no line. Programming a a strict subset of, and is
| much smaller than, software engineering. Communication,
| technical writing, customer and stakeholder management,
| system design, technology awareness and many, many more
| are what make a software engineer in addition to
| programming.
| ascar wrote:
| I personally like to compare it to building houses.
|
| Programming is laying the bricks, the cables, etc.
| Basically doing the actual building.
|
| Software engineering as in other engineering disciplines
| is more concerned with making sure everything actually
| works and fulfills certain standards of quality. The
| planning, design and architecture part of the work.
|
| For the last decades the person doing the programming and
| engineering were usually the same, but they are more and
| more drifting apart with more engineering focused roles
| like software architect.
|
| In much of the world engineer is also a protected title
| that requires formal education like with doctors or
| lawyers. The US is using it pretty inflationary.
| mek6800d2 wrote:
| Shades of the 1980s and prior decades! In the 1980s, I
| worked in the aerospace division of a Fortune 5 company.
| A headhunter called me up, was chatting, and asked me
| what I did. I said I was a "programmer". Silence on the
| other end and then, "Are there any people who design
| programs there?" "Umm, yeah, we all do." I was book-aware
| of this distinction in previous decades, but this was the
| first time I had encountered it in the real world (of a
| headhunter). I see that we "programmers" are still
| regarded as being like the streetsweepers in Victorian
| London, sweeping out a path in the manure and mud for the
| software engineers! :) (We had software architects back
| then.)
| bayindirh wrote:
| Software engineering has a higher level view which is
| more concerned about the architecture of the whole
| system.
|
| Programming is more concerned how it's implemented on the
| specific hardware/language, and how its limitations and
| advantages play a role in the implementation.
|
| You can know both, they intersect in a lot of places but,
| programming goes deeper, and software engineering goes
| higher.
| mek6800d2 wrote:
| That's a reasonable way to look at it, but there is a
| missing component. In the early 1990s, I was a
| subcontractor at a large firm which had software people
| who were only interested in designing software, down to a
| medium-level pseudocode, after which the design was
| handed off to coders. These designers were great people,
| but, on this project, none of the firm's designers and
| coders had hands-on knowledge of and experience with the
| hardware and operating system (an early version of
| VxWorks). The coders would gain this knowledge and
| experience from writing and testing the software, but not
| so the designers.
|
| My missing component was that there was no mind-to-mind
| feedback loop conveying this knowledge and experience
| gained by the coders back to the designers, from which it
| would inform the designers' future designs. (And there
| was no regular feedback about how well the design fit the
| problem and if the design required radical changes during
| coding and testing, although some of that is more an
| administrative concern than a technical one.) The
| "coders", by the way, were quite capable of designing
| their own programs - and did. I don't know why the firm
| had this subset of design-only'ers; they were smart and
| maybe the firm wanted to hang on to them and maybe
| "coding" roles were intended for brand new employees.
| [deleted]
| Lhiw wrote:
| I don't know if you can really make the distinction, is
| anyone actually hired as a "programmer" instead of an
| "engineer"?
|
| I feel like developer is the best name for what we do, it
| doesn't limit us to the act of coding and it doesn't make
| the presumption we're engineers (very few of us actually
| are).
|
| Then again if I could choose I'd probably prefer computer
| programmer, it doesn't get confused with property
| developer and pretty specifically covers what we do.
| baq wrote:
| Competent interns and other skilled juniors are usually
| good programmers but lack all the business acumen to be
| good engineers. This can't really be taught in a
| curriculum, because it's something that needs to be
| internalized by practice.
| SavantIdiot wrote:
| I know a guy that can architect optimizing compilers but
| writes shit code.
|
| That's where I draw the line.
| kevin_thibedeau wrote:
| Nowadays peripheral ICs are usually accessed over SPI, I2C,
| onboard USB, or some other indirect method. It is common
| for complex devices to have a micro on the other side
| handling I/O requests rather than spilling their guts to
| the world. That "other micro" could also be a full blown
| multi-core processor with an MMU running at hundreds of MHz
| and beyond. The difference back then is that parallel bus
| interfaces were king and custom ASICs couldn't necessarily
| afford the gate overhead of an embedded micro at all.
| bbarnett wrote:
| And thus we understand the human brain more, a collection
| of specialized processing regions, with APIs.
| bencollier49 wrote:
| https://en.wikipedia.org/wiki/Brodmann_area
| ketzo wrote:
| I mean, I'm a front end web developer, and I get fucked up
| about how little I know about _backend_ web development.
|
| Embedded programming? Dealing with _signals?!_ God forbid,
| man.
|
| There's just so much of everything! Terrifying! But fun!
| prox wrote:
| I wonder what a better approach is : do an intro on
| Assembly programming or get a SoC like Pi or Arduino to
| learn more about it.
| boondaburrah wrote:
| Intro to assembly using an arduino? :P
|
| My strategy has been to get into 80s game consoles where
| assembly programming was expected but the platform is
| small and standard enough that I can use emulators with
| memory views/debuggers & see everything going on.
|
| heck at the end I might even have a game!
| bhasi wrote:
| Nice, I'd like to do this too. Which console would you
| recommend starting with? I'd love to see an old timey
| programming manual and emulators for that platform. I've
| heard good things about Nintendo consoles, but I don't
| know where to start.
| phyrex wrote:
| I've only read the first couple of pages but this looked
| really neat: https://famicom.party/book
| [deleted]
| throw0101a wrote:
| > Embedded programming? Dealing with signals?! God
| forbid, man.
|
| "How does a USB keyboard work? by Ben Eater:
|
| * https://www.youtube.com/watch?v=wdgULBpRoXk
| joezydeco wrote:
| That's funny. I've been doing full-stack embedded
| development (bootloader assembly all the way to
| touchscreen UIs) for 30 years but the idea of trying to
| learn modern web front end scares the hell out of me.
|
| React? Angular? Node? What happened to Notepad and
| Apache?
| xondono wrote:
| I would recommend to revisit that with fresh eyes.
|
| I've found that's easier to build a simple UI by loading
| chromium + webapp than having to deal with the
| intricacies of multitarget crosscompiling.
| joezydeco wrote:
| That ecosystem used to suck heavily as of 3-5 years ago,
| but I know it's improving. But you still need Node and a
| bunch of shit running underneath to glue the UI to the
| drivers.
|
| As much as I'm starting to hate Qt, I can still have it
| up and taking to hardware in a few minutes. And the
| onscreen touchscreen keyboard is worth the money.
| xondono wrote:
| It does depend on the platform you are using.
|
| One of the devices I'm working on had to use rust (we
| were looking for some niche libraries, and we found that
| the C ones weren't working, while the Rust ones did).
|
| Building GUIs in rust is still a WIP, and I had to spend
| 2-3 days fixing libs and tweeking stuff to get to
| something that compiled but was very buggy.
|
| Instead of losing more time on that I set chromium +
| apache on the thing, and built the GUI as a web app. The
| rust executable has a simple API with actix that works
| flawlessly.
|
| In that case it was the perfect solution because I had to
| add an API for remote management anyway, but I found the
| approach quite nice to work with.
| VRay wrote:
| Node is a nightmare
|
| I can get a decently functional UI app working in native
| code with just the SDK for whatever platform it's on, but
| try to use React and suddenly I've got a web of 200
| dependencies, each more shady than the last. And that's
| just for "hello, world"
|
| Plus the JavaScript engine is single-threaded and
| insanely slow.. it's gross. I'm guessing that one of
| these days app developers are collectively going to snap
| out of it and throw Node in the trash
| joezydeco wrote:
| No, it's only going to get worse.
|
| As single-board devices get faster and cheaper by the
| week there's a flood of developers that have cut their
| teeth on Node/JS/React and they get something working on
| a Raspberry Pi and think "Yeah, embedded development is a
| piece of cake. I can do this."
|
| And maybe they're right, because doing it all by scratch
| and cobbling together robot parts to make a system work
| is just really getting to be old.
|
| I used to get annoyed at the RPi newbies but now I
| welcome it as job security because someone still needs to
| write the bootloader and drivers. And if you read
| StackOverflow/Reddit you'll see there's nobody teaching
| that anymore.
| throw0101a wrote:
| > What happened to Notepad and Apache?
|
| * https://motherfuckingwebsite.com
| BenjiWiebe wrote:
| Notepad and Apache are still present and working.
| Probably not a good choice for a payment processing
| single page online store, but fine for a simple
| informational website.
| rxhernandez wrote:
| Having done both frontend and embedded professionally for
| years, they're about equivalent in difficulty for a
| moderately complex system.
|
| For self-learning, frontend is orders of magnitude more
| accessible.
| Kliment wrote:
| Strong disagree. I do embedded development of varying
| complexity. I often have to learn and figure out new
| things, but once I have something figured out, I have it
| figured out, and I can drill down to hardware register
| level to figure things out when something is misbehaving.
|
| Every single time I touch anything web-related I discover
| that the entire landscape has shifted, all the tools I
| used last time are now abandonware, and I have to figure
| out everything anew. It may be more accessible if you're
| starting from scratch, but it's a constant treadmill that
| you instantly fall off of as soon as you do anything
| else. And when something doesn't work? Good luck finding
| out what's happening in the countless layers on top of
| layers on top of layers.
| Ginden wrote:
| > all the tools I used last time are now abandonware
|
| I think you are exeggarating. Over last few years, there
| were no hard deprecations, except for AngularJS. Many
| tools, popular in past, went "maintanence mode" and
| receive mostly bug fixes, but these tools are still
| viable.
| boppo1 wrote:
| Can one self-teach about embedded enough to find
| employment?
| AnyTimeTraveler wrote:
| I'd certainly think so. I almost did. I initially learned
| Java on my own. It's good to know at least one full
| programming language before diving into embedded
| programming, I think.
|
| Then got into Arduino programming. There are tutorials
| for that online. Try communicating with other Chips like
| a Shift-Register, then something that uses a standard
| serial protocol (ex. I2C).
|
| When you feel like you have a good grasp of the basics, I
| recommend getting a development board and doing the same
| there.
|
| Most Microcontrollers (ARM Cortex Processors at least)
| are pretty similar: You get a datasheet and a User's
| Manual. The User's Manual describes a bunch memory
| addresses, which control the built-in peripherals. There
| are excellent descriptions of what value will give you
| what result, but it can be a bit daunting to get your
| head around it at first.
|
| I recommend a chip that has a so called "Board support
| Package". I have experience with LPCOPEN. This will make
| things a bit easier, as you don't have to figure out each
| register address for each thing and can instead use
| functions like "Chip_TIMER_Enable(timer_t timer)".
|
| There is a lot more to it, but once you get started, you
| usually always see the next step.
| boppo1 wrote:
| Neat, thanks for the detailed answer!
| structural wrote:
| I self-taught enough to design and build a working PCB
| (that passed a bunch of certification testing), including
| writing programs for an ARM Cortex microcontroller. Took
| about six months of learning and then a couple months of
| design/implementation to get a product that can be sold
| and have the fundamentals in place to make similar kinds
| of products much more rapidly.
|
| It's very doable with dedicated study and I'd argue it's
| one of the best ways to get your design ability to rise
| to the level of being able to build something from
| scratch, without reference to other code / searching
| google for answers.
| xondono wrote:
| And yet it's trivially easy to understand that new shinny
| thing, and most problems you have, there's thousands of
| posts explaining how to solve them.
|
| Embedded has advanced a lot on this front, but for a lot
| if the industry, good luck finding anything but the
| original documentation.
| Kliment wrote:
| Maybe it's just me. Vendor documentation in hardware
| tends to be kinda crap but there's usually plenty of
| other sources for information from other people who
| implemented something using the part, and that
| information doesn't get stale, ever, and documentation
| state improves over time. I've had problems finding
| reliable info on what's going on in webdev, most posts
| are "do this" solutions which don't really help you
| understand what is happening under the hood, and there
| are _countless_ crappy tutorials. To be fair, I 'm an
| extreme case, I touch web stuff once every few years, and
| only if there's really no way around it, and a lot
| happens in browser capabilities and javascript in a few
| years.
| RayVR wrote:
| Only natural that complexity is increasing. When and where
| that's warranted will be an eternal debate.
| sroussey wrote:
| Heh, if you really want to go meta, you could talk about the
| microprocessors inside modern cpus and gpus and, oh man,
| systems in a chip...
| rcxdude wrote:
| In one SoC I am familiar with, there is a ARM cortex-m3
| core (far more powerful than the original PCs), with its
| own firmware, dedicated to managing power transitions in
| the SoC like suspend-to-RAM.
| jeffreygoesto wrote:
| Yup.
|
| https://nvidia.github.io/open-gpu-doc/Falcon-
| Security/Falcon...
|
| https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-
| R...
| randyrand wrote:
| Apple SoCs have something like a dozen CPUs in them all
| running seperate firmware. a display processor, gpu message
| processor, etc. Asahi Linux has a write up somewhere.
| sneak wrote:
| What's the difference between a human and a cellphone?
|
| A human only has two ARMs.
| dreamcompiler wrote:
| As I often tell my kids, somebody has to do the dad jokes.
| rackjack wrote:
| > Think of chips as microservices.
|
| That is an interesting perspective.
| unixbane wrote:
| >Think of chips as microservices.
|
| This is a good analogy, but not in your favor.
|
| This is all part of the disease of modern computing where you
| program against a giant machine with a giant interface and
| you set a few config variables and have no idea or control
| over how it will work and your program winds up full of
| unintended behavior. See: game engines, gstreamer, web
| frameworks, browser API, HDMI modules, terminal emulators,
| shells (bash, etc).
| Kye wrote:
| The flip side is that the more popular an off-the-shelf
| tool is, the harder it is to sneak something in. Someone
| somewhere is bound to notice fishy behavior at a certain
| scale. It lowers the skill level required to understand the
| choices you make and make better choices. I wouldn't even
| know where to begin trying to notice, much less explore,
| what AT&T is doing at 1111340002.
|
| The more components with a million eyes watching it, the
| more attention you can direct toward the rest.
| JohnFen wrote:
| > Someone somewhere is bound to notice fishy behavior at
| a certain scale.
|
| I'm not convinced that this is true to a meaningful
| degree. It's certainly theoretically true.
|
| However, we've now had a number of events where bad
| things were found in fundamental and popular OSS
| software, and those things existed for years or even
| decades before being found. And who knows how many more
| exist that haven't been found, or at least publicized,
| yet (and may never be).
|
| I think the reality is that most devs aren't deeply
| examining the tools and libraries they use. How could we?
| We'd spend all of our time vetting software and little
| time writing it.
| unixbane wrote:
| So you're saying having giant IP modules inside your
| electronics is somehow making things more secure? They
| certainly don't make the product any less buggy.
| StanislavPetrov wrote:
| >Your carrier can upload and run arbitrary code without your
| consent or knowledge. They can do this at any time.
|
| Two words: Faraday bag.
| yjftsjthsd-h wrote:
| You could also physically remove the SIM card, but there's a
| practical problem there; people with SIMs usually want to use
| them.
| pugworthy wrote:
| You'll never get the update then that it's confirming it
| installed. And you can't make phone calls. And you can't even
| use it unless you can get inside the cage. I guess it if
| comes with solitaire you could play that or something.
| StanislavPetrov wrote:
| > And you can't even use it unless you can get inside the
| cage.
|
| Bag not cage (though the bag is technically a Faraday cage
| you aren't actually entering it as it's only big enough to
| hold your phone). A small faraday bag is available for ~20
| on Amazon.
|
| >They can do this at any time.
|
| You can decide when you get updates and when you want to
| allow yourself to be tracked by whatever corporations,
| governments, and other actors that seek to track your
| movements. It's a false paradigm to suggest (like most
| people on this thread are doing) that you have no choice
| but to allow yourself to be tracked 24/7 or to go without a
| communication device. Keep your phone in a small shielded
| bag, remove it when you want to make calls, check your
| messages and are willing to divulge your location - its not
| rocket science.
| stinos wrote:
| _You can decide when you get update_
|
| Assuming the cage works perfectly (taking out the battery
| if possible seems a safer bet), the only thing you
| actually decide is when you get it out of the cage to use
| the device. However at that point the device can
| communicate and you cannot stop it from doing whatever it
| wants to. In other words: you decide you want to call,
| and if the thing decides it wants to update it might also
| do it at that point.
| zakki wrote:
| As long as you use the phone they have the chance to access
| the sim card and be able to upload and run any code.
| Marqin wrote:
| Also worth noting is that most of SIM cards are Java cards,
| running Java applets
| mavhc wrote:
| Java Card is not very similar to Java, Javascript is more
| like Java than Java Card is
| fulafel wrote:
| It doesn't resemble JS. It's a JVM/Java subset. You can
| even write apps using the Java Servlet API with JC 3.x
| lxgr wrote:
| That's only on JavaCard 3 connected, though - which is
| dead: https://stackoverflow.com/questions/9546812/javacar
| d-3-in-re...
|
| But I agree - Java to JavaScript is not the best
| comparison. Maybe a better one would be C programs
| written for a Unix system vs. C on a microcontroller:
| Same language; vastly different instruction set, OS and
| hardware capabilities and APIs available.
|
| Unlike C on microcontrollers, Java Card applications are
| hardware and OS agnostic, though!
| [deleted]
| Aaargh20318 wrote:
| To my understanding it's an actual subset of Java, a very
| limited subset, but a subset of the real Java nonetheless.
| Java Card applets are compiled using a real Java compiler,
| and then the bytecode is translated into a simplified
| format for running on the card.
| Silasdev wrote:
| This video from defcon gives a good overview of what Java
| Card applets is, the limitations and what it can do:
| https://www.youtube.com/watch?v=31D94QOo2gY
| throwaway9870 wrote:
| Many years ago, I worked on a serial link (think SATA, PCIe,
| USB 3, etc.) that had a small embedded processor to self test
| the link, perform analog component calibration, link equalizer
| calibration, and even make an eye diagram for link
| characterization. We could patch it with a few instructions
| over the JTAG port. There are way more processors in ICs than
| you would ever imagine.
| mortenjorck wrote:
| _> A SIM card is a full blown computer with its own CPU and
| memory._
|
| I read something to this effect years ago and mentally filed it
| away as "huh, that's interesting." This article is the first
| time I've understood what it actually means in practice, and
| it's an eye-opener.
| [deleted]
| kpetermeni wrote:
| Besides operators, individuals can also send OTA settings like
| APNs, proxies, etc. from a SIM card to SIM cards on another
| network. To the recipient, the message looks just like the
| settings you get from local MNOs when you first get connected
| when roaming in another country.
| Andrex wrote:
| How susceptible is eSim? More? Less?
| malshe wrote:
| +1 I came to ask the same question
| oaiey wrote:
| Considering that sim cards do a lot (think roaming on
| cheapest partner etc) .. you can bet that eSIM are equally
| capable and maybe even more capable.
| lxgr wrote:
| Pretty much the same, I would say.
|
| An eSim is essentially a virtualization solution with each
| eSim profile effectively running in a container which can be
| set up, deactivated, and deleted only by the profile manager.
|
| The profile manager communicates with the provisioning
| infrastructure in an encrypted and authenticated way, so the
| profiles being loaded, i.e. their code (if any) and data, are
| as inaccessible as those on a physical SIM.
|
| While active, an eSim profile has all the same capabilities
| as a physical SIM, including remotely loading Java
| applications, issuing proactive commands to communicate with
| the network, registering for event notifications about
| location changes and incoming/outgoing calls...
| binkHN wrote:
| So an iOS device with an eSIM is running a JVM in the eSIM?
| [deleted]
| lxgr wrote:
| Yup! I have at least two eSIMs myself that have SIM
| applications running in them that wouldn't be able to
| function otherwise. (The operators do IMSI switching
| based on SAT event triggers, from the looks of it.)
|
| The Oracle JVM installer wizard isn't lying when it's
| saying that there is billions of devices running Java in
| the world :)
| Andrex wrote:
| This is blowing my mind. I'm not sure what's real
| anymore...
| kylehotchkiss wrote:
| I'd like to know the same thing! Maybe the config files are
| more observable?
| lxgr wrote:
| They are encrypted and authenticated, since they contain
| the symmetric keys used to access the network.
|
| Without the keys of a legitimate eSim (i.e. those chaining
| up to a GSMA-approved vendor) you won't be able to inspect
| a profile even if you know the activation code.
| jschwartzi wrote:
| This was driven home to me many years ago when I popped a SIM
| from a Mexican carrier that had an embedded Dominos Pizza app
| on it. Suddenly the Windows Mobile phone I was testing had a
| new icon on it.
| eclipxe wrote:
| Likely the app was not embedded in the sim. It was likely a
| carrier profile that the sim activated that triggered the
| download and install of the app.
| Espressosaurus wrote:
| A distinction without difference from the end-user's
| perspective.
| lxgr wrote:
| Maybe, but you'd be surprised what kinds of SIM application
| toolkit based products there are in the world. These are
| actually running on the SIM, with your phone only proxying
| input/output!
|
| For example in many African countries, you have M-Pesa [1],
| which was at least initially entirely based on SAT.
|
| [1] https://en.wikipedia.org/wiki/M-Pesa
| adolph wrote:
| Essentially, the OS has a backdoor to allow commands from
| the SIM. I wonder what other uses are there for this
| method?
| lxgr wrote:
| Is it still a backdoor if it is publicly documented?
|
| Also, the API is somewhat limited. "Installing
| applications" here means "downloading code to the SIM
| card", which arguably has always been the phone
| provider's property.
|
| It's definitely not possible to install apps on the
| application processor OS via SIM-OTA. That would be OS-
| based carrier profiles, which the OS vendor has
| deliberately implemented.
| lupire wrote:
| The backdoor is thr other way -- The OS will execute
| intructions provided by thr SIM card. It's RCE via the
| SIM card and its network connection.
| ghostDancer wrote:
| You may know there is one but you still don't know how to
| open/use it.
| bbarnett wrote:
| The more important question is, can the SIM itself be
| remotely updated.
|
| If so, any entity with a court order, can install
| anything it wants on your phone.
|
| Alternatively, any entity it wants can use the sim itself
| to track beyond the norm...
| lxgr wrote:
| Not really updated, but new applications can be remotely
| installed and then interact with the baseband and (to a
| limited extent) the smartphone OS.
|
| It's not "any entity", though - the provider's keys are
| needed to do this, and they can already do much of that
| tracking using other, network-side means.
|
| If the signing keys are compromised, though, bad things
| can happen: https://www.srlabs.de/bites/rooting-sim-cards
| boppo1 wrote:
| Couldn't installations be observed though?
| lxgr wrote:
| They could (using a setup like the one in the article),
| but the payload is usually encrypted in addition to being
| authenticated, and such OTA updates are done for
| legitimate reasons all the time.
| [deleted]
| bitexploder wrote:
| More really. Secure Enclave on iOS is its own computer as well.
| joezydeco wrote:
| The touchscreen controller has one as well. And the NAND
| flash parts. And the Motion coprocessor on older models.
| cma wrote:
| And lightning -> AV cables have an arm SoC
|
| https://www.engadget.com/2013-03-02-lightning-digital-ac-
| ada...
| bitexploder wrote:
| Computers everywhere. Even ikea lamps have emm now :)
| lxgr wrote:
| > Your carrier can upload and run arbitrary code without your
| consent or knowledge.
|
| Well, arbitrary _sandboxed_ code.
|
| I agree that by today's standards, the APIs that code has
| access to seem excessive and are well worth trimming down, but
| some of them are vital to the network's internal operations
| (like OTA updating the list of preferred roaming partners),
| while others enable new use cases (like M-Pesa mobile
| payments).
|
| For example, multi-IMSI SIM cards are, in my opinion, an
| ingenious solution enabling entirely new products and bringing
| much needed competition to an industry that had been pretty
| stagnant (international roaming). That would not possible
| without the SIM application toolkit.
| JoshTriplett wrote:
| > some of them are vital to the network's internal operations
| (like OTA updating the list of preferred roaming partners)
|
| That should be the phone's job, not the SIM card.
|
| > while others enable new use cases (like M-Pesa mobile
| payments)
|
| That should be the phone's job, not the SIM card.
| jedimastert wrote:
| That requires phone manufacturers to consistently send out
| updates in concert with many _many_ phone carriers,
| including new ones no one has never heard of. I do not
| trust a single carrier to do that
| JoshTriplett wrote:
| > That requires phone manufacturers to consistently send
| out updates in concert with many many phone carriers
|
| The carriers could still provide information about their
| network, via a standard API.
|
| I'm talking about how this _should_ work if designed
| well, not incremental steps to get there with non-
| cooperating entities.
| JohnFen wrote:
| > I'm talking about how this should work if designed well
|
| I think that I've fantasized about this magical land with
| literally every system I've ever worked with in my entire
| career, including ones of my own design. I've come to
| suspect that utopia simply doesn't exist.
| lxgr wrote:
| True - not even Apple gets this right, being otherwise
| pretty good about timely software updates.
|
| My MVNO started being recognized incorrectly as being
| part of another network years ago, and apparently their
| engineers have been unable to reach anyone within Apple
| about the matter and get theem to apply what should be a
| trivial fix in their IMSI mapping table.
| lxgr wrote:
| > That should be the phone's job, not the SIM card.
| [internal operations]
|
| Maybe, but what would inevitably happen is for network
| operators to demand that only certified devices, or maybe
| basebands, be allowed on their networks.
|
| SIMs are a big reason of GSMs (and its successors')
| success: Having a trusted computing device to allow for key
| management and a few other things inside an otherwise
| untrusted/sandboxed phone was the compromise.
|
| I'm all for making the interfaces used less opaque and less
| prone to be used for shady purposes, but the concept of SIM
| cards is a net win for everyone, in my opinion.
|
| > That should be the phone's job, not the SIM card.
| [applications]
|
| If you have a smartphone, it is. Many people still don't
| own one.
|
| USSD is an alternative and is starting to be deployed in
| many markets previously using SAT, but it seems much more
| cumbersome to use and is less secure too (no trusted client
| side storage and tied to the security of the underlying
| transport protocols).
| JoshTriplett wrote:
| > Maybe, but what would inevitably happen is for network
| operators to demand that only certified devices, or maybe
| basebands, be allowed on their networks.
|
| There was already a battle between AT&T and people who
| dared connect phones they _actually owned_ to the phone
| network, and it ended well for the general public and
| badly for AT &T. The cell network should not get to
| determine what people attach to it; it should just pass
| data back and forth.
|
| (In an ideal world, the cell network would have
| absolutely nothing to do with phone numbers, either; it
| would _just_ pass data, and phonecalls would always
| happen over encrypted channels to your actual phone-
| number provider.)
|
| > the concept of SIM cards is a net win for everyone, in
| my opinion
|
| Public/private key crypto doesn't require a card that can
| also do other secret operations. And it doesn't require a
| smartcard either.
| lxgr wrote:
| > The cell network should not get to determine what
| people attach to it; it should just pass data back and
| forth.
|
| I absolutely agree.
|
| > And it doesn't require a smartcard either.
|
| There are many good reasons why a counterparty does not
| trust you (fully) with a set of keys.
|
| The biggest one is keys that allow financial transactions
| or billing events to happen: It makes the "I lost my
| password" defense for friendly fraud much less credible.
| Another can be to discourage sharing of a service (i.e.
| "account sharing").
|
| Now there's two ways to keep "your" keys safe as a
| service provider: You build a fully locked down platform
| and only allow devices sold and made by you to attach to
| it (and play your content, use your phone network,
| transact on your payments network etc.), or you
| standardize the interface to the "key jail", keeping the
| rest of the device open and accessible to independent
| security research.
|
| You can call such a tamper-proof device holding some
| issuer's private or symmetric key any way you want -
| functionally, it will be very similar to a smartcard.
| JohnFen wrote:
| > Many people still don't own one.
|
| And when my current smartphone dies, I'll be joining the
| ranks of those who don't own one. I'm aware of two other
| people who are also moving back to dumb phones. I wonder
| if this is going to become more common as time goes by.
| wl wrote:
| > [W]hat would inevitably happen is for network operators
| to demand that only certified devices, or maybe
| basebands, be allowed on their networks.
|
| This is already the case.
| lxgr wrote:
| In what way?
|
| I've heard that in the US, some providers are still
| insisting on this (essentially a leftover practice from
| the pre-SIM days!), but at least in Europe I've always
| been able to use any phone I like, even really obscure
| ones.
| wl wrote:
| My experience is in the US. PTCRB is the standardized
| one. Even on top of that, AT&T has additional testing
| (see TRENDI, which is a whole lot better than what they
| used to require). Verizon has their own idiosyncratic
| process where you don't learn what standards you need to
| meet until you submit a request for testing.
|
| The carriers don't use technical measures to keep
| uncertified devices off their network. It's still usually
| a violation of the terms of service. And yes, that means
| that aftermarket PCIe-form-factor cell radio in your
| laptop is theoretically a problem unless that precise
| laptop + card combination has been certified.
| 0xTJ wrote:
| I strongly disagree on the first point. The carriers used
| are entirely an issue with my carrier. I don't use a phone
| that's in any way associated with my carrier, and I expect
| the SIM card to "just work" when I put it in a phone.
| lxgr wrote:
| Would you rather have to copy-paste an arbitrary list of
| parameters into some preference menu option every time
| you travel internationally?
|
| (Ironically, SIMs are falling short on this end quite a
| lot since they don't allow providing GPRS and MMS related
| configuration, which means that now we have SIMs _and_
| manual lists...)
| 0xTJ wrote:
| I'm confused by what you're saying. I'm disagreeing with
| the comment saying that SIM cards being smart is bad.
| lxgr wrote:
| Ah, sorry, I must have misunderstood you or mixed up
| comments!
|
| Yes, I agree that SIMs being (moderately) smart helps
| them to just work in a new phone without any affiliation
| with the carrier.
|
| It's not perfect, though - APN settings are annoyingly
| part of the OS when they should arguably be a SIM and
| baseband implementation detail like the SMSC, for
| example.
| jimktrains2 wrote:
| For mobile payment, the SIM acts as a means to sign
| messages in a way that is difficult to spoof, as you cannot
| directly access the cryptographic key on it. This existed
| and worked long before secure elements or TPUs were on the
| scene.
| voltagex_ wrote:
| Can a hobbyist mess around with this at all?
|
| Edit: yes, but I wonder how much trouble you'd get in putting
| this into a real phone?
|
| https://www.aliexpress.com/item/32900944064.html?spm=a2g0o.d.
| ..
| myself248 wrote:
| TFA has links to the tools used. You'll find Osmocom.org an
| invaluable resource.
|
| I've put test SIMs in plenty of real phones, before tossing
| them into an RF chamber to talk to the network simulator.
| The real network doesn't seem to care.
| lxgr wrote:
| It makes sense that they don't: If you're using an
| unregistered/test MCC/MNC id as part of the IMSI, they
| would just consider your phone a roaming guest that they
| can't provide services to.
|
| Even if you'd be using an actual IMSI (not recommended -
| this seems like a legally more gray area), you would just
| fail authentication with that provider's AuC and the
| network would not let you register in what would be the
| GSM equivalent to a device trying to connect to a Wi-Fi
| with the wrong password.
| lxgr wrote:
| Probably none at all - such a SIM wouldn't have the
| required keys to even connect to any real network.
|
| SIM cards are just Java Cards, after all - the secret sauce
| is the proprietary software running on them (the ones
| you've linked seem to come with an implementation of that
| pre-loaded) and of course the keys they hold.
|
| Nobody keeps you from implementing all the SIM
| specifications in an open-source Java Card application, and
| I would in fact be very intrigued to see it happening ;) As
| far as I know, experimental/hobbyist GSM networks, like the
| ones running at some conferences, are still using
| proprietary SIM cards, and an open source implementation
| would be very interesting to study.
| JohnFen wrote:
| > Well, arbitrary sandboxed code.
|
| But a sandbox that has access to very sensitive data.
| lxgr wrote:
| Much of that data is already available to the provider (the
| only entity able to install new SIM applications) anyway:
| Cell location, incoming and outgoing calls, your IMEI...
| They already know all of that!
|
| There are some notable exceptions, like the ability to
| initiate voice calls possibly without any user interaction,
| and I'm all in favor of removing those from the
| specifications. I'm not sure whether modern devices
| actually implement these.
|
| The only remaining concern then is weak authentication key
| security, i.e. allowing unauthorized third parties to
| control SIM (and by extension phone) behavior, potentially
| without the operator's knowledge. This seems like a very
| similar concern to weak phone network signalling stack
| security (like being able to intercept SMS via SS7), which
| is an ongoing problem too.
| tgsovlerkhgsel wrote:
| The interesting question is: what APIs and data does the SIM
| card have access to?
| lxgr wrote:
| This spec is a good starting point:
|
| http://www.arib.or.jp/english/html/overview/doc/STD-T63v9_50.
| ..
|
| Generally speaking, the SIM interacts using both "proactive
| commands" (e.g. "send an SMS to this number) and event
| downloads (think "whenever the base station identifier
| changes, please let me know").
| lxgr wrote:
| Sorry, should have linked out the CAT specification
| instead: https://www.etsi.org/deliver/etsi_ts/102200_102299
| /102223/14...
|
| The former just refers to the latter for event downloading.
| tgsovlerkhgsel wrote:
| Thanks! Out of these, the following seem most
| concerning/abusable:
|
| * "setting up a voice call to a number held by the UICC"
| - effectively allows turning the phone into a bug
| (although not a very stealthy one, since presumably the
| normal call UI would be shown).
|
| * requesting the terminal to launch the browser
| corresponding to a URL - triggering exploits
|
| * providing local information from the terminal to the
| UICC; -- depends on what exactly the card can request,
| doesn't look like much except location which is discussed
| below
|
| * running an AT command -- depends on the AT commands
| available, but I don't expect anything ground breaking
|
| * requesting the terminal to start an application on the
| terminal -- depends on what exactly can be triggered
| (e.g. if it can trigger an app install it'd be extremely
| concerning, already installed apps less so), but I think
| it's only launching or listing already installed carrier
| apps.
|
| * requesting the terminal to report geographical location
| information to the UICC -- fine grained tracking. This is
| the most concerning for me, and I wonder how/if Android
| shows when/if that happens (or if it is allowed). I also
| wonder if this can be used even when the phone is in
| airplane mode (to collect data and upload it later).
| lxgr wrote:
| Great analysis, I agree on all points!
|
| The geographic location seems to be only network-based
| (i.e. this doesn't poll the phone for GPS data, but only
| accesses data available to the baseband).
|
| Hopefully, the following requirement also covers flight
| mode implementations:
|
| > Where location information or Network Measurement
| Results has been requested and no service is currently
| available, then the ME shall return TERMINAL RESPONSE (ME
| currently unable to process command - no service).
|
| If both are the case, then this does not leak more to the
| network than it could just determine itself from
| signalling data. In any case, as many things in these
| specifications, it leaves quite a lot of wiggle room for
| implementation mistakes, genuine and otherwise.
|
| As a historical note, there was a quite famous
| implementation of SIM-based positioning in Germany: One
| GSM provider implemented a "home zone" feature entirely
| on the SIM, by populating it with a database of cells
| that qualify for "home use"; this was then used to bill
| the landline rate rather than the (at the time quite
| expensive) mobile rate for outgoing calls.
| dannyw wrote:
| A SIM card generally holds somewhere along 32 to 128 kb, most
| of which empty and used to store user contacts.
| j16sdiz wrote:
| There is nothing technically stop the carrier putting more
| memory on the SIM card.
| jschwartzi wrote:
| It's even a microcontroller that emulates the original SIM,
| so it can have whatever specs they want.
| lxgr wrote:
| What do you mean by "original SIM"? As far as I know, SIM
| cards have always been specified in functional terms, so
| vendors were always free to implement them whatever
| hardware and software they choose, as long as the result
| complies to ISO-7816 and the relevant ETSI/3GPP
| specifications.
|
| Today, it's mostly Java Card implementations, meaning
| that the ISA and smartphone OS/runtime is abstracted away
| in any case.
| tapland wrote:
| They are ordered from the manufacturer
| (idemia,thales/gemalto,oberture) with speficied memory size
| depending on what capabilities are needed.
|
| The big iffy is that manufacturers were compromised (by the
| US afaik) in 2015 and all cards from then or earlier should
| be considered compromised.
|
| Few carriers encrypted their OTA-keys before then. I know
| that some carriers did not send encrypted keys to
| manufacturers still in 2018.
| lxgr wrote:
| That's a bit like saying "most of the space of a smartphone's
| persistent storage is empty and otherwise used to store
| photos and videos" when talking about smartphone operating
| systems and their security.
| userbinator wrote:
| This is true. AFAIK SIMs are based on an ISO 7816 smartcard
| with some additional features, and the former are definitely
| in that size range.
| downrightmike wrote:
| Defcon talk on it: https://www.youtube.com/watch?v=31D94QOo2gY
| kevingadd wrote:
| Would this mean that hypothetically, your SIM could send SMS
| messages even if your phone is in airplane mode?
| catlikesshrimp wrote:
| Under normal conditions: no. But a hacked phone may fake
| going offline and still be connected.
|
| The only way to turn off a phone for sure is to remove the
| battery.
| arpa wrote:
| > remove the battery
|
| ha ha.
| johnyzee wrote:
| Eat the SIM card.
| account-5 wrote:
| If you can access it.
| lxgr wrote:
| Depends a lot on how airplane mode is implemented on a given
| device, I'd say. To my knowledge, this is not specified by
| the relevant standards.
|
| One way would be to shut down the SIM as soon as it's
| activated, which would include proactive commands of any kind
| (like those the SIM uses to request sending an SMS from the
| phone/baseband).
|
| Another would be to keep the baseband and SIM active, but to
| still deactivate the radio - in this the SIM might still be
| able to issue proactive commands, but without any network
| attachment, they would just fail.
|
| Of course an implementation could also choose to briefly
| reattach to the network whenever it receives such a proactive
| command.
| raldi wrote:
| I think that's the lesson of this article -- the SIM can
| instruct the phone's radio to send and receive any sort of
| data (including SMS) without the rest of the phone ever
| knowing about it.
| judge2020 wrote:
| My understanding is that airplane mode does disable the
| radio entirely - so the SMS card trying to send messages
| wouldn't work unless the baseband (which, on iOS, is signed
| by apple and likely not an unknown binary blob to them)
| turned the radio on, let it connect to the network, sent
| the message, then turned off the radio, all without
| informing the OS.
| kevin_thibedeau wrote:
| You're assuming Apple doesn't have a way to bypass
| airplane mode when they receive a warrant.
| Thorrez wrote:
| Apple heavily resisted building a backdoor that would
| only be installed on a phone the FBI already had in their
| possession. Why would they build a way to bypass airplane
| mode if they receive a warrant?
| judge2020 wrote:
| More so, how would they tell a phone with radios disabled
| to turn on a radio, besides physical access?
| bbarnett wrote:
| By telling the radio firmware to do so?
|
| edit: the sim can tell the radio to turn on, when it
| wants to send a message.
|
| It is a full blown computer, with direct access to the
| radio firmware, with no OS oversight.
|
| The radio firmware can be updated remotely, too, and the
| OS only knows the modem is on, because the firmware tells
| it so.
|
| The icon on your phone showing signal/on/off is displayed
| by the OS, after querying the firmware. The OS has no way
| to know if the radio is on or not.
| vermilingua wrote:
| Yes but from where is this command originating? Can't be
| remote because well... the radio is off.
| PeterisP wrote:
| It can be remote but shifted in time. E.g. send a remote
| command that essentially says "if in airplane mode, every
| 60 minutes turn radio on and check for new commands".
| LexGray wrote:
| That would cause major issues in areas where phones are
| forbidden for national security or sensitive equipment
| reasons from having antennas active. I've never heard a
| report that a manufacturer has even considered that idea
| as it could potentially cost them major damages.
| PeterisP wrote:
| Of course, that's not something that a legitimate
| manufacturer would have in their standard firmware.
|
| However, that is a possibility for specific malicious
| firmware uploaded to some "phone of interest" to prevent
| its user from protecting themselves by turning on
| airplane mode.
| kevin_thibedeau wrote:
| They fought unlocking secure enclave. That has no bearing
| on active tracking. Apple is also under the eight ball
| with the threat of anti-trust regulation and are more
| incentivised than ever to make deals that turn down the
| heat on questionable business practices. They lost all
| credibility as a "security focused" company with their
| crazy on-device image scanning scheme.
| dboreham wrote:
| No
| striking wrote:
| It doesn't have a radio, so no.
| Helmut10001 wrote:
| What about eSims?
| HahaReally wrote:
| Just an authentication token.
| rvz wrote:
| Precisely.
|
| Can't wait to see what nefarious use cases that eSIMs can be
| used for then by our carrier then if your phone has one.
|
| Maybe in the future, eSIMs will be the only SIM in your phone
| and it can't be removed, just reprogrammed by the carrier.
|
| No thanks and no deal to eSIMs.
| ctdonath wrote:
| I've seen that template applied to every technology now
| considered bog standard (utterly mundane & normal).
| wizzwizz4 wrote:
| And where has that got us? Surveillance states, the
| whole... *gestures at Facebook* thing, insurance companies
| having access to your medical records. The oceans are full
| of plastic!
| matheusmoreira wrote:
| > A SIM card is a _full blown computer_ with its own CPU and
| memory.
|
| Yeah. They even run Java, that was the most surprising fact.
|
| > Your carrier can upload and run _arbitrary code_ without your
| consent or knowledge. They can do this at any time.
|
| So what can this code do? Can my phone be compromised somehow?
| criddell wrote:
| > Your carrier can upload and run arbitrary code without your
| consent or knowledge. They can do this at any time.
|
| Is that equally true of SIM cards and eSIMs?
|
| I'm in the process of setting up a new T-Mobile phone and they
| say they support eSIM but they are really pushing me to use a
| traditional SIM card. I've been wondering why they care.
| rootsudo wrote:
| " The point here is that the cellphone literally has a mind of
| its own, in fact multiple "minds", including in the SIM. These
| various minds might not even be talking to each other, and just
| because a phone did something, that doesn't mean that user caused
| it."
|
| Yes, baseband, modem f/w and the operating system work together
| but don't have to talk to one another.
|
| A great read about be REX, from Qualcomm that goes into more
| detials -
| https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attach...
|
| All the fun Qualcomm PDF's seem to be missing from the net now,
| but there were more official/confidental PDF's that went into
| details besides this: https://en.wikipedia.org/wiki/REX_OS
|
| BUt even reading from the old dead CDMA2000/eVDO standard you can
| see more of this too -
| https://ftp.unpad.ac.id/orari/library/library-ref-eng/ref-en...
|
| And more on "what is a qualcomm chipset"
| https://ftp.unpad.ac.id/orari/library/library-ref-eng/ref-en...
|
| Yes, these links are not for GSM, but Qualcomm makes GSM and
| these carry over as a standard, and these 10-15yr old slides are
| amazing and should be archived too - they used to be public even
| on Qualcomm sites too.
|
| But thank you for the https://yatebts.com/ link - that is so
| cool, what I do with diagnostic and fun tinkering is with
| Qualcomm Tools that I no longer have access too. QPST, QXDM, etc.
| 14 wrote:
| Reminds me of how I ended up with a U2 album on my iPhone. I
| never put those files there not asked for them or gave
| permission. Made me wonder what else could they plant on my
| phone.
| dang wrote:
| We detached this subthread from
| https://news.ycombinator.com/item?id=29136253.
| nucleardog wrote:
| I mean, you're talking about a bit of a different thing here--
| something done by the operating system and hardware vendor.
|
| So the answer would be "literally anything". Apple could push
| an update tomorrow that bricked your phone, turned it into a
| listening device, caused it to _only_ play that U2 album, etc.
| Ditto for Google (Android), Microsoft (Windows), etc.
| lostlogin wrote:
| It raises the question 'who can put shit on my phone?" The
| answer seems to be a large number of groups/people.
| vsnf wrote:
| See also: that one time Mozilla pushed the Mr. Robot
| extension to everyone's Firefox installation.
| userbinator wrote:
| Whenever I think the Internet protocol stack is too complex, I
| take a glance through the (also freely available) 3GPP
| specifications to refresh my perspective. They are so thick and
| dense it's a miracle that everything works, and I remind myself
| that people came up with all of it and there are probably experts
| who know far more than I ever will about that area. Nonetheless,
| I'm not surprised that they are full of little-known features
| like this.
| GuB-42 wrote:
| I wonder how it compares to Bluetooth?
|
| No one seems to get Bluetooth right. The specification is more
| than a thousand pages, and my understanding is that 5.0 is an
| complete rewrite (but you still have to support previous
| versions).
| userbinator wrote:
| Bluetooth is, while still huge, tiny in comparison to the GSM
| specs. I've actually read the whole thing, although not in
| complete detail --- just out of interest; it's similar to
| WiFi (802.11).
|
| The GSM specs aren't even available in a single document.
| It's split into dozens of pieces. My estimate would be in the
| tens of thousands of pages in total.
| dilyevsky wrote:
| They are likely thick and dense on purpose tho - the cartel
| doesn't want more competition
| boppo1 wrote:
| Who even has infrastructure to compete?
| BelenusMordred wrote:
| Baseband chips and sim cards aren't infrastructure, but you
| still can't compete because getting permission to run one
| on modern networks is financially well out of reach for
| most. This is why open source inspectable firmware simply
| doesn't exist for these things.
|
| All we currently have is leaked 2G and 3G source code for
| people to build their own off, most notable would be
| omsocombb
| exikyut wrote:
| > leaked
|
| "License: Affero GPLv3 for all cellular software, GPLv2+
| for some remaining software (libosmocore, OsmoPCU,
| OsmoSTP, OsmoGGSN)[1]"
| (https://en.wikipedia.org/wiki/Osmocom)
|
| O.o?
| userbinator wrote:
| I think that comment may be referring to the leaked
| Mediatek baseband source. That is capable of 3G/HSPA+ at
| least, maybe LTE.
| beeforpork wrote:
| Why is this number even on the list of SMS activities? Isn't that
| list compiled and issued by AT&T? Couldn't they just hide those
| target SMS numbers because they are, well, they could say, needed
| for technical implementation of SMS processing? It puzzzles me
| that they list these and afterwards do not tell what they really
| are.
| rwmj wrote:
| Presumably when AT&T is answering a court subpoena they have a
| duty to supply complete information, and in any case the legal
| and technical parts of the company don't talk to each other
| much.
| boramalper wrote:
| Would eSIM[0] improve the state of affairs with respect to
| privacy?
|
| On the one hand, as SIM circuits are now being shipped with
| phones, I can imagine the manufacturers having the opportunity,
| for the first time ever, to control the operations of a SIM such
| that it's no longer a black-box. On the other hand, due to
| legislative and practical reasons, eSIM modules would likely be
| no different than those black-box baseband processors with the
| further downside than we would also become unable to intercept
| the communication between a SIM (whose circuitry is now embedded)
| and a phone.
|
| I would love to read the answers of those who are more
| knowledgeable on the subject.
|
| [0] https://en.wikipedia.org/wiki/ESIM
| mike_d wrote:
| eSIMs are just the SIM chip implemented in a surface mount
| component soldered directly onto the board. The only difference
| is some limited parts of the cards memory are not write
| protected so it can be provisioned from software.
| bbarnett wrote:
| Meaning it is easier to hack, and also, debug/monitor, for
| now it is harder to place a device between sim and phone, as
| in this article.
| lxgr wrote:
| > some limited parts of the cards memory are not write
| protected
|
| This is a huge oversimplification. The card is running
| software that allows downloading and installing new profiles,
| but it will perform cryptographic validation of any payload
| handed to it.
|
| Even if a SIM profile passes that validation, the resulting
| SIM application will be instantiated with limited privileges
| on the smart card (which is arguably quite powerful since it
| matches that of SIM applications on physical SIMs).
| zinekeller wrote:
| A SIM Card* is a ISO card running a variant of JavaCard OS with
| standard APIs mandated by GSMA or 3GPP (despite it's already
| 5G) implemented, but carriers can (and do) add internal
| features for their use, to the point that some weird SIMs (no
| longer seen today) could also function as a debit card$?. Think
| of it as roughly similar to the POSIX compatibilty between
| Linux, macOS and *BSD, while having widly different
| capabilities tacked on.
|
| eSIMs just remove the physical ISO card package and put it
| instead into a dedicated chip inside your phone, so in theory
| and in practice it could do anything a regular SIM can do.
|
| * To be fair, I'm not familiar with how CDMA networks handle
| this, but this is irrelevant in the sense that CDMA (depending
| on the carrier) is dying or even dead already (in favour of LTE
| et al.).
|
| $? Payment cards and original SIM cards are ISO/IEC Card ID-1,
| the "mini" SIM cards are ISO/IEC Card ID-000, and micro and
| nano SIM cards are non-ISO additions by 3GPP.
| adolph wrote:
| The JavaCard OS website seems direct from 1999:
| https://www.javacardos.com/about/
|
| CNN might want to have a word with them regarding logo font:
| https://edition.cnn.com/style/article/chop-suey-fonts-
| hyphen...
| darkwater wrote:
| > The JavaCard OS website seems direct from 1999:
| https://www.javacardos.com/about/
|
| And you can still follow them on Google+!
| adolph wrote:
| Antique websites are so fascinating
| lxgr wrote:
| To be fair, that's just one specific Java Card
| implementation, not the entire platform.
|
| Head over to Oracle for slightly more modern logos ;)
| https://www.oracle.com/java/technologies/java-card-
| tech.html
| mensetmanusman wrote:
| This must be why the carriers are resistant to phones going to
| e-sims.
| walterbell wrote:
| Follow-up article by same researcher, including Verizon and
| T-Mobile SIMs, https://medium.com/telecom-expert/more-proactive-
| sims-f8da2e...
|
| _> Of the five tier-1 SIMs I just have "laying around", four of
| them proactively send messages or initiate connections through
| the cellular modem. Since these operations are happening between
| the SIM and the baseband processor, they are probably completely
| undetectable from the application processor and its Android
| /iOS/whatever software.
|
| > I hope this is the start of a much larger exploration of
| proactive SIMs from around the world._
| mschuster91 wrote:
| > I hope this is the start of a much larger exploration of
| proactive SIMs from around the world.
|
| I fear that the rise of eSIM modules will make that research
| ever more complex. In the worst case we'll either see BGA chips
| with vias to the BB chipset that can't be probed without
| extensive reflow work (which, in turn, may be impractical/too
| risky to do in scenarios where the module or the phone is
| evidence in court) or, _even worse_ , eSIM as part of the BB
| chip or SoC.
| pugworthy wrote:
| Clearly you can set it somehow, but is is hardwired? Or
| changeable? What if I buy a phone from AT&T and move to
| Verizon, does it still talk to AT&T or now Verizon?
|
| It would be an interesting security hole if one could modify
| the destination number and have it just send to a third party.
| kmeisthax wrote:
| The SMS messages originate from the SIM - the same device
| that tells the baseband how to connect to the cell network.
| So it's not possible (ordinarily) to separate proactive SMS
| from the intended recipient network.
|
| However, if we designed an intentionally broken baseband that
| connected to two SIMs, and swapped the proactive SMS from one
| to be sent to the other SIM's network, it still wouldn't do
| much. The SMSes are sent to invalid phone numbers that only
| make sense to that carrier's internal routing.
| jfrunyon wrote:
| This is about where you bought the _SIM_ from, not where you
| bought the _phone_ from.
| yjftsjthsd-h wrote:
| I dunno, I've seen phones with custom Android modifications
| per carrier; it could be both.
| p_l wrote:
| Those are handled, usually, by checking the network code
| reported by SIM and applying a specific package (usually
| on separate partition) to the system when doing factory
| reset. The selection of the packages or course varies,
| and back with smaller flash sizes it was common to have
| let's say only T-mobile but for multiple countries.
| kingcharles wrote:
| The AT&T SIM still talks to AT&T regardless of what network
| you are connected to. It has the full international number
| for the AT&T SMSC hardcoded into it so it can correctly route
| the message it is sending.
| vadfa wrote:
| Most operators have a whitelist of SMSCs that they will let
| you use. Some even ignore the SMSC field and always route
| all SMS through their SMSC so if you misconfigure your
| phone you will still get to send SMS (and so you can't use
| an external SMSC to send SMS without paying your telco...)
| lxgr wrote:
| Interesting! Would that override still work when roaming
| internationally, though?
|
| It sounds similar to some providers implementing a
| "catchall" APN for data connections, which however has a
| habit of failing when roaming in my experience.
| mdaniel wrote:
| Or in keeping with the URL scheme used by the submitted link:
| https://scribe.rip/telecom-expert/more-proactive-sims-f8da2e...
| kylehotchkiss wrote:
| This type of stuff makes keeping phone in a faraday bag carrier
| when not using it seem much more appealing. Pacsafe sells a nice
| one (or used to?) for like $40-50.
| hyproxia wrote:
| Or, y'know, just put it in airplane mode or unplug the SIM card
| fsckboy wrote:
| people like to receive messages and calls
| rramadass wrote:
| Can somebody recommend a good book/paper/video/etc. on
| Cell/Mobile phone HW/SW/Internals and Hacking (everything other
| than the Application Processor and its OS i.e. Android/iOS). The
| only one that i am aware of is an old paper by Harald Welte named
| _Anatomy of contemporary GSM cellphone hardware_.
| aaronleather wrote:
| The TP destination number 1111340002 does not fit into any public
| network numbering plan. It must be a private address inside AT&T.
| This number does not exist in the public network. You cannot call
| it or text in through normal means. For a message to get
| delivered to that private address, it must go to a particular
| AT&T SMSC that knows how to route it.
| Isamu wrote:
| > SIMs can send SMS on their own using a feature called
| "proactive MO-SMS"
|
| So many interesting tidbits in this article. This is what I come
| to HN for.
| rvnx wrote:
| I'm not sure why this would make the suspect innocent ? Couldn't
| it be the situation that the person was doing an update and that
| distracted him during driving ?
| matthew-wegner wrote:
| The opposite is more likely.
|
| Updating baseband firmware is like updating your network
| router; it's likely to briefly interrupt the connection.
|
| They're applied by the operating system, so the OS is going to
| choose to automatically do them when the phone is locked with
| idle network traffic. It's probably more of a sign the phone is
| _not_ in use.
| nulbyte wrote:
| The update may occur without user intervention, which would
| mean very little for this case.
| [deleted]
| koprulusector wrote:
| This is a firmware update of the SIM/underlying hardware. It's
| not like an OS update to iOS or Android. It's more akin to an
| automatic BIOS update, but for a piece of hardware that is
| modular. Think Realtek driver on a NIC.
| quickthrower2 wrote:
| It doesn't make them innocent (is innocent the right term for a
| lawsuit?) but it does mean this particular fact isn't evidence
| of anything related to this case.
| Dylan16807 wrote:
| Even if they were halfway through an update, that doesn't sound
| like dangerous driving.
| rvnx wrote:
| or even changing the SIM card and putting it into another phone
| while driving ?
| avs733 wrote:
| Both of those are hypotheticals the other side would have to
| provide some evidence to support in court
|
| The investigation here was grounded in an attorney reading a
| report and saying "look person sent a text message at time x
| just before crash" and a forensic analysis instead showing
| that the SIM card sent the message not the person.
|
| That debunks the claim of distracted driving based on the
| text message timing. That's the point, if they have evidence
| someone was swapping sims or interacting with the phone to
| run and update that's an entirely separate matter
| emodendroket wrote:
| I have to say that someone swapping SIM cards or initiating
| a phone update while driving also seems pretty improbable.
| lostlogin wrote:
| > initiating a phone update while driving also seems
| pretty improbable
|
| Does it? I'd guess it's about 3 clicks, and certainly
| less than 10.
| emodendroket wrote:
| Why would the type of driver who wants to putz with the
| phone while driving choose to kick off a process that
| will make the phone unresponsive for 15 minutes?
| avs733 wrote:
| The proliferation of dashcams has caused me to re-
| evaluate the probabilities I assign to events of rank
| stupidity while driving.
| tgtweak wrote:
| It also happens after a firmware update on the device.
| jaclaz wrote:
| Changing a mini/micro/nano SIM, removing it from one phone to
| insert it in another one while driving would be IMHO the
| "essence" of distracted driving, BUT in this specific case it
| was an (automatic? or previous?) update, from the article:
|
| >In this particular case, the phone had recently downloaded
| an update that included new baseband firmware. That was
| almost certainly the trigger for this message.
|
| The "recently" is "vague" enough, as we don't know how much
| time passes after tyhe update for the SMS to be sent by the
| SIM, it could be milliseconds but as well several minutes or
| even hours.
| judge2020 wrote:
| I don't think the article is alluding to the suspect being
| innocent, just that this specific "text" was automated and can
| be ruled out as having been physically sent by the person in
| question. Other texts around the same time could still make
| them guilty of distracted driving.
| DeathArrow wrote:
| I'm not sure that I would like the SIM to send data to anyone
| without me knowing it. But since both Android and iOS send user
| data without the user acknowledging, it might not be the biggest
| privacy issue.
| runnably wrote:
| This is a very well-written post! I don't know much about telecom
| stuff, but I didn't need to to understand this.
| C19is20 wrote:
| Also, the tldr is at the beginning!
| kaycebasques wrote:
| The author used a nice trick at the beginning of each section:
| phrasing the main idea of the section as a question and then
| answering that question.
| lxgr wrote:
| Not wanting to downplay the security implications of the SIM
| OTA/SAT infrastructure at all, but I think in this case, there is
| also a non-nefarious explanation:
|
| Back in the day of feature phones and early smartphones, carriers
| would proactively send device connectivity profiles (not sure
| what the technical term is) containing things like MMS and WAP
| configuration data to any new phone on their network.
|
| This might just be AT&Ts way of implementing the trigger for such
| a system. Obviously it would be unused today (iOS and Android
| don't support these profiles anymore to my knowledge), but these
| technologies generally have a very long tail.
| mintplant wrote:
| > iOS and Android don't support these profiles anymore to my
| knowledge
|
| Sure they do. You can configure them under the "Access Point
| Names" setting page in Android (buried under advanced network
| settings). Some MVNOs need you to input all that configuration
| manually when you first connect.
| lxgr wrote:
| Ah, I think I was unclear - iOS and Android phones don't
| support _updating these profiles via SMS_ anymore in the way
| that some older feature- and smartphones did.
|
| The first time a network would see a new device (or after a
| long period of inactivity), it would send these out
| automatically, which was mostly useful but at times annoying
| when switching phones regularly.
|
| There was usually also a way to manually trigger them, like
| sending a certain text (e.g. SETUP) to a short code.
|
| Of course iPhones and Android smartphones still need APN and
| MMS data to function correctly, but these days that data
| seems to be part of the OS. In my view, that's a step back -
| I've had to get onto Wi-Fi to look for the correct APN for a
| travel SIM more than once. Arguably, it should be part of the
| SIM these days, just like the SMSC configuration.
| desktopninja wrote:
| To me the process sounds like a regular ping and registration
| process. After all SMS was designed as a "ping protocol" and
| someone with a bright idea monetized it! #respect
___________________________________________________________________
(page generated 2021-11-07 23:01 UTC)