I'm writing a program in C++ that sniffs packets and compares them to a table by IP address. I would ike to know how to "Drop A Packet" if it does not meet the criteria that I setup. Everything is done, the sniffer, the criteria. I just need to know how to drop the packet...
Windows 7, Visual Studio 2010.
In general, packet sniffers don't modify the underlying stream, they just observe it.
It sound like what you really want is some sort of transparent proxy.
However, you should post some sample code or more details on what you are doing, since we have no idea how you actually implemented anything, and thus can't offer any suggestions.
Related
I am using gRPC for streaming telemetry data. Testing team wants to check if protobuf encoding is used by gRPC? Can anyone help me how I can verify that?
Is there a way to capture the send packets using Wireshark & verify if protobuf encoding is used?
Tried searching online but didn't get any useful results.
There are several possible ways to proceed.
Boring - Look At the Documentation
First is to consult the docs. A glance here is pretty good confirmation.
Though it's important to understand that there's several layers of the network stack here - gRPC uses Protobuf to encode application messages that are transferred across networks using http/2, which in turn may be configured to use TLS encryption, all of which ends up being sent over tcp sessions.
So, yes, gRPC does use Protobuf, but that's not the end of it (there's http/2 and possibly TLS too). The Testing Team may need to fully understand all of that.
Look At the Source Code
The source code all appears to be open source, one could double check that.
The More Interesting Way
Thirdly, and I recommend doing this regardless of whether or not the documentation was adequate to answer your question, the more fun way using Wireshark!
Wireshark can be easily extended. Basically, WireShark can unpick gRPC all the way to the proto messages themselves (unless you've turned on any of the security features in gRPC, in which case Wireshark will get stymied by not knowing the encryption keys). Wireshark can do this, because it looks like gRPC uses http/2, which is a defined protocol, but won't know how to decode the messages being transported using http/2.
What you can do is to use your .proto file to help generate a dissector plug-in for Wireshark, so that individual messages can be decoded within Wireshark. See here, and here
Okay, so that's a bit of work to implement, but it can be worthwhile, especially if "testing" is significant. What it means is that Wireshark, and a PCAP file in particular, can be an authoritive record of the telemetry stream that is independent of the software at either end of the telemetry link. Plus, it's a properly timestamped record, which might also be important.
You've also got a very powerful diagnostics tool for if anything is going wrong. E.g. if the telemetry data isn't looking right, where is the problem creeping in? Having a Wireshark plugin that can be used to examine the gPRC data all the way in to the message content is a useful tool.
The Wireshark PCAP file and dissection would also be a good way of seeing whatever else might be going on at the same time.
I've done this before, though I was using ASN.1 and created a system-specific ASN.1 dissector for Wireshark. Wireshark used in this way is very cool.
I did my best to search all topics regarding to SCADA and developing your own C++ desktop application to communicate with PLCs, but could not find any recent, or in my opinion, relevant topics that fit what I needed. If I missed them, a link to them would be very much appreciated. If I also happened to post this in the wrong section, or you can think of a better section for me to post this in, I will take it there.
With that said, I thank you in advance for taking the time to read my questions, and appreciate any input you have to offer.
A little bit about what I'm doing
I'm currently in school for electromechanical engineering, and for my final year project I am developing a desktop application in C++ to monitor PLCs we have located within one of our labs.
Within this lab, I have a pre-existing ethernet network connecting all PLCs to single point, which I am tying into with a PC, and will be doing all my work from there.
I will be developing the application in Qt for an easy way to design the GUI, and giving me access to the QNetworkInterface as well as QTcpSocket.
With that said, I wouldn't go as far as saying I'm an experienced programmer, but I have been fooling around with a few languages (i.e.: python, c++, c, php) for quite a few years, and am still learning, considering the learning NEVER stops.
My questions
Is there any reference material I can read, that you can suggest, on the subject to more easily understand what sort of process I need to go through to receive information (i.e.: individual I/Os, status bits, tags, logs, etc...) from the PLCs directly, and not through an OPC server?
If an OPC server is required, I've never dealt with OPC links other than using Rockwell Automations RSLinx to grab tags and display their values within excel (I had created a prototype using that exact method to start, but would like to move away from excel, and if possible, the OPC server (RSLinx) as well). What would you suggest to someone who knows nothing about the subject of OPC servers, or to my knowledge, OPC in general?
Have any of you previously written your own application to do something similar, if not of the same nature to what I'm trying to accomplish?
What advice or suggestions would you give for someone who is attempting this type of project?
PS: As a start for this project, I would initially just want to get the reading of the I/Os (tags or addresses) to view what their current values are (closed or open for inputs, energized or not for outputs). But eventually I would also like to be able to write values to tags on the PLCs I'm monitoring based on the values I've received from them.
PSS: I would like to note again, that I am still a student, and am still learning about this subject in it's entirety. I would just like to ask for your patience, as I may not grasp things completely the first time!
If I've missed any information you feel is pertinent to be able to provide an answer, please let me know! I will do my best to come up with said information in a timely manner!
Thank you!
EDIT #1: Added in another question, and altered my first question slightly
EDIT #2: Fixed up question 2
IMHO a SCADA program should have as a minimum requirement to be able to connect to an OPC server. OPC is used for most commercial PLCs.
Strictly speaking there is no need to have an OPC server/client approach but it gives you flexibility and gives you an abstraction model. If you want to directly connect to PLCs using a protocol then that is of course possible as well. You then need to know more details about the protocols and their various versions.
Yes I worked for a few years in a team that developed a commercial SCADA application.
It is very easy to get lost in details in such a project so try to keep things as simple as possible. By using OPC you will save time instead of fiddling directly with the protocols. You could add the ability to add custom-drivers for other protocols - depending on your timeframe. Try to model up your project before you start coding to a birdsview of the model and avoid getting lost in the details.
I would stay well away from looking to write your own code to connect directly
to an AB PLC - there are products out there that you can use in your application:
http://www.rtaautomation.com/software/ethernetip/client/tagc/ControlWin.html
http://www.automatedsolutions.com/products/dotnet/ascomm/
You would be better to use OPC - you can write you own OPC client if you want and follow examples you find here:
http://www.opcconnect.com/source.php#freesource
According to this http://www.control.com/thread/1026173407 you should be able to get source code of Kepwares OPC Quick Client.
It would probably be easier to just use a library as in this example (RSLogix,C#):
http://www.mesta-automation.com/opc-client-with-c-an-how-to-video/
You might find this of use:
http://www.rockwellautomation.co.kr/applications/gs/ap/GSKR.nsf/files/rslinxsdk_ma_eng.pdf/$file/rslinxsdk_ma_eng.pdf
Some resources:
http://www.opcconnect.com/ ,
http://www.mesta-automation.com/
Answer to question #4 - realize that your lab technically could contain ANY manufacturer's PLCs in the future. If you ever took a Data Communications class, you realize that for N different PLC types, you would have to write N different communication drivers for your PLC client.
This is where standards are helpful. Without the use of a standard protocol, scaling your lab could become more time consuming and less manageable. This is why communications standards exist.
HOWEVER, not all PLCs necessarily support the standard(s) you may decide upon.
The best choice is OPC/UA. Many PLCs have server drivers readily available. That means that your client just needs to understand 1 protocol (OPC/UA), and then it can "easily" be connected to any PLC that has a driver for that standard.
After that, there is OPC. After that, Modbus (TCP and RTU flavors), a relatively simple industry standard that is supported by most PLCs. EtherNet/IP is also a possible choice, although not all PLCs support it in a "server" role (many do support it as a client, but that is not what you need).
have a look at pycomm in github or pylogix at github which are Python written drivers to link to clx plc.
First of all, a big thank you to anyone willing to help!
You can skip the following wall of text if you want.
Background
I am trying to make a proxy program for my own minecraft server network. I wish to use multiple servers to allow people to play creative and survival on separate servers (to reduce serverload and increase my capacity). I am planning on using the transporter plugin for the server side of things, but I'd like to prevent having to install a clientpatch.
I discovered bungeecord, but it didn't do what I needed it to (namely, forge support for a modded server I plan on adding.) for mc 1.4.7 (which I need to use due to the server I plan on adding).
At the moment the system is running using a bungeecord proxy. However, md_5 told me that I'd need to write my own proxy (or mod his) to make it work the way I want. However, I really can't wrap my head around java (I just don't get it). So I decided to write my own.
The problem
After some research I discovered this to be doable. The hardest part would be to parse the packets. So I dug around for a library to do it for me. I came across libmcnet, which seemed to be what I wanted, but all the data it produced was garbled.
Looking over some packet dumps, and referencing it with wiki.vg, I discovered that libmcnet was giving me big-endian. However, my code and computers assume little-endian.
What I have done about it
After some thinking and looking over the code I thought it easier to write my own parser using some defines from libmcnet (namely include/mcnet/packets.h). So I copied the packets.h and read.h/read.c (both of which were heavily modified) and started recoding it. I did well enough, I think, as my system can successfully parse the server's 0xff (kick) packet during the server ping.
New problems
The next hurdle proved to be decrypting the client's data. It doesn't seem to use the same data standards as the server. For instance, the packet id the server transmits is 16 bit while the client's seems to be 8 bit.
So what I want to know:
Why does my code work fine on data from the server, but fail miserably when the client sends data? I'm pretty sure that libmcnet's code (on which I based it) is wrong as well.
Can anybody help me make this code work?
Code: http://pastebin.com/jg26yity (I figured this'd be cleaner)
Thank you all for your help!
*I'll add information if anybody requests more...
PS. First question asked here, so my post is a bit messy...
I figured it out, apparently I can't assume a library written to parse the minecraft protocol actually has proper code to read the protocol...
I was digging around and verifying what was read versus manually reading it... Appearantly a byte isn't a byte with minecraft and I thought the library had it covered.
I need to capture network traffic that is going in/out of a particular application. The main issue is that I would like to do this in a blocking fashion -- i.e. capture the traffic, perform some analysis and encryption/decryption on it and then forward it along its regular route. So, it must use some sort of a blocking mechanism.
Is there some code or a library that makes this easy to do on Windows (Server 2008 or Win7 will do)? Any C++ (or Python/Java) classes or libraries that already exist?
I intend for the solution to also execute on the same machine as the target app and have administrative privileges.
Any pointers to code samples would be greatly appreciated.
Thanks for your help.
p.s.: I have been looking at WinPcap but from my (limited) understanding, it can't filter/block based on specific applications. Is that right, or did I miss something? Any other solutions out there?
For this you should look at WinDivert. Unlike regular packet sniffers (like winpcap), WinDivert also has the ability to block/filter packets, so it might be what you are looking for. Disclosure: WinDivert is my own project.
I'm looking to write a small program which will intercept network packets (on the local machine) and modify them before they go out on the network. I need to be able to modify the headers as well, not just the data.
I've already looked through several possibilities but am unsure which one is best to pursue. There are open source packet filters out there, but filtering only seems to be able to either allow or reject packets, not much else.
The other solution would be to write an NDIS intermediate driver, but writing drivers is a beyond me. Even the simple pass-thru example in the WinDDK is thousands of lines. I'm also not looking forward to having to constantly reinstall a driver and reboot to test my code.
I'd ideally like the program to be self contained, and not rely on the installation of 3rd party drivers/software/whatever.
So if you people could point me in the right direction, throw some helpful links my way, whatever, I'd appreciate it.
Depends what kind of packets do you want to filter/modify.
If you're after application-level filtering, and want to get your hands on HTTP or similar packets, your best bet would probably be an LSP. Note however, following this path has certain disadvantages. First MS seems to be trying to get rid of this technology, and IIRC a part of Windows 7 logo requirements is "no LSP in your product", they seem to be promoting the Windows Filtering Platform. Second, you'd be very surprised with how much trouble you're getting into in terms of 3rd party LSP compatibility. Third, a very dummy LSP is still around 2 KLOC :)
If you're after an IP level packet filtering you'd need to go for a driver.
Windows Filtering Platform provides you with functionality needed in either case. However, it's only available on Windows Vista and later products, so no XP there. Another thing to take into consideration, WFP was only capable of allow/reject packets in user-land, and if you need to modify them, you'd need to go kernel-mode. (At least that what the situation was at the time it appeared, maybe they've improved something by now).
IMHO, If you want to modify packets you'll need something to talk to the hardware, a driver of some kind. If you do not want to use your own, you should get a 3rd party driver to inter-operate with.
For filtering there's libraries like: winpcap or libpcap.
Also have a look here: http://www.ntkernel.com/w&p.php?id=7
Another link: http://bittwist.sourceforge.net/
Hope this helps!
winpcap is only able to filter packets with precompiled conditions. What you need is to write LSP-level network driver. You won't need to reboot every time you reinstall it, but it can really modify packets before they go out to the network.
More info here: http://blogs.msdn.com/wndp/archive/2006/02/09/529031.aspx or here: http://www.microsoft.com/msj/0599/LayeredService/LayeredService.aspx
I'm no expert but I'm looking to do something similar on my LAN. I want to intercept packets form one single fixed IP and modify them before they go to my router then out onto the internet. I also want to capture and modify the returning packets prior to allowing them through to my host. The method I had envisaged was something like this...
ARP poison the host and router so my sniffing machine was having all packets passed through it.
Analyse the packets that I will want to modify in future and look for unique characteristics to those packets so I can catch just them.
Write a macro/script that looked for said characteristic in real-time and then modified it on the fly before sending it on its' way.
I know Cain&Abel for Windows is able (haha) to ARP poison but I'm not sure if it can provide raw dump of packet contents. Wireshark is able to dump all but not sure if it can ARP poison so as just to get what I'm after, if not then I can easily connect the host I want to intercept to my sniffer machine via ethernet and then share the internet via the sniffer so that all packets will go through the sniffer machine anyway.
So step 1 can be accomplished, I don't know if said programs have the ability to filter based on specifics yet but I'm guessing they do.
That's as far as I am with it. Hope this is of help to someone and maybe someone else can take this further?