Skip to content

Instantly share code, notes, and snippets.

@sebastien
Last active January 3, 2017 05:18
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sebastien/2da68e6c6032309cd056 to your computer and use it in GitHub Desktop.
Save sebastien/2da68e6c6032309cd056 to your computer and use it in GitHub Desktop.

Android & iOS "call-home" workaround

as explained by Matthias Strubel

If you disable mobile access on Android, you can still use an unprepared offline network. If you have mobile networks enabled and connect to a not prepared offline network, the smartphone will fall back to mobile wifi. Sometimes, there is a message, that gives you some chance to use it, but the Samsung phone I had for test purposes denied to work with LibraryBox (which is not prepared yet).

iOS5 or iOS6 introduced a call-home function, that checks for the internet. If it does not receive a specific answer (see below), it opens up a lightweight browser, where you usually can login in hotels (the captive portal). If you don't solve the connection issue with logging in, I think < iOS9 does not fall back to mobile network. I read, that iOS9 will partialle use mobile internet, when the wifi connection is bad. As vague this statement is, so low my knowledge is. Fact is, my prepared PirateBox does not bring my iOS9 iPhone back into mobile network mode.

How to fix that?

Android: Answer is: Send a HTTP-Code 204 on a specific request. I documented the progress of my our investigation here: PirateBox-Dev/PirateBoxScripts_Webserver#59 - It includes the domain names & URLs you need to spoof to answer a request. If you want to catch only specific domains, it might be additional work to figure all out.

iOS: Answer is: Answer with "Success". see https://github.com/PirateBox-Dev/PirateBoxScripts_Webserver/blob/master/piratebox/piratebox/www/library/test/success.html

Before iOS6 the URL was like apple.com/library/test/success.html , so simply take over that domain to your servers IP and prepare that folder including the success.html file.

Since iOS7 Apple uses a BUNCH of domains for sending out the internet check requests (apple owns all the domains). Spoofing them all is quite hard, but you can identify the request on its user-agent. This topic is one of the Top20 posts, linked from different pages including a cisco forum :D http://forum.piratebox.cc/read.php?9,8927 - you find the lighttpd.conf snippet inside. On PirateBox, we have this special configuration in lighttpd, that reacts on the user-agent and always deliver that success.html on every request. Since iOS7, that spoofs the internet detection in a very robust way until today.

For PirateBox, mostly static DNS entries in the network configuration are the problem, because I didn't want to setup firewall rules for DNS request... but I guess it is now time for that. .. but, that is another topic.

BTW: If you implement those things straight ahead, you loose the automatically opening browser on iOS and maybe a notification on Android. AFAIK, You can circumvent this, when you implement a original CaptivePortal which "unlocks" the fake answers after you confirmed the access in the CaptivePortal. Remember: The Mini-Browser of iOS for doing those CaptivePortal registration is very limited in its functions.

I think, if you implement those two techniques in your offline network application/infrastructure, you can circumvent it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment