I have a program on my iPad that makes a direct TCP connection (bypassing the HTTP proxy settings in the Settings menu). I have been tasked to debug this, but I've been unable to find a way to capture the data stream (and the guy who compiles the program is not very responsive).
So... I've been trying to set my wlan to "no encryption at all", booting up Kali, putting the wlan interface into monitoring mode (airmon-ng start wlan0). Then started Wireshark & tried sniffing on both mon0 & wlan0. Neither did really result into anything useful.
That's what I did till now, but I'm out of ideas.
Does anyone know what way I can do it? (preferably even using Windows?)
What I want to get in the end is a pcap file (so I can look at it in Wireshark) of the data traffic. I'm not interested in the packets per se, but in the raw data transfer of the application.
Thanks!
Use another Laptop (Windows or Linux, your choice) with WLAN card in Promiscuous mode, which will sit besides your iPad and capture all the packets on air.
Check this for more details.
What I finally did: I own an Android telephone which could be rooted (and installed "Shark for Root"). So, I enabled a hotspot, connected my iPad to it, and dumped the traffic that way. Weird thing though is that I had to reboot my device to be able to download the pcap file to my computer. It could be read on the device by SharkReader though without reboot.
bitShark is another option, and looks much more nice, but I prefer the simpler interface of Shark for Root.
Related
I'm currently looking at options to allow me to build a remote COM-port solution.
The idea is to be able to access from my remote PC, another PC that's directly connected to a device locally via its serial COM-port.
I know that the obivous answer is to use a VPN between the 2 Internet connected PCs.
However, I need this solution to be as seamless to the end-user as possible.
i.e. no installing and configuring VPN software, etc.
So I was thinking that WebRTC would be great because the end-user can simply use their web-browser and not have to install any additional software.
My question is, is it possible to stream the COM port data between the 2 PCs via WebRTC?
If so, can you please point me in the right direction as to how I can go about achieving this?
Sorry if this is a ridiculous question, I'm very new to WebRTC, just exploring my options.
Thanks.
That should work great!
Networking wise you get NAT Traversal. That means the two computers can be in completely different networks, and still communicate. You may have to run a TURN server if P2P isn't possible.
Data wise you can exchange anything you want via data channels. It is datagram based and you can send/receive binary data. You get a callback telling you how much has been delivered, that way you can detect backpressure.
Are you ok with installing software on the remote host? You can do something like Pion WebRTC's data-channels. This shows you can have a browser connect to a Go process via WebRTC. Then use tarm/serial on the remote host to interact with the device.
If you want a browser on both ends there is the Web Serial API I haven't used it myself though. That locks you into only doing Chromium which might be an issue.
I'm in a need of network sniffer that attaches itself to a process in Windows 7 and sniff through it's networking like ... where it is sending packets to what the packets contain what packets it is receiving basically all the network traffic between that selected process and the server it is sending packets to.
I already downloaded tools like Rawcap and SmartSniff but they either don't work as intended or they throw some errors while trying to attach to the process.
I also tried wireshark but it sniffs my whole traffic not per process base
I know a freeware-Capsa Free which may cover your needs. But they request you to register to download. http://www.colasoft.com/download/products/capsa_free.php
So you are looking for something like Unix's 'strace' command :) Please find Microsoft Process Monitor here: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx , give also a try to xperf: http://msdn.microsoft.com/en-us/library/ff190983%28VS.85%29.aspx
Good luck! :)
So when I am debugging my web applications and such, I've used the Charles web proxy and debugger and love it. It's so nice to see what's being sent and received via port 80 and 443. I can see all the resources loading, not just from the "browser" per say, but also flash applications. I can also see how the calls are being made, and it pretty easy to reconstruct them. It's a great debugging tool and I love it.
So I'm wondering two things:
First, I'm wondering is if there is something similar I can use to watch traffic that might be coming though on other ports. I guess some desktop applications will use the internet, but not necessarily via http / https requests. I remember looking at some security tools a few years ago - there are a lot of security tools out there, like kismet / etherCap, ethershark, etc - is there one that does what I'm describing in an easy and intuitive way?
Also, I'm wondering if I am using my iPhone / iPad / Android device, how can I set up a proxy through my computer so I can watch the http/https requests that the device makes?
Found the answer to that one here: http://www.ravelrumba.com/blog/ipad-http-debugging/
I'm mostly on a Mac so anything that is Mac friendly would be extra helpful.
Thanks!
I believe you are looking for Wireshark. It allows you to monitor the network interface on your machine and be able to tell you sent/receive packets as well as their protocols. It also has a protocol decoder that can be used to get Layer 7 information about a IP stream. You can also do a "Follow TCP stream" which allows you to view the entire conversation of that connection. It's based on libpcap (Packet capture) which the built in tcpdump also uses.
The only downside for you web developers is that if you're using SSL encrypted sessions, you can't decode it. The endpoints of the SSL session are "above" (using OSI model) the layer at which wireshark (and similar tools) operate.
Here's a good list http://sectools.org/sniffers.html. I used Wireshark back when it was Ethereal. At that time it ran under X11, It looks like that has changed.
I'm looking for a tool along the lines of Fiddler, or better yet Wireshark, that would run on a Windows Mobile 6.1 device.
I have an app which calls some webservices on one of our servers, and I want to make sure it it going out to the proper address.
Whenever I want to test something like that I connect the device to my PC and use ActiveSync. The mobile device then can send all of it's internet requests through the PC. Wireshark can then be used to sniff the traffic coming in and out of the device. Works good and is a stable approach.
I recently had to search for this myself. There are a few of these out there but most are old and have not been updated recently. If you are looking for one to sniff the WiFi traffic it should be simple and Google should provide something suitable. However the issue I ran into (and could not get around with about 3hrs invested) was trying to sniff the EV-DO/Cell data connection. Seems the cell radio uses a different type of network driver then the WiFi connections on a WinMo device. Not much of an answer, sorry, but I figured I would share my experiences.
There is an experimental version of WinPCap for windows CE.
Maybe it will work for you.
Is there a term used for whether a serial port echos characters received remotely versus having the local machine echo characters sent locally? I am looking to establish a SCPI command for turning on/off this remote echo protocol. Do most serial interface systems rely solely on echo characters locally when desired?
USConverters USB to RS485 Compact-Professional (SN-060519)converter uses a always on echo signal. RS485 is a half duplex communication so USConverters evidently felt the need to use the Receiver/Transmitter to always echo back what the host sent out to show that the character/data got the converter.
I've seen this SCPI command:
SYSTem
:COMMunicate
:SERial
[:RECeive]
:ECHO ON | [OFF]
No
When interactive systems with relatively or even absolutely dumb (what we now call) clients were common almost all of them used a round-trip to what is now called the server for character echo. It simply wasn't possible to have any control over the user experience without it. Even the purely electromechanical teletypes used full duplex on Unix systems.
The few systems with local echo were more-or-less emulating punch card input and generally were used to run a single large program that cooperated with the terminal hardware to run customer information systems or other online applications, but not true interactive computer access. Some of these systems were expensive and sophisticated, and they ran a lot of bank terminals, but they were almost universally disrespected for their interactive design.
As a concrete example, it is unlikely that even 0.1% of all the interactive Unix remote clients ever used local echo. (I'm sure it happened a few times on some pathetic and now forgotten mainframe.)
Having said all that, I'm not familiar with your application and perhaps it is simple enough that local echo makes sense. Since today's clients are far more powerful than yesterday's "servers", we pretty much only see the old paradigm when we ssh into a CLI to do some local system admin.
But even in that case in today's world we always have a "full duplex" (remote echo) system.
There are two different terminologies in play, that I'm aware of...depending on whether you're talking about a terminal device, or a host computer.
Back in the day....using a computer usually meant a VT-100 terminal or similar RS-232 device, connected via modem or hardline to the host. Such terminals would often
have a DIP switch selecting between "half duplex" mode (which echoed characters locally,
for devices that didn't support simultaneous incoming and outgoing I/O), and "full duplex"
mode, where the remote device was responsible for echoing any input it received.
The Unix "stty" command can enable or disable local echoing from the host side of the connection. This was probably necessary to interoperate with legacy devices that were hardwired for half-duplex or full-duplex only.
You are somewhat likely to encounter either terminology (half/full duplex, host echo on/off) to describe this sort of configuration.
In the context of modern human interface devices, full-duplex/"host echo enabled" is by far the most common configuration.
Embedded devices, on the other hand, are quite likely to employ custom protocols that don't involve one side echoing its input back across the connection.
As far as I recall, the concept is called "local echo", and it it's never used anymore.