30 October 2010

SMSC Address Caching in iPhones

I'm going to make one of my increasingly-rare technical posts today.

When we got back from Burning Man this year we received a few instances of a really interesting bug report. It goes like this: "My friend X and I texted each other on the playa with your system, but now that we are back home, we can't text each other anymore. Texts to and from other people still work. We both have iPhones." After some head-scratching, I recommended a brute-force fix: "Delete all of the messages you exchanged through our system at Burning Man." It worked.

So what happened? When you receive or send a text message via SMS, it has two E.164 addresses. One address, in layer 5, is the mobile phone number of the subscriber sending or receiving the message. The other address, in layer 4, is the SMSC that processes the text message. (SMSCs are to text messages what SMTP servers are to e-mail, and they have E.164 addresses just like telephones.) Normally, the SMSC address for your outgoing text messages is set by your carrier. In some phones, you can also override the carrier's SMSC address and provide one of your own. Here's my working theory: It appears that certain models of iPhone, under some set of conditions, remember the SMSC addresses from which you received a text message and then use that SMSC address for future outbound messages. When you send a text to a given person, these iPhones appear to send the outbound message through the same SMSC used for the most recent message received from that person, or, possibly, the SMSC address used for an error message associated with an attempt to send to that person. Since the OpenBTS system doesn't have a real SMSC address, we were just filling in the SMSC address field in the L4 header with a fake number. When people got home, these iPhones continued to use this fake SMSC address to send texts to anyone from whom they received text messages through our network. Those send attempts failed. When they deleted the messages with the fake SMSC address, everything worked normally again.

So what do we do to prevent this? One solution would be to stick a known SMSC address into the L4 header, instead of the fake one, but that might have unexpected effects of its own. A better solution is to preserve the L4 SMSC address end-to-end, even though we don't use it, which is what we will do in the future.

Live and learn. It is interesting to know, though, that you can use a BTS tool like OpenBTS or OpenBSC to control SMSC settings in a closed device like the iPhone. That probably deserves more investigation.


13 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. May be there is a side effect of standard mobile functionality "Reply via same SMSC". Author of the message can request such reply using a special flag in SMS header, resulting in answer being send via SMSC of a sender instead of default (which was set on a phone).
    SMSC address for outgoing messages is always set on the phone(usually from the sim-card, where it is written by operator).

    ReplyDelete
  3. Indeed, OpenBTS always sets TP-Reply-Path to 1 and thus advises MS to use SMSC from an original message. As long as OpenBTS actually ignores SMSC, I think we should set it to 0 to prevent such abuse.

    And it seems that iPhone follows specs - GSM 03.40 Annex D recommends to use "original SC" (i.e. SMSC from original message) to increase probabiility of message delivery.

    But it's still may be an interesting security issue.

    ReplyDelete
  4. So I also took a look at 03.40 Annex D after reading kzayko's comment, and this is a "feature" of the spec. But we only heard these reports for iPhones, so there's clearly some variation in how the spec is implemented. Yes, we should change the TP-Reply-Path, or at least make it configurable by the operator.

    As a security matter, it also an interesting attack path for a rogue SMSC, or for an IMSI-catcher operating in concert with a rogue SMSC.

    ReplyDelete
  5. Hi,.
    sorry about my bad english
    (USRP1~700$ D-BOARD~2*275$ ) about 1500$ without pc, BUT i may need about 10,000 of USRP + D-BOARDs but it is expensive, How can i reduce cost?

    another question: how many concurrent connection does the OPENBTS starterkit can handle?

    ReplyDelete
  6. Axez -

    Contact me privately through the e-mail address in a kestrelsp.com web site. Be sure to put OpenBTS in the subject line.

    -- David

    ReplyDelete
  7. Hi David,

    Happy new year !
    Hope to get some good news about the OpenBTS project on this blog.
    Best wishes for 2011 to you and your relatives.
    Best wishes to Harvind too.

    Cheers.

    Jean-Samuel.
    :-)

    ReplyDelete
  8. very informative article thank for this

    ReplyDelete
  9. http://www.telegraph.co.uk/technology/mobile-phones/7019873/Vodafone-guarantees-home-coverage-with-50-femtocell.html

    Femtocells are being sold in Europe now, is it possible that they could ever be useful for the project? Could they democratize the hardware costs needed?

    Michele

    ReplyDelete
  10. NICE POST! I'm glad I found this blog!!

    ReplyDelete
  11. Just stumbled upon your blog, and I love it. Irrelevant piece of information: I studied crreeative writing in Sheepwash, Devon.

    ReplyDelete
  12. When choosing the http://www.faucetsmarket.com/kitchen-faucets-c-22.html pieces and faucets, one should shop around before purchasing a specific Antique brass faucet. There is always a tendency to find something that may sometimes look better or be priced in Bathroom mirror more pleasing way than the purchased one.

    ReplyDelete
  13. When choosing the http://www.faucetsmarket.com/kitchen-faucets-c-22.html pieces and faucets, one should shop around before purchasing a specific Antique brass faucet. There is always a tendency to find something that may sometimes look better or be priced in Bathroom mirror more pleasing way than the purchased one.

    ReplyDelete