I'm using an application (an instant messenger) which is not very popular. I'm trying to find the protocol that it uses. I know it's using TCP/IP but I want to find out all the commands that it is sending to the server and receiving from the server.
I tried a couple of sniffers, but they can not recognize this application by name and more over all I got was some unrelated hexadecimal codes.
Is there any idea how I can find the application's specifications?
(Please note: I googled it and found nothing and also there is no documentation by the author.)
There are generally two approaches to reverse engineering something like this:
You could try disassembling it with a tool like IDA PRO.
You could try sniffing its traffic with a tool like Wireshark
Either way, it's likely to be a LOT of work.
Wireshark will tell you the protocol. The fact that you cannot read the messages in clear text on the wire is a good thing, isn't it?
Related
Im using libpcap and want to be able to analyze packets but without wireshark at all. However, I want to use the wireshark dissectors. Has anybody done this and can give me an explanation for the needed steps?
First of all see this answer about the dangers of using epan and linking to libwireshark. You're basically alone trying to make it work, it is not meant to work that way and a new version may break your code. It is always suggested to write a dissector instead since that API is not going to change.
If that did not scare you please read forward.
I have not performed it but i'm more-or-less familiar with the wireshark code tree. I believe that what you're after is the #include <epan/packet.h>, #include <epan/frame_data.h> and #include <epan/tvbuff.h> (Testy Virtual Buffer), these header files are distributed together with wireshark since are needed to write plugin dissectors.
Since one protocol often contains another protocol as the payload wireshark's way to deal with is the tvbuff_t. One dissector returns a tvbuff_t which can then be used by another dissector. You need to perform the entire decoding of the packet, (for example, starting from Ethernet) since wireshark is not there to do it for you.
The code in the epan directory is documented in the doc directory, notably the section 1.7 of doc/README.dissectors (Calling Other Dissectors) has information on how to use tvbuff_t and find_dissector().
It is a very hacky way of doing things, therefore i'll warn again: if you can get away with writing a dissector and use it within wireshark, do it.
I found the following Project on Github:
https://github.com/gnychis/android-wmon
One has to do some modifications in order to get it work, but much much easier than starting from the beginning.
I need to implement a software module that is able to retrieve the topology of an autonomous system.
Looking at the various protocol that are implemented in Cisco routers i concluded that the only two alternatives to obtain topology are smnp and ospf.
The first one is a workaround and i don't want to use it, this leads to ospf.
I haven't found library in c, java and python that are usable; this one ( http://www.ospf.org/ )is probably the most complete but comes without documentation and i don't have enough time to analyze all the code.
So i found quagga that can implement a software ospf router; seems the perfect alternative since it can work with both real network and simulated network in gns3.
But it's possible to obtain the ospf routing table from quagga since everything is from command line?
This are my conclusions and doubts if someone can suggest something better or help me with the next step it would be appreciated since i'm stuck at the moment.
Use quagga's ospfclient feature. There is already an example provided in the ospfclient directory (see ospfclient.c) which will show you how to retrieve the LSA database from a quagga/ospfd instance. For this solution to work you need to attach a PC to one of your OSPF backbone routers and configure quagga/ospfd on it to successfully learn the routes then you start your ospfclient to retrieve any information you need.
I have been trying to understand the concept of 'hooking' APIs and am currently facing a problem. I hope that experts here can clear it:
By going through a header file I noticed that the LoadLibrary function is actually mapped to one of the following two: LoadLibraryW or LoadLibraryA based on the flag used during compilation (UNICODE or ASCII, respectively). Now, if I have explicitly hooked the API 'LoadLibraryA' then will my hooked function get the control if it is compiled using the UNICODE flag?
It would be great if someone could explain or point me to a link that explains in detail how hooking works in such cases? How do compilation flags, character sets, locale, internationalization, impact hooking of APIs like LoadLibrary or CreateFile?
I'm currently in South Korea (Originally from UK) and for some reason some of my application is not working and I have a demo tomorrow. I presume the above mentioned doubt is the reason for the problem I'm facing.
I think that you need to read carefully this bible of api hooking Hooking in theory which explains everything about hooking like different approaches of hooking, lot of diagrams.... and also this one example. My suggestion is to use LoadLibraryW because it is superset of Acsii.
Bye
I am trying to build a very simple driver. Its sole purpose will be to register "PsSetCreateProcessNotifyRoutine" and on callbacks recieved from kernel, notify my Win32 application about which proccesses are started and stoped.
I only know how to build such a simple driver with "DriverEntry" and "DriverUnload" and compile it with DDK. But I don't know how to actually implement communication. I know it can be done with IOCTL. But beyond that I am in the dark. I cannot find simple example of how to do that in Delphi. I only know it can be done.
So what I am looking for is some simple and understandable tutorial on how to do it or event better an example delphi program with acompaniying driver code. Maybe there are even other ways of communication.
Any help would be appriciated.
Doesn't matter if in Delphi or not. You have to use the function DeviceIoControl. Read the article in MSDN about it.
In short, you'll have to choose some IOCTL codes from the available set. Then you call DeviceIoControl with one of these codes and pass some data, and in driver you handle that request and return something else.
You can also handle standard IOCTLS, such as the ones generated by calling ReadFile or WriteFile in user-mode.
Don't look for a "tutorial how to do that in Delphi", just look for any tutorial. They're all the same, no matter the language, it's pure Win32/Native api stuff. Here's one for example, just googled it out.
Is it possible to get location data out of Google Gears, Google Gelocation API or any other web location API (such as Fire Eagle) in such a format that it appears to other software as a GPS device?
It occured to me reading these answers to my question regarding WiFi location finding, on Super User, that if I could emulate a GPS unit, many of these web services could act as a 'poor-mans' GPS to otherwise less useful software that requires it.
Is GPSD an option?
Preferably OSX & Python, but I would be interested in any implementation.
There is a very similar thread on a Python mailinglist that mentions Windows virtual COM ports and discusses Unix's pseudo-tty capabilities. If the app(s) you want to use let you type in a specific tty device file, this may be the easiest route. (Short of asking the authors to provide a plugin API for what you're trying to do, or buying yourself a $20 bluetooth GPS mouse.)
Are you using OS X?
There is a project macosxvirtualserialport on Google code that provides a graphical wrapper around some of the features of a utility called socat. I'd recommend taking a look at socat if you see potential in the pseudo-tty route. I believe you could use socat to link a pipe from a Python program to a pseudo-tty.
Most native Mac apps will be querying IOServiceMatching for a device with kIOSerialBSDRS232Type, and I doubt that a pseudo-tty will show up as an IOKit service.
In this case, unless you can find a project that has already implemented such a thing, you will need to implement a driver as described in this How to create virtual COM port thread. If you're going to the trouble of create a device driver, you would want to base it on IOKit because of that likely IOServiceMatching query. You can find the Apple16X50Serial project mentioned in that post at the top of Apple's open source code list (go to the main page and pick an older OS release if you want to target something pre-10.6).
If your app is most useful with realtime data (e.g. the RouteBuddy app mentioned in the Python mailinglist thread can log current positions) then you will want to fetch updates from your web sources (hopefully they support long-polling) and convert them to basic NMEA RMC sentences. You do not want to do this from inside your driver code. Instead, divide your work up into kernel-land and user-land pieces that can communicate, and put as little of the code as possible into the kernel part.
If you want to let apps both read and write to these web services, your best bet would probably be to simulate a Garmin device. Garmin has more-or-less documented their protocol in the IntfSpec.pdf file included with their Device Interface SDK. Again, you'd want to split as much as you could into user-space code.
I was unable to find a project or utility that implements the kernel side of an IOKit-based virtual serial interface, but I'd be surprised if there wasn't one hiding somewhere out there. Unfortunately, most of the answers I found to that question were like this, with the developer being told to get busy writing a kext.
I'm not exactly sure how to accomplish what you're asking, but I may be able to lend some insight as to how you might begin to get it done. So here goes:
A GPS device shows up to most systems as nothing more than a serial device -- a.k.a. a COM port if you're dealing with Windows, /dev/ttySx if you're in *nix. By definition, a serial port's specific duty is to stream data across a bus, one block at a time. So, it would then follow logically that if you want to emulate the presence of a GPS device, you should gather the data you're consuming and put it into a stream that somehow acts like an active serial port.
There are, however, some complications you might want to consider:
Most GPS devices don't just send out location data; there's also information on satellite locations, fix quality, bearing, and so on. Then again, nobody's made any rules saying you have to make all that data available. There's probably more to this, but I'll admit that I need to do more research in this area myself.
I'm not sure how fast you can receive data when dealing with Google Latitude, etc., but any delays in receiving would definitely result in visible pauses in your "serial port"'s data stream. Again, this may not be as big a complication as it seems, because GPS devices are known to "burst" data across the bus anyway, but I'd definitely keep an eye on that. You want to make sure there's always a surplus of data coming across, not a shortage.
Along the way you'll also have to transform the coordinates you receive into valid GPS sentences, as well. You can find specifications for those, but I would definitely make friends with the NMEA standard -- even though it is a flawed standard, it's the one everyone seems to agree on anyway.
Hope this helped you, at least a little bit. Are there anymore details specific to your problem that you think could be useful in answering this question?
Take a look to Franson GPS Gate which allows you to connect to Google Earth among other things (like simulating GPS and so on). Is windows only though but I think you could get some useful ideas from it.
I haven't looked into it very much, but have you considered using Skyhook's SDK? It might provide you with some of what you are looking for. It's available for every major desktop and mobile OS.