I'm trying to figure out the communication between an iOS app, and an online server. To my knowledge, a REST service is used.
With a tricky setup with two macs, an ethernet hub and an iPhone, I manage to capture the traffic between the device and the server.
So far so good. However, when I fire up the app, a trace is shown in Wireshark (also very good), but all that is listed is in TCP protocol, where I am expecting HTTP protocol.
Now, I'm running out of knowledge.
Does this mean, that there is no HTTP communication going on at all, or am I seeing raw TCP packages that need to be assembled into HTTP? If the latter, how do I approach that, and will I ever see readable xml?
Thanks for your insights!
Actually, this question became obsolete, since I found exactly what I wanted to do here:
http://nickfishman.com/post/50557873036/reverse-engineering-native-apps-by-intercepting-network
Related
I need to make TCP based decentralised chat app for local network. By decentralised I mean there is no central server. Each entity on a network should have server/client architecture. When app starts it should check which user is online ( already running the app ). My question is how can i check that? Can i do it by trying to connect via connect() function from socket library? I'm new to programming, especially socket programing, so if it's a dumb question sorry in advance.
You should definitely study how other decentralized applications do this. There are lots of techniques.
Each instance of the application should, as part of its server functionality, track the addresses of other instances of the application. Each instance should, as part of its client functionality, keep track of a few instances it can connect to. Prefer instances that have been around for a long time.
The software should include a list of servers that have been running for a long time and are expected to typically be available. You may wish to include a fallback method such DNS, maintained by anyone willing to keep a list of well-known servers offering access through a well-known port. The fallback method can also be IRC or HTTP.
If you want to stay decentralized, you might want to try multicasting or broadcasting a request packet to all hosts on the network to discover other instances of your chat application.
Something similar has been implemented in Pidgin, named Bonjour. It works quite nicely and provides chatting capabilities on a local network. More specifically, it is defined as a Serverless Messaging part of XMPP.
If you are looking for code examples, have a look at one of my projects where I use multicast to discover hosts on the local network that provide a specific service: Headers and implementation.
Since I'm not happy with the functionality of an iPhone App that operates my Actioncam, I would like to write an app that improves on that functionality.
In order to do that, by lack of proper documentation, I need to reverse engineer the communication between the App and the Device.
What I know, is that the Device only responds on ports 21, 554 and 15740.
I managed to create a setup including an iPhone, the Device and two Macs, and traffic analyzing software called Charles (but likely I could also use Wireshark), that shows me all HTTP(S) traffic.
This is where my knowledge ends. What I hoped to see, was that Charles would report something like
rtsp://[my device ip, which is known to me]:554/[unknown to me path]
Potentially it would even involve a login and password in that URL.
Could any of you give me a hint on how to proceed? Aforementioned software seems to be limited to HTTP traffic.
What excatly do you want to reverse engineer? The video feed or control logic? From what you mentioned it seems that 21 could be used for FTP, 554 for RTSP and 15740 for some custom TCP protocol. If you have no idea about the format of the data that is sent over to the port 15740 it will be quite hard to reverse engineer (except if it is some kind of plain text ascii protocol).
For the video feed - I'd suggest setting up Wireshark to monitor the port 554 and then you should be able to see the url of the video location from the DESCRIBE command.
I'm currently playing around with WebRTC on Chrome behind a company firewall, using Google's demo app at: https://apprtc.appspot.com. Is there any sure-fire way to determine whether the connection being made to another app user outside my company firewall is via UDP or streaming TCP through Google's STUN/TURN server? chrome://webrtc-internals provides a lot of stats, but nothing obvious to me. Or is there an API call I can make during the session to determine the transport type? Thanks
=========== UPDATE ==============
FYI, this provides more information - press 'i' when using the demo app will show if using a TURN server (but not if using tcp/udp).
Wireshark will work fine for that. On Firefox, you can go to about:webrtc, click on the peerconnection, and see which candidates from ICE were selected (and if they're TCP or UDP, etc).
[edit - added]
Programmatically, you can look at the type of candidates using statistics reports, such as in this example and this PR and using the type property. You may have to parse the SDP to get the priority from the Candidates in Firefox. (thanks to Fippo for pointing this out).
I want to setup a personal videoconferencing service for my family, friends and myself. The main problem I have with current options is that they are either closed-source and centralized (GG hangouts, skype) or open-source but not working in corporate environment or in hotels (due to strict firewalling rules and the "Skype is going through, if you want VOIP use that" kind of netadmin reaction).
I have two solutions then. Either setup a STUN/TURN relay server and use XMPP and SIP as I used to, but that would require my friends to setup that too. Or setup a whole VOIP server. 2 solutions come to mind: SIP and XMPP. Though to my knowledge, each of them ultimately uses the (S)RTP/RTCP protocol.
And that's the problem. Out of the specific signaling part used by the two of them, I really can't figure out the difference between them, their typical use case.
I think you're right in that as far as setting up a video conferencing system XMPP and SIP are equivalent. They both are signalling only protocols and the media sessions they set up typically use RTP (although they can both be used to set up any kind of session you want but RTP is the norm).
The biggest problem is also going to be the one you mention about getting video streams out of a corporate firewall. Skype overcomes this obstacle by sending it's media over an SSL connection and is thus able to get through firewalls. Theoretically you could do the same with RTP and in the past I once used openvpn connections with a SIP client to test some audio calls. My experience wasn't great as the audio was very choppy, assumedly as a result of all the extra packaging that is required to get the high volume of small audio packets from one end to the other. That was nearly a decade ago though so perhaps with the better CPU and bandwidth resources available now it would work better.
Personally I think I'd stick with Skype as it's going to be a big hassle to set up your own system. If you were to go ahead with your own the first option I would try would be Asterisk combined with openvpn so that if the clients were behind a firewall or had NAT issues they could connect over it.
I'm trying to get into an implementation of some kind of push notification for a Windows WPF client application and a java backed server.
The idea is to avoid as much as possible polling the server, so I thought to implement it with sockets and messages, and relying in some easy pulling solution in case a socket connection could not be done, (Firewalls, etc).
In the other hand is important that the data traveling get encrypted.
So I have a couple of question/"request for opinions" more related with the WPF client:
Perhaps already exist some solution for that, any tips?
Could be good to think in some SSL sockets connections for that?
If 2 is OK, there is some native solution for secure sockets in .net or any library?
If sockets solutions is an option, I guess i need to go through port 443 and by the way it will avoid many problems with firewalls and so on, am i right?
I know there is many question but all are related to the same problem.
Thanks in advance.
http://clientengine.codeplex.com/
Yes, SSL is good if you need to keep the data secure during transfer
Yes, http://clientengine.codeplex.com/ indicates it supports SSL/TLS
Well, it depends on whether you are controlling the server or not. If you have control over it you can use whatever port you want.