I am implementing a client (IOS device) and Server. I wish to keep the payload of request/responses to a minimum so plan to implement a custom TCP based service. My only concern is if I can rely on the port I use being always open through 3G etc. There must be other apps that use non standard ports and TCPon IOS?
If you can, you might use Port 80/443(SSL) for your custom TCP server. You only have to ensure that your have a free IP on your Server to bind your custom server-application to port 80.
If it's not HTTP(D) behind port 80/443(SSL), thats not a problem!
When using other port you may run into problems with blocked traffic in firewall rules.
But that's the standard case. Like a VOIP/SIP iOS App needs the SIP Port 5090. So if you are try to make a call within your University WiFi where only some Ports except 5090 are supported, the app won't run/connect.
So. You should make it like Viber or WhatsApp Messenger does. Use Port 80/443(SSL) and try to get the max possible connects trough possible firewalls.
Related
I've got an app that supports Bonjour and manually connecting to an IP (all within the same local network). I'm now looking at whether I can use MPC instead and while it obviously would be able to replace Bonjour, I haven't seen anything that allows me to replace the functionality around manually connecting to the IP. For context, my app runs in networks that have multicast disabled which is when users fall back to manually entering the IP address.
I could have the receiving app host a webserver and send a request there. Could I create a Peer based on the ip:port combination? That would allow me to make use of MPC for the MCSession aspect.
Is it possible to set up a Multipeer Connection based on an ip:port rather than having it automatically discovered via multicast?
I'll go with a solution based on NWConnection which uses NWEndpoint and can be created with both IP:port and a Bonjour-established service.
If I would've had access to the full Network.framework then I could've used that for both discovery & communication but due to SDK constraints I'll be using MultipeerConnectivity for the discovery aspect instead. By providing the device its IP & port when broadcasting the Bonjour service, another device can discover it automatically and then use the extra info to create an IP:port-based NWConnection.
When I use Charles Proxy for iOS and play some games, I recognize that they etablish connections with the protocol prefix "socket://" followed by an IP address (instead of a hostname, which is always present for other HTTP(s) connections). I'd assume that those are websockets.
Currently, I'm trying to implement a tool to track rudimentary network activity. To archive that, I'm using the NEKit (https://zhuhaow.me/NEKit/) in combination with the NEPacketTunnelProvider extension for iOS. Using that, I was able to set up a local HTTP Proxy server and setup the network interface to redirect every HTTP(s) request over that local proxy. Through an observer, I was able to see all the requested hostnames.
Now I found out, that some games (those which are using websockets) are not working properly with my solution. Regarding to this discussion https://news.ycombinator.com/item?id=16694670 it seems like proxying the HTTP(s) data flow doesn't enable me to handle websocket connections:
Yes, but the problem with Charles (well, iOS related at least) is that iOS websockets don't go through the HTTP Proxy configured. They're just considered a raw socket. Thus, even on desktop Charles, it's a nogo.
Due to that, some apps don't even work when my tracker is enabled, since they can't etablish a connection to their servers.
Is there the possibility to archive something similar for the websocket connections since the combination of GCDHTTPProxyServer (NEKit) and NEProxySettings (NetworkExtension) is only working for HTTP(s)? How can I track and (even better) proxy websocket connections?
I'm using Charles Proxy and Wireshark to monitor http(s) traffic from various iOS apps I'm using on my iPhone. These apps require me to set the HTTP Proxy under the iOS Wifi settings (let's call these the Proxy Settings).
My business needs to see ALL URL's that are being called from my phone. From all apps. All URL's, not some of them.
Now Charles and Wireshark both work fine and I can see a ton of traffic coming from my phone.
However, I can't help but wonder whether I might be missing some HTTP calls. Maybe calls that don't use the Cocoa Core Foundation libraries as the basis for their networking.
For instance, I could write my own HTTP library out of TCP/IP and these would bypass the Proxy Settings.
So my question is: what is the likelihood that some apps are using custom-rolled HTTP libraries and side-stepping my Proxy Settings. Or worse, they're using raw TCP/IP to communicate with a server. I know it's possible, but do any APIs work this way? Does anyone do it?
I found the answer: Use mitmproxy in transparent mode. proxy is not used. harder to setup because it needs work on the router, but it reliably captures every packet on port 80 and 443 regardless of proxy settings.
Assuming that you are able to keep your device tethered, then you may be able to use the pcap service to monitor all traffic. According to the following paper (2014) the pcap service is running on every iOS device:
"Identifying back doors, attack points, and surveillance mechanisms in iOS devices"
You should be able to connect to it via usbmuxd. I'm not sure whether there is a pre-rolled client for the pcap service. There is a list of services supported by libimobiledevice here. Pcap is not on that list.
Alternatively, you can use wireshark to capture all traffic on your wifi network.
I'm trying to make a file sharing app. One solution that I came up with is using an embedded mini HTTP server to allow others to connect to my app (and serve content to them). Now, I wonder, what if, the user already has an app that uses this technique, and already has the port 80 busy listening for incoming connections. When I'll try to start my server, it will fail, won't it? Can I avoid this situation?
80 tcp port well known as HTTP, best way to avoid this problem is select some non popular port after 1024 to your app
Assuming that you run your mini web server in your iPhone and your user is in another iPhone or a PC, they will connect to you based on your IP or bonjour address. The HTTP traffic will use port 80 by default so if you are not using http you will probably want another port other than 80. The webdav apps for iPhone typically use 8080. Regarding your question - if they have a web server app in their iPhone installed - it does not matter even if they are using the same port, the server runs on your iPhone not theirs.
I do not think that the iPhone can operate more than 1 wen server at a time, I understand new virtualisation technology allows multiple web servers running in a common server with a common IP, Far as I know the webdav apps that I have cannot run concurrently.
Is there an app or clever way to check TCP:IPv4 traffic for a host:port on iOS devices? Users will be connecting to a device with an iOS app, and if there is an existing way to sniff or otherwise log TCP (and any IP traffic) on an iPad that would be super useful. We could eventually add this into the app, but it seems like there has got to be a nice app for inspecting a network... e.g. some of the functionality of wireshark, socat, and nmap. I don't seem to be able to use the right search terms in the app store and I'm also wondering if there is a way to do this in the Safari browser?
I ended up using iTelnet and turning off all the login scripts. That will connect to any ip:port with TCP.