I'd like to send RAW network packets from our Delphi application (XE3 to XE5, if important), but I can't find any info whatsoever about using PCap in Delphi at all.
How would one do that?
There is one Magenta library (sockmon and sockstat, monitoring and statistics library for observing raw incoming packets on selected interface), which works nice for receiving RAW packets, however there is no option to send RAW packets out.
Thanks.
Related
I am working on Windows with C# but this is more of a general question.
If I receive UDP packages with a UDP client they are normally removed from the receive buffer so other programs can no logner access this data.
My experiments showed that this is not the case for boradcast messages. If I connect multible programs to the same UDP port and call the receive function both application can see the broadcast packages, but only one application can see unicast packages as they are deleted when first read by the OS?? I guess...?
My question is is there a way to change this socket behaviour? can I set up my socket to preserve this data so a second programm could access it as well? Or is this not possible?
the overall goeal as you can guess is to have multible programs receive the same UDP packagees send via Unicast.
After alot of research i can confirm this is not possible with unicast packages.
You can use PCAP to achive this but not with the native UdpClient
im in the process of making an application similar to skype to interact with another computer and i have a few questions.
I know all the basics such as how to send data over tcp etc in the form of an image and audio.
How does applications like skype send live audio? Does it litrally record 1 byte of audio, send it and play it and then repeat the process? For me its not instant so i dont see how that would be possible.
How would u send string and image through tcp at the same time (video call + chat), would you use multiple ports? i can see how that would be very bad. The way im doing it atm is when i click to recive an image, i set it up to receive an image so it receives properly, if a string got sent at this time for example, it wouldnt work as it cant be converted to an image if you see what im saying. im not sure how else i would do it. I Could send each thing with its type as the beginning for example "string Hello how are you" then decypher the data type through that, but that seems abit tedious and slow.
If anyone could give me an insight, that would be fantastic
I can't speak for how skype does it, but this should be a starting point:
Streaming audio/video is usually transported over UDP sockets, not TCP. TCP guarantees delivery whereas UDP is best effort. If you have a temporary connection loss you care more that the video you're receiving is current, not that you receive the whole stream.
The data is usually compressed (and sometimes encrypted) using a standard compression algorithm after being received from a camera/microphone. Have a look at H264, which is commonly used to compress video.
RTP is often used to transmit audio/video. It allows multiple types of stream to be combined over a single socket.
Control traffic is usually sent separately over a different socket, usually TCP. For example SIP which is used for VoIP phones initiates a control connection over a TCP or UDP port (usually 5060). The two ends then negotiate which types of stream will be supported, and how those streams will be sent. For SIP, this will be an RTP stream which is set up on a different UDP port.
I have a software which uses a TUN device to read datapackets, process something on them and send them out. Now I am asking myself, if it is possible, to send the "tun packets" without touching them.
Over the TUN device I get IP Packets but over a RAW socket I just can send self defined transport layer packets...
Is there a possibility to just take this packet from the TUN device and send it over a network card out?
If anybody is interested in that topic, I wrote a witepaper to wrap up all needed information to use RAW-sockets: http://tuprints.ulb.tu-darmstadt.de/6243/1/TR-18.pdf
You didn't enable IP_HDRINCL socket option on the RAW socket?
If IP_HDRINCL option is enabled, you can send self defined network layer packets.
I want to capture and save the data that's being sent to a certain process through internet .
Are there any tools for the job?
If not, does listening to the same port as the process that I'm trying to get data from, will get me the data?
Any help appreciated !
You can try Wireshark: http://www.wireshark.org/
Or RawCap: http://www.netresec.com/?page=RawCap
I don't know what is the data format you are trying to capture. I used these two tools to capture xml data from web service.
On Windows, use Winsock Packet Editor (WPE). You will be able to hook a process' all Winsock-related functions and capture (and even modify/block) any TCP/IP, UDP packets that the application receives or sends. For all other operating systems, you will have to either:
write your own tool that hooks various socket functions (e.g. send, recv, etc.)
or just use Wireshark which will capture all Layer-3 packets that goes through your network card. You will have to use your own knowledge of the application that you're trying to monitor in order to filter the packets that are specific to the application.
Are there any tools for the job?
Wireshark. But what have you tried?
If not, does listening to the same port as the process that i'm trying to get data from, will get me the data?
Not if you don't forward the traffic to the real destination, otherwise the other party will be waiting forever on a response, or simply timeout and close the connection. You should create something like a proxy.
Wireshark is easier.
I am capturing network packets of Gtalk using Microsoft Network Monitor. Very often I see small sessions of communication where a packet with TCP payload of 37 is sent by me to dst port 5222 and I receive an ACK for it. I can't see the contents of this packet because it is encrypted using TLS. Gtalk uses XMPP protocol. Any experts know what does this small session represent? Is it part of protocol specifications? Is there any way I can see the contents of this packet?
Is this being sent periodically, like every 30s, 1m, etc? If so, it's likely one space character, after it's been (potentially compressed then) encrypted. Many XMPP endpoints will do this to keep the socket open in the face of the large number of odd middleboxes that assume that if you haven't sent data in a while, the socket is dead.