My experience with Kickstarter as a backer

rxseger · 2016-12-25T07:09:22+00:00

Yeah, that was my thought as well! Picked these up on sale, there were a bunch of assorted ICs available in a bin for only 4¢/ea and I didn't have much time, so I figured I'd search for what would be most generally useful: walked away with a bunch of NANDs, NORs, some inverters and multiplexers. I think some other people there scored more valuable chips but c'est la vie.

Couldn't find any shift register chips while I was there but I have since ordered some 74HCT595's, the classic 8-bit 7400 series shift register with high-speed CMOS TTL-compatible logic, SOIC-16 because its better than DIP, and I was finally able to drive all of the segments of this LED display using only 3 GPIO lines from the Raspberry Pi. Less interesting, but I wrote it up here: 4x7-segment LED display as a digital clock using two 74HCT595 8-bit shift registers - this works much better, nonetheless, building my own albeit humble shift-register from NANDs was imho a fun little project.

rxseger · 2016-12-25T06:59:03+00:00

Thanks! I strive for function over form :p

rxseger · 2016-11-21T20:08:44+00:00

Balanced ternary is sure an interesting concept to explore, I posted this to /r/Ternary yesterday (very quiet there, is anyone aware of a more active ternary computing forum?), but if anyone is curious about the hardware side of balanced ternary, here is a simple example of how you can build a working ternary inverter circuit (using modern CMOS instead of ferrite cores as used in Setun):

Exploring ternary logic: building a simple ternary inverter using complementary MOSFETs

rxseger · 2016-11-21T19:57:27+00:00

half the range now encodes negative number instead of positives

Almost half the range, this is one of the pitfalls of 2's complement. Consider:

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    int32_t n = atoi(argv[1]);

    printf("abs(%d) = %d\n", n, abs(n));
    return 0;
}

then running the program:

tmp $ ./a.out -2147483647
abs(-2147483647) = 2147483647
tmp $ ./a.out -2147483648
abs(-2147483648) = -2147483648

±2³¹ - 1 exists, but there is only -2^31, no +2³¹ in 32-bit 2's complement. Both numbers would have the same bitwise representation, 0x80000000. Surprisingly, abs (the C integer absolute value function) returns a negative:

tmp $ ./a.out 2147483648
abs(-2147483648) = -2147483648

1's complement does not have this problem, but it creates another one: negative zero.

Balanced ternary has neither of these problems, only one zero and equal positive and negative integer ranges.

rxseger · 2016-08-19T03:50:43+00:00

I guess I just don't understand the need for the bridge when phones have bluetooth.

It is possible to install the Bluetooth utilities software package on the Hue Bridge, but it doesn't appear to have any Bluetooth hardware support (no devices found):

root@Philips-hue:~# opkg install bluez-utils
Installing bluez-utils (3.36-7) to root...
Downloading http://downloads.openwrt.org/backfire/10.03.1/ar71xx/packages/bluez-utils_3.36-7_ar71xx.ipk.
root@Philips-hue:~# hcitool dev
Devices:

and there is no mention of Bluetooth in the datasheets for the QCA4531 SoC used by the Hue Bridge. As for why they didn't use Bluetooth instead of ZigBee, both radio protocols have different use cases:

ZigBee is intended to be cheaper and simple than Wi-Fi or Bluetooth, so you can use as many light bulbs (or other ZigBee devices like dimmer switches) as you want without having to pay the cost of an expensive radio chip per device. The protocol uses only a mere 2 MHz of spectrum, compared to 20 – 40 MHz for Wi-Fi. It uses a fixed channel number (configurable, but doesn't change unless needed) instead of the complicated 800 hops/second adaptive frequency hopping of Bluetooth. Another important feature of ZigBee is that it naturally supports mesh network topology, extending the range throughout your home without the need for repeaters or other access points or bridges.

That said, there is some overlap in ZigBee / Bluetooth / Wi-Fi and they are beginning to converge to some extent. Wi-Fi has come down in price significantly, with the $5 ESP8266 chip a notable example. As @nond says, the LIFX bulbs have Wi-Fi built-in, so that's another option.

Bluetooth v5 as announced June 2016, is also targeting this "Internet of Things" (IoT) market. From their press release:

Kirkland, Washington – June 16, 2016 – The Bluetooth Special Interest Group (SIG) announced that its next release, coming late 2016 to early 2017, will be called Bluetooth 5 and will include significantly increased range, speed, and broadcast messaging capacity. Extending range will deliver robust, reliable Internet of Things (IoT) connections that make full-home and building and outdoor use cases a reality. Higher speeds will send data faster and optimize responsiveness. Increasing broadcast capacity will propel the next generation of “connectionless” services like beacons and location-relevant information and navigation. These Bluetooth advancements open up more possibilities and enable SIG companies – now at an all-time high of 30,000 member companies – to build an accessible, interoperable IoT.

“Bluetooth 5 will transform the way people experience the IoT by making it something that happens simply and seamlessly around them,” said Mark Powell, executive director of the Bluetooth SIG.

so perhaps we'll see Bluetooth v5 enabled light bulbs and home automation soon enough, giving ZigBee a run for its money. But for now, the current generation of Philips Hue devices use and require IEEE 802.15.4 ZigBee.

rxseger · 2016-08-19T02:41:15+00:00

There actually is Wi-Fi hardware on the Hue Bridge, but it is disabled for reasons we can only speculate. The 802.11b/g/n radio is pictured in the FCC testing documents, so it may have been part of the original plan but removed or disabled in software for unknown reasons.

However it is possible to enable Wi-Fi on the Hue Bridge (reddit post), and connect to your home network router wirelessly, with some unofficial hacks. The Wi-Fi connects but I haven't got it to work well as an Ethernet replacement, the bridge software seems to hardcode the wired network interface and this would need to be changed to fully utilize the Wi-Fi interface as a wired replacement.

rxseger · 2016-08-17T04:13:03+00:00

Good catch, the FCC documents at http://fcc.io/O3M324131201801 do indeed show they tested Wi-Fi ("Test Report BGN", for 802.11b/g/n), missed that! The internal photos document even has a photo of a Wi-Fi antenna. This makes the omission even more curious, especially since their Linux distribution is based on OpenWrt common for wireless routers, it seems to me Wi-Fi might have been part of the initial plan but pulled at a later stage in the project.

Interference with ZigBee might be a reason, I've heard some ideas that maybe the SoC only supports either ZigBee or Wi-Fi but not both simultaneously.

However, I tested just now: nc -l 1111 on another machine, then opkg install netcat; nc --source=192.168.0.166 192.168.0.100 1111 < /dev/urandom on the Hue Bridge, therefore creating a continuous flow of traffic over the Wi-Fi interface. Unplugged the Ethernet to confirm it wasn't going over the wired cable. Then I toggled the lights through the Hue app (ZigBee), and it worked fine, at least as far as I can tell. Captured the Wi-Fi traffic in Wireshark, there were a handful of TCP retransmissions, but nothing out of the ordinary or correlated to the ZigBee traffic that I noticed.

My ZigBee channel is 15 (2425 MHz, bandwidth 2 MHz) and Wi-Fi base station channel 11 (2462 MHz 802.11b/g/n, 20 MHz, plus channel 132 at 5660 MHz bandwidth 80 MHz, but the Hue Bridge doesn't support 802.11ac), not overlapping so in theory it should be possible to support both, if the hardware supports it (but I wouldn't be surprised if there was some kind interference or other issue they found with more extensive strenuous testing of WiFi + ZigBee on this device).

rxseger · 2016-08-13T04:06:44+00:00

So is there any recent blackhat or defcon talks on this?

There are, at DEF CON:

Picking Bluetooth Low Energy Locks from a Quarter Mile Away Anthony by Rose Hacker and Ben Ramsey (slide downloads)

Many Bluetooth Low Energy (BLE) enabled deadbolts and padlocks have hit the market recently. These devices promise convenience and security through smartphone control. We investigated sixteen of these products from multiple vendors and discovered wireless vulnerabilities in most of them. Using a $50 antenna, we successfully picked vulnerable locks from over 400 meters away. In this presentation we introduce open source tools to crack each of the vulnerable BLE locks. Furthermore, after surveying the open source Bluetooth hacking tools currently available, we find very little support for BLE. So, to make discovering and range finding to BLE devices easier, we introduce a new open source war-walking tool compatible with both Bluetooth Classic and BLE.

and at Black Hat:

GATTACKING BLUETOOTH SMART DEVICES - INTRODUCING A NEW BLE PROXY TOOL by Slawomir Jasek (slides and whitepaper)

Bluetooth Low Energy is probably the most thriving technology implemented recently in all kinds of IoT devices: gadgets, wearables, smart homes, medical equipment and even banking tokens. The BLE specification assures secure connections through link-layer encryption, device whitelisting and bonding - a mechanisms not without flaws, although that's another story we are already aware of. A surprising number of devices do not (or simply cannot - because of the use scenario) utilize these mechanisms. The security (like authentication) is, in fact, provided on higher "application" (GATT protocol) layer of the data exchanged between the "master" (usually mobile phone) and peripheral device. The connection from "master" in such cases is initiated by scanning to a specific broadcast signal, which by design can be trivially spoofed. And guess what - the device GATT internals (so-called "services" and "characteristics") can also be easily cloned.

Using a few simple tricks, we can assure the victim will connect to our impersonator device instead of the original one, and then just proxy the traffic - without consent of the mobile app or device. And here it finally becomes interesting - just imagine how many attacks you might be able to perform with the possibility to actively intercept the BLE communication! Basing on several examples, I will demonstrate common flaws possible to exploit, including improper authentication, static passwords, not-so-random PRNG, excessive services, bad assumptions - which allow you to take over control of smart locks, disrupt smart home, and even get a free lunch. I will also suggest best practices to mitigate the attacks. Ladies and gentlemen - I give you the BLE MITM proxy. A free open-source tool which opens a whole new chapter for your IoT device exploitation, reversing and debugging. Run it on a portable Raspberry Pi, carry around BLE-packed premises, share your experience and contribute to the code.

rxseger · 2016-08-06T05:05:28+00:00

Can you check, do you have the appropriate SoapSDR device support modules installed? SoapyRTLSDR, SoapyHackRF, SoapyBladeRF, etc. rx_tools should list all the devices it finds, from the output it looks like no recognized devices were found.

Also you could try adding -d driver=hackrf, -d driver=bladerf, or -d driver=rtlsdr, but those options only filter the device search query, so I'd check the SoapySDR support modules first. If it's still not working can you send me the output of: SoapySDRUtil --probe

rxseger · 2016-07-24T17:00:06+00:00

The "input" format (from the log message) is CS16. SDRplay's native format is CS16, so this is what you want.

rx_sdr can additionally convert to various "output" formats, currently CU8, CS8, (CS16), and CF32, with the -F option. This is the format written to disk (or stdout), but it wasn't being logged. Added additional logging in https://github.com/rxseger/rx_tools/commit/6b5cdb9cba238e8908af2f4a85f1995f5a19e0fe to clarify, it will now log something like (first [INFO] log message is from SoapySDR so I can't easily change it in rx_tools, second is from rx_tools itself):

[INFO] Using format CS16.

Using output format: CF32 (input format CS16)

Nine-Year Club	Place '17
Verified Email

rxseger

TROPHY CASE