Apple HomeKit Accessory Development Kit Gets More Accessible

December 27, 2019 by Kerry Scharfglass 6 Comments

Every tech monopoly has their own proprietary smart home standard; how better to lock in your customers than to literally build a particular solution into their homes? Among the these players Apple is traditionally regarded as the most secretive, a title it has earned with decades of closed standards and proprietary solutions. This reputation is becoming progressively less deserved when it comes to HomeKit, their smart home gadget connectivity solution. In 2017 they took a big step forward and removed the need for a separate authentication chip in order to interact with HomeKit. Last week they took another and released a big chunk of their HomeKit Accessory Development Kit (ADK) as well. If you’re surprised not to have heard sooner, that might be because it was combined the the even bigger news about Apple, Amazon, the Zigbee Alliance, and more working together on more open, interoperable home IoT standards. Check back in 2030 to see how that is shaping up.

“The HomeKit ADK implements key components of the HomeKit Accessory Protocol (HAP), which embodies the core principles Apple brings to smart home technology: security, privacy, and reliability.”
– A descriptive gem from the README

Apple’s previous loosening-of-restrictions allowed people to begin building devices which could interact natively with their iOS devices without requiring a specific Apple-sold “auth chip” to authenticate them. This meant existing commercial devices could become HomeKit enabled with an OTA, and hobbyists could interact in sanctioned, non-hacky ways. Part of this was a release of the (non-commercial) HomeKit specification itself, which is available here (with Apple developer sign in, and license agreement).

Despite many breathless mentions in the press release it’s hard to tell what the ADK actually is. The README and documentation directory are devoid of answers, but spelunking through the rest of the GitHub repo gives us an idea. It consists of two primary parts, the HomeKit Accessory Protocol itself and the Platform Abstraction Layer. Together the HAP implements HomeKit itself, and the PAL is the wrapper that lets you plug it into a new system. It’s quite a meaty piece of software; the HAP’s main header is a grueling 4500 lines long, and it doesn’t take much searching to find some fear-inspiring 50 line preprocessor macros. This is a great start, but frankly we think it will take significantly more documentation to make the ADK accessible to all.

If it wasn’t obvious, most of the tools above are carefully licensed by Apple and intended for non-commercial use. While we absolutely appreciate the chance to get our hands on interfaces like this, we’re sure many will quibble over if this really counts as “open source” or not (it’s licensed as Apache 2.0). We’ll leave that for you in the comments.

Google Creates Debuggable IPhone

November 3, 2019 by Al Williams 8 Comments

Apple is known for a lot of things, but opening up their platforms to the world isn’t one of those things. According to a recent Google post by [Brandon Azad], there do exist special iPhones that are made for development with JTAG ports and other magic capabilities. The port is in all iPhones (though unpopulated), but is locked down by default. We don’t know what it takes to get a magic iPhone, but we are guessing Google can’t send in the box tops to three Macbook Pros to get on the waiting list. But what is locked can be unlocked, and [Brandon] set out to build a debuggable iPhone.

Exploiting some debug registers, it is possible to debug the A11 CPU at any point in its execution. [Brandon’s] tool single steps the system reset and makes some modifications to the CPU after key instructions to prevent the lockdown of kernel memory. After that, the world’s your oyster. KTRW is a tool built using this technique that can debug an iPhone with a standard cable.

Continue reading “Google Creates Debuggable IPhone” →

Apple Lightning Video Adaptors Run IOS, Dynamically Loaded

July 30, 2019 by Jenny List 28 Comments

Apple has for a very long time been a company that ploughs its own furrow when it comes to peripherals, with expensive proprietary hardware being the order of the day over successive generations of its products. One of its current line of proprietary interfaces is the Lightning connector, best thought of as an Apple-only take on the same ideas that the rest of the world knows as USB-C. There are a whole host of white dangly peripherals that can be hung from your iDevice’s Lightning port, including a pair of display adaptors that allow them to drive an HDMI or VGA monitor. [Lisa Braun] has subjected one that had failed to a teardown, and her analysis gives some insight into the way Apple creates its peripherals.

Where you might expect these to contain mostly the equivalent of a graphics card, in fact they have a fully-fledged SoC of their own that runs its own OS with the same Darwin kernel as its host. Unexpectedly this is not held upon the adapter itself, instead it is shipped with iOS and loaded dynamically. Thus the file containing it can be retrieved from iOS and unpacked, leading to some interesting analysis. In a fascinating twist for those of us unused to Lightning’s internals, it’s revealed that the device can be driven from a USB port with the appropriate cobbled-together adapter, allowing a full-size MacOS device to interrogate it. This many not be news to readers with a long memory though, we’ve told you in the past about reverse engineering the Lightning connector.

Open Source Computer Controlled Loom Weaves Pikachu For You

June 18, 2019 by Helen Leigh 17 Comments

The origin story of software takes us back past punch card computers and Babbage’s Difference Engine to a French weaver called Joseph Marie Jacquard. Jacquard created a way to automate mechanical looms, giving weavers the ability to change a loom’s pattern by simply switching punch cards. This invention not only made it possible to produce detailed fabrics in a vastly simplified way, it was an extremely important conceptual step in the development of computer programming, influencing Babbage’s development of the Analytical Engine amongst many other things.

So, when [Kurt] saw his son’s enthusiasm for weaving on a simple loom, he started thinking about how he could pay homage to the roots of software by designing and building an open source computer controlled loom. He knew this was going to be difficult: looms are complex machines with hundreds of small parts. [Kurt] wrestled with wonky carriage movements, cam jams, hook size disasters and plenty of magic smoke from motor control boards. After a year and a half of loom hacking he succeeded in making a 60 thread computer controlled loom, driven by an iPhone app using Bluetooth.

As well as writing up the story of this build on his blog, linked above, [Kurt] has also has made all of his design files, PCB layouts, firmware and code available on GitLab.

We’ve featured a few weaving hacks over the years, including this cheap, simple 3D printable loom and a Jacquard inspired bitmap display.

Fun, informative build video after the cut.

Continue reading “Open Source Computer Controlled Loom Weaves Pikachu For You” →

Does Library Bloat Make Your Smartphone App Look Fat?

December 18, 2018 by Tom Nardi 53 Comments

While earlier smartphones seemed to manage well enough with individual applications that only weighed in at a few megabytes, a perusal of the modern smartphone software store uncovers some positively monstrous file sizes. The fact that we’ve become accustomed to mobile applications requiring 100+ MB downloads on what’s often a metered Internet connection in only a few short years is pretty crazy if you stop to think about it.

Seeing reports that the Nest app for iOS tipped the scales at nearly 250 MB, [Alexandre Colucci] decided to investigate. On his blog he not only documents the process of taking the application apart piece by piece to find out just what’s eating up all that space, but lists some potential fixes which could shave a bit off the top. Even if you aren’t planning a spelunking expedition into your pocket supercomputer’s particular variant of the Netflix app, the methodology and tools he uses here are fascinating in their own right and might be something worth adding to your software bag of tricks.

By passing the application’s files through a disk usage visualizer called GrandPerspective, [Alexandre] immediately identified some rather large blocks of content. The bundled Apple Watch version of the app takes up 23 MB, video and audio used to walk the user through the device setup weigh in at 22 MB, and localization files for various languages consumes a surprising 33 MB. But the biggest single contributor to the application’s heft is the assorted libraries and frameworks which total up to an incredible 67 MB.

Of course the question is, how much of it is really necessary? It’s hard to be sure from an outsider’s perspective, but [Alexandre] notes that a few of the libraries used seem to be redundant or obsolete. In some cases this could be the result of old code still lurking in the project, but the four different libraries used for user tracking probably aren’t in there by accident. It also stands to reason that the instructional videos could be offloaded to something like YouTube, so that only users who need to view them have to expend their bandwidth on it.

Getting a little deeper into things, [Alexandre] notes that some of the localization images appear to be redundant. As a specific example, he points to the images of the Nest itself displaying Fahrenheit and Celsius temperatures. While logically this should only be two image files, there are actually eight copies of the Celsius image, each filed away as language-specific. These redundant localization images could easily be stripped out, but with gains measured in only a few hundred kilobytes, it probably wasn’t considered worth the effort during development.

In the end there’s really not as much bloat as we might like to believe. There were some redundant files, maybe a few questionable library inclusions, and the Apple Watch version of the app could surely be separated out. All together, it might get you a savings of 30 – 40%, but still not enough to bring it down under 100 MB.

All signs point to the fact that modern smartphone software development is just a lot more burdensome than us hackers might like. Save for projects looking to put control back into the hand’s of the users, it looks like mobile operating systems aren’t going to be slimming down anytime soon.

[Ben Krasnow] Gasses MEMS Chips, For Science

November 20, 2018 by Dan Maloney 61 Comments

Why in the world does helium kill iPhones and other members of the Apple ecosystem? Enquiring minds want to know, and [Ben Krasnow] has obliged with an investigation of the culprit: the MEMS oscillator. (YouTube, embedded below.)

When we first heard about this, courtesy in part via a Hackaday post on MRI-killed iPhones, we couldn’t imagine how poisoning a micro-electromechanical system (MEMS) part could kill a phone. We’d always associated MEMS with accelerometers and gyros, important sensors in the smartphone suite, but hardly essential. It turns out there’s another MEMS component in many Apple products: an SiT 1532 oscillator, a tiny replacement for quartz crystal oscillators.

[Ben] got a few from DigiKey and put them through some tests in a DIY gas chamber. He found that a partial pressure of helium as low as 2 kPa, or just 2% of atmospheric pressure, can kill the oscillator. To understand why, and because [Ben] has a scanning electron microscope, he lapped down some spare MEMS oscillators to expose their intricate innards. His SEM images are stunning but perplexing, raising questions about how such things could be made which he also addresses.

The bottom line: helium poisons MEMS oscillators in low enough concentrations that the original MRI story is plausible. As a bonus, we now understand MEMS devices a bit better, and have one more reason never to own an iPhone.

Continue reading “[Ben Krasnow] Gasses MEMS Chips, For Science” →

Helium Can Stop Your IPhone — Maybe Other MEMS, Too

October 31, 2018 by Al Williams 115 Comments

Sometimes hacking isn’t as much about building something, it’s about getting to the root of a particularly difficult problem. [Erik Wooldrige] was facing a problem like that. He’s a system specialist at a hospital near Chicago. Suddenly a bunch of iPhones and Apple watches were failing or glitching. The only thing anyone could think of was the recent install of an MRI machine.

Sure, an MRI machine can put out some serious electromagnetic pulses, but why would that only affect Apple products? Everything else in the hospital, including Android phones, seemed to be OK. But about 40 Apple devices were either dead or misbehaving.

Continue reading “Helium Can Stop Your IPhone — Maybe Other MEMS, Too” →