New Bluetooth 5 Channel Hopping Reverse Engineered For Jamming And Hijacking

August 10, 2019 by Mike Szczys 9 Comments

Bluetooth Low Energy (BLE) 5 has been around since 2016 with the most recent version 5.2 published just this year. There’s not much hardware out there that’s using the new hotness. That didn’t stop [Damien Cauquil] from picking apart BLE 5’s new frequency hopping techniques and updating his BtleJack tool to allow sniffing, jamming and hijacking hardware using the new protocol.

As you can imagine, the BLE standard a complicated beast and just one part of it is the topic here: the PRNG-based frequency hopping scheme that is vastly different from BLE 4.x and earlier. The new standard, called Channel Selection Algorithm (CSA) #2 — uses 65535 possible channels, compared to just 37 channels used by its predecessor. Paired devices agree to follow a randomized list of all possible channels in sequence so that they remain in synchronization between hops. This was put in place to help avoid collisions, making it possible for many more BLE devices to operate in close proximity. This is important to note since it quickly becomes obvious that it’s not a robust security measure by any means.

To begin channel hopping the two devices must first agree on an order in which to hop, ensuring they’ll meet one another after each leap. To do so they both run the same 32-bit seed number through a PRNG algorithm, generating a list that will then be followed exactly in order. But it turns out this is not very difficult to figure out. All that’s needed is the access address whose top 16-bits are publicly available if you’re already sniffing packets, and the bottom 16-bits is the counter that increments the hop address list.

If you want to jam or hijack BLE 5 communication you need to establish which “randomized” channel list is being used, and the value of the counter that serves as an index to this list. To do so, [Damien] sniffs packets on two different channels. These channels will be used over and over again as it loops through the channel list, so calculating how much time occurs between each channel indicates how far apart these channels are on the list.

In practice, [Damien] first implemented a sieve (the same concept as the Sieve of Eratosthenes for finding primes) that starts with a list of all possibilities and removes those that don’t contain a matching timing between the two channels. Keep doing this, and eventually, you’ll whittle your list down to one possible channel order.

This certainly worked, but there were timing issues that sometimes meant you could learn the seed but couldn’t then sync with it after the fact. His second approach uses pattern matching. By measuring hops on 11 consecutive channels, he’s able to synchronize with target devices in a minute or less. From there, jamming or hijacking methods come into play. The randomization of this scheme is really marginal. A more robust technique would have used an internal state in both devices to generate the next hopping channel. This would have been much more difficult for an attacker to figure out. From the device perspective, CSA #2 takes very little computation power which is key for power-sipping IoT devices most often using BLE.

As mentioned before, [Damien] had trouble finding any hardware in the wild using the BLE 5 standard. His proof of concept is built on a pair of nRF52840 development boards. Because it needs more testing, the code hasn’t been merged into the main version of BtleJack, but you can still get it right now by heading over to BtleJack repo on GitHub.

Bots That Snag The Hottest Fashion While Breaking Social Trust In Commerce

August 10, 2019 by Mike Szczys 17 Comments

Scarcity on the Internet is the siren song of bot writers. Maybe you’ve lost an eBay bid in the last milliseconds, or missed out on a hacker con when tickets sold out in under a minute — your corporeal self has been outperformed by a bot. But maybe you didn’t know bots are on a buying frenzy in the hyped-up world of fashion. From limited-run sneakers to anything with the word Supreme printed on it, people who will not accept any substitute in wearing the rarest and most sought after are turning to resellers who use bots to snag unobtanium items and profit on the secondary market.

At DEF CON 27 [FinalPhoenix] took the stage to share her adventures in writing bots and uncovering a world that buys and sells purchasing automation, forming groups much like cryptocurrency mining pools to generate leads on when the latest fashion is about to drop. This is no small market either. If your bots are leet enough, you can make a ton of cash. Let’s take a look at what it takes to write a bot, and at the bots-for-sale economy that has grown up around these concepts.

The internet is built with bots in mind and we have Google to thank for this. Their major innovation was moving us off of a curated internet to one that is machine crawled. Everyone wants good Google juice and that means building a site that is friendly to the Google bots that crawl and index the internet. This makes automation for your own purposes quite a bit easier. Namely, the monitor-bots that are used to detect when a retailer has the latest in stock. [FinalPhoenix] demonstrated a simple script that grabs the XML site map, parsing it for newly in-stock items, flagging them when found. But here’s the killer — if your monitor bot is a good one, you can turn it into a discord channel and sell subscriptions to others playing the reseller game, to the tune of $15-30 a month per subscriber.

Example slide of code used in a web-based buy-bot

Once your bot reports stock, the race is on to buy it before anyone else can. For this, you could use the APIs of the site, but that’s time-consuming and a lot easier for retailers to detect and block bot usage. For this part of her botting tools [FinalPhoenix] likes to use web-based bots that go through a browser framework like Chromium and allow obfuscation techniques like scrolling, clicking other items, random pauses, and other simple-minded actions that make your bot appear to be only human. In the examples for this talk, the Puppeteer framework was used for this purpose. In the end, the main role of this part of the bot is to use a verified account to complete the purchase as fast as robotically possible, which is why they’re called buy-bots. Retailers do have some tricks to combat these web-based attacks like adding secret keys in the DOM that need to be sent with the next post, but these are easy to discover and incorporate into the scripts.

This raises up another interesting part of the scheme, the verified accounts. For the best chance at profit, you need multiple accounts, each used just one time to avoid your buy-bot being detected by the retailer. For this, [FinalPHoenix] turns to services that sell accounts in packages of 500-10,000 and cost around just $5-10 per batch.

But wait, here’s where it gets really wild as recursion takes hold. Yes, these buy-bots are for sale (from sites like AIO Bot and usually around $300-1500), but they’re sold in limited quantities so that it’s harder for retailers to notice and take countermeasures. Just like how the clothing was limited release and incentivized bots-wielding resellers to enter the market, there is a secondary market for the bots themselves. [FinalPhoenix] reports that reselling one of these bots can yield $1000-1500 in profit. The same principles apply, and so what we’ve ended up with is bots buying bots to buy clothes. Who knows how many levels of bot-bot transactions there are, but it certainly feels like turtles all the way down.

Bot-based high-speed trading is the real way to make major bank on the securities market. Your average hacker is shut out of that “legitimate” business, but any enterprising programmer has the option of automating whichever reseller market they find most interesting. This breaks the public trust in commerce — buying quality products from a seller connected to their production for a reasonable price. If frustrates the manufacturer, alienates the consumer, but there appears to be little in place preventing it.

From An Eye To An Eye: Human Muscles As A Joystick

August 10, 2019 by Inderpreet Singh 2 Comments

The interface between humans and machines has been a constantly evolving field. Sure the computer mouse was a game-changer, but time moves on. We are now looking at integrating machines via soft HMIs for personal applications. A research team led by the University of California, San Diego has presented a paper interfacing a soft lens with the human eye.

The lens itself is a pair of electroactive elastomer films that encapsulates a small quantity of saltwater. These films constitute the muscle and are controlled by an external source of electrical pulses. The signals are generated when electrodes placed around the eye of a subject and detect movement. Actions such as blinking are converted to a zoom-in-zoom-out activity which is designed to mimic human squinting.

The suggested potential applications are visual prostheses, adjustable glasses, VR, and even soft robots eyes. Yes, we are heading from whirring robots to squishy robots, but that also means that people with disabilities can get a second chance. This approach is non-invasive as opposed to brain implants.

[via Phys.org]

[Thanks for the tip Qes]

Continue reading “From An Eye To An Eye: Human Muscles As A Joystick” →

Stepper-Controlled Chop Saw Automates A Tedious Job

August 10, 2019 by Dan Maloney 23 Comments

We’re not going to question why [Absorber Of Light] needs to cut a bazillion little fragments of aluminum stock. We assume his reasoning is sound, so all we’re interested in is the automated chop saw he built to make the job less tedious, and potentially less finger-choppy.

There are probably many ways to go about this job, but [Absorber] leaves few clues as to why he chose this particular setup. Whatever the reason, the build looks like fun, with a long, stepper-driven threaded rod pushing a follower down a track to a standard chop saw. The aluminum stock rides in the track and gets pushed out a set amount before being lopped off cleanly as the running saw is lowered by a linear actuator. The cycle then repeats until the stock is gone.

An Arduino controls the stock-advance stepper in the usual way, but the control method for the linear actuator is somewhat unconventional. A second stepper motor has two cams offset by 180° on the shaft. The cams actuate four microswitches which are set up in an H-bridge configuration. The stepper swivels back and forth to run the linear actuator first in one direction then the other, with a neutral position in between. It’s an interesting approach using mechanical rather than the typical optical isolation. Check it out in action in the video below.

We’ll admit to some curiosity as to the use of the coupons this rig produces, so maybe we’ll get lucky with some details from [Absorber Of Light] in the comment section. After all, we knew exactly what the brass tubes being cut by the similar “Auto Mega Cut-O-Matic” were being used for.

Continue reading “Stepper-Controlled Chop Saw Automates A Tedious Job” →

Those Elevator Emergency Call Buttons Are Actually Pretty Janky

August 10, 2019 by Mike Szczys 26 Comments

We’ve all stared at that button in the elevator with the phone icon on it, supremely confident that if the cab came to a screeching halt while rocketing up to the 42nd floor, a simple button press would be your salvation. To be fair, that’s probably true. But the entire system is not nearly as robust as most people think.

Friday at DEF CON 27, [Will Caruana] took the stage to talk about phone phreaking on an elevator. The call buttons first appeared on elevators in 1968 as actual phone handsets, eventually becoming a mandated feature starting in 1976. Unfortunately, the technology they use hasn’t come all that far since. Phone modules on elevators did benefit when DTMF (touch tones) and voice menu systems rolled around. But for the most part, they are a plain old telephone service (POTS) frontend.

[Will] spends his spare time between floors pressing the call button and asking for the phone number. It’s the lowest bar of social engineering, by identifying yourself as an elevator service technician and asking for the number he is calling from. His experience has been that the person at the other end of the phone will give you that number no questions asked nearly every time. What can you do with a phone number? Turns out quite a bit.

The keys to the castle are literally in the elevator phone user manuals. The devices, shipped by multiple manufacturers, come with a default password and [Will’s] experience has been that nobody changes them. This means that once you have the phone number, you can dial in and use the default password to reprogram how the system works. This will not let you directly control the elevator, but it will let you speak to the people inside, and even change the call-out number so that the next time that little button is pressed it calls you, and not the phone service it’s intended to dial. That is, if the system was even correctly set up in the first place. He mentioned that it’s not too hard to find elevators that don’t have their location set up in the system — if you do need help, it may be hard to figure out which elevator you’re actually in. There have also been instances where these call the 24-hour maintenance staff for the building, a bewildering experience for sleepy personnel who didn’t sign up for this.

Want to go beyond the call button and dig deeper into the secrets of pwning elevators? [Will] suggests watching the HOPE X talk from [Deviant Ollam] and [Howard Payne] called Elevator Hacking: From the Pit to the Penthouse.

660 FPS Raspberry Pi Video Captures The Moment In Extreme Slo-Mo

August 10, 2019 by Sven Gregori 18 Comments

Filming in slow-motion has long become a standard feature on the higher end of the smartphone spectrum, and can turn the most trivial physical activity into a majestic action shot to share on social media. It also unveils some little wonders of nature that are otherwise hidden to our eyes: the formation of a lightning flash during a thunderstorm, a hummingbird flapping its wings, or an avocado reaching that perfect moment of ripeness. Altogether, it’s a fun way of recording videos, and as [Robert Elder] shows, something you can do with a few dollars worth of Raspberry Pi equipment at a whopping rate of 660 FPS, if you can live with some limitations.

Taking the classic 24 FPS, this will turn a one-second video into a nearly half-minute long slo-mo-fest. To achieve such a frame rate in the first place, [Robert] uses [Hermann-SW]’s modified version of raspiraw to get raw image data straight from the camera sensor to the Pi’s memory, leaving all the heavy lifting of processing it into an actual video for after all the frames are retrieved. RAM size is of course one limiting factor for recording length, but memory bandwidth is the bigger problem, restricting the resolution to 64×640 pixels on the cheaper $6 camera model he uses. Yes, sixty-four pixels height — but hey, look at that super wide-screen aspect ratio!

While you won’t get the highest quality out of this, it’s still an exciting and inexpensive way to play around with slow motion. You can always step up your game though, and have a look at this DIY high-speed camera instead. And well, here’s one mounted on a lawnmower blade destroying anything but a printer.

Continue reading “660 FPS Raspberry Pi Video Captures The Moment In Extreme Slo-Mo” →

A Keyboard Interface For Your SInclair ZX

August 10, 2019 by Jenny List 11 Comments

The SInclair ZX 8-bit computers of the early 1980s were masterpieces of economy, getting the most out of minimal hardware. The cassette tape interface was a one-bit port, the video was (on the first two models anyway) created by the processor itself rather than a CRT controller, and the keyboard? No fancy keyboard controllers here, just a key matrix and some diodes between a set of address lines and some data lines. The ZX80 and ZX81 were not very fast as a result of their processors being tied up with all this work, but it ensured that their retail price could break the magic £100 barrier in the British market, something of a feat in 1980.

A host of hackers still devote their time to these machines, and among them [Danjovic] has updated that ZX keyboard by producing an interface between that matrix and a PS/2 keyboard. As you might expect it uses a modern microcontroller board, in this case an Arduino Nano but it doesn’t stretch the imagination to think that a USB equipped board might perform the same task. It sits upon the relevant lines, and performs the necessary logical connection between them depending upon the serial input from an attached PS/2 keyboard. The project goes into some detail on PS/2 to ZX mappings, but perhaps of most interest is its explanation of the bus timings involved. The Arduino makes use of the ZX WAIT line to hold the Z80 and ensure that there is enough time for it to perform its task, it would be interesting to note whether or not this has a visible impact on BASIC program timing.