Wednesday, September 25, 2013

Drive-by Wi-Fi Attacks Against Android + The Beginning of Defense

Drive-by command execution in short just posted information about a significant vulnerability in Android applications using common ad networks.  To summarize,

The Android WebView API implements a miniature browser inside an app - not only does it render HTML, it can execute javascript.

In an attempt to make it simpler for developers to include rich web environments which can interact with the standard Android UI of the application, the WebView can provide a Javascript Bridge, which allows Java methods to be executed by Javascript calls.

Unfortunately, the bridge code can allow for execution of arbitrary code through the use of reflection, Java's implementation of introspection.  Introspection / reflection allows running code to examine itself, and dynamically call methods by signatures based on method name, argument types, and so on.

There's plenty of interesting function calls to run, but the one leveraged by MWR Labs is to get the runtime environment of the webview, and then find the exec() function.  Runtime.exec() in Java is basically what you'd expect - the equivalent of exec() or popen() in libc.

In other words, anyone able to hijack the traffic between your phone and the ad network can execute system commands at the privilege level of the vulnerable application.


Any entity able to intercept traffic from the Android device should be able to trigger exploitation against any vulnerable applications.

Let's leave aside cell data - yes, a state actor could almost definitely interfere with traffic at this level, as could a spoofed GSM tower running something like OpenBTS, but neither is likely to be the prime vector.  Instead, let's look at Wi-Fi, my favorite frenemy technology.

Partly as a function of the user interface, and partly due to being consumer technology, phones aren't generally all that good at giving the user intelligent choices when it comes to Wi-Fi.  You get a list of networks you've seen before and connected to, and you get an icon saying you're associated to Wi-Fi (or that you're not).  

Additionally, there isn't a whole lot in the UI for configuring WPA-EAP networks securely.  Until recently there was very very little support for this, and it's still under development.  By happily accepting a default situation where the device doesn't validate server certificates, PEAP support is nearly worthless.

So what's the wireless attack surface?

1.  Any previously configured open network.  This includes 'linksys' and 'attwifi' for those keeping score at home.
2.  Any WPA-EAP network without proper certificate backing

The second is certainly juicy, but lets assume any device we're looking at is going to send out a bunch of probes for open networks it's talked to in the past.  This lets us do:

1.  Simple evil twin attack; clone the SSID of the access point and control outbound traffic
2.  Karma; grab any network the device is looking for and spoof it.  The Wi-Fi Pineapple is a great tool for this.
3.  Wait for them to join any open access point and hijack them via TCP session hijacking.  MSF-Airpwn is my (somewhat obvious) favorite here.

Juicy, juicy mobility

Mobile devices (not just Android) are especially vulnerable to Wi-Fi hijacking attacks because they will promiscuously roam to anything that looks like an access point they know, even when the user isn't paying attention.

On Android, official apps like Google Maps and Google Now even suggest you always leave Wi-Fi enabled, so that Wi-Fi based positioning will work more accurately.  This means the device is constantly looking to join networks, and constantly at risk for random hijackers.

The one glimmer here is that most ad-driven applications are required to only show ads when the user is actually looking - they probably won't be loading new ads constantly while the screen is off, though who knows for sure.  Unfortunately this won't prevent users who have their devices on - doing whatever users do, connecting to random Wi-Fi networks.


As mentioned by the MWR Labs guys, this lets an attacker run anything they want at the privilege level of the application which was hijacked.  Since it's using a WebView natively hosted in the app, it has network access permissions as a start.  Most Android devices are not configured to block read-only access to the external storage (either a SD card or flash partition on the internal storage) where bulk app data, photos, downloads, etc are stored, so it would be fairly simple to scrape all of that.

Depending on the other permissions the app has, it may be possible to place phone calls or send text messages, being either an annoyance or a significant revenue source.

Installing applications typically requires user interaction, so while it's possible to download entirely new APKs, it would require the user have out-of-market installs enabled, and to click accept.

Depending on the device settings there's a chance it could be possible to install new APKs via the android debug bridge locally - this opens up a whole new set of problems, if the user has ADB enabled and the application is able to install via local ADB privilege escalation would be simple.  Combined with the Android Master Key vulnerability, a full take-over of the system could be possible, but I haven't investigated leveraging ADB locally.

The gold crown of course goes to simply rooting the device - Android has had a history of local vulnerabilities which can gain root, and while newer releases have significantly improved device security, not all devices are running newer releases.  Vendors keep putting in fantastic backdoors all on their own - shell execution combines wonderfully with CVE 2013-447, which allows any user to execute commands as root on older Motorola devices such as the Defy.

The beginning of defense (or pushing my own product)

There aren't a lot of solutions which don't require modifying the phone; either with a custom ROM or by gaining root.

I'm personally terrified of running anything from the marketplace (or anywhere else) that requires root on Android.  The controls are just too coarse:  Once you allow an application to run as root, you lose all control of the entire system.  It becomes impossible to determine if something has installed backdoors, altered the system, etc.

If you DO have root, you can implement traditional firewalls (Android can run iptables), and you can even implement per-application firewalls (since every app on Android runs as its own user you can filter by uid).  You can also block the common ad network servers with a /etc/hosts file.

You can also reduce the attack window by controlling when Wi-Fi is enabled.  This can be done manually, of course, but I think there's a smarter way.

Smarter Wi-Fi Manager is a tool I've been working on to handle Wi-Fi settings intelligently.  This report has given me a reason to push an initial release out to the world before the entire set of features I'm aiming for are done, but it's already an effective tool.

Smarter Wi-Fi Manager

SWM attempts to manage your Wi-Fi state while requiring as little direct care and feeding as possible.  It leans the cell towers near where you use Wi-Fi automatically, then disables Wi-Fi when you are no longer connected.  When you return to a learned location, it will automatically re-enable Wi-Fi for you.

To train a new location, just turn on Wi-Fi manually and connect to a network.  The learning system will take over from there, and the next time you come back to the area, it will re-enable Wi-Fi automatically.

Specific SSIDs can be excluded from training - attwifi, linksys, timewarner, and so on, networks which appear all over and which you only want to connect to manually.

Wi-Fi can also be disabled when specific Bluetooth devices are connected - for instance, automatically turn off Wi-Fi when connected to a car stereo, or to a Bluetooth headset or pedometer or some other device which indicates you're somewhere other than home.

Hopefully future features will include geofencing for more precise location control, time-range based control of Wi-Fi and Bluetooth (turn off between 9 and 5 for example), and control of the preferred network list so that the device attempts to connect to the proper network.

SWM is also a bit of an experiment in funding open source development - while the Google marketplace version is a for-pay app, it is fully open source, which is available from the SWM page as a Git repository.  It was built using Android Studio, the all-in-one Google tool.  There is no difference between the released versions and the version found in Git.

You can find more about SWM on the Kismet page:

And on the Google Play market link:

And remember to read the full MWR Labs report at:

Smarter Wi-Fi Manager for Android

[ Update - A more in-depth description of the problem & the tool in this post ]

I've been working on this for a while, but the recently announced vulnerabilities in android ad networks which allow for shell command execution via hijacked traffic pushed me to release a working version before getting all the features I wanted done:

Intelligently manage your wireless on android - SWM automatically learns where you use Wi-Fi, and will turn it on when you're in one of those locations and automatically turn it off when you're not.  You can also control Wi-Fi by Bluetooth association - automatically turn off Wi-Fi when you're connected to your car stereo, for example.

This is a bit of an experiment in funding open source - the app is paid in the marketplace, but also open source.  If you can't, or don't wish to, buy it from the market place, you can compile it from source using Android Studio.

Thursday, September 12, 2013

A guest post from Renderman

This decision is of a court that does not seem to understand the technology nor that trying to make new technologies fit in the definitions of old tech is not going to fit. Under this judgement, the entire 802.11 specification is technically in violation. With Google and their famous motto of 'Don't Be Evil', every judge looking to make a name is hoping to be the one to make them 'be evil'

An interesting part of this case was that results of the Canadian privacy commissioners report on the issue: which, in short comes down to; "Delete the data, setup controls and processes to prevent it happening again, don't do it again". A fairly levelheaded and sane approach.

We are in an era where technology is rapidly evolving, and the generation gap between the creators and the legislators is larger than ever. Often the courts are dealing with things they have no understanding of and that no apt analogy exists (or, even worse, they use a bad analogy, as in this case).

I wonder if the judge or his family use Wi-Fi at home and realize they are breaking the same judgement?

You can see more from Renderman at @ihackedwhat on Twitter, and at

Wi-Fi isn't radio!?

So, this happened.  #$&^@#.

The 9th Circuit Court of Appeals has ruled that Google can be prosecuted for the capturing of wireless data by Street view cars.  (Disclaimer: Reports indicate that this software was Kismet; having never been a Google employee I have no position on that; it's open source software, I expect it to show up all over the place).

There are some very odd aspects to the ruling - the full text of which can be found here:

The most controversial aspect of the ruling is the declaration that Wi-Fi isn't radio.

Data Transmitted over a Wi-Fi Network Is Not a “Radio Communication” under the Wiretap Act.

From a technical standpoint this is obviously, blatantly, wrong - of course Wi-Fi is radio.  From a legal standpoint, this appears to be drawn from previous interpretations by Congress and exact terminology:

Congress does not use “radio” or “radio communication” to reference all of the myriad forms of communication that use the radio spectrum. Rather, it uses “radio” to refer to traditional radio technologies, and then separately describes other modes of communication that are not ordinarily thought of as radio, but that nevertheless use the radio spectrum.

One of the cited examples is the specification of "radio" as a separate concept from "television" or "communications".  So how did they decide this?  It's tied to the phrase "common meaning", in other words, the non-technical belief that "radio" is for AM and FM audio, and not a whole lot else.  Specifically, the ruling references previous statements, in utterly unrelated cases:

"..Not surprisingly, Congress has not typically assumed that the term “radio” encompasses the term “television.” See, e.g., 18 U.S.C. § 1343 (imposing liability for “[f]raud by wire, radio, or television”) (emphasis added); 18 U.S.C. § 2101 (imposing liability for inciting a riot by means of “mail, telegraph, radio, or television”) (emphasis added); 7 U.S.C. § 2156 (defining an “instrumentality of interstate commerce” as “any written, wire, radio, television or other form of communication);

Which leads to the surprisingly clear statement:

2. A “radio communication” is a predominantly auditory broadcast, which excludes payload data transmitted over Wi-Fi networks


The payload data transmitted over unencrypted Wi-Fi networks that was captured by Google included emails, usernames, passwords, images, and documents that cannot be classified as predominantly auditory. They therefore fall outside of the definition of a “radio communication” as the phrase is used in 18 U.S.C. § 2510(16).

So under this ruling, Wi-Fi isn't broadcast - but what about when it is?  For example, literally, broadcast packets, which are transmitted indiscriminately and define the actual presence of the network?

Technical impacts - This is bad.  Absurdly bad.

It all depends how this ruling is interpreted and enforced.  For law enforcement agencies, there are two types of snooping on data. [* more info here]

  1. Pen/Tap registers and Tap and Trace.  On phone lines, these are essentially the metadata of the call - when a call takes place, the source and destination, duration of the call, etc.  For email, this type of trace can capture header data, sender and recipient emails, and subject lines, but not the content of emails.  These are simpler to get.
  2. Traditional wiretaps, which can contain the content of messages, full packet logs, the content of emails, etc.  These are harder to get and require (in theory) more oversight.
This gets extremely sticky because the statutes interpret a wiretap as anything which receives the information - for a packet-based capture system, this means the copy stored in RAM in the system buffers prior to filtering.  Even if you filter the based on headers and discard the data, it counts as a wiretap.

A researcher, pen-tester, or someone running a WIDS system, or anyone running an access point in Linux (which uses a monitor-mode interface), is going to be capturing all packets on the channel.  Despite the ruling explicitly stating:

But “radio hobbyists” do not mistakenly use packet sniffers to intercept payload data transmitted on Wi-Fi networks. Lending “radio communication” a broad definition that encompasses data transmitted on Wi-Fi networks would obliterate Congress’s compromise and create absurd applications of the exemption for intercepting unencrypted radio communications.

Under the actual limitations of wiretap law, this is exactly what happens under every WIDS system - even if the packets which are not part of the target network, or even if the data packets, are immediately discarded (such as Kismet running under "don't be evil" mode, with "hidedata=true" set in the config), a copy is still made and kept in RAM as part of the kernel packet buffers or in the Kismet (or whatever) buffers.

This seems to be a fundamental failure to understand the nature of shared media:  If you're transmitting on a channel, ALL users of that channel will see your transmissions.  They might ignore them, but they're going to see them.  That's how it works.

By not taking any precaution to encrypt data, a user on an unencrypted network is voluntarily transmitting their traffic for anyone to monitor.

Is this a particularly desirable situation for a user to be in?  No - but the last time I checked, being foolish wasn't against the law.  People do things all the time that aren't particularly safe, secure, or smart.

Critically, the ruling seems to think it's difficult to monitor Wi-Fi:

First, Wi-Fi transmissions are not “readily” available because they are geographically limited and fail to travel far beyond the walls of the home or office where the access point
is located.
Second, the payload data transmitted over unencrypted Wi-Fi networks is only “accessible” with some difficulty. Unlike traditional radio broadcasts, a Wi-Fi access point cannot associate or communicate with a wireless device until it has been authenticated.

Considering the vast majority of Wi-Fi reaches far beyond the property lines of the owners - which causes problems in urban settings, and which many users deliberately attempt by boosting the power or adding after-market antennas, I'm not too confident about that assertion.  Plus, Google only monitored from the street - that means the networks were broadcasting beyond private property into public space.  Seems like that's a pretty clear-cut broadcast.

The second assertion is a major misunderstanding of how Wi-Fi, and Wi-Fi monitoring, operates.  Unencrypted networks are received by everyone in range of them, they're just deliberately discarded if they're not originating from a network a client is connected to.  Broadcast management packets are specifically designed to be received by every device in the area, as are the traffic flow control packets.  Wi-Fi has been specifically designed to co-exist with additional Wi-Fi networks in the same space because it's impossible to not receive packets from other networks!

While Google did take deliberate action to record all the packets seen, it's definitely not difficult to receive them in the first place.  Just because a user may choose to not be aware of how things work under the cover doesn't mean it's not trivial.

But what about the FCC?

What indeed!  The FCC - the regulatory body concerned with radio communications.  Like Wi-Fi.  Which uses radio - already examined this case and declared that Google was not infringing:

In it the FCC specifically addresses the fact that Wi-Fi networks have broadcast transmissions to all receivers, and that Wi-Fi networks can have extended coverage reaching into public areas.

Additionally, Wi-Fi networks fall under Part 15 of the FCC rules.  The extremely exciting (by which I mean not exciting at all) rules, by which all devices in the frequency ranges used by Wi-Fi must abide by, can be found here:

The two relevant aspects of the document that I could find is the statement that cordless phones operating under Part 15 must contain a sticker explicitly notifying the user that privacy is not guaranteed when using the device, and the following admonition about monitoring:

Except for the operations of law enforcement officers conducted under lawful authority, no person shall use, either directly or indirectly, a device operated pursuant to the provisions of this part for the purpose of overhearing or recording the private conversations.

What constitutes a "private conversation"?  Surely using encryption should fit that - it demonstrates an explicit desire to obfuscate.  Conversely, shouting into the street would not constitute a private conversation.  Person-to-person email might be assumed to be a private conversation - except the US government has already made it clear that it doesn't consider any email on a remote server to be protected by any expectation of privacy.

So it's all the users fault, right?

I wouldn't be comfortable saying it's all the users fault they're engaged in insecure behavior - while huge inroads have been made into educating users about Wi-Fi security (and in the past decade I've seen adoption of some form of encryption jump from around 10% of networks to around 70%), responsibility also lies on the manufacturers to ship more devices with secure default settings.  This is slowly becoming more common, but needs to continue this trend.

What happens now

Taken at it's most literal, this ruling effectively makes standard modes of Wi-Fi operation illegal:  By failing to recognize the broadcast nature of Wi-Fi control packets, it makes it impossible for normal CSMA/CA collision avoidance (detecting flow control packets from any network overlapping the current channel), or even building lists of networks in the area (receiving and processing all packets until a beacon is seen).

This will also impact all WIDS systems - which by design capture all the packets in the channel and look for unauthorized networks, while ignoring or discarding packets from other networks - after capturing them and discarding them.

Would they prosecute basic operational methods?  Probably not.  Could they?  Probably yes.  Would it be tacked on as another 100 charges to inflate public outrage, force a plea bargain, or push for excessive sentencing?  I'd certainly expect so.

Security through Legislation

What's worse than security through obscurity: I won't tell you how it works so of course you could never figure it out?  Security through legislation:  It's secure because I say you can't look at it.

Security by Legislation has been applied to several wireless communications standards already - analog cell phones and digital pagers offer no security and no protection, but are considered "secure" because it's illegal to look at them being insecure.  This sort of "protection" provides two things:  A club to beat offenders with, should they ever be caught, and a limit on the above-board products which might otherwise violate ("see all pages in your neighborhood!").  What it does not prevent is any behavior by individuals already inclined to break the law, nor does it offer any incentive for manufacturers to develop more secure devices.  Pager networks are still heavily used today.  By hospitals, EMS, fire departments, alarm networks, and traditional alert systems like email forwarders for company network monitoring.  They're still unencrypted, and they still offer no protection against message spoofing.

By contrast, Wi-Fi is barely over a decade old (in any modern implementation with widespread adoption).  In that timeframe, extensive work has been done by security researchers, many many tools exist for testing and protecting networks, and major improvements have been made to providing users with actual, working security.  If they can be bothered to turn it on.

Thanks to Amanda, Renderman, Mister X, and folks who know who they are, for reviewing, fact checking, and telling me I needed to get this written.

Feel free to post in the comments or @KismetWireless on Twitter

Thursday, August 22, 2013

HackRF, pt 2 - GNU Radio Companion and Practical Sigint

* Go here for Part 1, looking at data from the HackRF in Baudline

Playing with keyfobs and baudline is a lot of fun, now lets try something more complex where the output data has more meaning (even if we decode the keyfob data, it's probably not going to show anything logical other than a big random number - feel free to try though!)

The transmitter in this case is a junky 433mhz transmitter meant for use with Arduino, which runs about $2:

We know this one transmits at 433mhz, so lets do a capture with the HackRF at 435MHz:

$ hackrf_transfer -r -f 435000000 -s 8000000

When we load this into Baudline (see previous post about this), we get:

Who remembers their CW?

So we know we have something reasonable in the file; now lets load it into GRC, GNU Radio Companion.

GRC allows you to build flow graphs with a GUI.  They're then compiled to python (and can be run independently of GRC).  Writing code using the GNU Radio blocks can achieve the same thing, but GRC has a lot of helpful features to make it simpler for GNU Radio newbies (of which I'm definitely one).  One downside is the GRC UI can sometimes make it challenging to find block - if you're having trouble finding something in the list, you can start typing the name and it should search for it.

Step one is to load our log file into a format GNU Radio can use easily.  The HackRF logs are IQ data pairs, stored as unsigned 8 bit integers (you can read more about IQ, or Quadrature Sampling, here).  GNU Radio components generally want complex IQ data, so we need to transform the file to that (as a big ugly image that breaks the layout entirely on the blog page):

You can get the grc xml file here.

A lot of things are going on here, and we haven't even started trying to do anything interesting!

This uses the standard "File Source" component to load the file, then converts UChars (unsigned 8 bit values) to floats in the "UChar to Float" block.  The "Deinterleave" stage splits the single stream of IQIQIQ data into I and Q channels, then recombines them as a "complex" stream via "Float to Complex", which most GNU Radio stages expect.

The "Add Const" stage then re-centers the data around 0; since it uses unsigned ints, with a range of 0-256, the HackRF samples center around 127.  (I had to bug Mike Ossmann about this - all the more reason to go sign up for the HackRF kickstarter - if it makes the stretch goal, we get videos of GNU Radio courses!)

Finally, the "Throttle" stage does, perhaps, the obvious - throttles the throughput to 8M.  Without this stage, it could easily swamp the system it is running on.  In general I've found it makes sense to throttle to the rate of the capture, because there can be odd interactions between rate and bandwidth otherwise - with IQ samples, the rate and bandwidth are linked.

The throttle stage uses the variable throttle_rate, found at the top of the image.  This lets you easily set the rate for different capture, with one significant gotcha:  GRC doesn't represent numbers in a format it can actually use!  GRC can accept raw numbers, or scientific notation (or hex, or octal, or any other format Python supports), but represents them as a human readable value which is NOT accepted.  In this case, 8000000 or 8e6 are acceptable values, however 8M is not.  Go figure.

So, now we have the file loaded in a format we can use.  What next?

The first step is to look at our signal - we can direct the output of throttle into a FFT sink like this:

And get a view of our signal:

Where we see our DC spike at our capture frequency (435MHz), and some of our signal, around 433.8MHz.

Now, look at the setup of the FFT sink - by default GNU Radio doesn't know (and doesn't care) what your center frequency is.  Unless you tell it otherwise, your center frequency is 0.  The signal would then be at -1.2MHz.  Nothing really cares about this, but I like to know where things really are, so I like to configure the FFT to be accurate:

In this case, the "Sample Rate" and "Baseband Freq" are set to variables, "samp_rate" and "capture_freq".  "Sample Rate" should match the input sample rate (in this case, 8M, the value we throttled to) or else the FFT won't update properly.

We use variable blocks in GRC, so:

So now we know where our signal is - to avoid the spike of the DC offset, we captured off-center at 435MHz.  We also captured far, far more data than we ever need in terms of bandwidth.  We can solve both of these problems at once using a "Frequency XLating FIR Filter".

The Frequency XLating Filter allows us to do three things at once:

  1. Shift the center frequency of the signal.  We'll use this to "scroll down" to our desired signal.
  2. Apply a pass filter.  This filters out parts of the signal we don't care about, so when we're measuring things later on, we're only measuring our signal and not some other radio noise.
  3. Decimate the signal.  Contrary to the actual definition of the word, in SDR terms, Decimate simply means Divide.  This reduces the bandwidth and sample of the signal, which reduces the amount of processing power need to handle it.  Since this reduces the sample rate, we'll have to remember this in future blocks!

Here we set the decimation using variables again - they're so much more convenient than trying to change all the dependent modules later.  To get the decimation value, we divide the incoming sample rate by the target rate - in this case, 50KHz, a relatively arbitrary value - it's wide enough to encompass our signal, and we don't have to fiddle too much because our signal is VERY strong in this sample. In reality we could probably use a much smaller value here. We have to cast the result to an integer, otherwise GRC gets angry;  Since this is really all Python under the covers, we use the Python integer cast, int(...).

Under "Taps", we use the variable firdes_tap - more on this later.  This performs the filtering to isolate our signal.

Finally under "Center Frequency", we tell it to shift - again using variables.  We want to shift down to our signal, so we need to shift by about 1.2MHz, or 435MHz - 433.828MHz.  Since we're shifting down, we make it negative.

I use GNU Radio 3.6 - the latest cutting edge release is 3.7, which has changed some things around.  Specifically in this case, the "Center Frequency" is now treated as the "actual" center frequency.  If you're on GNU Radio 3.7, remove the negative sign here.  This, and other changes, can be found here.

[ EDIT 09/02/2013 - Having updated to GNU Radio 3.7, I'm not sure what the changelog really indicates should be done - a negative offset as shown in the example script works fine, and a positive does not. ]

The firdes_tap variable defines our low-pass filter.  The key parameters here are:

  1. Gain (1) - We're not adding any gain into the signal.
  2. Sample rate (samp_rate) - This has to match the sample rate coming in, in this case 8M
  3. Cutoff frequency (2000) - We're defining the lower cutoff at 2KHz
  4. Transition band frequency (20000) - Set the transition band of the filter.  This should be less than half of the sample rate (in our case our decimated sample rate is 50k, so 20k is reasonable)
The WIN_HAMMING and 6.76 parameters tell GNU Radio to use a windowed filter and can generally be left alone.

After passing through the filter, decimation, and re-centering, we can put the signal back into a FFT display and see something like this:

Notice that the signal covers much less bandwidth, and is silenced except around our target area.  Playing with the values in the low_pass filter will yield different results, and you can learn a lot more about lowpass filter setup here.

Remember as well to set up your FFT plot properly:

Specifically, since we have decimated our signal to our target rate, it is now only 50KHz.  We have also changed the center frequency of the signal, so we set both "Sample Rate" and "Baseband Freq" to our target variables.

Now we have a lower-bandwidth, centered, filtered, ASK / OOK signal.  What can we do with it?

ASK and OOK are basically "high volume for one" and "low volume for zero".  They vary the amplitude (hence "Amplitude Shift Keying").  We can detect this in GNU Radio by measuring the magnitude of the signal:

The "Complex to Mag" converts a complex IQ signal to a simple magnitude.  Because in our sample our signal is so strong, and we've filtered it so that only our signal is being looked at, we can do a simple magnitude calculation on it.  If we had other stray signals still in the sample, we wouldn't be able to take the sample route.

Notice how the "Out" tab of the "Complex to Mag" block is orange instead of blue - this indicates the output is a Float, and that blocks which connect to this must expect a float.

We can set the scope sink to expect a float via the "Type" dropdown menu.

Running our GRC now gives us the scoped output of the magnitude of the signal.  Using the mousewheel to scroll out the scope time range a little, we see:

Which looks gratifyingly like the signal we saw in baudline back in the beginning, only we've constructed it by isolating our desired signal, focusing in on it, and converting it to magnitude counts.

You can get the sample data file here, and the GRC file here.

Next post, we'll focus on taking this signal from GRC and processing it back into data.

Thanks to Mike Ossmann, everyone in #hackrf on Freenode, and everyone who helped proof-read this and offered advice on the post.

* Go here for Part 1, looking at data from the HackRF in Baudline

Friday, August 9, 2013

Playing with the HackRF - Keyfobs

* Go here for Part 2, Processing the signal with GNU Radio Companion.

The HackRF is on Kickstarter, so here's a little write-up of some of the awesome stuff you can do with it, and why you should go get one.

I've been wanting to play around with my car keyfobs for a while; mostly out of idle curiosity.  They're something everyone has, and tend to put out a nice clean signal.  For my testing I used a 2006 Subaru keyfob, and my friend's Kia keyfob - they use different encodings, so this is a fairly interesting test.

Beyond academic interest, keyfobs may not be that useful to play with - they (should) all use rolling codes so that a captured unlock sequence can't be used more than once.  I wouldn't assume they've all implemented this properly, of course, as some conferences and speakers are pointing out.  It's definitely an area where more research is needed.

To start with, I did some searching to find out what frequency they operate at.  It turns out Kia runs at 315MHz, while Toyota and Subaru run at 433.847MHz (for many models, at least).

So, now we know where to look - what do we do with that?  First off, I fired up GQRX to get an idea of what was going on; pressing the keyfob returned data (sorry, don't have a screenshot handy of that specifically, but here's an example of gqrx capturing OOK data):

So we know something is going on; now we want to record it.  The quickest way to do this is hackrf_transfer:

$ hackrf_transfer -r -f 312000000 -s 8000000

Notice we're capturing slightly off-center from 315MHz.  Since we're capturing 8MHz wide, we'll get our signal, but by offsetting from center we avoid the DC offset which causes a spike at the center of the HackRF tuning band.  Recent firmware has made this significantly smaller, but it's still easy to avoid entirely, so lets do that.

Leave hackrf_transfer running for a while, while pressing the lock (or unlock) button on your key fob a few times.  After a few seconds, hit control-c to stop capturing.

I suggest naming your files carefully - the capture data itself is raw IQ samples, and doesn't contain any indication of how wide the samples are (8M), what the center frequency is (312MHz), or how it's encoded (for HackRF, all the captures are 8bit).  Better to name it properly to begin with.

Now we've got a big file of capture data; what can we do with it?  One good tool is baudline - ...  Unfortunately the licensing terms for baudline prevent its inclusion in distributions, so you'll need to download it independently.

There are a few quirks with baudline - one of them is that it doesn't handle large files (over about 50MB) very well, another is that it runs "file" (the file autotype detection) on any file you provide for it.  This is slow, so a quick fix for that is to alter your $PATH variable before launching baudline.  My baudline launcher script looks like:

export PATH=~/bin/disable:$PATH

and ~/bin/disable/ contains a "file" script which contains simply:

exit 0

So we need to make a smaller file for baudline - fortunately, "dd" handles this very well.  To get the first 50MB of the sample file,

$ dd bs=1M count=50

To get subsequent blocks of the file,

$ dd bs=1M count=50 skip=50

The tool "split" can also be used to break the file up into parts.

So we've got a smaller chunk of our file, let's open it up in baudline.  Use right-click, "input->open file..." then select the file and set the format to "raw" instead of "auto detect".  That will get you:

The magic settings here are:

"custom" sample rate of 8M (since we captured at 8MHz / 8M samples wide).  If you captured at another rate, like 20MHz, put 20000000 here.

"channels" are 2, since hackrf logs I and Q data.  Since we're logging IQ, turn on the "quadrature" checkbox, and since HackRF logs differently than baudline expects, turn on "flip complex".

Finally, since HackRF logs unsigned 8bit samples, click "8 bit linear (unsigned)".

Now we get a fancy display, like:

And we get a nice display of our signal; in this screenshot it's a Subaru keyfob using OOK (on-off-keying) encoding, basically morse code (transmit or not transmit)

Using the Kia keyfob, we get a FSK (frequency-shift-keying) signal, zoomed in we see:

What do we see here?  After the transmitter turns on, it sends a pattern of 'off' and 'on' signals, basically '101010101010'.  Look back at the Subaru OOK capture - it also sends a consistent '1010101010' pattern at the beginning.  This preamble tells the receiver that real packet data is coming, and helps us see how long the duty cycle is for 'on' and 'off'.

Scrolling further down the Kia FSK signal, we see it begin to send real data:

Which is the actual FSK encoded bits being sent to the car to unlock.

Finally, in baudline, it's possible to select a range and save it to a file:

by selecting the range, and right clicking to "output->export selection as..."

Beware, baudline changes the format of the file when you export it.  This will affect loading the file in the future, and any gnuradio code you develop to process the file in the future.  A less destructive option is to use 'dd' to trim the file (just make some guesses at the size) and load it into baudline.

To re-open a file you've saved from baudline, use the following settings:

Specifically, the file changes from 8bit unsigned to 16bit, and no longer needs the "flip complex" checkbox set.

Next post, I'll load a HackRF sample file into Gnuradio-Companion and try to extract the ASK bitstream directly.

* Go here for Part 2, Processing the signal with GNU Radio Companion.

Wednesday, August 7, 2013

Making a Wi-Fi contest

Druid asked me to design a Wi-Fi contest for the LOL Bitcoin party at Defcon21; as far as I know no-one ended up finishing it.  I'm not sure if that was due to lack of interest or obtuseness of the challenge.

For hardware, I used a cheap-as-dirt Rosewill 125N as the multi-SSID AP, and a Raspberry Pi on a powered USB hub and a hand full of random wireless cards as the clients providing interaction with the AP.

The ultimate goal was to log into a WPA2-PSK network with a complex passphrase, designed to be non-trivial to brute force (and likely impossible given the duration of the challenge, 2 days).

The passphrase was comprised of 3 overlapping parts.  Each piece overlapped with the others to provide alignment hints.

Part one of the passphrase was the MAC address of a client probing for somewhat obvious networks - hints about other components of the challenge, etc.  Converting the MAC address to ASCII got you the first piece.  Additional hints were in the SSIDs probed for - "Part one is right in front of you".

Part two of the passphrase was the WEP key of an encrypted network.  A client routinely joined the WEP network and pinged, to force an ARP exchange.  Standard WEP cracking (aircrack-ng) would disclose the key.

The third and final part of the passphrase was concealed by a WPA-PEAP client.  The client was deliberately misconfigured to not validate certificates.  By bringing up a WPA2-EAP network for the client looking for "ARE YOU MY MOMMY?", with a radius server configured to accept any login, the client would join, arp for an IP address, and then send a UDP frame containing the final component of the WPA2 passphrase.

The probing client hinted towards this network by probing for SSIDs like "there's a lost client" "he's very trusting" "can you give him a home"

With all 3 components of the passphrase, joining the network would cause a client to ARP for a specific IP address again, then send another UDP frame with the target email address.

Originally the plans were much more evil - requiring a SDR of some sort and hunting across multiple frequencies given.  I hope at least people had fun!

Thursday, March 28, 2013

2013-03-R1 released

2013-03-R1 is released; get it at the usual spot.  Primarily bugfixes which needed to happen; fixes include better terminal support in some terminal configs, better behavior on channel control by taking down the controlling vap, radiotap parsing fixes, and a bunch of other cleanups and bugfixes.

Phy-neutral is still cooking in the git codebase.

Monday, March 18, 2013

Kismet-2013-03-R1 baking....

Ramping up to release Kismet-2013-03-R1.

This release isn't terribly exciting - it's mostly 2 years of bug fixes pulled out of the dev tree, because a release with those fixes really needed to happen.

Phy-neutral is turning out to be excessively invasive so it's not included in this release - expect another hopefully in the not too distant future with major changes and new features.

For those who want a preview of 2013-03-R1, it's in the Git tree under the Kismet-2013-03-R1 branch.  If you notice any issues let me know before it goes to release and packaging.

Fixes include some memory management, a radiotap alignment issue creating bogus channels on some systems, downing the primary vap in mac80211 to get network management tools to leave us alone and not break channel control, libnl3 support, gps fixes, and general other goodness.

Anyone using 2011-03 or earlier, this upgrade is for you.  Anyone following git already, nothing to see here.

Wednesday, January 2, 2013

Quantal packages

Added Quantal packages (yeah, I know, it took me a while, I suck) to the downloads page for Kismet.