I want to know which software/tool can be used to make custom packets and send them and capture responses
I am trying to observe my os behaviour for different packets comming and i want to make my own packets and it may be tcp upd or icmp or ssl packets with the fields i want in them so that i can send to my os and observe its response. So is there any tool/software to do there please help me
I have a pet project called CommsChampion Ecosystem. It was created to facilitate easy and highly compile time configurable implementation of binary communication protocols in C++ for embedded systems. I suppose you could use it to achieve your goal.
At first you use XML based domain specific language called CommsDSL to define your custom binary protocol, then you should use a code generator application called commsdsl2comms to generate a separate CMake project. The latter, may build the protocol analysis and visualization tools, which you could use to send your custom messages / packets and see the response. The CommsChampion Ecosystem is very well documented, you shouldn't have any difficulties navigating it and building everything that you need.
Related
I have been trying to establish a network of ESP8266 (Specifically ESP-01). However, I am not able to find any documentation or anything related on how to actually communicate using HTTP GET and POST methods since I only need a temporary short time communication between multiple sending Nodes to one main Aggregator node.
I don't want to use any Arduino-related libraries as I'm working with STM32. However, I have seen some Arduino-based libraries related to this like ESPAsyncWebServer. But I am not able to find any AT-commands inside it and it's too complicated and intricate for me to understand.
I am basically making a custom library in short so how is communication using HTTP is done between 2 ESPs either using AT commands or any other way (I am going to be communicating to the ESP modules using a dedicated microcontroller through UART) or better if there's any other better way for implementing multiple to 1 connection on ESP. How can I establish this communication to basically send and receive numbers and characters.
I've got a proprietary BMS language that is sending it's info over a specific UDP port on the network. The existing interface is not very well made or maintained, and functions poorly.
I have access to the stack for the code, and don't mind creating some interpretation functionality
My question is what is the best way that I should be receiving these raw packets in my program to be interpreted? I'm not finding any good documentation on how to do this, and I wanted to try and do it in a reasonably appropriate way.
Do I basically need to make my program constantly sniff a specific port? and will this be cumbersome to the network or program to be doing this?
You tagged this BACnet. Why don't you try Wireshark, with a capture filter "udp port 47808" and see if wireshark exposes the packets in a way that makes sense to you. (or have you done this). If it is bacnet, then normal UDP sockets, bound to port 47808 is the way to go. Note, that 47808-47823 are the most common BACnet "default" ports. Use cports or something to see exactly what port(s) your application is bound to.
You could use a packet-capture library - but that has security connotations, so instead you can probably (for most part) get away with using a .NET 'UdpClient'.
But! The real challenge is the breaking-down & interpretation of the BACnet packets, which is the hard part.
There is (now!/finally) a NuGet package for BACnet - not that I've used it, but that might be one of the best choices for your case.
But I also suggest you experiment with the (advanced & free) VTS (Visual Test Tool) too.
You could also try using the BACnet stack that YABE uses too.
I would like to be able to communicated with PLC controllers, so that I can send and receive custom commands on the PLC.
My idea of being able to do this was to have a TCP listener on the PLC that could read TCP incoming packets on a specific port, and execute routines based on the commands in the packets. It could also send information back via TCP/IP.
This would allow me to write software in multiple languages such as C#, PHP, JavaScript, etc. so that software can be used on any platform such as Windows, iOS, Android, etc. to issue commands to the PLC. This would also mean you do not need the PLC software (which can be costly) to view or control the PLC.
I am not a PLC programmer, so I do not know if PLC has the capability of sending and receive custom TCP packets. I would like to know that a) if it is possible b) how feasible it would be to do this and c) what exactly I should research so that I can accomplish this.
Thanks.
It sounds a bit like reinventing the wheel. You want to make something like KepServerEX?
http://www.kepware.com/kepserverex/
There are also two things to consider - one is the ability to interface with the PLC to share data (ie: for a custom HMI) and the other is to program the PLC. For the latter you still need the control software from the manufacturer unless you're willing to reverse engineer and re-write it from the ground up.
Keep in mind, also, that PLCs don't work the same way that other software does. There are no functions or procedures or classes or objects or even really any "commands", per se. A PLC is a system which executes a continuous fixed program of mostly raw logic rules and calculations. A typical interface to an HMI involves reading and writing directly to/from logic bits and word data (ie:hardware memory locations) which represent the current state of the machine. OPC already does this just fine so I'm not quite sure what you're going for.
If you're looking for a cheap/free alternative to a full commercial package, something here may work for you :
http://www.opcconnect.com/freesrv.php
If I understand correctly, when referred to "Run/Stop" you mean for the PLC to 'Start' or 'Stop' scanning the code and updating its I/O. If this is the situation, it would be perfectly suitable to add a Scan_If_On bit (which will be written by a TCP Command) in parallel connection with the "Start" bit controlled by the HMI.
This way, there will be 2 forms of "Starting" the process controlled by the PLC. HMI and TCP.
I have a client which sends data via UDP-broadcast. (To let's say 127.0.0.255:12345)
Now I want to have multiple servers listening to this data. To do so on a local machine, they need to share the port 12345 for listening.
My question is, if that is possible, if there are any disadvantages and if there could be problems with this approach.
There is one alternative which unfortunately brings with a lot of overhead:
Implement some kind of registration-process. On startup, each server tells the client its port. The client then sends the messages to each port (having to send the data multiple times, some kind of handshaking needs to be implemented...)
Do you know any better alternative?
If that matters:
I'm using C++ with Boost::Asio. The software should be portable (mainly Linux and Windows).
You will have to bind the socket in both processes with the SO_REUSEPORT option. If you don't specify this option in the first process, binding in the second will fail. Likewise, if you specify this option in the first but not the second, binding in the second will fail. This option effectively specifies both a request ("I want to bind to this port even if it's already bound by another process") and a permission ("other processes may bind to this port too").
See section 4.12 of this document for more information.
This answer is referenced to the answer of cdhowie, who linked a document which states that SO_REUSEPORT would have the effect I'm trying to achieve.
I've researched how and if this option is implemented and focused mainly on Boost::Asio and Linux.
Boost::Asio does only set this option if the OS is equal to BSD or MacOSX. The code for that is contained in the file boost/asio/detail/reactive_socket_service.hpp (Boost Version 1.40, in newer versions, the code has been moved into other files).
I've wondered why Asio does not define this option for platforms like Linux and Windows.
There are several references discussing that this is not implemented in Linux:
https://web.archive.org/web/20120315052906/http://kerneltrap.org/mailarchive/linux-netdev/2008/8/7/2851754
http://kerneltrap.org/mailarchive/linux-kernel/2010/6/23/4586155
There also is a patch which should add this functionality to the kernel:
https://web-beta.archive.org/web/20110807043058/http://kerneltrap.org/mailarchive/linux-netdev/2010/4/19/6274993
I don't know if this option is existing for Windows, but by defining portable as an attribute for software which runs on Linux too, this means, that SO_REUSEPORT is OS specific and there is no portable solution for my question.
In one of the discussions I've linked it is recommended for UDP to implement a master-listener which then provides the incoming data to multiple slave-listeners.
I will mark this answer as accepted (though feeling kind of bad by accepting my own answer), because it points out why the approach of using SO_REUSEPORT will fail when trying to use it with portable software.
Several sources explain that you should use SO_REUSEADDR on windows. But none mention that it is possible to receive UDP message with and without binding the socket.
The code below binds the socket to a local listen_endpoint, that is essential, because without that you can and will still receive your UDP messages, but by default your will have exclusive ownership of the port.
However if you set reuse_address(true) on the socket (or on the acceptor when using TCP), and bind the socket afterwards, it will enable multiple applications, or multiple instances of your own application to do it again, and everyone will receive all messages.
// Create the socket so that multiple may be bound to the same address.
boost::asio::ip::udp::endpoint listen_endpoint(
listen_address, multicast_port);
// == important part ==
socket_.open(listen_endpoint.protocol());
socket_.set_option(boost::asio::ip::udp::socket::reuse_address(true));
socket_.bind(listen_endpoint);
// == important part ==
boost::array<char, 2000> recvBuffer;
socket_.async_receive_from(boost::asio::buffer(recvBuffer), m_remote_endpoint,
boost::bind(&SocketReader::ReceiveUDPMessage, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)
How do I go about executing a fuzzing strategy to stress a network stack, specifically at the third and fourth layers (network and transport)? I've looked at frameworks to generate fuzzers, like SPIKE, but it seems to me that they are mostly focused on the application layer and above? Is there any well known techniques out there to fuzz well-known protocols in these layers, say, TCP?
Thanks.
Look at Scapy. It allows you to fuzz at the network and transport layers. The fuzz function will fuzz anything you didn't explicitly specify in the IP or TCP layers (you can apply it separately to each). This gives you a range of abilities from just randomly generating ip addresses and port pairs to making and sending nonsense packets.
You may also want to look at Fragroute. This will twist TCP/IP into using all sorts of evasions techniques, but could potentially unveil otherwise hidden bugs/vulnerabilities in your network stack.
Furthermore, if your organization doesn't object, you could set up a Tor exit node and capture traffic from it. I've found it useful for testing correct TCP connection state tracking. Though your end of the connections is well-known and unchanging, there's a huge variety of servers as well as fun network congestion issues. It's basically an endless source of traffic. Be sure to check with your higher ups as your org may object to being a potential source of malicious traffic (even though there is a strong precedent of non-liability). I've gotten around that issue by running it/capturing at home, then bringing in the pcaps.
If you want to fuzz the IP, UDP, or TCP route your packets from your high level services via loopback to a process that reads them, fuzzes them, and forwards them. You need a driver that lets you talk to raw sockets and you need to read/learn what the applicable RFCs say for those protocols.
There is an easy way to do this. Just as Justdelegard recommends, Scapy is probably the best thing to use, in general.
Take a look at Releasing ICMPv4/IP fuzzer prototype by Laurent Gaffié. His Python code, which incidentally he has reposted in more readable fashion at pastebin.com, imports from scapy and uses some methods he defines to do a couple of types of fuzzing. IP and ICMP packets are handled in his sample code. So, this sounds exactly like what you are seeking.
Right now, there seems to be a lot of companies using Tcl/Expect to do custom automated testing of networks. SIP, H.323, layer 2 & 3 protocols, etc.
So if Scapy does not meet your needs, you might be able to make or find something written in Tcl using Expect to do the job. Or, you may wish to do some things in Python, using Scapy - and other things in Tcl, using Expect.
Tcl has long been used for network test and management applications. There was a book on how to use Tcl to do SNMP-based network management way back in the 1990's.
Syntax of Tcl is decidedly odd but the libraries are very powerful. It comes with a framework-like ability to define behavior of custom network behavior atop sockets, similar to what you can do with the standard libraries for the Python programming language.
Unlike Python and other scripting languages, there is an extremely powerful tool for Tcl programs named Expect (see expect man page).
Expect has a handy capability. It can auto generate a Tcl test script. The generated script makes calls to Expect functions. When doing this recording, it functions as a passive man-in-the-middle, recording both sides of the conversation. Kind of the way that you record Macros while you do some editing in MS Word or in Emacs.
Then afterward, you can edit the automatically-generated Expect script to fine tune it, make it behave differently, or creation multiple variations of it. It is very handy for creating regression tests. You should be able to use this to kickstart writing higher layer protocol tests, should you need some. Beats starting from scratch.
I think you can use Tcl/Expect to test standard TCP applications (FTP, HTTP, SMTP, etc.) that use string based commands. It works well for testing character based applications like TELNET that read input from stdin and generate output to stdout too.