iPhone TTL modification to cloak tethered packets - let's make them work harder to catch us.

[UltimaKilo]

I called AT&T three days ago to sign up to a tethering plan. Since 2007, I may have used at most 8GB of data. When I called they tried to con me out of my data plan without telling me. Obviously I was very angry since I've been such a loyal customer for 20 years now.

So now I've followed these steps and I've been tethering with my unlimited data plan for a couple of days. As of right now, I have not received a text message or an email. Albeit, I've barely had to use it. OP's post makes a lot of sense and I know other people have had some success with this, at least on a Windows machine.

I've been keeping an eye on this thread for a couple of days now. I haven't really needed to tether, but its good to know that I have it if I need it. I hope this helps mask us from AT&T. I can't believe a company would try to screw over such a loyal customer who barely even uses data (I'm always on WiFi).

 

[sbddude]

Obviously I was very angry since I've been such a loyal customer for 20 years now.

Really? 20 years? I didn't know there was such a thing as AT&T Wireless 20 years ago. Even cell phones 20 years ago?

I can't believe a company would try to screw over such a loyal customer who barely even uses data

Loyalty means nothing to AT&T and most large companies.

 

[gloss]

Really? 20 years? I didn't know there was such a thing as AT&T Wireless 20 years ago. Even cell phones 20 years ago?

The first consumer cell phone was the DynaTAC in 1983.

 

[sbddude]

AT&T was founded in 1994
http://en.wikipedia.org/wiki/AT&T_Wireless_Services

and for those interested, http://en.wikipedia.org/wiki/History_of_mobile_phones

 

[TC25]

AT&T was founded in 1994
http://en.wikipedia.org/wiki/AT&T_Wireless_Services

AT&T Wireless was created in 1994 not AT&T.

Really? 20 years? I didn't know there was such a thing as AT&T Wireless 20 years ago. Even cell phones 20 years ago?

This would appear to be a case of people think history started the day they were born.

Loyalty means nothing to AT&T and most large companies.

and why should it, to any company, regardless of size?

 

[sbddude]

AT&T Wireless was created in 1994 not AT&T.



This would appear to be a case of people think history started the day they were born.



and why should it, to any company, regardless of size?

Thank you but I am older than 20.

AT&T Wireless, which we are all a customer of if we have an AT&T iPhone, was not in existence 20 years ago.

Anyway, enough OT. Please return the discussion to the original topic.

 

[TC25]

Anyway, enough OT. Please return the discussion to the original topic.

I agree, you embarrassed yourself enough.

 

[dukebound85]

I agree, you embarrassed yourself enough.

Why not let the issue drop? You seem to be getting caught up on semantics of his reference of ATT

 

[TC25]

Why not let the issue drop?

If you wanted this topic to drop, why did you reply?

You seem to be getting caught up on semantics of his reference of ATT

Ah, this is why. So, when I reply it's because I won't let the issue drop but when you do, it's to 'add value' to the discussion. Now I understand. No more replies from me.

 

[Fry-man22]

I called AT&T three days ago to sign up to a tethering plan. Since 2007, I may have used at most 8GB of data. When I called they tried to con me out of my data plan without telling me. Obviously I was very angry since I've been such a loyal customer for 20 years now.

So now I've followed these steps and I've been tethering with my unlimited data plan for a couple of days. As of right now, I have not received a text message or an email. Albeit, I've barely had to use it. OP's post makes a lot of sense and I know other people have had some success with this, at least on a Windows machine.

I've been keeping an eye on this thread for a couple of days now. I haven't really needed to tether, but its good to know that I have it if I need it. I hope this helps mask us from AT&T. I can't believe a company would try to screw over such a loyal customer who barely even uses data (I'm always on WiFi).

Every post from the post quoted above this one is OFF TOPIC and should honestly be deleted.

I don't care about AT&T plans or customer service for the purpose of this thread. For the love of God we're now discussing when it started?!?!? Once again, if you don't have anything concrete to add to the technical discussion please start another thread to rant about plans or share knowledge as to the formation dates of the company.

 

[Fry-man22]

I'm not sure this is right for the question that was asked. The question as I understood it was: can AT&T detect tethering if a VPN is used _On The iPhone_. I think your answer is correct for a VPN established on the tethered device but not for a VPN established on the iPhone.

I believe that, if the iPhone itself establishes the VPN, any tethered packets would be sent through the VPN, which results in the VPN software sending a new iPhone-originated packet containing the original packet through to the VPN software on the other side, where it's unwrapped and sent on to the original destination. If that's right, there should be no way for an external viewer (e.g. AT&T) to distinguish between a VPN packet originating with an iPhone app and a VPN packet originating from a tethered source.

I could be wrong about this, but I'm actually not sure how it would work for a VPN to NOT encapsulate all traffic, local or not, within a series of VPN packets. From a TCP/IP perspective, the VPN itself is the sender/receiver of all traffic; that there's other TCP/IP information contained within that stream should be irrelevant to the VPN packets themselves.

I'm sorry but you are indeed incorrect. The poster you quoted was EXACTLY CORRECT and explained it perfectly. They have to have the "Envelope" information exposed so they can be routed. The answer given was correct regardless of the origination of the VPN connection.

 

[qsl]

I'm sorry but you are indeed incorrect. The poster you quoted was EXACTLY CORRECT and explained it perfectly. They have to have the "Envelope" information exposed so they can be routed. The answer given was correct regardless of the origination of the VPN connection.

I'd like a bit more of an explanation of this, then. How is the "Envelope" information on the tethered device in any way relevant?

Here's an example, using a "normal" VPN instead of a "privacy" VPN.

Computer X sends a packet destined for internal.foo.com, a site behind a corporate firewall and not routable via the public internet. Computer X routes its traffic to Computer Y. Computer Y is running a VPN connection to foo.com. Computer Y encapsulates the packet within a VPN packet, routing it to vpn.foo.com. The packet traverses the internet, arrives at vpn.foo.com, and is unwrapped. vpn.foo.com sends the packet to internal.foo.com.

In what way would it be relevant for the routers between Y and vpn.foo.com to know that the packet is destined for internal.foo.com? They can't route to internal.foo.com; indeed, they may be unaware of the existence of internal.foo.com. There is no requirement that this "envelope" be exposed; it's relevant only to vpn.foo.com.

For another take on this, consider "privacy" VPN services; I'll give secure-tunnel.com as an example, since they support iPhones. The idea here is that your computer makes a connection to secure-tunnel.com's VPN server; all traffic is then routed over the VPN. The ENTIRE point of buying this service is that the systems between your computer and secure-tunnel.com's VPN server cannot tell to where your packets are being sent nor what is in them. Exposing "envelope" information for the packets routed through the VPN would largely compromise the value of the service.

VPNs are defined-endpoint services. Every packet sent through the VPN starts at one of the endpoints (e.g. your iPhone) and ends at the other (the VPN server), or vice versa of course. There is no need to expose any routing information about where the packets being sent through the VPN are going; no intervening routers can send those packets anywhere but to the endpoints and have them make any sense to the receiver.

Again, if you can provide a viable explanation as to why the VPN would need to expose envelope information, I'd be happy to revise this. But it needs to make sense in both the traditional and privacy senses and respect the defined-endpoint nature of the VPN.

Also: it makes an enormous difference where the VPN originates. If the VPN originates on the tethered system, all bets are off. At that point, the packets are just like any other packets originating on that system and will have the 65 TTL, etc. They're not subject to deep inspection, because they're encrypted, but the TTL value will still be different by default. However, if the VPN originates on the iPhone, in a networking sense the packet has originated on the iPhone, not the tethered node.

 

[Fry-man22]

I'd like a bit more of an explanation of this, then. How is the "Envelope" information on the tethered device in any way relevant?

Here's an example, using a "normal" VPN instead of a "privacy" VPN.

Computer X sends a packet destined for internal.foo.com, a site behind a corporate firewall and not routable via the public internet. Computer X routes its traffic to Computer Y. Computer Y is running a VPN connection to foo.com. Computer Y encapsulates the packet within a VPN packet, routing it to vpn.foo.com. The packet traverses the internet, arrives at vpn.foo.com, and is unwrapped. vpn.foo.com sends the packet to internal.foo.com.

In what way would it be relevant for the routers between Y and vpn.foo.com to know that the packet is destined for internal.foo.com? They can't route to internal.foo.com; indeed, they may be unaware of the existence of internal.foo.com. There is no requirement that this "envelope" be exposed; it's relevant only to vpn.foo.com.

For another take on this, consider "privacy" VPN services; I'll give secure-tunnel.com as an example, since they support iPhones. The idea here is that your computer makes a connection to secure-tunnel.com's VPN server; all traffic is then routed over the VPN. The ENTIRE point of buying this service is that the systems between your computer and secure-tunnel.com's VPN server cannot tell to where your packets are being sent nor what is in them. Exposing "envelope" information for the packets routed through the VPN would largely compromise the value of the service.

VPNs are defined-endpoint services. Every packet sent through the VPN starts at one of the endpoints (e.g. your iPhone) and ends at the other (the VPN server), or vice versa of course. There is no need to expose any routing information about where the packets being sent through the VPN are going; no intervening routers can send those packets anywhere but to the endpoints and have them make any sense to the receiver.

Again, if you can provide a viable explanation as to why the VPN would need to expose envelope information, I'd be happy to revise this. But it needs to make sense in both the traditional and privacy senses and respect the defined-endpoint nature of the VPN.

Also: it makes an enormous difference where the VPN originates. If the VPN originates on the tethered system, all bets are off. At that point, the packets are just like any other packets originating on that system and will have the 65 TTL, etc. They're not subject to deep inspection, because they're encrypted, but the TTL value will still be different by default. However, if the VPN originates on the iPhone, in a networking sense the packet has originated on the iPhone, not the tethered node.

Dude, I don't need to explain TCP/IP Packet Header protocol in this thread - http://en.wikipedia.org/wiki/IPv4#Header this wiki shows you all you would want to know. Basically VPN is irrelevant to this ENTIRE DISCUSSION as that pertains to encrypted DATA in the packet structure as described here http://en.wikipedia.org/wiki/IPv4#Data

The packet traverses the internet, arrives at vpn.foo.com, and is unwrapped.

So how does it traverse the internet if the magic VPN has covered up all routing info? I'm not saying I know exactly how endpoint VPN tunnels work, but I can tell you the packet has to have routing data exposed.

Please if you have questions and don't understand Google it, but it has been discussed that deep packet inspection is likely not the way AT&T is detecting tethering so further VPN discussion is totally OT.

It makes no "enormous difference" where the VPN is, that just determines if the packets from only the tethered device have encrypted data or if all packets leaving the device are.

Again, if you can provide a viable explanation as to why the VPN would need to expose envelope information, I'd be happy to revise this

Right, I forgot, the magic internet tubes let your packets traverse them and they find their way to the endpoints like light-bikes in TRON...

I could not care less if you revise anything. I honestly didn't read all your entire huge post because it's just not important at this point. Once again, it's not my job nor is it the purpose of this thread to explain VPN or the way packets are routed to you so if you are confident in your statements by all means stand by them.

PDANet has an option in their latest release to "Hide Tethering". Hopefully MyWi will release a similar update soon and I can just delete this thread.

 

[Sparky9292]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_2 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8H7 Safari/6533.18.5)

There is a easy way to tell if MyWi, Pdanet are detected.

Simply sign up for AT&T's tethering plan. Then use MyWi for a day.
Look at your statement online under tethering use and see if AT&T recorded it.

I know that the new PdaNet has a stealth mode but no one really knows if it works. I might spend the $45 for a month to AT&T so I can access the data and see the logs.

I read an article that states that PdaNet, MyWi don't really do any native routing. They simply hook on to the iPhones tethering codebase. That makes sense because it would take too long to code everything from scratch.

So now, the authors of MyWi and Pdanet need to get off their lazy asses and code lower level and avoid using any of the native iOS tethering code that flags AT&T.

I wish PdaNet would simply prove stealth mode works rather than guessing.

 

[patent10021]

So now, the authors of MyWi and Pdanet need to get off their lazy asses and code lower level and avoid using any of the native iOS tethering code that flags AT&T.

LOL Heaven forbid they make their lives easier with perfectly legit and ready to use clean code

 

[qsl]

Before I make specific responses, here's a very short argument. If you can't respond to this, please admit that you don't really understand how VPNs work:

There are commercial services which sell VPNs for privacy/anonymity. Their service is based on the VPN masking both the content and destination of the data being sent from your computer, preventing ANY intermediate observer from determining either of those things. If your understanding of VPNs is correct, how can these services possibly provide the services their customers pay for?

So how does it traverse the internet if the magic VPN has covered up all routing info? I'm not saying I know exactly how endpoint VPN tunnels work, but I can tell you the packet has to have routing data exposed.

The packets travel from one endpoint of the VPN (the originating computer) to the other (the VPN server) and vice versa. That routing information is exposed -- it has to be. Information as to where the actual data packets are going is irrelevant to the intermediate nodes. VPNs are used used to send packets which are not publicly routeable.

See http://en.wikipedia.org/wiki/VPN for information about how VPN endpoints work. Basically, you're right in saying the VPN packets need to have routing information, but completely incorrect in saying that the ultimate destination needs to be exposed. Only the VPN server/client endpoints need to be exposed.

A VPN is in fact exactly the sort of "magic tube" you dismiss in your argument, only it's not magic and is very simple conceptually. On each end, the VPN accepts packets destined for a variety of hosts. These packets are encapsulated in a VPN packet which is sent from one endpoint of the VPN to the other. On the other end the encapsulation is removed and the packet is sent to the original destination. From the perspective of the intermediate nodes between VPN endpoints, all that is being sent is a sequence of packets originating at one endpoint and terminating at the other. The content of these packets, INCLUDING the routing information used only once the VPN has been traversed, is not available.

Please if you have questions and don't understand Google it, but it has been discussed that deep packet inspection is likely not the way AT&T is detecting tethering so further VPN discussion is totally OT.

This is highly misleading. It has been discussed, but the conclusion of the discussion was that AT&T does has considerable investment in deep packet inspection technology and is likely using it to detect tethering. However, this particular thread is about TTL inspection.

I honestly didn't read all your entire huge post because it's just not important at this point.

So your belief is that you can dismiss an argument by sticking your head in the sand and ignoring it?

 

[Sparky9292]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_2 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8H7 Safari/6533.18.5)

So now, the authors of MyWi and Pdanet need to get off their lazy asses and code lower level and avoid using any of the native iOS tethering code that flags AT&T.

LOL Heaven forbid they make their lives easier with perfectly legit and ready to use clean code

True, but it makes it really easy for AT&T to detect.

Wonder what will happen to MyWi now that at&t can detect it and legal tethering does not need it anymore.

 

[rwd hero]

Someone could make a lot of money if they would hurry and write an easy to use tweak and sell it for $.99

 

[Azzin]

Does this help: http://www.iphonedownloadblog.com/2...nauthorized-tethering-from-jailbroken-iphones ?

 

[Benji222]

pda net does this..

 

[mainomega]

...WORKED ?...

I did this on my laptop... 5 hours later... I get a faking txt from them about tethering.

It did not work for me !

 

[DirtySocks85]

...WORKED ?...

I did this on my laptop... 5 hours later... I get a faking txt from them about tethering.

It did not work for me !

But for how long have you been doing this? The problem that I've been noticing is that people seem to assume that AT&T is notifying them because they just detected them. This seems highly unlikely. AT&T has to take time to process this data. More likely is that they already had you in the system to receive the notice and you just happened to get it after 5 hours of TTL hidden right before you were going to get a notice anyway. Unfortunately, I don't think this is going to be easy to determine since AT&T could have a lot of us on a list, but we just haven't gotten our notices yet. I haven't been notified, but even if I stopped tethering today I'm going to guess that I could get a notice from previous use.

 

[mainomega]

I stopped tethering as soon as it was announced by this forum (an others) that people had started receiving notices. So it couldn't have taken them a month to process the data. Anyways I'm in Chicago if anyone is keeping a regional mental chart.

 

[scottuf]

Yes - you can change the TTL of the iPad by either installing a terminal client and using the sysctl command on the device or you can ssh into the device and execute it there. The command to change it is the exact same as the one posted above for OSX.

IMPORTANT NOTE though - this does NOT persist though a reboot of the iPad. After a reboot the ttl reverts to 64 and it MUST be changed again. It should be easy to create a shell script to do this and set it to execute at startup. I'll see if can get this done tonight and post how to set it up.

This whole thread should come with the disclaimer that we still don't know for sure if this is how they detect tethering. It is in my opinion by far the most likely, but that could be totally off base.

Were you able to get a shell script for the ipad to work? can you post how to set it up if so?

thanks

 

[scottuf]

Were you able to get a shell script for the ipad to work? can you post how to set it up if so?

thanks

nvmd, figured it out and it works

unzip the attached. Place com.scott.TTLmod.plist into /Library/LaunchDaemons on the iPad. Make sure ownership is root:wheel and permissions are 644. Place TTLmod.sh into /var/mobile/Scripts. Make sure permissions are 775. Might have to create the Scripts folder.

Reboot and running

sysctl net.inet.ip.ttl

should return 65.