Hello, this is basically a more user friendly version of darkys previously released packet decoder in the form of a wireshark plugin.
If you don't know what this is for, this is not for you and you don't need to read on.
It was built and tested on Wireshark version 1.8.3 (32bit) and will propably only work for that version. Also, it might not work for versions of Arma2OA above or far below beta98836.
To install, simply put the arma.dll file into "C:\Program Files (x86)\Wireshark\plugins\1.8.3".
To use, start sniffing in wireshark and find the arma2oa udp packets (maybe by server ip, or by not doing much else than having arma on) in the list, select one and click "Follow UDP Stream" as can be seen in the screenshot, then "Decode As..." and select the ARMA from the list. Then you can see the decrypted data in its own tab.
This has no anti-detection. However, in theory, that is not needed as you can run this on a computer that is acting as a internet gateway for the computer that arma is running on, and you do not need to run it on the computer running arma itself.
This image has been resized. Click this bar to view the full image. The original image is sized 844x667.
wireshark complains about invalid plugin.
however, i don't realy need this. i was checking it out since i am stuck wirth darkys code. if someone is still around here, reading this and has a clue:
whats the problem with just telling the algorithm for decoding oO
its not a problem of the bytecode / arma version as long as we are in 1.62, right?
are only the packet bytes above offset 24 decoded? as from comparing wireshark captures and decodings by darkys tools i just see that not the entire data changes after decoding...
int DecodePacket(BYTE* packet, int size) { int Result = 0;
if (packet && size >= 24){ int unknownVal = 0; int i = 24; int unknown_field0 = *(DWORD *)(packet + 0x08);
unknownVal = sub_B713BD(unknown_field0);
do { *((BYTE *)packet + i) ^= byte_table[(i + unknownVal) & 0x7FF]; ++i; } while (i <= packet[0]); // according to other thread, this is supposed to be (i <= *(WORD *)packet)?
here different kinds of satellites depending upon the distance from the earth and others depending upon their orbits. Circular and elliptical orbital are two kinds of orbital satellites.
Also satellites are classified based on their height above Earth’s surface. The kinds of satellites are
Low-Earth orbits (LEO)— These satellites are in range of 180 kilometers to 2,000 kilometers above Earth. Most of these satellites are for military purposes and for collecting weather data.
Medium-Earth orbits (MEO)— These satellites are in range of 2,000 kilometers to 36,000 kilometers. Navigation satellites are of this kind.
Geosynchronous orbits (GEO)— GEO satellites, also known as geostationary satellites, are in range greater than 36,000 kilometers. Television and communication satellites are of this kind.
Satellites used for television or communication signals are generally in either elliptical orbit or geostationary orbit. Most of these satellites uses DVB standard for transmission.
The DVB Project is an Alliance of 200 worldwide companies. Digital video broadcasting is been used worldwide to deliver multimedia content and television. DVB standard has been adopted by all the countries and is the benchmark for digital television worldwide. The DVB-S, DVB-C system is used across the world. Around 1 Billion DVB receivers are used worldwide. DVB is not encrypted and is broadcast so anybody can receive the signal if you have the right tools and knowledge. Since 2002 lot of people have been using technique to download digital content from satellites for free. Below are the steps for intercepting satellite communications as per Mike Stevens, Professor of satellite ethical hacking training at International Institute of Cyber Security.
STEP 1( HARDWARE)
To sniff the Satellite broadcast you will need a Satellite dish with Low Noise Block down converter (LNB). The bigger the dish the better the range of signal it can pick. The cost of good satellite dish can vary from 50 USD to 300 USD.
Below you can see how easy is it to buy a satellite dish.
The size of the antenna depends upon the satellite you wish to sniff; you would like to just sniff one particular satellite then a small dish of 75cm will also do. This you can easily find out by searching over the Internet or you can visit the website of satellite company.
You can get details about the satellite you want to intercept from Internet; for example the below are details of some of the satellites in Latin America.
As per expert from International Institute of Cyber Security, Mike Stevens you can use website like below to find the Polarization Setting (LNB Skew), Elevation, Azimuth for your Antenna dish placement according to your satellite and location.
The next thing you need is a DVB Tuner card (DVB-S/S2 tuner card). A DVB tuner card is a kind of card that allows satellite signals to be received by a computer. Most DVB tuners also function as video and multimedia content capture cards, allowing them to record satellite content onto a hard disk. The cards come in PCI Express (PCIe), PCMCIA, ExpressCard, or USB devices standards. The tuner card is easily available in market and cost around 100 USD. Different brands of cards that work smoothly are DVBWorld, TBS/QBOX, Azureware, TechniSat, TechnoTrend, Genitech, and TeVii. As per ethical hacking experts most commonly used card is Technisat skystar 2.
DVB Tuner card
DVB Tuner card Satellites
You can install these cards as normal PCI cards or in USB form and their installation is very easy.
STEP 3 (FEED HUNTING)
Now you will need a Feed scanner software (Feed hunting) so that you can do automatic scanning and streamreader.dll , it’s basically the protocol driver that turns streams into readable data such as binary and ASCII files “Videos, documents, pages, torrents, iso files”. There are many free software available online. Some of the scanning softwares are CrazyScan, Easy Blind Scan. With this software you can do Blind Scan and Auto Scan.
STEP 4 (SATELLITE FISHING)
You will need sniffing software depending on what your end motive is. These softwares allow offline downloading of data, live streaming of Radio and video, satellite internet and intercepting signals. Some of these softwares are:
SkyGrabber
SkyGrabber is software that is used to tune a satellite dish for the best reception of satellite internet service or television programming. The software has the scanner mentioned in step 3 and gives the option to select a satellite from a dropdown list. Virtually all the world’s regional satellite networks appear in that list, arranged by longitude. If your satellite provider is not listed, you can manually add the provider through a New Provider dialog. As soon as you’ve chosen a satellite, it shows various signal quality configurations that, that you can use to point the satellite antenna en correct direction as covered in step 2. You can set file filters to download particular type of data.
You can even watch television programs through the card at the same time as using the software to download content.
This software is priced around 40 USD Euros and belongs to Russian company. However most people used cracked version of this software which is more easily available.
Skynet
Software similar to Skygrabber but in this we have to configure PID for specific transponders. This list is available in Internet.
Fishsat
This software is free but its mostly used in Middle East and it is for DSL frequencies for downloading DSL related data.
DVBDream
Streaming software for Windows.
PROG DVB
Streaming software, also available for Android.
ALTDVB
Streaming software.
TSReader
TSReader is a transport stream analyzer, decoder, recorder and stream manipulator for MPEG-2 systems.
DVBSNOOP
Dvbsnoop is a DVB / MPEG stream analyzer program, which enables you to watch (live) stream information in human readable form.
Its purpose is to debug, dump or view digital stream information (e.g. digital television broadcasts) sent via satellite, cable or terrestrial.
You can use DVBSnoop kind of software with wireshark for data analysis purposes. And can be used for advance hacking attacks.
In next article we will cover more about satellite encryption and hacking attacks involving satellites with the help of telecommunications ethical hacking expert, Dan Morris. This article is only for educational purposes.
Dynamic linker tricks: Using LD_PRELOAD to cheat, inject features and investigate programs
April 2, 2013 — Rafał Cieślak
This post assumes some basic C skills.
Linux puts you in full control. This is not always seen from everyone’s perspective, but a power user loves to be in control. I’m going to show you a basic trick that lets you heavily influence the behavior of most applications, which is not only fun, but also, at times, useful.
A motivational example
Let us begin with a simple example. Fun first, science later.
random_num.c:
1
2
3
4
5
6
7
8
9
10
#include
#include
#include
intmain(){
srand(time(NULL));
inti = 10;
while(i--) printf("%d\n",rand()%100);
return0;
}
Simple enough, I believe. I compiled it with no special flags, just
gcc random_num.c -o random_num
I hope the resulting output is obvious – ten randomly selected numbers 0-99, hopefully different each time you run this program.
Now let’s pretend we don’t really have the source of this executable. Either delete the source file, or move it somewhere – we won’t need it. We will significantly modify this programs behavior, yet without touching it’s source code nor recompiling it.
For this, lets create another simple C file:
unrandom.c:
1
2
3
intrand(){
return42; //the most random number in the universe
}
We’ll compile it into a shared library.
gcc -shared -fPIC unrandom.c -o unrandom.so
So what we have now is an application that outputs some random data, and a custom library, which implements the rand() function as a constant value of 42. Now… just run random_num this way, and watch the result:
LD_PRELOAD=$PWD/unrandom.so ./random_nums
If you are lazy and did not do it yourself (and somehow fail to guess what might have happened), I’ll let you know – the output consists of ten 42’s.
This may be even more impressive it you first:
export LD_PRELOAD=$PWD/unrandom.so
and then run the program normally. An unchanged app run in an apparently usual manner seems to be affected by what we did in our tiny library…
Wait, what? What did just happen?
Yup, you are right, our program failed to generate random numbers, because it did not use the “real” rand(), but the one we provided – which returns 42 every time.
But we *told* it to use the real one. We programmed it to use the real one. Besides, at the time we created that program, the fake rand() did not even exist!
This is not entirely true. We did not choose which rand() we want our program to use. We told it just to use rand().
When our program is started, certain libraries (that provide functionality needed by the program) are loaded. We can learn which are these using ldd:
What you see as the output is the list of libs that are needed by random_nums. This list is built into the executable, and is determined compile time. The exact output might slightly differ on your machine, but a libc.so must be there – this is the file which provides core C functionality. That includes the “real” rand().
We can have a peek at what functions does libc provide. I used the following to get a full list:
nm -D /lib/libc.so.6
The nm command lists symbols found in a binary file. The -D flag tells it to look for dynamic symbols, which makes sense, as libc.so.6 is a dynamic library. The output is very long, but it indeed lists rand() among many other standard functions.
Now what happens when we set up the environmental variable LD_PRELOAD? This variable forces some libraries to be loaded for a program. In our case, it loads unrandom.so for random_num, even though the program itself does not ask for it. The following command may be interesting:
Note that it lists our custom library. And indeed this is the reason why it’s code get’s executed: random_num calls rand(), but if unrandom.so is loaded it is our library that provides implementation for rand(). Neat, isn’t it?
Being transparent
This is not enough. I’d like to be able to inject some code into an application in a similar manner, but in such way that it will be able to function normally. It’s clear if we implemented open() with a simple “return 0;“, the application we would like to hack should malfunction. The point is to be transparent, and to actually call the original open:
inspect_open.c:
1
2
3
4
intopen(constchar*pathname, intflags){
/* Some evil injected code goes here. */
returnopen(pathname,flags); // Here we call the "real" open function, that is provided to us by libc.so
}
Hm. Not really. This won’t call the “original” open(…). Obviously, this is an endless recursive call.
How do we access the “real” open function? It is needed to use the programming interface to the dynamic linker. It’s simpler than it sounds. Have a look at this complete example, and then I’ll explain what happens there:
The dlfcn.h is needed for dlsym function we use later. That strange #define directive instructs the compiler to enable some non-standard stuff, we need it to enable RTLD_NEXT in dlfcn.h. That typedef is just creating an alias to a complicated pointer-to-function type, with arguments just as the original open – the alias name is orig_open_f_type, which we’ll use later.
The body of our custom open(…) consists of some custom code. The last part of it creates a new function pointer orig_open which will point to the original open(…) function. In order to get the address of that function, we ask dlsym to find for us the next “open” function on dynamic libraries stack. Finally, we call that function (passing the same arguments as were passed to our fake “open”), and return it’s return value as ours.
As the “evil injected code” I simply used:
inspect_open.c (fragment):
1
printf("The victim used open(...) to access '%s'!!!\n",pathname); //remember to include stdio.h!
To compile it, I needed to slightly adjust compiler flags:
I had to append -ldl, so that this shared library is linked to libdl, which provides the dlsym function. (Nah, I am not going to create a fake version of dlsym, though this might be fun.)
So what do I have in result? A shared library, which implements the open(…) function so that it behaves exactly as the real open(…)… except it has a side effect of printfing the file path :-)
If you are not convinced this is a powerful trick, it’s the time you tried the following:
LD_PRELOAD=$PWD/inspect_open.so gnome-calculator
I encourage you to see the result yourself, but basically it lists every file this application accesses. In real time.
I believe it’s not that hard to imagine why this might be useful for debugging or investigating unknown applications. Please note, however, that this particular trick is not quite complete, because open() is not the only function that opens files… For example, there is also open64() in the standard library, and for full investigation you would need to create a fake one too.
Possible uses
If you are still with me and enjoyed the above, let me suggest a bunch of ideas of what can be achieved using this trick. Keep in mind that you can do all the above without to source of the affected app!
Gain root privileges. Not really, don’t even bother, you won’t bypass any security this way. (A quick explanation for pros: no libraries will be preloaded this way if ruid != euid)
Cheat games: Unrandomize. This is what I did in the first example. For a fully working case you would need also to implement a custom random(), rand_r(), random_r(). Also some apps may be reading from /dev/urandom or so, you might redirect them to /dev/null by running the original open() with a modified file path. Furthermore, some apps may have their own random number generation algorithm, there is little you can do about that (unless: point 10 below). But this looks like an easy exercise for beginners.
Cheat games: Bullet time. Implement all standard time-related functions pretend the time flows two times slower. Or ten times slower. If you correctly calculate new values for time measurement, timed sleep functions, and others, the affected application will believe the time runs slower (or faster, if you wish), and you can experience awesome bullet-time action. Or go even one step further and let your shared library also be a DBus client, so that you can communicate with it real time. Bind some shortcuts to custom commands, and with some additional calculations in your fake timing functions you will be able to enable&disable the slow-mo or fast-forward anytime you wish.
Investigate apps: List accessed files. That’s what my second example does, but this could be also pushed further, by recording and monitoring all app’s file I/O.
Investigate apps: Monitor internet access. You might do this with Wireshark or similar software, but with this trick you could actually gain control of what an app sends over the web, and not just look, but also affect the exchanged data. Lots of possibilities here, from detecting spyware, to cheating in multiplayer games, or analyzing & reverse-engineering protocols of closed-source applications.
Investigate apps: Inspect GTK structures. Why just limit ourselves to standard library? Let’s inject code in all GTK calls, so that we can learn what widgets does an app use, and how are they structured. This might be then rendered either to an image or even to a gtkbuilder file! Super useful if you want to learn how does some app manage its interface!
Sandbox unsafe applications. If you don’t trust some app and are afraid that it may wish to rm -rf / or do some other unwanted file activities, you might potentially redirect all it’s file IO to e.g. /tmp by appropriately modifying the arguments it passes to all file-related functions (not just open, but also e.g. removing directories etc.). It’s more difficult trick that a chroot, but it gives you more control. It would be only as safe as complete your “wrapper” was, and unless you really know what you’re doing, don’t actually run any malicious software this way.
Implement features. zlibc is an actual library which is run this precise way; it uncompresses files on the go as they are accessed, so that any application can work on compressed data without even realizing it.
Fix bugs. Another real-life example: some time ago (I am not sure this is still the case) Skype – which is closed-source – had problems capturing video from some certain webcams. Because the source could not be modified as Skype is not free software, this was fixed by preloading a library that would correct these problems with video.
Manually access application’s own memory. Do note that you can access all app data this way. This may be not impressive if you are familiar with software like CheatEngine/scanmem/GameConqueror, but they all require root privileges to work. LD_PRELOAD does not. In fact, with a number of clever tricks your injected code might access all app memory, because, in fact, it gets executed by that application itself. You might modify everything this application can. You can probably imagine this allows a lot of low-level hacks… but I’ll post an article about it another time.
These are only the ideas I came up with. I bet you can find some too, if you do – share them by commenting!
