BSides Vancouver 2015 - Wesley Wineberg - Analyzing the EMU-2 Zigbee Home Energy Monitor

is a home energy monitor sometimes also called an in-home display it uh basically talks to your smart meter and shows you what the current readings are what energy you're using that sort of thing it does that by using the zigbee protocol to read data from your smart meter the device by itself doesn't record data or anything like that it actually just pulls it all straight from your smart meter so why did I choose this device to do a talk on at b-sides um turns out that the emu2 is one of only two devices that are approved by BC Hydro for people to use as a home area network device to connect to their smart meter

it also only costs 35 dollars so it's pretty accessible if anyone wants to just get one of these you do have to be a BC Hydro customer I believe before they'll sell you one but uh otherwise it's pretty cost effective and it's a fairly I thought representative device of what you kind of come across when you're looking at embedded systems and trying to consider their security it communicates to your PC over USB toxic V just seemed like it'd be a fun Target to look at so I mentioned that it's one of two devices approved by BC Hydro and I kind of was a little bit curious why that would be so I looked it up and BC Hydro

statement says BC Hydro requires vendors to go through testing so that we can ensure their energy monitors are compatible with BC hydro's metering system currently rainforest automation is the only manufacturer with devices that have been validated to work with BC hydros meters oh really uh zigbee Alliance says the zigbee certified program ensures that products built using zigbee function as expected and products from different manufacturers and interoperate with each other so one of them has to be lying um I don't know I think we can probably all agree that the only thing worse than paying for a certification is paying for one twice shouts out to anyone who runs a certification program foreign the other device that uh is also

approved is the rainforest automation Eagle um yeah I got some of the specs on it here it displays your real-time energy usage similar to emu2 but it lets you view it on a web browser uh it runs an internal web server it also can connect to reinforced automations energy View apps cloud so I thought about looking at this one until there's there I thought maybe that'd be a little bit too easy just because this is b-sides doesn't mean we have to make it that easy so I'm sure it'll be a fun Target if anyone else wants to look at it but I wanted a little bit more of it

so back to the emu2 the first the first thing we want to do when we're testing a device any device this device is look up what public information is already available and documented that might be useful to us from a security perspective there's no sense in making anything more black box than you need to um so I was looking for things like you know what technologies does this device use maybe how does it store any sort of sensitive data what what Sav um will it support firmware updates uh or firmware updates available uh all that kind of things and so what I found is that there's actually a pretty decent documentation on this device specifically there's a user manual a

quick start guide nothing really special on those though there's also a technical manual that's available off their website and it was actually really good had a actually had a lot of technical details instead of just claiming to be a technical manual and finally there is what they call the Raven XML API manual which is the manual for the command supported for the devices USB interface so uh read through the technical manual and it covered a lot of things that I'd already expected about the device you know communicates using zigbee supports the Smart Energy profile of zigbee um talks about how to power on your device that kind of thing one thing that it did mention that was kind of interesting was

this diagnostic mode so you can get to the diagnostic mode according to the manual by pressing both buttons on the device at once and which will put you into a configuration mode and then if you press those buttons again and hold them down for five seconds you get to the diagnostic mode in the diagnostic mode you can do a few different functions one of which is a device hard reset to basically tell the device to clear out every set of data and settings it currently has one screen then would show you the device ID the MAC address that kind of thing and then the last screen would show the device's link key so when I first read this I thought hey

that that could actually be really interesting that might be something that's valuable or something that you don't want easily to be displayed but it turns out it's not actually anything special so when we go through the zigbee section at the end of my presentation I'll talk a little bit more about the link key and how that relates to

so the Raven XML API manual documents how you talk to the device over USB turns out that the device is USB port is basically just a USB to serial adapter I think they require that you download the prolific drivers if your computer doesn't automatically find it and then according to the manual you just connect to it like a regular com Port um uh 115 kilobits per second default and I feel like I lost a slide oh no it's coming up and so then it says once you connect to that you talk to the device using basically XML formed commands and respond with responses so an example command from the manual is get device info and the example response that it says

you should expect to see is nice info clue including the device Mac address the install code and key and from information so that sounded like it'd be interesting so I connected it up tried it out and great I immediately started seeing XML data scrolling by as the device was pulling data from the meter and displaying it on the screen I could read data or send commands to it so as soon as I had that working the first thing that I immediately thought is okay well they've documented what commands are you supposed to send to the device uh how can we start abusing it instead so normally you could send a command like uh give the device a nickname call it

test but it's probably you know interesting to call it test 20 times so I sent that command down to the device and this was the response uh specifically note the nickname field and then the account field so this can't be good um at this point I decided okay there's there's clearly some input parsing issues which not surprised to see that's not a good thing but I should probably stop poking at it too hard because if I'm overriding from one field into the next on embedded devices fairly liked it that I'll just start overwriting into device memory and gotten started and it's gonna be really lame besides presentation so I moved on to to the next thing

um the reinforced automation uh to help people who don't want to pull up a Serial console and typo XML commands manually they provide some software called personal meter reader and it's basically free and lets you collect and visualize and see all the data coming from your home energy monitor maybe you want to I don't know I'm not sure what the use case was but it lets you pull down all that data the software supports both the emu2 and the reinforced automation Raven which is kind of like a USB dongle version of the emu2 for a fairly similar device and it communicates to either device over USB so since it's talking to the device over USB just like we were talking to it over

the serial Port I basically assume that it's using the exact same protocol but vendor software often will have interesting features that you don't otherwise have access to um as an example this application says that it supports doing firmware updates to the emu2 device firmware updates are always a area of interest when you're looking at a device's security but the first thing I wanted to start with was just looking for some hidden modes hidden functionality that might be in the application so I took a very quick look at it and I discovered that the application was written in.net .net just like Java is basically application reverse engineering on easy mode so I don't actually have a ton to say about

it but it made the testing go really quickly um uh opened the application using a tool called ilspy and basically decompiled the application and I immediately spotted there's going to be a few interesting command line Flags so one is debug and one is slash Trace and so on the screen here it's probably hard to see compared to my last slide but normally the application looks like this on the next one we've got two more options in the top bar one called show debug and one called Diagnostics um Jody bug is kind of pulled out to the right there and basically it gives you some information about what's happening lets you choose which commands to send

to the device um see the responses or put the application into a demo mode and Diagnostics mode lets you see all the raw commands that are being sent to the emu2 device and see all the responses and log them to a file if you like so since we already had the XML manual a bunch of these commands we already knew about interesting to see but not super useful but then I noticed there's actually some commands being sent and received that I I don't see an XML manual so next thing I want to take a look at is well what what commands does this application actually support so uh I continued digging through it using IL spy ieltspy is basically just

an open source.net assembly browser and decompiler it's based off of.net reflector which is now commercial closed Source tool back when it used to be open source you could just use it for free and so this style spy project kind of continued that as you can see in the screenshot here it really is just like browsing the source code of that Asian you get function names variable names the only thing you're really missing is comments from the source code but it makes it very easy to quickly get a handle on what an application is doing how it's parsing input what what function um so I started to look for how does it talk to the device and how does that

firmware update mechanism work and uh basically what what undocumented API functions exist my first rule of technology is basically that implementation never matches documentation so I wanted to see what else we could find it turns out there's 11 commands in the personal reader reader application that are used that aren't in the XML manual so here is a list of them and here's the rest of them so in this list some of it looked like just general commands get some meter readings kind of interesting but not super interesting uh image block and race PDM things like that they look a lot more interesting so I trace through it a little bit more and found that a

lot of these commands you don't you not only need to send a command name to the device but you need some additional options but once again since we can just more or less browse the application source code it includes all those options in there as well so here's an example of the image block dump command Cinemas block dump command I tried it out and sure enough it lets me read back what looks like the devices flash memory and reading through the application when you're doing a firmware update after you do the update it can then dump the firmware back I guess to verify that it wrote correctly and so it says that sector one starts at

zero goes till that address and sector three starts to further down and continues on so I considered just patching the application so that even though I'm not doing a firmware update I could still do the firmware readback but I figured it would be just as easy to make a quick python script to do the same so I got a script called serialdump.pi set it up to dump for me sectors one and three so I tried out the script and it actually worked great it's fairly slow because you have to send a fully formed XML command with a bunch of data and then you only get back 64 bytes of data at a time but sector one and three basically just

didn't look like anything useful is just a bunch of a bunch of zeros um looking back at the application the debug mode had a bunch of suggested commands and this was one of them and it said read at offset 40 000 instead so I did that and that actually returned some valid valid so I started reading around in that address range and was getting data in some parts and not others so I decided uh let's just do this Brute Force way and tell it to read 10 megabytes of data out of this device and see what we get uh and so sure enough I hit some data uh I'm gonna open this in wordpad for a

really exciting demo here

all right so I got a file basically oh it's on my screen but

uh screen extensions yeah we're getting there there we go maybe

uh comrade Alex told me that Hardware security demos are always kind of lame and reversing engineering demos are even worse I cannot disprove that I'm sorry so uh you're here's basically what I pulled down from the device it's clearly not just blank data but there wasn't a ton of readable data eventually through it I found some of let's see I found some of the settings we stored in the device found test

that kind of thing uh but I I basically was wondering okay have I actually retrieved the devices full firmware um started looking through it more and it looks like retrieve some of the strings from the device but a lot of the commands that I'd expect to see being parsed weren't there okay back to the PowerPoint

yes all right so at this point I'd kind of explored the USB interface pretty completely I'd explored the uh you know buttons that you could press is in the menus you could get to and it looked like there was an interesting functionality there it looked like I might break the device if I poke too hard at the interface so I decided it was time to move on to some Hardware analysis but a quick summary is basically that this device is pretty good documentation which is always helpful um parsing is going to be an issue and the debug and undocumented functionality lets us read or write firmware if we want to do that but clearly we're not getting the full

firmware so we need to we need to look more so next section we're going to talk about is basically how to do some Hardware analysis on a device um I'm gonna try and cover it from the ground up and go into some detail but there's a lot to cover at the same time looking at device Hardware interfacing to device Hardware is actually a lot easier these days than it was even five years and a lot of this stuff's actually quite accessible so before you get a device and just start tearing apart its Hardware it's always good to keep in mind what you want your goals to be uh publish often it'll turn out that it's much

easier just to look at device Communications or device software instead of going straight to the hardware so the things I was looking for is what kind of debug interfaces are going to be on the hardware can we actually get a full copy of the firmware we tried through software got some of it like definitely not all of it um can we get access to the devices stored memory we're seeing you know the nickname I gave to the meter and some other stuff but uh I had a suspicion that I wasn't getting the full complete set of data that's stored on the device and ultimately you know how can we take full control this device how can we how

can we get root even though it doesn't run Unix there's no root okay so uh with any uh Hardware security assessment the first thing I always like to do is uh once again look up what public information is out there the FCC filings is probably the first and best source of information on a device if it talks wirelessly in any way the link there take you right to the FCC lookup page it says it's outdated and don't use it but they can't stop me um you can also look up patent filings sometimes they have animation most of the time patents don't actually pretty useless and patents basically rarely match reality uh patents clearly are only ever filed for

defensive purposes to build company shareholder value uh manufacturing documentation is also sometimes available so similar to the technical manual or the XML manual sometimes manufacturers of components of the device will put out a bunch of documentation and then a company like rainforest automation might just then build that into the into their product but the manufacturer's documentation is also going to be really helpful and sometimes you can find information just off of a surprising variety of sources so sometimes there'll be an engineer at the company who's got a super detailed LinkedIn page of all the Technologies he used and all the challenges he faced and all the ways he solved them sometimes you can just Google for

information about the device and someone's posted hap at source code on GitHub it's always worth seeing what's out there before you go to all the hassle of actually uh tapping into the hardware and trying a bunch of things that you might otherwise not need to so I looked up the FCC filings this is what you get basically when you go to the FCC page I don't have a screenshot of it here but I always like to do a search by the grantee code which is basically tied to the company instead of the full ID so the idea you see there ycx RFA zed1052 you can just search for ycx and that'll pull up all the FCC filings from

reinforced Automation and oftentimes like you'll find that they've got similar products that have useful information as well or they've got some product them brought to market yet but they've register with FCC and so the main things from the FCC filing that are going to be useful are the devices internal photos external photos sometimes the user manual if you're having a hard time finding that frequency info if you're not already confident in what frequencies it talks on block diagrams and schematics are always useful but you're only going to find those on Old devices so devices probably from about 2000 and earlier uh generally have those available from that point onwards all companies request that they'd be confidential so you're

not going to get access to them of that full set the main thing I wanted to look for at this device was the internal photos basically photographs of the internal circuit board and the components that are going to inside the case of the device if you're lucky these photos will show the boards with enough detail that you can off the microchips and ID them if you're less lucky you might just be able to see if there's programming headers or serial interfaces or that kind of thing and if you're even less lucky you'll probably just be able to guess that it's a fuzzy picture of a circuit board hard to know what you're gonna get but for rainforest automation they

actually had pretty clear pictures this is what you can see when you go to FCC page and they've even got pieces of their circuit board labeled so you don't even have to guess you got the trace antenna up the top got some transmitter circuitry a little bit below it makes sense so I moved on to then actually opening up the device so this device was actually really strange normally to open a device the screws are hidden under the feet pads or something like that under a sticker this device you actually have to tear the front cover screen off and then under that the screws are hidden so that took a little bit before I figured that out

but it's actually relatively easy the the screens just kind of glued on it just peels off once you open it up this is what you're going to see this is my device basically the circuit board we've got the the two wires at the bottom there just uh connected to the battery pack that you can hook up and so uh once we see this we don't actually have to fully reverse engineer the PCB here really all we're going to want to do is ID the chips that are on there and Trace out how we can talk to them and so before I go further it's probably worth pointing out the the connectors the the through-hole pins

that you see in the middle there when the device is fully assembled they're actually accessible through the battery compartment in the back so getting access to those you don't even have to open the device up if you don't want to they're just right there on the back side or front side I guess depending how you look at it of the device the LCD is actually just soldered right on so I thought about tearing that off but since I looked at FCC filings I knew there was going to be nothing exciting under it anyways so I just left it there so next I basically I'm gonna get gonna talk through what i what you want to

look for on this board and then I'm going to give a quick summary of what each chip is so when you're looking at a circuit board like this you've got basically traces between the components this case they're lighter greens surrounded by darker green um you've got the external connectors on the left side there the micro USB and a USB and the AC DC I guess power adapter um other than that the only real connectors the outer header into are in the middle there and they're actually labeled so that's the other thing you want to look at is basically what are all the various labels on the on the circuit board that says ecosmarter technology rainforest automation so you know maybe

we look up who we call smarter technology is I did a quick Google it just sounded like the same company nothing too interesting there um the MAC address sticker there is kind of interesting it looks like they just printed it off of a label maker which kind of implies that they got a pretty limited production process that they're not doing a lot of this stuff automatically but some guys actually printing off the label one by one um and that's really it like there's a lot of other things we could look at if we were trying to you know clone this device or do other things but we're just interested in what Hardware is there how

do we talk to it so going from left to right the first chip is the prolific 2303hx and so that is the USB to serial adapter chip basically it connects to a USB port and outputs serial for you makes it really easy it's a very common chip doesn't really have any logic Beyond doing that conversion the next chip is the wind Bond 25q blah blah it is a one megabyte flash memory chip and so the way we know what each of these are is basically you take the chip markings put them into Google see what datasheet comes up almost always you'll get a hit as to what the device is and usually they'll have much

information about each device so now we know that the device has one megabyte of flash memory the next chip is an RF access basically uh modulationship and it says it's specifically designed to work with zigbee Communications to modulate the data you're sending out wirelessly which makes sense because it's connected directly to the trace antenna on the circuit board the next chip is probably the most important one on the board it's the nxp or genic basically genic made it nxp blogenic the jn5148 and so this is the main processor on the device looking up the data sheet for this it's specifically designed to support zubi Communications and a bunch of other functionality related to that so I'm actually gonna

go through a few of the features so the data sheets public and covers all the all the useful information that you're going to want to know about the microcontroller some of the key points are that this is a single chip that integrates both the microcontroller running program logic as well as the as well as acts as a transceiver to send out the actual zigbee packet data has a 32-bit risk CPU it can run up to 32 megahertz has 128 kilobytes of ROM and 128 kilobytes of RAM bootloaded program code and data it also has an AES security processor which is going to need to do zigbee and supports JTAG for debugging finally the last chip here is the ti 74l

v08a and I actually had a hard time finding a data sheet for this chip until I realized that it's actually just a TI clone of another chip and despite looking big and interesting it's actually just a dumb logic chip that does four and operations depending on the input you give it so it's not worth considering at all so those are the chips the next thing we want to know is how do we how do we communicate to these and we kind of know how we talk to the USB to serial chip just over that USB port the only other interesting one then is the jn5148 microcontroller and so I looked up the pinotes on that controller and compared

them to the connector interface in the middle here and I found that the labels are actually completely correct so the various pins you can you can test to see if they're wired to something by just using a multimeter and doing a continuity test which basically sees if voltage can go from point A to point B on your probes so if it's you know pin five on the chip you put one Probe on that and then put the next Probe on the pin that you're wondering if it connects to and if you if your thing says there's a connection and have a pretty good level of confidence that that's where it gets routed to um the labels in this case just made

that a whole lot easier so what we can see is on the right side hopefully you can see it I don't know um in the right side there's uh a number of pins miso ground spy clock mostly SSM all of which are going to be used for spy Communications SPI on the left side there were some pins labeled io4 five six and seven and so I looked up the data sheet and basically I O pins four five six and seven are either mapped to serial I receive and transmit or they're mapped to the JTAG debug interface I read then a little bit further in the data sheet and basically it says the reason they're mapped to both is you can

either have serial output enabled or you have JTAG debugging enabled all right I think I need to go faster uh so what are the tools that you need to do this what are the tools that I use to do this so if if you got your company's budget to spend or got money that's bringing a hole in your pocket you can buy probably I guess a proper set of tools but you don't necessarily need to do that if you're just kind of interested in playing around with this getting a start on it there's always a lower cost option so you're going to need a soldering iron one way or another even if you don't want one

um so if you're gonna you know spend the company's budget spend a few hundred dollars maybe 500 on a really nice soldering iron if you want to do it yourself just get a 25 one from Home Depot that'll make your life a little bit more difficult but it'll work you're going to need a multimeter you can spend ten dollars and buy one at Home Depot so that's what um or you can actually get a proper one and buy a 500 fluke um the next thing that is going to be useful is a logic analyzer it's basically like a way more limited oscilloscope uh little signals you can spend 600 and buy a pretty nice one uh

connects to your computer and get Standalone units there's a bunch of options on the other side of things you can spend thirteen dollars and get a say the logic knockoff or spend thirty dollars and get a logic pirate which is probably a lot more legit than buying a knockoff finally the last thing you're going to want is a Serial TTL cable so normally when you connect to a Serial port on a computer serial ports they'd run at a higher voltage and signaling rate than than serial TTL which runs at a lower voltage so you're going to need a different cable ftdi makes a cable that does this um that I know people have been hating on

ftdi lately but I actually think it's pretty awesome that a company decided to go out and break all their competitors and lock off devices I mean people complained about it but it's like complaining about downloading Hot Tub Time Machine 2.avi.exe and getting virus I mean you wouldn't download a car ftdi also makes a cable that can interface with a spy jteg and a bunch of other protocols they got two cables they basically look the exact same they use the same microcontroller internally but pins on them broken out so one version of it has the serial pins one version has the jtakes by whatever other pins I got both uh you can get a ton of

different jteg programmers potentially though so whatever whatever is going to work best for you and the last thing that you usually need I didn't in this case but usually you're going to need a bench power supply to actually power the unit instead of just running it off of there's a ton more tools that you can buy if you got budget to spend and you need them but these are some of the basics that you're going to want to have okay so software tools I'll go quickly through this the you don't actually need to go too crazy when it comes to Hardware analysis there's a lot of Open Source tools that you might want to use

wordpad for data visualization there's this program called Binary Editor bz that uh VZ we're in Canada that lets you visualize uh hex output that a device might have so that was kind of useful to me too I don't actually know its history it's made by some Japanese organization but as far as I'm aware Japanese only have cyber weapons for defensive purposes so it's probably not going to be a virus um there's also uh something that you're gonna need to interface to your logic analyzer so there's a tool Suite put out by sigrock you could also use the saily logic analyzer if you've got that there's a few options and last for the ftdi cable you're going to need to use

lib MP SSE um it's a quick question who knows what this is in HEX show hands uh hoping for more hands you guys gotta work on this that's oxf so I mean you could use a hex editor you probably should use a hex editor but sometimes wordpad's great so I connected up to the serial Port as you can see here I did a fantastic job of soldering on jumper cables instead of a proper header it worked pretty good I was pretty happy with it um so I connected to serial ports wanted to see if they were actually JTAG as one of the options but it turns out they're just serial when you talk to the device

over USB it spits out the exact same things coming out this port so sadly we didn't have a JTAG interface to use there um the Spy bus I hooked up my logic analyzer intercepted the communications had to play around with it a little bit but otherwise it worked pretty good um at the bottom there if you're using Sadie logic once you capture all your data you can export it and then you just got to transform it a bit so there's a command there that I found pretty useful but basically around the device from boot to see if it would read all the flash memory and I could get access to the full device firmware but what I've

discovered is I got the exact same thing as when I read it out using my script over USB still looked like I was missing pieces of it or something was going on so I decided the next thing to do is uh go back to seeing if we could just talk to the nxp chip directly instead of looking at the Spy Communications so the jn5148 according to the data sheet has a bootloader and with this bootloader you can then switch the chip into programming mode and to do that basically all you got to do is pull the Miso pin down to the ground when the device boots up and instead of booting it'll drop into the

bootloader they have a kind of a custom tool to do this but all you really got to do is hold one pin on the other while the device boots and it's good to go so I ran their flash programming software held down the pin and uh was pleased to see that it actually worked we can talk to the bootloader their software you might be able to see it now maybe not but at the bottom it read back my device's Mac address so I knew it was talking properly but then I started to be concerned because Under The Flash field gets kind of cut off because their software is messed up but it says device ID 13 brackets encrypted so what what

does this encryption mean uh I thought hmm you know maybe maybe it's maybe it's lying you know who who actually puts encryption on their device these days no one so I moved back to spy again and instead of just capturing the input I thought that's that's read it directly so I used the ftdi cable instead of a logic analyzer told it to read the first three megabytes even though it's a one megabyte chip uh but once again exact same thing just repeated three times because I read three megabytes so now it's starting to feel like maybe it really is encrypted or maybe it's possibly compressed uh I went back to reading more documentation and discovered that there's the application

called the genic encryption tool and it says you can use it to encrypt a flash memory and it's especially recommended for devices implementing zigbee Smart Energy so now I actually decided you know maybe maybe it really is encrypted so what are we going to do about this um check the header for what we'd read back check the spec it says hey you'll see a you'll see a boot record you'll see the MAC address you'll see the IV sure enough in our image dump which oh you could probably read um had the magic value had the MAC address on the top right and then had the IV which turns out to be underscore rainforced underscore I suspect that reinforest automation is

one of those companies that thinks IV stands for invariant Vector instead of initialization Vector uh uh I guess it could be worse the stuff was still encrypted and according to the docs the encryption key is stored underneath fuse on the chip that you can't just read back directly supposedly so uh at this point it seemed like the next piece software wasn't going to help me it wasn't reading back anything useful there's another programming tool called Atomic programming that can apparently read more memory but you got to buy their Hardware so I just searched on Google what else is available and I can across this application called genprogue from the University of karlsru and usually using stuff off people's

GitHub pages is not worth the effort but this was just a python script so I thought I'd give it a try patched it to work in Windows and dumped flash memory but once again flash memory still encrypted so I decided Well you know the bootloader seems to be giving me some options giving me some success what other commands or functionalities there the Gen progue referenced the bootloader operations document which I read through and uh discovered that there's definitely some undocumented commands being available and used um but you know I mean what about the ones that are just in this document and so we've been reading from Flash the whole time but there's actually the option to read from Ram instead looking

at the Gen Pro application it had that functionality built in it just wasn't uh it just wasn't actually tied out to doing anything um looking at the data sheet it says when the bootloading program executes or starts up it reads in flash memory automatically decrypts it for the application to run the user program doesn't need to handle any of this so reading between the lines it sounds like the bootloader reads in from flash memory takes the encrypted image pulls the key from e-fuse decrypts it and it's got to go somewhere so it decrypts it into RAM so I made some updates to the Gen prog scripts that it could actually read from Ram save it to a file told it to read a

megabyte of RAM and I actually ended up with some new data so that was exciting to see but it was still just kind of junk data I look back at the data sheet which are Super useful and it said hey you're actually supposed to read from Ram at oxf000. so I tried that next and I still just got Junk data but that was starting to make a lot more sense because the device needs to run the bootloader to get the program code stored into round before there's going to be anything interesting there so I powered on the device and then pulled the Miso line low so I dropped back into the bootloader after it had

already booted up uh and I had success instead of getting back the encrypted firmware image I got back a completely different set of data so this is where my bz editor comes in to do some big data visualization we've got like almost a billion bits here so it's clearly some pretty big data and as we can see in the top right corner that I mean that clearly looks to me like a interrupt Vector table I don't know about you guys um but basically it turned out to be the full firmware image as well as all the stored data a do a cool wordpad demo now but I'm getting pretty high on time uh what did I find in this though I

found some interesting bonus commands so we knew about the commands to read back the firmware I found a few others that weren't documented including getting some meter attributes which didn't turn out to be too interesting the race halt which sounded terrible so I didn't run it and this command called secret which is still actually a secret to me you send it and the device just does nothing but clearly it's doing something otherwise it would tell me it's an invalid command so it's a it's a area for future research I guess normally what we do at this point now we've got the firmware image is we try and reverse engineer it decompile it figure out what

we could um the processor using this device is somewhat obscure so I don't think there's even going to be a processor module in Ida Pro for it but it is just based on the open risk architecture so figuring out the op codes and making your own disassembler probably wouldn't be too much effort but uh uh I wanted to look at communications next so that's what I moved on to so The quick summary is basically the serial pins they're mapped directly to USB they're not too interesting but the remainder of the pins that are accessible on the circuit board are mapped to spy which you can uh intercept data on but it's going to be encrypted

you could read The Flash chip directly and it's going to be encrypted um otherwise you can go back to those serial pins and access the bootloader instead if you try and read backflash it's going to be encrypted but if you read back Ram it's not encrypted you can get the full firmware image so I'm going to try and go through zigbee really fast um but I think that'll be okay so zigbee is a standard for low power Mesh networking runs on 2.4 gigahertz just like Wi-Fi it runs on top of a protocol called 802.15.4 which is kind of a spec for wireless devices that use low power a lot of different other applications are written on top of it

not just like B there's six low pan Isa 100 a few other ones um it's a it's a protocol that really takes the OSI model to Heart it has layers and it has more layers and it has more layers um and it's got a few different iterations so zigbee isn't always zigbee there's like 20 frames of it uh that's what it looks like there's layers um the the one thing you need to know about zigbee is it's a lot like Bluetooth there's uh application profiles so uh similar to Bluetooth has you know hands-free advanced audio distribution a bunch of other ones zigbee will have a bunch of protocols that are profiles that it supports and

I've got a list of some of them here the one that we're going to be interested in is the Smart Energy profile so smart energy is an application profile and it defines a bunch of functions that your device can or should support including price demand response metering messaging and so on uh one of the ones that's going to be important to us is the key establishment cluster and the over there upgrade is just kind of fun to it so what previous work has been done on zigbee there's actually been a lot of interest on zigbee zigbee kind of Hit the mainstream around 2000 I guess so people started looking at it started looking at the security of it and

various things were found so a lot of weaknesses were found in certain zigbee profiles uh I'd pull zigbee home automation it does key exchange by taking a fixed key encrypting your new session key with that fixed key that's shared among every single device in the world and ta-da you've got your security key exchange except obviously since everyone knows the fixed key in the world that everyone uses not accomplishing anything um eventually someone made a framework called killerby actually if you guys made it and it's basically a collection of scripts as well as some firmware that you can load onto the device that let you analyze zigbee Communications in a bunch of different ways so what tools you're going to need if

you want to start talking zigbee there's actually a bunch of tools for doing ZB Communications these days that are fairly low cost there's the atmel RZ USB stick which is quite popular atmel has a little bit of a scam going where they program firmware onto this thing that's completely useless so you need to buy a programmer from them to reprogram good firmware onto it uh but the programmer is only 50 bucks too if you get their dragon otherwise there's a bunch of commercial ready to go Solutions let's uh that'll all do a good job of being able to capture and potentially transmit data as well um I decided to go with the atmel RZ USB

stick because it works great with the killer bee framework um although the killer be firmware for it is actually kind of terrible so you're going to want to use the Wireshark firmware that that Mill puts out instead generally um so what does this let you do you can load the Wireshark firmware on it and basically plug it into your computer and Wireshark will now recognize it as a capture device and you're capturing just like you're capturing off ethernet um Wireshark turns out to actually have fantastic support for zigbee decoding these days so it's a really great way to start getting a handle on what's actually being sent out so if it was if that was all that would

be great but probably not great from the Security's perspective so even though we can capture data all of the packets sent using zoopy Smart Energy are going to be encrypted and they're actually encrypted using two different encryption Keys one is the network key and one is the application link key uh to to get those keys from say your smart meter and your rainforced automation device to each other um devices have an install code and it's install code is printed on the back of it um usually printed on the back of a device and that code basically maps to an encryption key uh part of the install code includes a check sum the remainder of it you take run it through a hashing

algorithm which is public and you'll end up with the first encryption key used to start your key exchange process um and so the pairing process this is straight from the manual basically you send a join request you join to the coordinator it will then send you the network key that you're going to use and it's going to encrypt it to your install code you then take that key uh send a new request and tell it that you want to talk to the key establishment cluster to perform the key exchange to get the final application key so you've got all the keys needed and I've got a diagram here that basically shows that a little bit more clearly

uh this diagram straight from the nxp documentation actually um so what what are these encryption Keys actually used for how does that technology work uh zigbee uses AES ctm's CCM star that's like the actual name of it um to encrypt uh or authenticate packets um AES is obviously a symmetric Cipher CCM star is the block mode it's up to then each application profile and to some extent the devices themselves what encryption mode they Implement zigbee Smart Energy uses mode 5 which means that packets will have the payload data encrypted and there'll be a 32-bit message Integrity check value also applied so packets will basically be both encrypted and authenticated which is exactly what you want to see for a

wireless protocol um so if we want to do encryption or decryption of this traffic the process basically involves knowing the calculating a nonce value taking the encrypted data and taking the decryption key running those all through the algorithm and getting the decrypted output if you want to also then perform the mick validation check you're also going to need to need to have access to the packet headers because it covers the entire contents of the packet so nothing can be spoofed so the nonce calculation is basically pretty straightforwards it requires the source address of the device sending the packet the frame counter value which is in the header and the security code control flag which is also in the header

um the security control flag you can't just take it straight from the header of the packet I spent a bunch of time trying to figure out why nothing was working in my code and it turns out the zigbee spec at some point in time decided hey devices should no longer tell people what security mode they're using because that's giving away too much information or I don't even know it seems kind of crazy but they decided take that out and instead the receiver the transmitter should just know to once they've received a packet xor it with the proper mode which in this case is five so you need to take that xor and then you'll have the valid nonce you won't have the

valid nons if you just leave that part out um so all of this actually sounded pretty complicated like I said I spent a much time trying to get it working and you know is there just actually a library we can use to do this for us um the answer is yes and no uh Wireshark has a fantastic zigbee decoding like I said but Wireshark isn't exactly a tool for uh you know uh generating packets and making doing all kinds of weird decryption checks and stuff it's it's there to analyze um there's also a bunch of libraries available but they're designed or put out by the companies that make the microcontrollers that talk zigbee so you

can't run them on your computer you could run them on the jn5148 or things like that but but not actually very accessible so the next thing I looked at was the killer bee framework since it has a lot of functions that are useful when you're trying to do zigbee security analysis um the killer bee framework basically extends scapey which is uh protocol parsing and generation tool I guess I'd call it um and that actually is really useful but it also has some limitations and basically the zigbee protocol supports a bunch of different ways to form and send a packet and it's actually quite complicated to cover all of those ways which is why I was kind of impressed that Wireshark

does such a good job um so the killer bee framework actually is only compatible with a few of those the other like big downside for me at least is that it doesn't that is that scape he doesn't work in Windows and Killer B is based on scapey and Escape he's terrible for not working in Windows someone should tell them so uh we could use the killer bee libraries but they're going to need some patching so I decided to think about what are what are my goals going to be when I'm doing this so basically I can intercept traffic but I'd like to be able to decode and decrypt that traffic to see what's really being sent to do that I'm

going to need the required encryption Keys the link key and the application key and finally I'm going to need to or I'm probably going to want to start generating traffic of my own uh send it to my device see how it processes it so I'm going to need to build some of my own scripts and tools to do that so I thought about some options tried some things decided the best thing that is probably going to work is to patch killerby uh even though it doesn't work on Windows and um then in doing so I realized that a lot of the decryption functions in killer bee are actually just stolen straight from Wireshark they made a python

bindings for the Wireshark C library and just started using it that way which I thought was actually a great idea so if I'm going to make some applications I could do the same and in the killer bee framework there's a tool called ZB good find which uh follows a great idea and strategy which is we're looking for encryption Keys we've got a memory dump let's take every possible value from the memory dump try it as an encryption key see if it works the problem is that ZB good find is designed to work against the 802.15.4 layer encryption uh years they also have their own types of decryption and so that's not the type of decryption we need so I needed to kind

of take that functionality but make it for zigbee Smart Energy so uh looked into doing some killer bead patching there's actually a library that already covers some of this um and as I started doing it I realized you know my patches are just as bad as the stuff that's already there in killerby uh it works but it's still pretty terrible um and I also discovered that it's actually really hard to get any reference data to use for this no one has posted like zigbee packet captures online that include any sort of useful encryption or decryption stuff so it actually made it really tedious I'm gonna look at see if I can get my device to rotate its keys after

this and see if I can post my Wireshark captures because I think it'd be really helpful for anyone who's trying to explore this more so one of the things I learned as I was going through the patching process is that zigbee devices often leave out data fields this I guess helps save space on the air it's a low protocol so that makes sense but what I discovered is that um you're required to restore them before you continue processing and so that that's right you got to take packet data that wasn't there write it back into the packet and then do your decryption and then do your method validation calculation which I would I would think if you're

validating your message you want to validate the message you received not some message you reconstructed so I I lost a few hours on that But ultimately I got to a script I called it Zed zigbee network key finder basically like I said takes your memory image takes the data you're trying to decrypt I patched it so it doesn't use scapey you just copy paste some values from Wireshark directly into it so I can run on Windows made me happy and give it a try uh and boom success took about five seconds to run got right down to the bottom of memory and told me that it found the packet since we have the mick validation check we know for sure that

it really is decrypting it so there's no guessing um so I took that put it in Wireshark and it worked but as soon as I decrypted that layer the final layer was the application security layer and it was still encrypted as I expected because you need two keys so there's this uh whole process we're doing the key exchange and derivation uh there's um certificates that get issued to each device to kind of validate which devices which tied to the device's MAC address and it turns out that there's a company called certacom now owned by Blackberry I believe and they somehow patented the technology that's used to do this encryption process and also became the only CA for all zigbee Smart Energy

devices uh so I guess they paid someone off to do that um I don't know you'd kind of think that a Canadian company would be a little bit more honorable than to run a sham certificate selling business but booster to come but that all sounds pretty complicated I'm running out of time like what can we do here right what if what if that final key that gets exchanged after all that certificate process is just stored in memory so took all the data put it back in my script ran it and success right at the start of memory we've got that key and so uh the the interesting thing to note here is that these are symmetric keys so

this is this is really all I'm going to need and I'm going to show this in Wireshark right at the end but I'm just going to go through slides first um basically put it in and we've got the network layer it decrypts successfully and we've got the application support layer it decrypted successfully so it's a symmetric key which means that we can pretend to be the emu2 device to the smart meter because the key we could also pretend to be the smart meter to the emu2 device so I pretty much hope that itron zigbee packet parsing is pretty solid because BC Hydro I think is expecting that you can only ever talk to the device if

you're an emu2 or a reinforced automation Eagle but now that we have the decryption Keys we can send anything we want um I haven't done any testing against my smart meter I'm not saying that you should but that option is definitely available consult your lawyers or whatever I'm just the technical guy so in summary zigbee packets have a ton of layers there's tools out there but they're pretty scattered and can be hard to use zigbee Smart Energy in general does a pretty good job of key exchange and security it's not like the home automation profile it's actually a lot more solid I didn't see any flaws in its techniques but the the thing to always remember is

that if you've got an endpoint device that a customer has chances are they're going to be able to pull those keys out so with symmetric keys with symmetric Keys you're never going to be able to know which side is which once someone has grabbed those keys sign certs aren't going to help you if you can just go direct to the Keys so I want to wrap things up because I definitely don't want to hold people up from lunch but basically in conclusion we looked at this device from a bunch of different angles software Hardware Communications um debug modes were useful for pretty much all of those zigbee as a Smart Energy zigbee Smart Energy is as a protocol is

pretty decent even if it's pretty hard to work with pulling encryption keys from endpoint devices in case you were wondering is always pretty much completely possible electric utilities should not expect that just because they've said hey you can only use a reinforced automation device to talk to your smart meter but that's actually going to be enforceable so I don't know if we have any time for questions I gotta know but I'll be around come find me contact me anytime what's at synac find me on the twitters

and all the tools that I kind of showed here are going to be available at those links thank you

our lunch is served out there and around 12 30 we're going to do another raffle for the pros and VIPs uh bit9 is going to do a little bit