Is it possible, or does anyone know the best way to capture MSN chats? I was thinking about attaching to the MSN process, and messing about searching for static addresses for conversations, to capture them.
(This is all on the windows platform using c++)
It would probably be easiest to sniff packets on the ports known to be used by MSN. That has the added benefit of working with clients other than the Microsoft one (such as Pidgin).
Assuming the protocol is unencrypted, it would probably be easier to attach to the process and intercept the network traffic than to search all of the application memory for chats. But that's no small task, either.
omg i just googled and discovered there's a whole cottage industry around doing this. pay $60+ to record MSN chat - are you kidding ? .. Please~ someone release an Open Source solution.
Related
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.
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.
For some time now I've been tossing around what I think is am awesome idea: I want to write essentially a C++ phone server to handle all of my incoming calls on a land-line. I'll have a white-list (yay never having to worry about telemarketers ever again!), a black-list, and will be able to access my phone using my gaming headset, allowing me to make/answer calls while I'm gaming or whatever. In the future I'd also like to hook it up to a gui and make it have pop-ups and other cool features.
The problem is, I have no idea where to start. I'm familiar enough with C++, but have no idea how to go about doing anything with a phone-line. I can plug a phone-line into my computer, but I have no idea how to get my program to be able to use that connection. There's WinSock2 for being able to use my ethernet connection, is there something similar I'd be able to use to use the phone line? As it's using the same ethernet jack, I wonder if it's even possible to use WinSock2 to use the phone-line?
I saw this post, which wasn't particularly helpful: stackoverflow link , which points out Dual-tone multi-frequency signaling. I stumbled across this site: link, but isn't really going to help me get started.
So I was wondering, is there some sort of library out there that would allow me to tap into a phone-line that's connected to my computer? Is there a standard somewhere out there concerning phone-lines and what the different combinations of tone's mean? Can anyone here help get me started? I realize it's somewhat of a big undertaking, so any push in the right direction would be greatly appreciated. Thanks.
[Update:]
I found this question, which is a step in the right direction, but I'm not sure yet if it helps me (I need to go to bed, and will take a look at it in the morning). I did see mention of a Microsoft Telephony API though, I'll try doing more research on that tomorrow.
If working with MS products is not an absolute necessity, you might also consider taking a shot at Asterisk. This is an open-source PBX (in software) that allows development on Linux, Windows (emulated) and Mac. At the company where I work, we use it for implementing small-scale exchanges, about a 100 lines or so. It also interfaces well with VoIP and allows a whole host of protocols. I have developed scripts and programs in C++ that work on voice packets in real-time, and so far, my experience has been good. As for your stated use-case of blocking telemarketers etc., this would be a very good fit. Check out further details here.
After doing more research, having one link lead to another link, and coming up with new search terms, I stumbled across this site that looks like it could kick me off using the Windows Telephony API in C++: link. This link includes open source c++ samples showing how to do the basics of what this question asks, I'll just have to test to see if they actually still work.
This is only the beginning of my research, so I'll keep you posted on any other findings. If anyone else is knowledgeable in this area, please still feel free to drop me information on what I want to accomplish.
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?
I am currently working on a C++/COM project using ArcEngine(From ESRI). Aside from the fact that there is little to no support in terms of documentation (SDK is there.) Anyways, i am wondering if anyone here has had any experience in making the initialization process of ArcEngine faster. Right now it takes 30-35 seconds just to initialize the engine. Now we are going to be running several of these applications. Does anyone have any experience, with this?
Its a very werid and odd task, but ESRI's developer forums are no help. and i couldnt find anything on google.
Any ideas?
It's been almost a decade since I last played with ESRI stuff, so I can't help you with anything specific to ArcEngine.
Maybe you can pool instances? In the best case scenario you would be able to reuse ArcEngine instances, and could return an instance back to pool after you're done with it.
If that's not possible, you could at least try to have a number of instances ready to roll, although whether that is possible and/or useful depends a lot on the specifics of your app.
Is it really COM? In that case, the ArcEngine will be exposing a set of COM interfaces. COM interfaces are not magic, and not uniquely bound to one program. In fact, COM has explicit support for proxying. This is e.g. used by DCOM; you get a local proxy for the remote server.
In this case, it should be possible to write a custom COM proxy that fakes the initialization stuff but forwards everything else. Towards your client, the proxies COM interface is identical except faster. Towards ArcEngine, your proxy can wait quite long between calls.
Something that I have found useful with getting ESRI products to start faster (not necessarily ArcEngine, but this probably applies) is to specify the port number (generally 27004) in the registry where the license server is defined.
HKEY_LOCAL_MACHINE\SOFTWARE\ESRI\License\LICENSE_SERVER
HKEY_LOCAL_MACHINE\SOFTWARE\ESRI\ArcInfo\Workstation\8.0\LICENSE_SERVER
When you set this in installation or through the desktop administrator, it is generally something like: #yourserver.name
Change this to 27004#yourserver.name
Again this may not solve your issue, but if you're not doing it, it's worth a try. I've found it to speed things up in our environment, both using a license manager on a network and with a hardware dongle on the local machine.
Well from my understanding ArcEngine initialization, initializes a special COM environment.
You don't ever get any sort of real handle over the initialized environment. Can you somehow store a COM Enviroment and pass it to other programs. My current idea is:
Windows Service Running in Background with initialized ArcEngine. Program somehow queries the service, the service returns the COM Enviroment. Is this even possible?
I had a lot of grief with ESRI forums providing very little help. It feels like Arc* developers are largely on their own.
Using ArcEngine + .Net the initialization time for an application has been trivial (maybe 1 second?) in our environment -- are you using a slow remote server or is this JUST the engine with no network or maps being loaded?
Whenever I've had to deal with large data sets, ESRI has a pig though.
Good to see some discussion on SO of ESRI products! Not a lot here yet...
Exactly what line is taking 45 seconds? If I had to do some psychic debugging, I would guess that you are running into a problem with your license server.
Check that first.