NEPacketTunnelProvider Sniffer iOS - ios

As I recently found this paper describing a sniffing mechanism for iOS using Apple's NEPacketTunnelProvider Extension, I got curious and it made me want to understand it from a technical point of view. As I usually don't work at a deep network layer like that, I'm not able to comprehend it in the detail I'd like to. As Charles Proxy for iOS must do something very similar without requiring supervised devices, I assume the approach which the author of the paper presented in 2016 might be still working nowadays.
The author claimed that "Everything like IP packet parsing, building
an IP packet or parsing a DNS response had to be implemented ourselves." As I want to fully understand that, I tried to build it myself. I build a NetworkExtension and a message loop for the packetFlow of the NEPacketTunnelProvider. I was able to obtain the ip datagrams and tried to parse them. I used unsigned integers of the corresponding size for the source and target ip, the transport protocol and ip version, but I'm unsure how to handle the treat the payload. My parser uses the ptr.load(fromByteOffset: <offset>, as:<DataType>.self) where ptr is a UnsafeRawPointer to access the packet flow information. Since the data might exceed the storage of UInt64, I don't know how to access and store the payload in a proper way.
Furthermore, I figured that the source IP is always 192.168.20.1 (set as my interface's NEIPv4Settings address) and my target ip is always 192.168.2.1 (my dummy NEDNSSettings server). This leads me to my first questions: Are those DNS queries? Will the datagram packet claim any further information about the actual target? Would that mean that I have to somehow execute the request to the DNS server and reroute the packet to the target which I will obtain from that DNS query?
The next step would be to implement a TCP / UDP handling, right? My current parsing approach is able to distinguish between UDP, TCP and ICMP (even though I don't have investigated in the last one yet). Therefore, I'd iterate over the datagrams and lookup whether they require a UPD or TCP session/connection and transfer the datagram. The problem I currently see their from a conceptional point of view: How do I know which source/target port to use for TCP/UPD connections/sessions? As far as I know, this information is not part of the IP Packet itself (since it's rather some information we need on transport layer level, not on network layer level).
Additionally, I found a project called Specht on github. It uses a self-written library called NEKit which somehow also uses the NEPacketTunnelProvider approach. When I understand their approach correctly, they managed to somehow build a local proxy server by writing some observer mechanisms in order to handle the requests, but since I'm relatively new to networking and swift, I'm not sure whether I understand that completely correct or whether I just haven't find all those TCP/UDP and/or DNS logic. Is this project comparable to the approach of the paper and charles proxy?
One last question: Charles proxy is in most cases able to show the hostname of the target. I'm currently just able to see destination ip addresses (which aren't real destination ip addresses, but the address of my DNS server). How am I able to see the hostname as human readable text? Does Charles do a nslookup somehow? Does Charles obtain that information out of the datagrams?
I know it's quite ambitious of me with much missing knowledge in this topic, to build something similar for test reasons, but I'm still motivated to look deeper into that topic and also have the feeling that I have understand already some key points, but unfortunately not enough to solve the puzzle... Maybe you're able to give me some more hints to get a better understanding. If there might be even an easier way to archive a similar behavior (to see outgoing connections on hostname level), I'd be interested in these as well :-)

I've published a Beta Proxyman iOS (website) - a Network Sniffer by using NEPacketTunnelProvider and Network Extension, so I might have experienced to answer some of your questions.
IP Package, IP Diagram, DNS, How to parse it?
Luckily, there is another way to set up a NEPacketTunnelProvider to provide you with an HTTP Message, not IP Package (it's too low-level, and you have to deal with the Parser, DNS, ...)
HTTP Message is easier to parse because there are plenty of reliable libraries (e.g. http-parser from nodeJS)
How to build a Network Sniffer on iOS?
It's a complicated question to answer, I would break it into small chunks:
MitM / Proxy Server
Firstly, you need a working MitM Proxy Server, which is capable of proxying and intercepting the HTTP/HTTPS Traffic. You can implement it by using SwiftNIO or CocoaAsyncSocket.
How does it work?
In general, the data flow might look like this:
The Internet -> iPhone -> Your Network Extension (VPN) -> Forward to your Local Proxy Server (in the Network Extension) -> Mitm/Proxy Server starts intercepting or monitoring the traffic -> Save to a local database (in Shared Container Group) -> Forward again to the destination server.
From the main app, you can receive the data by reading the local database.
The reason why we need a local database is that the Network Extension and the Main app are two different processes, so they could not communicate directly like a normal app.
Show me the code?
In the Network extension, let start a Proxy Server at Host:Port, then init the NetworkSetting, like the sample:
private func initTunnelSettings(proxyHost: String, proxyPort: Int) -> NEPacketTunnelNetworkSettings {
let settings: NEPacketTunnelNetworkSettings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "127.0.0.1")
/* proxy settings */
let proxySettings: NEProxySettings = NEProxySettings()
proxySettings.httpServer = NEProxyServer(
address: proxyHost,
port: proxyPort
)
proxySettings.httpsServer = NEProxyServer(
address: proxyHost,
port: proxyPort
)
proxySettings.autoProxyConfigurationEnabled = false
proxySettings.httpEnabled = true
proxySettings.httpsEnabled = true
proxySettings.excludeSimpleHostnames = true
proxySettings.exceptionList = [
"192.168.0.0/16",
"10.0.0.0/8",
"172.16.0.0/12",
"127.0.0.1",
"localhost",
"*.local"
]
settings.proxySettings = proxySettings
/* ipv4 settings */
let ipv4Settings: NEIPv4Settings = NEIPv4Settings(
addresses: [settings.tunnelRemoteAddress],
subnetMasks: ["255.255.255.255"]
)
ipv4Settings.includedRoutes = [NEIPv4Route.default()]
ipv4Settings.excludedRoutes = [
NEIPv4Route(destinationAddress: "192.168.0.0", subnetMask: "255.255.0.0"),
NEIPv4Route(destinationAddress: "10.0.0.0", subnetMask: "255.0.0.0"),
NEIPv4Route(destinationAddress: "172.16.0.0", subnetMask: "255.240.0.0")
]
settings.ipv4Settings = ipv4Settings
/* MTU */
settings.mtu = 1500
return settings
}
Then start a VPN,
let networkSettings = initTunnelSettings(proxyHost: ip, proxyPort: port)
// Start
setTunnelNetworkSettings(networkSettings) { // Handle success }
Then forward the package to your local proxy server:
let endpoint = NWHostEndpoint(hostname: proxyIP, port: proxyPort)
self.connection = self.createTCPConnection(to: endpoint, enableTLS: false, tlsParameters: nil, delegate: nil)
packetFlow.readPackets {[weak self] (packets, protocols) in
guard let strongSelf = self else { return }
for packet in packets {
strongSelf.connection.write(packet, completionHandler: { (error) in
})
}
// Repeat
strongSelf.readPackets()
}
From that, your local server can receive the packages then forwarding to the destination server.
Don't forget to save all traffic log to the local database, then notifying the main app to reload it.
One last question: Charles proxy is in most cases able to show the hostname of the target. I'm currently just able to see destination ip addresses (which aren't real destination ip addresses, but the address of my DNS server). How am I able to see the hostname as human readable text? Does Charles do a nslookup somehow? Does Charles obtain that information out of the datagrams?
Since we don't deal with IP Package, we don't need to implement the DNS Resolver. If you need a DNS, you can config like the following code:
let dnsSettings = NEDNSSettings(servers: ["8.8.8.8", "1.1.1.1"])
settings.dnsSettings = dnsSettings
As we receive the HTTP Message package, you can get hostname for free (From the Request's URL or Host Header)
Hope that my answer could help you.

Related

iPhone: IPv4 Wi-Fi access fails with cellular radio enabled

I've got an iPhone app that makes UPnP queries over Wi-Fi to locate a Wi-Fi-connected camera, using GCDAsyncSocket. All the communications use IPv4 addresses over an ad-hoc network created by the cameras themselves, and the app is working properly with over 2500 field deployments.
However I have one customer for whom it fails on his iPhone, unless Airplane Mode is on, or cellular data is turned off. The same camera works fine with his iPad mini, so it's not the camera's fault as best we can determine.
The app sets up a listening socket:
_listenSocket = [[GCDAsyncSocket alloc] initWithDelegate:self
delegateQueue:dispatch_get_global_queue(QOS_CLASS_UTILITY, 0)];
_listenSocket.IPv6Enabled = NO;
accepted = [_listenSocket acceptOnInterface:getWirelessInterface()
port:_upnpPort error:&error];
It then sets up a sending socket, also with IPV6 disabled; connects to the host (at a known or suspected IP address) over the wireless interface; and sends a UPnP SUBSCRIBE message:
_sendSocket = [[GCDAsyncSocket alloc] initWithDelegate:self
delegateQueue:dispatch_get_global_queue(QOS_CLASS_UTILITY, 0)];
if (!_sendSocket) {
NSLog(#"sendMsg: unable to allocate sendSocket");
return;
}
_sendSocket.IPv6Enabled = NO;
NSError *err = nil;
if (![_sendSocket connectToHost:hostParts[0]
onPort:[hostParts[1] intValue]
viaInterface:getWirelessInterface()
withTimeout:TIMEOUT
error:&err]) // Asynchronous!
{
// If there was an error, it's likely something like
// "already connected" or "no delegate set"
NSLog(#"socket connectToHost error: %#", err);
return;
}
[_sendSocket writeData:[msg dataUsingEncoding:NSUTF8StringEncoding] withTimeout:TIMEOUT tag:1];
Normally, this works as expected. However, in this one case, the send fails; the delegate method socketDidDisconnect:withError: gets called:
sendSocket disconnected with error: Error Domain=GCDAsyncSocketErrorDomain
Code=8 "IPv6 has been disabled and DNS lookup found no IPv4 address."
If I delete the "xxxSocket.IPv6Enabled = NO;" lines, I get this instead:
listenSocket disconnected with error: Error Domain=NSPOSIXErrorDomain
Code=65 "No route to host"
Various Googlings indicate that "no route to host" indicates an IPv4 address can't be resolved in an IPv6 environment, and the "IPv6 has been disabled and DNS lookup found no IPv4 address" message is self-explanatory.
Why is this happening on this one iPhone, and not on all the others out there (including my own test instruments)? How might I fix it, aside from saying "turn cellular data off"? Why is DNS even involved, if I'm using the IPv4 address of the very router (ad-hoc access point) I've already connected to to get the network running in the first place?
(One other stackoverflow post (GCDAsyncUdpSocket immediately closes when sending to an IPv6 address) suggested retrying until things worked, but I haven't had any success with that.)
I haven't been able to figure out why this is happening: it affects at least two people on T-Mobile in Florida and California, but I can't replicate it using T-Mobile in Washington.
I did find a fix: replace connectToHost with connectToAddress, which connects to the IPv4 address directly without a DNS resolution step. While connectToHost allows either a hostname or an IP address, it runs a DNS lookup step even with an IP address, and that lookup was getting confounded by whatever was occurring when the affected iDevices were connected to T-Mobile.

iOS & Safari 11 WebRTC does not gather STUN/TURN Trickle ICE Candidates

My web application is failing to gather WebRTC relay ICE candidates via a CoTURN server when using Safari 11 on iOS 11 (iPhone 5s & iPhone 7) or desktop. The web application (which establishes a one-way audio only WebRTC peer connection) works fine between the real browsers (Chrome and Firefox) either direct or via CoTURN relay, and I normally get 6-15 ICE candidates on these browsers.
I have a (frankly, unnecessary) call to getUserMedia on the receiving side, which allows host ICE candidates to be produced by Safari. (Note... the user must approve audio and/or video access before Safari will provide host Ice Candidates, even if on a receiving-only end. I'm past that hurdle, but just so you won't hit it too... This is out of "privacy" concerns.). Before I added the allow getUserMedia, I received no ICE. Now I receive two candidates. One with a private IPv4 and another with an IPv6. This is enough to get the app working properly when on the same machine or local network. So I'm pretty confident with other parts of the application code. I am not sure if my problem is with the application code or the CoTURN server.
Example of the ICE candidates received:
{"candidate":{"candidate":"candidate:622522263 1 udp 2113937151 172.27.0.65 56182 typ host generation 0 ufrag r23H network-cost 50","sdpMid":"audio","sdpMLineIndex":0,"usernameFragment":"r23H"}}
I pretty sure the RTCIceServer Dictionary for my RTCPeerConnection is inline with the following standards:
https://w3c.github.io/webrtc-pc/webrtc.html
https://www.rfc-editor.org/rfc/rfc7064
https://www.rfc-editor.org/rfc/rfc7065
And I've tried multiple variations of parameters:
// For Example:
var RPCconfig = {
iceServers: [{
urls: "turn:Example.live",
username: "un",
credential: "pw"
}]
};
// Or:
var RPCconfig = {
iceServers: [{
urls: "turns:Example.live",
username: "un",
credential: "pw",
credentialType: "password"
}, {
urls: "stun:Example.live"
}]
};
// And even more desperate attempts...
var RPCconfig = {
iceServers: [{
urls: "turn:Example.live?transport=tcp",
username: "un",
credential: "pw",
credentialType: "password"
}]
};
Here's an example of the signaling process log for an idea of what is going on. This is from the receiving side, which is Safari 11. The other browser was Chrome (compare 6 vs 2 ICE candidates). The state change refers to oniceconnectionstatechange.
SDP Offer received.
Sending signal SDP
Sending signal IceCandidate
Sending signal IceCandidate
ICE Candidate Received
4:08:25 AM State Change -> checking
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
4:08:40 AM State Change -> failed
CoTURN is configured quite liberally in terms of accepting every possible transport method as far as I am aware. It works well for providing ICE Candidates and as a relay for the other browsers.
Any direction would be greatly appreciated. Even if it is just a sample RTCIceServer Dictionary code that works or a proven TURN server to try.

Cooja - How to assign different services to a mote/node?

I need to create a network of 10 motes. I want each mote to provide 3 services with s1 = 0.25, s2 = 0.5 and s3 = 0.025. Also, I want to identify / select selfish / malicious mote(s).
Any help will be highly appreciated.
A solution to this should not be complicated to write yourself but I guess you can look at using the service registration and dissemination hack (servreg-hack) application in contiki. The operation of the application is very simple, all the application does is enable nodes to advertise services that they offer by broadcasting a SERVICE_ID (which is just an unsigned 8-bit integer). When a another node in the vicinity of the broadcasting node receives a message it stores the SERVICE_ID and the address of the node that sent the message. If the node needs a service, it can then just look up the address of a node that offers the service by calling the servreg_hack_lookup function.
The unicast-sender and unicast receiver applications in the examples section of the contiki distribution (Contiki/examples/ipv6/simple-udp-rpl) use servreg_hack.
So on both nodes you would initialise the servreg app by calling
servreg_hack_init();
then on the service provider you would register a service by calling
servreg_hack_register(SERVICE_ID, service_provider_ip_addr);
this service would then be received and registered on the service user node. The service user would can then call
service_provider_ipaddr = servreg_hack_lookup(SERVICE_ID);
to get the address of the node that provides the service identified by SERVICE_ID.

Resolving a hostname from Bonjour networking

I have a Java based server using JmDNS which is being discovered from an iOS app.
The discovery works fine and this is the callback that gets executed by the NetServiceDelegate to record the details:
public func netServiceDidResolveAddress(_ service: NetService) {
guard let hostName = service.hostName else {
return
}
mockServerUrl = "http://\(hostName):\(service.port)/analytics"
Logger.log("Using mock server at \(mockServerUrl)", forLevel: .info)
}
This results in a URL that looks like this:
http://az-mbp-ether-lan.local.:9090
Now I swear this was working, however now when I try and send data to this endpoint with Alamofire it consistently times out.
Replacing the hostname with the hardcoded IP address of the target machine makes it work again, so there is no fundamental issue with the code sending the data.
Should an address of the form above ending in ".local." be resolvable from an iOS device on the same network as the target server?
The problem was on the Java server side. It was registering by calling InetAddress.getLocalHost(). This was returning the loopback address.
I revised my code to find a non-loopback address based on this question:
IP Address not obtained in java

Send parameter to socket in swift iOS app

I am making chat application in swift by using socket.io and node.js.
I need to send along the user name parameter with one socket method. I tried like below without sending parameter. This works good but i need to add user name parameter to get specific data instead of total data. sorry for silly question am new to socket concept.
socket.on("updatechat") { dataArray, ack in
print(dataArray)
}
Take a look at SocketIOClientOption, there is a parameter called connectParams.
case connectParams([String: AnyObject]) // Dictionary whose contents will be passed with the connection.
So, all you need to do is to pass the parameters into the config: when your are creating your socket.
let socket = SocketIOClient(socketURL: URL(string: "http://localhost:8080")!, config: [.connectParams(["username": "whatever"])])
If you are looking for SocketManager, you can set it with SocketIOClientConfiguration connectParams.
let manager = SocketManager(socketURL: URL(string: "socket_url")!,
config: [.log(true),
.compress,
.connectParams(["token": "- your token -"])])
You have to connect via sockets using the specific parameter. And then you will receive events only based on restrictions. Like you will connect sockets with an user id, and then will receive messages only for that user.
The implementation is different depend on the library that you are using for sockets. For swift I would recomand to use Socket.IO-Client-Swift.

Resources