After the rust string overview of its internal substructures, let's see if c++ QString storage is more light, but first we'r going to take a look to the c++ standard string object:
At first sight we can see the allocation and deallocation created by the clang++ compiler, and the DAT_00400d34 is the string.
If we use same algorithm than the rust code but in c++:
We have a different decompilation layout. Note that the Ghidra scans very fast the c++ binaries, and with rust binaries gets crazy for a while. Locating main is also very simple in a c++ compiled binary, indeed is more low-level than rust.
The byte array is initialized with a simply move instruction: 00400c4b 48 b8 68 MOV RAX,0x6f77206f6c6c6568
And basic_string generates the string, in the case of rust this was carazy endless set of calls, detected by ghidra as a runtime, but nevertheless the basic_string is an external imported function not included on the binary.
The string is on the stack, and it's very curious to see what happens if there are two followed strings like these:
auto s = string(cstr);
string s2 = "test";
Clang puts toguether both stack strings: [ptr1][sz1][string1][null][string2][null][ptr2][sz2]
C++ QString datatype
Let's see the great and featured QString object defined on qstring.cpp and qstring.h
Some QString methods use the QCharRef class whose definition is below:
class Q_EXPORT QCharRef { friend class QString; QString& s; uint p;
Searching for the properties on the QString class I've realized that one improvement that rust and golang does is the separation from properties and methods, so in the large QString class the methods are hidden among the hundreds of methods, but basically the storage is a QStringData *;
After removing the methods of QStringData class definition we have this:
struct Q_EXPORT QStringData : public QShared { QChar *unicode; char *ascii; #ifdef Q_OS_MAC9 uint len; #else uint len : 30;
An Android remote administration tool (RAT) is a programmed tool that allows a remote device to control a smartphone as if they have physical access to that system. While screen sharing and remote administration have many legal uses, "RAT" software is usually associated with the unauthorized or malicious activity. I have streamlined here top android hacking tools of 2018.
TOP ANDROID HACKING TOOLS OF 2018
Here are the most advanced in functionality top android hacking tools of 2018.
1. DROIDJACK
DroidJack gives you the power to establish control over your beloveds' Android devices with an easy to use GUI and all the features you need to monitor them. It has many advanced features that you can perform over the remote smartphone. DroidJack is one of the top lists as it also has the functionality to read/write WhatsApp messages.
You can also follow a step by step tutorial on how to hack smartphone remotely using droidjack.
2. OMNIRAT
OmniRAT is the super powerful multi-OS remote administration tool that can a smartphone either using a smartphone or using a Windows or Mac PC. It has a huge list of features that make it very powerful. It can make calls through that smartphone remotely. It's completely fully undetectable.
3. ANDRORAT
AndroRat is a client/server application developed in Java Android for the client side and in Java/Swing for the Server. The name AndroRat is a mix of Android and RAT (Remote Access Tool). It was developed as a project by the university students, which works great for hacking into Android devices.
You can also follow a step by step tutorial on how to hacking a smartphone remotely using androrat.
4. SPYNOTE
SpyNote is a lightweight Android remote administration tool (RAT) to hack into a smartphone device remotely. It gives you the power to establish control over Android devices with an easy to use GUI and all the features you need to monitor them. Build a custom APK or bind the payload to an already existing APK such as a game or social media app.
You can also follow a step by step tutorial on how to hack any android phone remotely with spynote.
5. AHMYTH
AhMyth is a powerful android remote administrator tool that gives you the power to establish control over your beloveds' android devices with an easy to use GUI and all the features you need to monitor them.
These are all the top android hacking tools of 2018. There are also many other rats but these are the most advanced in tech and features. There may appear few more that can compete these and make a place to be in the top android list.
Bob was tasked to break into XYZcorporation, so he pulled up the facility on google maps to see what the layout was. He was looking for any possible entry paths into the company headquarters. Online maps showed that the whole facility was surrounded by a security access gate. Not much else could be determined remotely so bob decided to take a drive to the facility and get a closer look.
Bob parked down the street in view of the entry gate. Upon arrival he noted the gate was un-manned and cars were rolling up to the gate typing in an access code or simply driving up to the gate as it opening automatically.Interestingly there was some kind of wireless technology in use.
How do we go from watching a car go through a gate, to having a physical device that opens the gate?
We will take a look at reversing a signal from an actual gate to program a remote with the proper RF signal.Learning how to perform these steps manually to get a better understanding of how RF remotes work in conjunction with automating processes with RFCrack.
In the the previous blogs, we sniffed signals and replayed them to perform actions. In this blog we are going to take a look at a signal and reverse it to create a physical device that will act as a replacement for the original device. Depending on the scenario this may be a better approach if you plan to enter the facility off hours when there is no signal to capture or you don't want to look suspicious.
Recon:
Lets first use the scanning functionality in RFCrack to find known frequencies. Weneed to understand the frequencies that gates usually use. This way we can set our scanner to a limited number of frequencies to rotate through. The smaller rage of frequencies used will provide a better chance of capturing a signal when a car opens the target gate. This would be beneficial if the scanning device is left unattended within a dropbox created with something like a Kali on a Raspberry Pi. One could access it from a good distance away by setting up a wifi hotspot or cellular connection.
Based on research remotes tend to use 315Mhz, 390Mhz, 433Mhz and a few other frequencies. So in our case we will start up RFCrack on those likely used frequencies and just let it run. We can also look up the FCID of our clicker to see what Frequencies manufactures are using. Although not standardized, similar technologies tend to use similar configurations. Below is from the data sheet located at https://fccid.io/HBW7922/Test-Report/test-report-1755584 which indicates that if this gate is compatible with a universal remote it should be using the 300,310, 315, 372, 390 Frequencies. Most notably the 310, 315 and 390 as the others are only on a couple configurations.
RFCrack Scanning:
Since the most used ranges are 310, 315, 390 within our universal clicker, lets set RFCrack scanner to rotate through those and scan for signals.If a number of cars go through the gate and there are no captures we can adjust the scanner later over our wifi connection from a distance.
Currently Scanning: 433000000 To cancel hit enter and wait a few seconds
Example of logging output:
From the above output you will see that a frequency was found on 390. However, if you had left this running for a few hours you could easily see all of the output in the log file located in your RFCrack/scanning_logs directory.For example the following captures were found in the log file in an easily parseable format:
Analyzing the signal to determine toggle switches:
Ok sweet, now we have a valid signal which will open the gate. Of course we could just replay this and open the gate, but we are going to create a physical device we can pass along to whoever needs entry regardless if they understand RF. No need to fumble around with a computer and look suspicious.Also replaying a signal with RFCrack is just to easy, nothing new to learn taking the easy route.
The first thing we are going to do is graph the capture and take a look at the wave pattern it creates. This can give us a lot of clues that might prove beneficial in figuring out the toggle switch pattern found in remotes. There are a few ways we can do this. If you don't have a yardstick at home you can capture the initial signal with your cheap RTL-SDR dongle as we did in the first RF blog. We could then open it in audacity. This signal is shown below.
Let RFCrack Plot the Signal For you:
The other option is let RFCrack help you out by taking a signal from the log output above and let RFCrack plot it for you.This saves time and allows you to use only one piece of hardware for all of the work.This can easily be done with the following command:
From the graph output we see 2 distinct crest lengths and some junk at either end we can throw away. These 2 unique crests correspond to our toggle switch positions of up/down giving us the following 2 possible scenarios using a 9 toggle switch remote based on the 9 crests above:
Possible toggle switch scenarios:
down down up up up down down down down
up up down down down up up up up
Configuring a remote:
Proper toggle switch configuration allows us to program a universal remote that sends a signal to the gate. However even with the proper toggle switch configuration the remote has many different signals it sends based on the manufacturer or type of signal.In order to figure out which configuration the gate is using without physically watching the gate open, we will rely on local signal analysis/comparison.
Programming a remote is done by clicking the device with the proper toggle switch configuration until the gate opens and the correct manufacturer is configured. Since we don't have access to the gate after capturing the initial signal we will instead compare each signal from he remote to the original captured signal.
Comparing Signals:
This can be done a few ways, one way is to use an RTLSDR and capture all of the presses followed by visually comparing the output in audacity. Instead I prefer to use one tool and automate this process with RFCrack so that on each click of the device we can compare a signal with the original capture. Since there are multiple signals sent with each click it will analyze all of them and provide a percent likelihood of match of all the signals in that click followed by a comparing the highest % match graph for visual confirmation. If you are seeing a 80-90% match you should have the correct signal match.
Note:Not every click will show output as some clicks will be on different frequencies, these don't matter since our recon confirmed the gate is communicating on 390Mhz.
In order to analyze the signals in real time you will need to open up your clicker and set the proper toggle switch settings followed by setting up a sniffer and live analysis with RFCrack:
Open up 2 terminals and use the following commands:
#Setup a sniffer on 390mhz Setup sniffer:python RFCrack.py -k -c -f 390000000.
#Monitor the log file, and provide the gates original signal Setup Analysis: python RFCrack.py -c -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c -n.
Cmd switches used
-k = known frequency
-c = compare mode
-f = frequency
-n = no yardstick needed for analysis
Make sure your remote is configured for one of the possible toggle configurations determined above. In the below example I am using the first configuration, any extra toggles left in the down position: (down down up up up down down down down)
Analyze Your Clicks:
Now with the two terminals open and running click the reset switch to the bottom left and hold till it flashes. Then keep clicking the left button and viewing the output in the sniffing analysis terminal which will provide the comparisons as graphs are loaded to validate the output.If you click the device and no output is seen, all that means is that the device is communicating on a frequency which we are not listening on.We don't care about those signals since they don't pertain to our target.
At around the 11th click you will see high likelihood of a match and a graph which is near identical. A few click outputs are shown below with the graph from the last output with a 97% match.It will always graph the highest percentage within a click.Sometimes there will be blank graphs when the data is wacky and doesn't work so well. This is fine since we don't care about wacky data.
You will notice the previous clicks did not show even close to a match, so its pretty easy to determine which is the right manufacture and setup for your target gate. Now just click the right hand button on the remote and it should be configured with the gates setup even though you are in another location setting up for your test.
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.05
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.12
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.20
Percent Chance of Match for press is: 0.19
Percent Chance of Match for press is: 0.25
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.97
Percent Chance of Match for press is: 0.90
Percent Chance of Match for press is: 0.88
Percent Chance of Match for press is: 0.44
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
Graph Comparison Output for 97% Match:
Conclusion:
You have now walked through successfully reversing a toggle switch remote for a security gate. You took a raw signal and created a working device using only a Yardstick and RFCrack.This was just a quick tutorial on leveraging the skillsets you gained in previous blogs in order to learn how to analyzeRF signals within embedded devices. There are many scenarios these same techniques could assist in.We also covered a few new features in RF crack regarding logging, graphing and comparing signals.These are just a few of the features which have been added since the initial release. For more info and other features check the wiki.
I recently grabbed the latest version of the Ganglia web application to take a look to see if this issue has been fixed and I was pleasantly surprised... github is over here - https://github.com/ganglia/ganglia-web Looking at the code the following (abbreviated "graph.php") sequence can be found -
I can only guess that this previous snippet of code was meant to be used as some sort of API put in place for remote developers, unfortunately it is slightly broken. For some reason when this API was being developed part of its interface was wrapped in the following function -
According the the PHP documentation - Following characters are preceded by a backslash: #&;`|*?~<>^()[]{}$\, \x0A and \xFF. ' and " are escaped only if they are not paired. In Windows, all these characters plus % are replaced by a space instead.
This limitation of the API means we cannot simply pass in a function like eval, exec, system, or use backticks to create our Ganglia extension. Our only option is to use PHP functions that do not require "(" or ")" a quick look at the available options (http://www.php.net/manual/en/reserved.keywords.php) it looks like "include" would work nicely. An example API request that would help with administrative reporting follows: http://192.168.18.157/gang/graph.php?g=cpu_report,include+'/etc/passwd'
Very helpful, we can get a nice report with a list of current system users. Reporting like this is a nice feature but what we really would like to do is create a new extension that allows us to execute system commands on the Ganglia system. After a brief examination of the application it was found that we can leverage some other functionality of the application to finalize our Ganglia extension. The "events" page allows for a Ganglia user to configure events in the system, I am not exactly sure what type of events you would configure, but I hope that I am invited.
As you can see in the screen shot I have marked the "Event Summary" with "php here". When creating our API extension event we will fill in this event with the command we wish to run, see the following example request - http://192.168.18.157/gang/api/events.php?action=add&summary=<%3fphp+echo+`whoami`%3b+%3f>&start_time=07/01/2012%2000:00%20&end_time=07/02/2012%2000:00%20&host_regex=
This request will set up an "event" that will let everyone know who you are, that would be the friendly thing to do when attending an event. We can now go ahead and wire up our API call to attend our newly created event. Since we know that Ganglia keeps track of all planned events in the following location "/var/lib/ganglia/conf/events.json" lets go ahead and include this file in our API call - http://192.168.18.157/gang/graph.php?g=cpu_report,include+'/var/lib/ganglia/conf/events.json'
As you can see we have successfully made our API call and let everyone know at the "event" that our name is "www-data". From here I will leave the rest of the API development up to you. I hope this article will get you started on your Ganglia API development and you are able to implement whatever functionality your environment requires. Thanks for following along.
Update: This issue has been assigned CVE-2012-3448
