IO Ninja - programmable terminal emulator / sniffer (part 2)

    io ninjaThis article is a continuation of the previous introductory article , which dealt with the motivation and history of the IO Ninja terminal / sniffer , and talked a bit about the built-in capabilities of our product. We continue the story of what is available “out of the box”, but with a more practical bias.

    IO Ninja was originally conceived as an all-in-one utility, and the package includes a large number of built-in plug-ins for working with various vehicles in different modes. However, instead of a dry listing of the list of plugins and their capabilities, I decided to demonstrate a small sample of the tasks from life that our company faced in practice, and which well-known terminals and monitors do worse than IO Ninja (and often do not do at all).

    TCP Forwarding to Serial


    tcp-to-serial link settingsUsers of Unix-like systems are well aware of the ability to redirect the output of one program to the input of another. Session Linking in IO Ninja provides similar functionality. The difference is that instead of a unidirectional data cascade, as in the case of Unix pipes, the connection of two sessions “shortens” the output of one to the input of the other and vice versa (in this case, all transmitted data is logged). This makes it possible to use IO Ninja as a universal intermediary for redirecting and / or listening.

    Suppose a device is connected to a computer through a serial interface (serial). Open IO Ninja and start the Serial session. We open and configure the serial port (perhaps, we send several test commands to the device in order to make sure that it is lively).

    Next, we start the TCP Listener session, select the interface and TCP port on which we will listen. We connect our two sessions Serial and TCP Listener through the settings dialog and - voila! Now you can connect to our serial device via TCP from any other computer!

    tcp-to-serial link

    Search for devices in the local segment using UDP broadcast


    A typical method for auto-detecting devices on a network is broadcasting UDP by sending an echo request and then collecting response packets - this, in particular, works with auto-detection for all embedded modules produced by our company. IO Ninja can be used as a broadcast UDP terminal for one-to-many communication.

    Open the UDP Socket, register 255.255.255.255 (or subnet-broadcast type 192.168.1.255 as the address), and send an echo request. As a result, we see a list of all devices in the local segment. Further, if necessary, we can continue to communicate with a specific device.

    device auto-discovery

    By the way, pay attention to the button with a compass. When working with UDP (and especially on the server side), it is often necessary to remember the address from which the packet came and answer exactly there - there is no connection! In principle, nothing prevents copying the address from the log and pasting it into the “Remote address” input field. But why do with your hands what can be put on the car? We press a compass, and we receive required automation - the UDP session will automatically reconfigure Remote address.

    Saving part of the input stream to a file


    Sometimes during debugging you need to save a piece of received data to a file. It can be, for example, a block that needs to be sent unchanged in this or some other session, maybe it is a file transmitted by a remote host, maybe something else.

    Standard terminals often stall on this rather simple task, and this is due to the following points:
    • Data can be binary and contain non-printable characters;
    • Data can be spread out between several packets;
    • As a rule, we need not the entire input stream, but a strictly defined block (which means that by simply redirecting the stream to a file, the problem is also not completely solved).

    IO Ninja compares favorably with the presence of a log in the form of a “hexadecimal sheet” with gluing of incoming packages - this allows us to accomplish exactly what we need.

    ssh log save as file

    Select the desired data block (looking, if necessary, at the status bar - the offset and length of the selected block are displayed there), save it to a file, and then use it. For example, we forward it to another session:

    midnight commander on tcp listener

    Reception of TCP connections using TCP Listener


    We saw above how TCP Listener can organize redirection so that you can connect to a serial device over TCP. However, the initial purpose of the TCP Listener plugin is not this, but rather as a server-side TCP terminal (in particular, for debugging the client side of a TCP connection).

    We create a new TCP Listener session, select the interface and port, and start our server. After receiving an incoming connection from the client with the terminal, you can work as usual.

    google chrome on tcp listener

    Note that the TCP Listener also has a choice: whether to accept new incoming connections if the connection is already available. This option can be extremely useful in situations where the client establishes many secondary connections to the same address (as, for example, many web browsers)

    Listening to TCP Connections Using TCP Proxy


    IO Ninja includes the Network Sniffer plugin, a PCap-based network sniffer for listening on network connections. However, in some cases it is much more convenient to use another built-in plugin, namely TCP Proxy.

    TCP Proxy is a combination of TCP Connection and TCP Listener, which allows you to organize an intermediary for TCP connections. The convenience of this approach lies in the fact that it immediately gives a clean log of data streams in real time (instead of a log in the form of packets from which data streams must be restored later). In addition, this model also works where listening with a sniffer can be difficult (with certain models of network switches, Wi-Fi cards, etc.)

    We create a TCP Proxy session, configure the server and client sides and run our proxy server. Any connection to this server will generate a secondary connection from the client side of our proxy, while all data received on the client side will be transferred to the server side and vice versa. In this sense, TCP Proxy resembles session binding, but is specially sharpened for TCP and therefore more convenient.

    ftp sniffing with tcp proxy

    Debugging Windows Named Pipes


    IO Ninja can be used as a tool for debugging a fairly common approach to IPC (Inter-Process Communication) in Windows - named pipes. In particular, some of our Windows drivers communicate with related services and applications.

    To emulate the server side of your application (the one where ConnectNamedPipe is called), run the Named Pipe Listener. This plugin allows you to accept incoming named pipe connections that will come from your client application / service.
    After establishing a connection, you can communicate with the client, analyzing the log of received requests and sending him response packets (created, for example, in the package builder).

    To emulate the client side (the one where CreateFile is called), the Generic File plugin is used.

    named pipe to tdevmon

    In addition to debugging named pipes (or FIFOs in * nix), this plugin can also be used to read and write non-standard device drivers.

    We briefly touch on the issue of listening named pipes. Suppose you have an application or driver that uses pipes for IPC. If you can somehow configure the named pipe address on the client side, then you can listen to pipe connections using an intermediary (similar to TCP Proxy).
    How exactly?
    Пусть отлаживаемая система устанавливает pipe соединение на \\.\pipe\debuggee_pipe_server. Выбираем какое-нибудь незанятое имя pipe, например, \\.\pipe\my_pipe_proxy. Настраиваем клиентскую сторону отлаживаемой системы на этот наш \\.\pipe\my_pipe_proxy. В IO Ninja открываем пару Pipe Listener и Generic File, связываем их. В Pipe Listener прописываем \\.\pipe\my_pipe_proxy, жмём Listen. В Generic File прописываем \\.\pipe\debuggee_pipe_server, жмём Open. Посредник готов.


    Over time, future versions of IO Ninja will also add full listening to named pipes without organizing man-in-the-middle (as a first approximation, most likely through the user-mode API hooking, and later through the file system filter).

    Sending beaten frames for testing


    The need to send “broken” or otherwise specially formed Ethernet frames is not so common and may seem more likely to be exotic. Nevertheless, this functionality is in demand in a number of quite real scenarios. For example, in our practice, this was necessary when debugging the implementation of the TCP / IP stack for the built-in modules produced by our company; another realistic application area may be the tasks facing network security experts, firewall developers, etc.

    Open the Network Sniffer session, select the interface and the capture filter, and start the capture. In the package builder, we prepare the necessary frame - for example, you can use the built-in library of TCP / IP packet templates, or simply copy some of the captured frames into a hex editor and correct the necessary fields.

    inject frame with network sniffer

    Click Send, and the frame we lovingly compiled sets off to complete a combat mission!

    Conclusion


    This list of scenarios for using IO Ninja is far from complete, but, in principle, sufficient to demonstrate the overall picture. In addition, he is absolutely honest - all the functions described above were born from the practical needs that arose during the development of our products.

    In the next part of the article, we will move on to the most interesting part - the programmability of IO Ninja and the new features that this opens up.

    Next part of the article


    Part 3: Writing an “answering machine” http://habrahabr.ru/company/tibbo/blog/256803/

    Also popular now: