Waze | Another way to track your moves

Millions of drivers use Waze, a Google-owned navigation app, to find the best, fastest route from point A to point B. And according to a new study, all of those people run the risk of having their movements tracked by hackers.

Researchers at the University of California-Santa Barbara recently discovered a Waze vulnerability that allowed them to create thousands of “ghost drivers” that can monitor the drivers around them—an exploit that could be used to track Waze users in real-time. They proved it to me by tracking my own movements around San Francisco and Las Vegas over a three-day period.

“It’s such a massive privacy problem,” said Ben Zhao, professor of computer science at UC-Santa Barbara, who led the research team.

Here’s how the exploit works. Waze’s servers communicate with phones using an SSL encrypted connection, a security precaution meant to ensure that Waze’s computers are really talking to a Waze app on someone’s smartphone. Zhao and his graduate students discovered they could intercept that communication by getting the phone to accept their own computer as a go-between in the connection. Once in between the phone and the Waze servers, they could reverse-engineer the Waze protocol, learning the language that the Waze app uses to talk to Waze’s back-end app servers. With that knowledge in hand, the team was able to write a program that issued commands directly to Waze servers, allowing the researchers to populate the Waze system with thousands of “ghost cars”—cars that could cause a fake traffic jam or, because Waze is a social app where drivers broadcast their locations, monitor all the drivers around them.


The attack is similar to one conducted by Israeli university students two years ago, who used emulators to send traffic bots into Waze and create the appearance of a traffic jam. But an emulator, which pretends to be a phone, can only create the appearance of a few vehicles in the Waze system. The UC-Santa Barbara team, on the other hand, could run scripts on a laptop that created thousands of virtual vehicles in the Waze system that can be sent into multiple grids on a map for complete surveillance of a given area.

In a test of the discovery, Zhao and his graduate students tried the hack on a member of their team (with his permission).

“He drove 20 to 30 miles and we were able to track his location almost the whole time,” Zhao told me. “He stopped at gas stations and a hotel.”


Last week, I tested the Waze vulnerability myself, to see how successfully the UC-Santa Barbara team could track me over a three-day period. I told them I’d be in Las Vegas and San Francisco, and where I was staying—the kind of information a snoopy stalker might know about someone he or she wanted to track. Then, their ghost army tried to keep tabs on where I went.

Users could be tracked right now and never know it.

– Ben Zhao, UC-Santa Barbara computer science professor

The researchers caught my movements on three occasions, including when I took a taxi to downtown Las Vegas for dinner:

And they caught me commuting to work on the bus in San Francisco. (Though they lost me when I went underground to take the subway.)

The security researchers were only able to track me while I was in a vehicle with Waze running in the foreground of my smartphone. Previously, they could track someone even if Waze was just running in the background of the phone. Waze, an Israeli start-up, was purchased by Google in 2013 for $1.1 billion. Zhao informed the security team at Google about the problem and made a version of the paper about their findings public last year. An update to the app in January of this year prevents it from broadcasting your location when the app is running in the background, an update that Waze described as an energy-saving feature. (So update your Waze app if you haven’t done so recently!)

“Waze constantly improves its mechanisms and tools to prevent abuse and misuse. To that end, Waze is regularly in contact with the security and privacy research community—we appreciate their help protecting our users,” said a Waze spokesperson in an emailed statement. “This group of researchers connected with us in 2014, and we have already addressed some of their claims, implementing safeguards in our system to protect the privacy of our users.”

The spokesperson said that “the concept of Waze is that we all work together to share information and impact the world around us” and that “users expect to offer certain information about their route in exchange for unparalleled navigation assistance.” Among the safeguards deployed by Waze is a “system of cloaking” so that a user’s location as displayed “from time to time within the Waze application does not represent such user’s actual, real time location.”

But those safeguards did not prevent real-time tracking in my case. The researchers sent me their tracking minutes after my trips, with accurate time stamps for each of my locations, meaning this cloaking system doesn’t seem to work very well.

“Anyone could be doing this [tracking of Waze users] right now,” said Zhao. “It’s really hard to detect.”

Part of what allowed the researchers to track me so closely is the social nature of Waze and the fact that the app is designed to share users’ geolocation information with each other. The app shows you other Waze drivers on the road around you, along with their usernames and how fast they’re going. (Users can opt of this by going invisible.) When I was in Vegas, the researchers simply populated ghost cars around the hotel I was staying at that were programmed to follow me once I was spotted.

“You could scale up to real-time tracking of millions of users with just a handful of servers,” Zhao told me. “If I wanted to, I could easily crawl all of the U.S. in real time. I have 50-100 servers, and could get more from [Amazon Web Services] and then I could track all of the drivers.”

Theoretically, a hacker could use this technique to go into the Waze system and download the activity of all the drivers using it. If they made the data public like the Ashley Madison hackers did, the public would suddenly have the opportunity to follow the movements of the over 50 million people who use Waze. If you know where someone lives, you would have a good idea of where to start tracking them.

Like the Israeli researchers, Zhao’s team was also able to easily create fake traffic jams. They were wary of interfering with real Waze users so they ran their experiments from 2 a.m. to 5 a.m. every night for two weeks, creating the appearance of heavy traffic and an accident on a remote road outside of Baird, Texas.

“No real humans were harmed or even interacted with,” said Zhao. They aborted the experiment twice after spotting real world drivers within 10 miles of their ghost traffic jam.


While Zhao defended the team’s decision to run the experiment live on Waze’s system, he admitted they were “very nervous” about initially making their paper about their findings public. They had approval from their IRB, a university ethics board; took precautions not to interfere with any real users; and notified Google’s security team about their findings They are presenting their paper at a conference called MobiSys, which focuses on mobile systems, at the end of June in Singapore.


“We needed to get this information out there,” said Zhao. “Sitting around and not telling the public and the users isn’t an option. They could be tracked right now and never know it.”

“This is bigger than Waze,” continued Zhao. The attack could work against any app, said Zhao, turning their servers into an open system that an attacker can mine and manipulate. With Waze, it’s a particularly sensitive attack because users’ location information is being broadcast and can be downloaded, but the attack on another app would allow hackers to download any information that users broadcast to other users or allow them to flood the app with fake traffic.

“With a [dating app], you could flood an area with your own profile or robot profiles and basically ruin it for your area,” said Zhao. “We looked at a bunch of different apps and nearly all of them had this near-catastrophic vulnerability.”

The scary part, said Zhao, is that “we don’t know how to stop this.” He said that servers that interact with apps in general are not as robust against attack as those that are web-facing.

“Not being able to separate a real device from a program is a larger problem,” said Zhao. “It’s not cheap and it’s not easy to solve. Even if Google wanted to do something, it’s not trivial for them to solve. But I want them to get this on the radar screen and help try to solve the problem. If they lead and they help, this collective problem will be solved much faster than if they don’t.”

“Waze is building their platform to be social so that you can track people around you. By definition this is going to be possible,” said Jonathan Zdziarski, a smartphone forensic scientist, who reviewed the paper at my request. “The crowd sourced tools that are being used in these types of services definitely have these types of data vulnerabilities.”

Zdziarski said there are ways to prevent this kind of abuse, by for example, rate-limiting data requests. Zhao told me his team has been running its experiments since the spring of 2014, and Waze hasn’t blocked them, even though they have created the appearance of thousands of Waze users in a short period of time coming from just a few IP addresses.

Waze’s spokesperson said the company is “examining the new issue raised by the researchers and will continue to take the necessary steps to protect the privacy of our users.”

In the meantime, if you need to use Waze to get around but are wary of being tracked, you do have one option: set your app to invisible mode. But beware, Waze turns off invisible mode every time you restart the app.

Full paper here.


OmniRAT – the $25 way to hack into Windows, OS X and Android devices


Just last week, police forces across Europe arrested individuals who they believed had been using the notorious DroidJack malware to spy on Android users.

Now attention has been turned on to another piece of software that can spy on communications, secretly record conversations, snoop on browsing histories and take complete control of a remote device. But, unlike DroidJack, OmniRAT doesn’t limit itself to Android users – it can also hijack computers running Windows and Mac OS X too.

And that’s not the only difference between DroidJack and OmniRAT. Both of them may be being sold openly online, but OmniRAT retails for as little as $25 compared to DroidJack’s more hefty $210.

Security researchers at the anti-virus company Avast describe OmniRAT as a “Remote Administration Tool.

And it certainly can be used for entirely legitimate purposes, with the permission and consent of the owners of Android, Mac and Windows computers it tries to control.

But, in the wrong hands, it can also be considered a “Remote Access Trojan” – giving malicious hackers an opportunity to sneakily spy on and steal from unsuspecting users duped into installing the code.


In his blog post, researcher Nikolaos Chrysaidos describes how he believes hackers have infected Androids with OmniRAT after sending an SMS.

Apparently, a German Android user explained on the Techboard-online forum how he had received an SMS telling him that an MMS had not been delivered directly to him due to the StageFright vulnerability.

In order to access the MMS, the user was told to follow a bit.ly link within three days, and enter a PIN code.

However, as Crysaidos explains, visiting the URL would initiate the attempt to install OmniRAT onto the target’s Android device:

Once you enter your number and code, an APK, mms-einst8923, is downloaded onto the Android device. The mms-einst8923.apk, once installed, loads a message onto the phone saying that the MMS settings have been successfully modified and loads an icon, labeled “MMS Retrieve” onto the phone.

Once the icon is opened by the victim, mms-einst8923.apk extracts OmniRat, which is encoded within the mms-einst8923.apk. In the example described on Techboard-online, a customized version of OmniRat is extracted.

Android app icon

Perhaps the long list of permissions requested by the app would make you think twice, if it weren’t so common for so many popular apps in the Google Play store to make similar requests.

App permissions

The problem of course is that through its cunning social engineering, and the target’s keen attempt to view the MMS that they might have been sent, it may be all too likely that the user grants permission for the app to be installed without thinking of the possible consequences.

And, as the app is capable of sending its own SMS messages, it may be that your infected Android device could then send further messages with malicious intent to your friends, family and colleagues, in the hope of hijacking further devices. After all, users are more likely to be tricked into believing a message is legitimate, and letting their guard down, if they receive a message apparently coming from someone they know and trust.

Sadly victims will probably have no clue that their devices are compromised, and even if they uninstall the MMS Retrieve icon, the customised version of OmniRAT remains installed on their Android smartphone, and will be sending data to a command and control (C&C) server seemingly based in Russia:

Russian domain

So, the question to ask is how should you protect yourself?

Well, clearly you should resist the urge to install apps onto your smartphone from anywhere other than the official app stores. Although malware has unfortunately snuck into the Google Play store in the past, you’re much more likely to encounter malicious code from unauthorised sources.

Furthermore, I would recommend running a security product on your Android device to detect malicious code and that – if possible – you keep your Android smartphone patched with the latest version of the operating system.

Finally, always think long and hard before clicking on links from untrusted sources. It could be that you’re just one click away from a hacker trying to take remote control of your Android phone.




United Airlines’ Frequent Flyer App has been hacked

United Airlines’ Frequent Flyer App Can Be Hacked to Reveal Passenger Info

Flying has never been more convenient for customers. The security checks might be a drag, but sometimes all it takes to check in online is punching in a few digits into a mobile app.

But that may be just a little too convenient. A cybersecurity company has discovered that it’s possible to obtain the personal and flight information of United Airlines MileagePlus customers through the company’s app.

“An attacker can get access to personal details such as email, phone number, flight details (origin, destination, date, time, seat) and even the boarding pass,” Yosi Dahan, co-founder and CEO of Turrisio Cybersecurity, told Motherboard in an email.

When logging into the United Airlines app to check in, a customer can either enter their booking confirmation code or MileagePlus ID and doesn’t need to give any other information, such as a password. MileagePlus is United Airline’s frequent flyer program. If the user’s flight is within 24 hours, their information will be displayed on the app.

Image: Censored screenshot provided by Dahan to show the information he uncovered

MileagePlus IDs are very basic: they come in the format of two letters, followed by six digits. So instead of having to find out the ID of a particular customer, Dahan wrote a simple Python proof-of-concept script that could allow an attacker to grind through the possible combinations of IDs and automatically check if any flights were booked with them.

There is no indication that the app has actually been abused by criminals. But Dahan, who has previously written about the MileagePlus app security, envisioned that it could be possible to launch a social engineering attack with information gleaned this way. He suggested, for instance, that an attacker could call a victim and present them with information that only United Airlines should know, then scam them into handing over credit card details.



Credit:  motherboard

DynamoRIO | Runtime Code Manipulation System

About DynamoRIO

DynamoRIO is a runtime code manipulation system that supports code transformations on any part of a program, while it executes. DynamoRIO exports an interface for building dynamic tools for a wide variety of uses: program analysis and understanding, profiling, instrumentation, optimization, translation, etc. Unlike many dynamic tool systems, DynamoRIO is not limited to insertion of callouts/trampolines and allows arbitrary modifications to application instructions via a powerful IA-32/AMD64 instruction manipulation library. DynamoRIO provides efficient, transparent, and comprehensive manipulation of unmodified applications running on stock operating systems (Windows or Linux) and commodity IA-32 and AMD64 hardware.

DynamoRIO’s powerful API abstracts away the details of the underlying infrastructure and allows the tool builder to concentrate on analyzing or modifying the application’s runtime code stream. API documentation is included in the release package and can also be browsed online.



Downloading DynamoRIO

DynamoRIO is available free of charge as a binary package for both Windows and Linux. DynamoRIO’s source code is available under a BSD license.



DynamoRIO Website: http://www.dynamorio.org




One in Five Android Apps Is Malware

Report: 1 in 5 Android Apps Is Malware

Bad news, phandroids. Android malware is on the rise.

According to Symantec’s latest Internet Security Threat Report, “17 percent of all Android apps (nearly one million total) were actually malware in disguise.” In 2013, Symantec uncovered roughly 700,000 virus-laden apps.

More than one third of all apps were what Symantec calls “grayware” or “madware” — mobile software whose primary purpose is to bombard you with ads. The company also discovered the first example of mobile crypto-ransomware – software that encrypts your data and holds it hostage until you pay ransom for it – for Android devices.

symantec norton internet threat security report

How to stay safe

The good news is that it’s pretty easy to avoid infection if you obtain your apps from a trusted source, like the Google Play Store. The company doesn’t break out how many of the 1 million+ malware apps were found in the Play Store, but Symantec’s Director of Security Response Kevin Haley admits the number is probably quite low.

“Google does a good job of keeping malware out of the Store,” Haley says. “And if a malicious app does make it in there, they do a good job of finding it and getting rid of it.”

On the other hand, if you visit alternate Android app markets, download apps from app maker’s Websites, get them via email links, or find them on Bit Torrent sites, you run a much greater risk of infecting your phone, he adds.

Other App Stores

Symantec used its Norton Mobile Insight software to crawl more than 200 Android app stores, downloading and analyzing more than 50,000 apps and app updates each day in 2014.

Most of the malware found by Symantec tries to steal personal data like phone numbers and contact lists, which are then sold on the Internet’s black market, says Haley. Some may cause your phone to send text messages to premium SMS services, automatically adding charges to your monthly bill. Other apps may pelt you with ads that pop up randomly over other applications. Some apps even change your default ringtone to an advertisement, Haley says.

The Android malware problem is greater overseas, especially in regions where users can’t access Google Play and must rely on third-party app marketplaces.


Mobango is one of hundreds of alternate Android app marketplaces in the wild. Be careful out there. (Mobango.com)

If you see unusual charges on your bill for premium texting services or ads start popping up where you don’t expect them, those are good signs you’ve got an infection, he adds. Your best recourse is to use a mobile security app to scan and protect your phone.

As for iOS? Symantec found a grand total of 3 malware apps in 2014. All of them required the iPhone to be jailbroken before it could be infected. In 2013 it found zero.

“One of the benefits of Android versus iOS is that it gives you a lot more freedom as to where you can download apps,” Haley says. “But that freedom comes with a cost.”




Mobile Tracking and Device Identification via Sensor Fingerprinting

New mobile attack vector allows cyber attackers to track and identify mobile victims via sensors fingerprinting


Cyber Security researchers discovered a new techniques and methodology of privacy botnet that allows an attacker to gain user’s personal information, detailed location, movement and motion surveillance, area mapping and more.

The malware found was designed to work in a stealth mode and running as a receiver behind a system background service. Once the attacker sends an SMS message containing different message body texts (For example: question mark or smiley) to the target device, it will cause the device to send a private information that not required any special permission or dialog’s box approval from the victim client.

The core functionality and the real advantage of the potnet (or privacy botnet), from an attacker’s point of view, is the ability to get different type of data from the victim’s device including: cellular network information and other sensor data of the targeted victim.


The malware allows an attacker to get an information about the geolocation and the positioning of the target device. This data is calculated on the potnet C&C server and then available to the attacker in order to track the target device’s exact motions.

Diagram 1.0: Human tracking system


Next generation of privacy botnet

Potnet and The Next generation of privacy’s botnets are not acting as a banking Trojan or malware and it is not designed to steal your banking credentials, log into your account or transfer your funds to criminals, is the type of malware that’s designed to track your motion, movement and geolocation, so that they can be used for social engineering, advanced positioning and tracking techniques.

The Potnet’s malware that found essentially doing this by grabbing the victim’s information and send it to certain websites. These websites are pre-specified by the attackers, and they are typically Command and Control (C&C) servers that hosted anonymously in a third-party web hosting service.

The data that is collected, then calculated on the server side in order to provide to the attacker an accurate picture about the victim. Utilizing a short processing time on the client side of the malware, data sent to the server minimized, thus reducing the possibility of detection by client side’s defense mechanisms.

Using a non-conventional device data allow the attacker to track victims that located at low-connectivity or bad-signal environments like inside buildings and even underground level (according to the cellular data signal).

Diagram 1.1: Tracking victims in low-connectivity or bad-signal environments


Weaponization of government tracking techniques

One of the harmful aspects of the potnet’s malware family is that when it enters into the target mobile device, it is very difficult to be detected or to know the exact trigger that used in order to send an information or data out from the device.

Once executed, the malware generates an incoming broadcast receiver and then waits for a specific SMS text message that contains smiley or question mark as the message text body for example. Once the SMS message arrived, the malware then logs all activities related to a specific sensor data and the cellular network information include the cell id, LAC, MNC, MCC, etc.… and sending them to the potnet C&C server.

Sending only a small amount of data to the C&C server at the backend reduces the possibility of detection by client side’s defense mechanisms (like Anti-Viruses or other signature-based protection techniques). This methodology and technique of calculating additional information that related to the victim by correlating the collected data with third-party APIs and other web-services are one of the advantages of potnets and the next generation botnets.


Diagram 1.2: Triangulation is calculated according to the signal of every base-station (cell tower)



You can read or download the full AboutAndroid Malware Analysis Report here:

Read (SlideShare): http://www.slideshare.net/erangoldstein/meet-the-potnet

Original post: https://www.linkedin.com/pulse/meet-potnet-eran-goldstein



Hack a Car | Part Two

a complete guide to hacking your vehicle bus on the cheap & easy – part 2 (interpreting the data)

OBD hackin part deux
in part 1 of this series, i covered the basics for how to interface with a vehicle bus using an inexpensive USB or Bluetooth ELM327-based scan tool. in part 2 below, i’ll go over how to actually use that hardware interface to collect and analyze data with the intention of discovering how to interact with the vehicle in some specific way.for my own first project, i wanted to know how to intercept the steering wheel radio remote-control button press events. i replaced my factory radio with a Motorola Xoom 10″ Android tablet in order to have a bigger and better GPS (and OBDII app, and better entertainment options, etc). however, touching the screen precisely while driving can be difficult (especially when bouncing around off-road). hence why i wanted the factory steering wheel buttons to still control volume, track, play/pause, etc. i’ll use this goal as an example to walk through navigating the bus data.


what you’ll need


task 1: get a baseline

the first task is to gather some baseline data – i.e. what msgs are flying around the bus when your are NOT doing whatever particular interaction you are looking to find the msg for. i tested and found that with the vehicle not running, i could still use the steering wheel buttons to control the radio. that made things a little simpler since i would be able to gather all my sample data with the engine off and the key in “run” (there are way less msgs on the bus when the vehicle is not running).

  • issue the following commands (one at a time): ATL1, ATH1, ATS1, ATAL
  • be sure your serial terminal app is set to log to a text file.
  • issue ATMA to have the scan tool start reporting all of the bus msgs it sees.
  • just press enter after a minute to stop the stream of data.


task 2: log data from the event/interaction in question

the next task is to log the bus msgs when the action you are looking for occurs. this could be when something like when the radio changes tracks, when you press the sunroof close button, etc. i wanted to know the msg for each steering wheel button. i did a data collection run for each of the 6 buttons separately. for each run, i would press the same button 5 times, trying to space the presses evenly about 1 second apart. i wanted to create some sort of pattern that would hopefully stand out in the data stream.

  • repeat the steps from the previous task, while causing the event in question (or allowing it to happen if you have no control over it).


task 3: analyze the data

now you’re ready to analyze the data you collected in order to find just the bus msgs you care about. i used Excel, but you could go with any spreadsheet or database tool that you’re familiar with. the complete MS Excel spreadsheet for all the examples below can be downloaded here: 2003WJ-PCIBus-SWButtonData.xls

  • paste the data from each of your baseline/test runs into separate sheets of the spreadsheet. all the bus msgs should be in the first column. add a column header called “msg“.


  • on the sheet with the baseline data, add a second column with the header “count“. just fill this column with a “1” for every row.


  • still on the baseline data sheet, create a pivot table that sums the count for each msg. this is just an easy way to give you a list of distinct msgs.


  • now go to the sheet with your first sample data run. again use “msg” for the first column header and create a second column filled with 1’s called “count“.
  • for the third column add the header “not in baseline“. for the value of every row, specify a function that places the msg from the first column into this column ONLY if that msg is not in the baseline list. the function might look something like this (my baseline data pivot table is in the sheet named “baseline”, on column “D”):

=IF(ISNA(MATCH(A2,baseline!D:D,0)), A2, "")

you should end up with something like this, where the third column is a bunch of blank cells with only a few having msgs in them:


  • now create another pivot table similar to the previous. however, for this sample run sheet, use the “not in baseline” and “count” columns. this give you a list of distinct bus msgs that occurred during your test that were NOT duplicates of msgs from the baseline run. it also tells you how many times the msg occurred. you’ve basically removed the background noise from your data sample. if you’re after something really simple, this might be nearly the end of your journey. for my project, i needed to compare several of the buttons to really understand what was going on.

pivot once more

  • in the previous img, notice i had several distinct bus msgs that were not in my baseline. i had pressed the “up” button on the right side of the steering wheel 5 times for this test run, yet none of the distinct “not-in-baseline” msgs happened exactly 5 times! so i went ahead and repeated these steps for the other 2 buttons on the right side. below are the pivot tables i generated from each of the test runs.

dare to compare

  • now for some basic deductive reasoning and a little intuition. above i’ve highlighted in red all of the msgs that occurred at least 5 times – i knew that i definitely pressed the buttons distinctly and hard enough that they should have registered for each press, but perhaps they were sending multiple msgs if i held them down just a bit too long? next i crossed out any msgs duplicated between test runs (the 3 different buttons can’t be producing the exact same msg).


  • this left me with one unique msg to look at in 2 of the runs, and 2 unique msgs in the other run. however with this little data left, it was easy to spot a pattern – all 3 runs had a msg that was sent to bus ID 11. i guessed that 11 must be the radio’s ID, and the 3 distinct msgs sent  it must be my 3 buttons on the right side of the steering wheel.


task 4: test your hypothesis

  • you might next want to do a confirmation test, monitoring only the ID that you believe is sending the msg (ATMT#), or only the ID that the msg is destined for (ATMR#).

based on the deductions above, i thought i had the right 3 bus msgs. but why didn’t they occur exactly the number of times i pressed the buttons? i decided to perform another test, but only monitor ID 11 (the radio). hopefully my sample data would be small enough to look at directly and spot a pattern. again i tested each button separately, this time issuing the command ATMR11 to only see msgs destined for the radio. i pressed each button 5 times again, about a second apart. this time i was extremely deliberate and consistent in how i pressed each button. check out the results:

we have a GO

i think what is happening is a side-effect of mechanical switches known as contact bounce or chatter. i later saw that holding down a switch sends regular timed repeats of the msg, whereas a quick press can send from 1 to 3 msgs in rapid succession. this reinforces my suspicion of bounce.

  • another way to test your conclusions is to send the msg into the bus and physically verify the vehicle responds as expected. this would work for actions like locking/unlocking the doors, etc. i tried to replicate the “up” button on the right side of the steering wheel. if i was sending the right msg, then i would hear the radio increase volume (and see the display indicate the new level). the “up” button msg that i had monitored was 3D 11 04 00 C3, so i used the the command ATSH 3D 11 04 and then issued 00 C3. sure enough, it worked!

for all of the examples so far i’ve been working with the a SAE J1850 type bus. the msg structure and sample commands should work with most other protocols except CAN-Bus. you may have already inferred part of the msg structure:

3 byte header + up to 7 data bytes + checksum

the ELM327 reports the msgs in hex, so they look like this  (where PP = priority, RR = receiver ID, TT = transmitter ID, DD = data, CC = checksum):


the msg structure for CAN is just a bit different, and the ELM327 has an entire set of commands specifically for working that protocol. check out the datasheet for complete info on msg structures and all the possible commands.


additional resources

  • walkthrough of a much more complex data gathering/analysis exercise (CAN-Bus, Mini Cooper)


  • Chrysler/Jeep/Dodge


  • Audi/VW



  • BMW






you’ve likely surmised that vehicle bus hacking can prove non-trivial. it could be much more complex than my little example. i’ve read that some manufactures encode longer data across multiple standard msgs using custom schemes. deciphering something like that might be impractical. deciphering constantly changing data from a running vehicle is also challenging.

there are professional data collection and analysis tools/software, but you could also write your own. creating a simple application that time-stamps each msg in the log file would be a good start to help find patterns. adding the capability to graph msg frequency would be useful as well.

i came away from this project frustrated that the majority of data moving about in our vehicles is proprietary. it’s just another example of how society is moving away from a fix-it culture. if this type of information remains confidential, there is no hope of an individual or small repair shop fixing certain types of vehicle problems. we’re not far from a future where cars are as throw-away as iPads. one day i’ll have a Jeep that has to go to the Fiat/Chrysler Genius Bar. there i’ll find out that repairing whatever minor issue it has is too costly because everything is glued together, and that i’m better off buying the new model.


Credit: theksmith

Common Android Wear Tasks for Security Researchers and Developers

Getting started with security research and development on the Android Wear platform can be challenging 🙂

Here are my notes on how to get started quickly.


Before you do anything!

1. Back up your IntelliJ configuration if you use IntelliJ at all.

2. Install Android Studio. Do NOT try to use IntelliJ to do Android Wear development.

Once you’ve got Android Studio installed you’ll need to do some setup on your devices (watch and phone) to get them working. Here I assume you’re using physical devices for your phone and your watch, no emulators.


Enabling debugging on your Android Wear device

The first time you set up your watch for remote debugging do the following:

  1. Tap your watch face to get the “Speak now” prompt
  2. Tap the screen again to get the list of options
  3. Scroll down to “Settings” and tap it
  4. Scroll down to “About” and tap it. If you see “Developer options” in this list already you do not need to do this procedure since it has already been done.
  5. Scroll down to “Build number” and tap it 7 times. You should get a message that says “You are now a developer!”.
  6. Swipe to the right to get the previous menu
  7. Scroll down to “Developer options” and tap it
  8. Tap “ADB debugging” if it says it is disabled
  9. Tap “Debug over Bluetooth” if it says it is disabled

After your Android Wear device has been set up once you’ll only need to follow these steps to re-enable debugging if you ever disable it:

  1. Tap your watch face to get the “Speak now” prompt
  2. Tap the screen again to get the list of options
  3. Scroll down to “Settings” and tap it
  4. Scroll down to “Developer options” and tap it
  5. Tap “ADB debugging” if it says it is disabled
  6. Tap “Debug over Bluetooth” if it says it is disabled


Enabling debugging over Bluetooth from your Android phone to your Android Wear device

  1. Open the “Android Wear” app
  2. Tap the settings icon at the top of the screen (the two gears that look like the icon below)two small gears
  3. Make sure “Debugging over Bluetooth” is checked
  4. Once it is checked two fields will appear below it. They are “Host” and “Target”. “Target” will say “connected” when your watch is connected to your phone. “Host” will say “connected” when ADB is connected to your watch.


Setting up ADB for Android Wear debugging over Bluetooth

Make sure ADB sees your phone:

  1. Connect your phone via USB and make sure USB debugging is enabled
  2. Run adb devices from the command line. You should get some output like this:
     $ adb devices
     List of devices attached
     01234567890abcdef    device
  3. Check to see if there is a device in the list called “localhost:4444”. If so, you are already paired and ready to go. You do not need to do this procedure.
  4. To connect ADB to your watch run adb forward tcp:4444 localabstract:/adb-hub; adb connect localhost:4444 and you should see this:
     $ adb forward tcp:4444 localabstract:/adb-hub; adb connect localhost:4444
     connected to localhost:4444
  5. Run adb devices again and you should see this:
     $ adb devices
     List of devices attached
     01234567890abcdef    device
     localhost:4444       device
  6. If you do not see the localhost:4444 entry then double check that ADB debugging and Bluetooth debugging are enabled on your watch. Then check to make sure Bluetooth debugging is enabled in the Android Wear app on your phone. Once those are verified you can run this command again and it will try to reconnect.

Now that you’ve done all of that Android Studio should give you a dialog like this when you try to run or debug an application:

"Choose Device" dialog



Credit and Thanks to:  Tim Mattison

AppUse – Android Pentest Platform Unified Standalone Environment

AppUse Virtual Machine, developed by AppSec Labs, is a unique (and free) system, a platform for mobile application security testing in the android environment, and it includes unique custom-made tools.

Faster & More Powerful
The system is a blessing to security teams, who from now on can easily perform security tests on Android applications. It was created as a virtual machine targeted for penetration testing teams who are interested in a convenient, personalized platform for android application security testing, for catching security problems and analysis of the application traffic.
Now, in order to test Android applications, all you will need is to download AppUse Virtual Machine, activate it, load your application and test it.


Easy to Use
There is no need for installation of simulators and testing tools, no need for SSL certificates of the proxy software, everything comes straight out of the box pre-installed and configured for an ideal user experience.
Security experts who have seen the machine were very excited, calling it the next ‘BackTrack’ (a famous system for testing security problems), specifically adjusted for Android application security testing.


AppUse VM closes gaps in the world of security, now there is a special and customized testing environment for Android applications; an environment like this has not been available until today, certainly not with the rich format offered today by AppUse VM.
This machine is intended for the daily use of security testers everywhere for Android applications, and is a must-have tool for any security person.


We at AppSec Labs do not stagnate, specifically at a time in which so many cyber attacks take place, we consider it our duty to assist the public and enable quick and effective security testing.


As a part of AppSec Labs’ policy to promote application security in general, and specifically mobile application security, AppUse is offered as a free download on our website, in order to share the knowledge, experience and investment with the data security community.


  • New Application Data Section
  •  Tree-view of the application’s folder/file structure
  •  Ability to pull files
  •  Ability to view files
  •  Ability to edit files
  •  Ability to extract databases
  •  Dynamic proxy managed via the Dashboard
  •  New application-reversing features
  •  Updated ReFrameworker tool
  •  Dynamic indicator for Android device status
  •  Bugs and functionality fixes



Credit:  kitploit