Hi all, it took me a year or so but I've finally managed to build Tor for iOS with a working support for TransPort, as you can see on: https://github.com/sid77/evelyn/blob/master/tor/make.sh The next natural step is to hack together full device torification as iOS jailbroken devices can run pf (without ALTQ support).
I'm not very comfortable with pf and pfctl so my first step was to head out to https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#BSDPF looking for some clue. However, jailbroken iOS' ifconfig can not bring up a second loopback interface (I think the kernel is not allowing it) so I had to test out some custom rules, my current pf.conf is as follow:
-8<- scrub in
rdr pass on lo0 inet proto tcp all -> 127.0.0.1 port 9040 rdr pass on lo0 inet proto udp to port domain -> 127.0.0.1 port domain
block return out
pass quick on lo0 keep state
pass out quick inet proto tcp user nobody flags S/SA modulate state pass out quick route-to lo0 inet proto udp to port domain keep state pass out quick route-to lo0 inet proto tcp all flags S/SA modulate state -8<-
taken from: https://github.com/sid77/mobiletor/blob/master/pf.conf I apply it running this script: https://github.com/sid77/sbsettingstor/blob/master/com.sbsettingstor.enable Tor is running as user nobody (not really secure but I still have to figure out system user management on the platform) and answering DNS queries on 127.0.0.1:53.
This solution is failing *REALLY* hard as I managed to run into a kernel panic as soon as I tried to generate some traffic with Mobile Safari or Cydia.
Is there any pf guru out there which can give me some insights?
Ciao, Marco
On 5/31/12 5:19 PM, sid77@slackware.it wrote:
Hi all,
Hi Sid.
it took me a year or so but I've finally managed to build Tor for iOS with a working support for TransPort, as you can see on: https://github.com/sid77/evelyn/blob/master/tor/make.sh
Whoohoo!
The next natural step is to hack together full device torification as iOS jailbroken devices can run pf (without ALTQ support).
I'm not very comfortable with pf and pfctl so my first step was to head out to https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#BSDPF looking for some clue.
It's been a while since I've used pf for serious things, but I think I can still manage.
However, jailbroken iOS' ifconfig can not bring up a second loopback interface (I think the kernel is not allowing it) so I had to test out some custom rules, my current pf.conf is as follow:
That's weird. I can look into that over the weekend.
-8<- scrub in
rdr pass on lo0 inet proto tcp all -> 127.0.0.1 port 9040 rdr pass on lo0 inet proto udp to port domain -> 127.0.0.1 port domain
block return out
pass quick on lo0 keep state
pass out quick inet proto tcp user nobody flags S/SA modulate state pass out quick route-to lo0 inet proto udp to port domain keep state pass out quick route-to lo0 inet proto tcp all flags S/SA modulate state -8<-
taken from: https://github.com/sid77/mobiletor/blob/master/pf.conf I apply it running this script: https://github.com/sid77/sbsettingstor/blob/master/com.sbsettingstor.enable Tor is running as user nobody (not really secure but I still have to figure out system user management on the platform) and answering DNS queries on 127.0.0.1:53.
This solution is failing *REALLY* hard as I managed to run into a kernel panic as soon as I tried to generate some traffic with Mobile Safari or Cydia.
Is there any pf guru out there which can give me some insights?
I expect that you really _DO NEED_ that second loopback interface for the above config, otherwise your packets will just end up in one big loop. A workaround might be to tag the packets when they are rdr'ed and make sure that you only rdr packets that are non-tagged. I have to look up the exact syntax on how to do that. I strongly suggest testing your pf rules on another machine first (OpenBSD or FreeBSD VM) and then deploying in iOS.
Do you have the kernel crash log handy by any chance? It should be in /Library/Logs/CrashReporter/Panics
Cheers, RPW
----- Original Message ----- From: "Ralf-Philipp Weinmann" ralf@coderpunks.org To: tor-dev@lists.torproject.org Sent: Thursday, 31 May, 2012 5:46:49 PM Subject: Re: [tor-dev] Help with pf and iOS
Whoohoo!
LOL, thanks!
I expect that you really _DO NEED_ that second loopback interface for the above config, otherwise your packets will just end up in one big loop. A workaround might be to tag the packets when they are rdr'ed and make sure that you only rdr packets that are non-tagged. I have to look up the exact syntax on how to do that. I strongly suggest testing your pf rules on another machine first (OpenBSD or FreeBSD VM) and then deploying in iOS.
Yeah, I sense the loop there. I thought that
pass quick on lo0 keep state pass out quick inet proto tcp user nobody flags S/SA modulate state
was my "exit strategy", anyway. Looks like they never really work ;-) Tagging packets is a good idea! It's something I didn't think to try in first place as, usually, it's useless when it comes to iptables but it's pf here, so I should definitively try it.
Do you have the kernel crash log handy by any chance? It should be in /Library/Logs/CrashReporter/Panics
Gone, but I will try to replicate it. Looking for some 0days, are you? :-P
<sid77@...> writes:
----- Original Message ----- From: "Ralf-Philipp Weinmann" <ralf@...> To: tor-dev@... Sent: Thursday, 31 May, 2012 5:46:49 PM Subject: Re: [tor-dev] Help with pf and iOS
Whoohoo!
LOL, thanks!
I expect that you really _DO NEED_ that second loopback interface for the above config, otherwise your packets will just end up in one big loop. A workaround might be to tag the packets when they are rdr'ed and make sure that you only rdr packets that are non-tagged. I have to look up the exact syntax on how to do that. I strongly suggest testing your pf rules on another machine first (OpenBSD or FreeBSD VM) and then deploying in iOS.
Yeah, I sense the loop there. I thought that
pass quick on lo0 keep state pass out quick inet proto tcp user nobody flags S/SA modulate state
was my "exit strategy", anyway. Looks like they never really work Tagging packets is a good idea! It's something I didn't think to try in first place as, usually, it's useless when it comes to iptables but it's pf here, so I should definitively try it.
Do you have the kernel crash log handy by any chance? It should be in /Library/Logs/CrashReporter/Panics
Gone, but I will try to replicate it. Looking for some 0days, are you? :-P _______________________________________________ tor-dev mailing list tor-dev@... https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi sid77,
I've got tor in transparent proxy mode working on jailbroken iPod 4 with iOS 6 installed. I've started with iOS 5.1.1 but quickly found out that any 'route-to' rule results in kernel panic as soon as there is a match while the same ruleset worked as expected on Mac OS X machine. My bet is on the fact that the 'jailbreaking' is the culprit of this behaviour
Everything worked just fine on a jailbroken iOS 6 though, I'm not a pf guru, I just needed a proof of concept, so my ruleset looked like this(I'm running tor as root from command line, hence the allow root rule):
table <self> const { self }
rdr on lo0 proto tcp from any to ! <self> -> 127.0.0.1 port 9040
#allow ssh on 22 pass in quick proto tcp from any to any port 22 pass out quick proto tcp from any to any port 22
#allow root(tor) traffic pass out on ! lo0 proto tcp all user root tag "allowed" keep state
pass out on ! lo0 route-to lo0 \ proto tcp all\ ! tagged "allowed" \ tag "intercepted" \ keep state
As you can see the udp traffic bit is left out and furthermore, the whole ruleset could be optimized but it works.
The second nasty bit was compiling tor for iOS 6. I'm pretty sure you know the iOS SDK doesn't come with all required by transparent proxy functionality include headers, net/pfvar.h in particular. Quick googling gave me
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/net/pfvar.h as well
as the other 2 missing and required by net/pfvar.h
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/tree.h and http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/net/radix.h
after downloading those I quickly figured the -DPRIVATE and -DNO_APPLE_EXTENSIONS flags and compiled tor. Well, it didn't work with tor giving me an ENODEV error over ioctl() call, so I suspected the headers were too old. My kernel version was xnu-2107.2.33, but the latest available version of xnu was 2050.9.2 (http://www.opensource.apple.com/source/xnu/xnu-2050.9.2), so I crossed my fingers and downloaded the required headers from that tree.
Some locations have changed since v1456.1.26. My curl commands executed from inside <SDK>/usr/include looked like this:
sudo curl -o libkern/tree.h \ http://opensource.apple.com/source/xnu/xnu-2050.9.2/libkern/libkern/tree.h?t...
sudo curl -o net/radix.h \ http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/bsd/net/radix.h?txt sudo
curl -o net/pfvar.h \ http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/bsd/net/pfvar.h?txt
I noticed that NO_APPLE_EXTENSIONS ifdefs were gone from the pfvar.h, so I patched tor/src/or/connection_edge.c, replacing all instances of pnl.sport, pnl.dport and pnl.rdport with pnl.sxport.port, pnl.dxport.port and pnl.rdxport.port respectively.
After compilation I ran tor from cl like: ./tor --User root --DataDirectory . --TransPort 9040 --SocksPort 0 --Log debug making sure it works only in Transparent Proxy mode with SOCKS disabled
Toggling pf rules in another terminal causes showmyip.com to show different IPs while observing traffic flowing through tor.
Hope this information helps.
All the best, E.F.
The pf rules formatting is broken, here are the correct ones
table <self> const { self }
rdr on lo0 proto tcp from any to ! <self> -> 127.0.0.1 port 9040
#allow ssh on 22 pass in quick proto tcp from any to any port 22 pass out quick proto tcp from any to any port 22
#allow root(tor) traffic pass out on ! lo0 proto tcp all user root tag "allowed" keep state
pass out on ! lo0 route-to lo0 \ proto tcp all\ ! tagged "allowed" \ tag "intercepted" \ keep state
On Fri, Sep 28, 2012 at 3:41 PM, Eugene F. e.fryntov@psiphon.ca wrote:
<sid77@...> writes:
----- Original Message ----- From: "Ralf-Philipp Weinmann" <ralf@...>
To:
tor-dev@... Sent: Thursday, 31 May, 2012 5:46:49 PM Subject: Re:
[tor-dev]
Help with pf and iOS
Whoohoo!
LOL, thanks!
I expect that you really _DO NEED_ that second loopback interface for
the
above config, otherwise your packets will just end up in one big loop.
A
workaround might be to tag the packets when they are rdr'ed and make
sure
that you only rdr packets that are non-tagged. I have to look up the
exact
syntax on how to do that. I strongly suggest testing your pf rules on another machine first (OpenBSD or FreeBSD VM) and then deploying in
iOS.
Yeah, I sense the loop there. I thought that
pass quick on lo0 keep state pass out quick inet proto tcp user nobody
flags
S/SA modulate state
was my "exit strategy", anyway. Looks like they never really work Tagging packets is a good idea! It's something I didn't think to try in first
place
as, usually, it's useless when it comes to iptables but it's pf here, so
I
should definitively try it.
Do you have the kernel crash log handy by any chance? It should be in /Library/Logs/CrashReporter/Panics
Gone, but I will try to replicate it. Looking for some 0days, are you?
:-P
_______________________________________________ tor-dev mailing list tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi sid77,
I've got tor in transparent proxy mode working on jailbroken iPod 4 with iOS 6 installed. I've started with iOS 5.1.1 but quickly found out that any 'route-to' rule results in kernel panic as soon as there is a match while the same ruleset worked as expected on Mac OS X machine. My bet is on the fact that the 'jailbreaking' is the culprit of this behaviour
Everything worked just fine on a jailbroken iOS 6 though, I'm not a pf guru, I just needed a proof of concept, so my ruleset looked like this(I'm running tor as root from command line, hence the allow root rule):
table <self> const { self }
rdr on lo0 proto tcp from any to ! <self> -> 127.0.0.1 port 9040
#allow ssh on 22 pass in quick proto tcp from any to any port 22 pass out quick proto tcp from any to any port 22
#allow root(tor) traffic pass out on ! lo0 proto tcp all user root tag "allowed" keep state
pass out on ! lo0 route-to lo0 \ proto tcp all\ ! tagged "allowed" \ tag "intercepted" \ keep state
As you can see the udp traffic bit is left out and furthermore, the whole ruleset could be optimized but it works.
The second nasty bit was compiling tor for iOS 6. I'm pretty sure you know the iOS SDK doesn't come with all required by transparent proxy functionality include headers, net/pfvar.h in particular. Quick googling gave me
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/net/pfvar.has well
as the other 2 missing and required by net/pfvar.h
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/tree.hand http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/net/radix.h
after downloading those I quickly figured the -DPRIVATE and -DNO_APPLE_EXTENSIONS flags and compiled tor. Well, it didn't work with tor giving me an ENODEV error over ioctl() call, so I suspected the headers were too old. My kernel version was xnu-2107.2.33, but the latest available version of xnu was 2050.9.2 (http://www.opensource.apple.com/source/xnu/xnu-2050.9.2), so I crossed my fingers and downloaded the required headers from that tree.
Some locations have changed since v1456.1.26. My curl commands executed from inside <SDK>/usr/include looked like this:
sudo curl -o libkern/tree.h \
http://opensource.apple.com/source/xnu/xnu-2050.9.2/libkern/libkern/tree.h?t...
sudo curl -o net/radix.h \ http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/bsd/net/radix.h?txts...
curl -o net/pfvar.h \ http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/bsd/net/pfvar.h?txt
I noticed that NO_APPLE_EXTENSIONS ifdefs were gone from the pfvar.h, so I patched tor/src/or/connection_edge.c, replacing all instances of pnl.sport, pnl.dport and pnl.rdport with pnl.sxport.port, pnl.dxport.port and pnl.rdxport.port respectively.
After compilation I ran tor from cl like: ./tor --User root --DataDirectory . --TransPort 9040 --SocksPort 0 --Log debug making sure it works only in Transparent Proxy mode with SOCKS disabled
Toggling pf rules in another terminal causes showmyip.com to show different IPs while observing traffic flowing through tor.
Hope this information helps.
All the best, E.F.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Eugene F. -
Eugene Fryntov
-
Ralf-Philipp Weinmann -
sid77＠slackware.it