(tl;dr - If you are using a cheap smart watch, probably don’t. If you want to skip to the juicy bit jump to “Authentication”)
As with most complicated things in my life, it started with a simple question.
Do you know how to get the data off this watch?
Surely there’s an export feature in the app to a common file format like GPX, TCX or FIT. That’s pretty standard. Yet we couldn’t find a way. The only share and export functionality just provided an image with some stats on it.
Also given Android’s lockdown on the file system (to the point that you can no longer backup your phone!) there was no way to access the DB to obtain data (without root anyway).
Investigating the Ryze Android app I quickly discovered that this is a white label of an IDO smart watch.
It got me thinking - could I pick up one of these watches for a lot cheaper to play with. Eventually I landed on searching Amazon. The hardest part was working out if it was actually an IDO based device. I discovered what worked well was looking for watches that use the “VeryFit” app which is the IDOs stock app. There’s actually a bunch of watches that use this app. I found one for a low price of $39 (AUD) and free next day shipping.
My partner however was a little confused. The watch came in some shiny packaging without mentioning its brand. To be honest I’m pretty impressed with what you can get for $39 these days.
Hilariously I paired my IDO watch with the Ryze app and it just worked fine. I wasn’t actually expecting that to work but it seemed ok with it.
Would I buy one? yes - as a Bluetooth Low Energy reverse engineering example device otherwise no. Onwards to reverse engineering!
To the cloud
The first thing I looked at was syncing data from the cloud. This was pretty easy and basically just required following the same request flow as the phone. It however has some drawbacks, you still need to use the app, and you need to have an account. I didn’t really progress any further with this - but it is a viable way forward with those limitations.
Getting data off watch directly
I’m going to skip past dealing with authentication for the moment as that gets a little spicy and we don’t want to ruin the standard story telling plot framework.
Once connected and authenticated the device presents a bluetooth service at 0AF0 which provides several characteristics. The import ones to us are a subscription to 0AF7 - this is where data from the watch to the phone is sent while 0AF6 allows us to send commands.
adb logcat and BlueSee.app were lifesavers here. The app logs a lot of information about what its doing and how its working. You can pretty much work out everything from using the app with adb logcat running then emulating that flow with BlueSee.app. Also what helps is that the developers seemed to have a scattering of their documentation and source code on GitHub and some of the other vendors shipping these have done the same. Not all the source code is available which would have made reverse engineering just a little bit easier but its a good start.
So we send commands by writing to 0AF6. The easiest first set is 0x0201 which provides some basic device info. The device will write back to 0AF7 with the returned data. For these 0x02.... commands the return data will be structured like:
Getting activity data we need to use the “v3” protocol. These commands have the first byte a 0x33 or “3” in ASCII.
The v3 protocol can have data be split over multiple transmissions - a requirement of using this style BLE. So that the watch and phone can know that a new command has started rather than a continuation there’s a preamble DAADDAAD. This is just an utterly weird design choice given all the other features in BLE that could have been used. There’s then a service selectorish thing, length, command, sequence fields, followed by data and eventually a CRC.
To send a request to get the last activity I use the following command:
0x33 - '3' version protocol
0xDA - this is preamble to detect new command midway through
0xAD - preamble
0xDA - preamble
0xAD - preamble
0x01 - health?
0x10 - length (without '3' and checksum (last two bytes) - aka minus 3 on single packets)
0x00 - length
0x04 - cmd
0x00
0x0B - sequence - can just pick anything
0x01 - sequence
0x00 - start / stop
0x04 - cmd
0x00
0x00
0x00 - checksum
0x00 - checksum
Checksum calculation
I think its just some sort of CRC16 however I’m not sure which because the device I have never checked it so I never bothered working it out.
V3 return data
The return contains much of the same header. You can use the sequence numbers to line things up with you have to handle queueing of data and multiple requests.
Activity data is nearly always split over multiple packets so just read in the subscription until the data received matches the provided length in the header or until you see another preamble.
Then its a matter of unpacking the data. Noting that you’ll have arrays of varying lengths.
You might be thinking that this protocol will be stripped down to save transfer speed, however the protocol sends stuff like pace in several different units.
Online activity downloader
I built a really rough and dirty website for talking to my device and getting the health data off it. You can play around with it at https://sprocketfox.io/ido/. It’s happy path’d for my $39 crappy watch so probably won’t work for most people. It generates a TCX file that can be used on Strava or Garmin.
Authentication
When I originally paired the device I scanned a QR code on the watch. Turns out this probably just had the mac address on it or something because after several hours of getting device info and pulling activity data I realised that I had never performed any authentication step. Resetting the app and repairing also revealed that there's no pairing code. Nothing. The device isn't locked or secured once connected. Anyone can connect to the device at any time and start issuing commands.
You can pull activity data, sleep data, heart rate data, menstrual data. You can perform firmware updates. I don’t have GPS in my version of the watch but I bet you can access that as well. Whatever you want you can get it - there’s no protection. I can only test with my watch, but I suspect this applies to most devices that have been white labeled.
The watch I bought off Amazon has 5000+ ratings and the VeryFit app has over 5 million downloads. There’s 10k Ryze Connect app downloads according to Google Play. From what I can tell Cove, BoAT and bfit Move are also using the same app/protocol - I imagine there is a lot more as well. These are sold in retail stores like JB Hifi and Harvey Norman. There’s even kids versions of these watches which adds to a creepyness factor.
I pondered about how to disclose this and decided to go with the “fuck it” approach. The reasoning is that it’s going to be hard to find all the different vendors to let them know and I suspect they won’t care. I just don’t have the time go talk to AI chat bots, lodge support forms, have support people not understand my concern, have multiple generic replies saying “it’s not an issue our vendor said its secure” ect…. Is “JJMJKJ” (yes thats who sells it on Amazon) going to do anything - no. Not a chance. So rather than go through that entire process, get burnt out, and still be left with no actual device security I’m taking the approach of letting people know as soon as possible.
If you’re in Australia you can request a refund as the device isn’t fit for purpose or of acceptable quality.
File transfer / bluetooth serial endpoints: There’s some file upload for firmware features that could be interesting
Hijacking the app by pretending to be a watch: Perform attacks the reverse way, pretend to be someone else’s watch. Maybe can make phone calls, take pictures.
Overflows: There’s lots of places that smell like overflows can happen.
Unless you actively work across all layers of Australia’s national electricity market (NEM) there’s a high likelihood that this blog post will make you less confident in understanding the dynamics of the NEM.
I’ve worked at a aluminum smelter (one of the biggest energy loads you can find on the grid), a energy distributor and a power station. My first introduction was an aluminum smelter. The smelter wanted to change its load based on the spot power price. This dabbling in the NEM lead me to investigating the NEM’s open data and I eventually setup a website to visualise it. For a long time it was one of the only free and accessible ways of seeing the spot price, generation / demand and station generation. The websites long shutdown now. Often I had requests from people thinking I was from the AEMO/NEM which was concerning…
Even with this knowledge I still made bad assumptions and mistakes when talking about the NEM. From a high level it seems simple, you have loads and generators, people bid, you get a power price. There are soooooo many more variables to it than that though. It’s highly likely that I’ll still make mistakes in this post. Also the rules, requirements and the dynamics of the market change frequently.
Complication 1 - Interconnectors
The NEM currently has the following regions, VIC, QLD, NSW, TAS and SA. I say currently as the Snoy Hydro used to be its own region. Each Interconnector has its own limitations based on technology (AC, or HVDC).
It’s easy to simplify this as each region is its own market and the interconnectors are just generators and loads. This gets you so far. However where this starts to break down is that the interconnectors pass power through them, not cash. All going well power flows from low price region to high price region. However there’s a variety of factors that cause the fiscal model of the NEM not to match the actual model - for example data errors could cause the interconnector to fiscally run the opposite way to physically. This makes people sad.
Bonus complication
Interconnectors aren’t necessarily a single physical interconnector and could be made up of multiple connectors. This is called a notional interconnector. A directional interconnector is all the interconnectors flowing in a single direction to another region.
So you have to consider not just the limits of a single interconnector but all the interconnectors between the regions
Complication 2 - Regional losses
Lets make a simplified version of the NEM with a single generator and a single load. The load will be in Melbourne and the generator will be in Townsville. The loss in power from cabling will be significant.
The NEM “solves” this by using regional reference nodes and marginal loss factors to help calculate how much the power is worth.
Complication 3 - Grid constraints
Every piece of equipment has limits. The amount of current it can handle. How much can it handle at $x temperature. Best case when equipment hits its limit, it will trip, worse case it will be damaged.
Given the risk it’s important that these are modelled so that the grid can’t put a single piece of equipment at risk of hitting these limits.
What does this mean? Well even if we have plenty of generation, if its in the wrong place or other equipment is fault AEMO might need to request changes to ensure power system security, which includes things like voltage and frequency.
Check Out Constraints
The AEMO publish a constraint library to check out.. Might take awhile to get through. (Correction, the link provided here is for the WEM however it gives you an idea of the types of constraints and how many there can be)
Complication 4 - FCAS
Frequency Control Ancillary Services. FCAS. A very important part of keeping the grid at 50hz. This is an extra set of rules that are followed to bring the grid back to 50hz. More recently it was discovered that we needed even faster recovery from faults. So we also have Very Fast FCAS.
Bonus complication
Understanding AEMOs 3d FCAS trapezoid
(it’s actually not as bad as it looks at first glance…. but still)
Complication 5 - RERT
Reliability and Emergency Reserve Trader. This is effectively AEMO having their own contracts with companies to provide generation or load reduction for when the market isn’t able to respond.
Complication 6 - Time scales
So I haven’t talked about much about bidding. Bidding happens every 5 minutes. So we have Very Fast FCAS and FCAS that happens in seconds to a minute, the spot price at every 5 minutes, RERT that happens at much longer. Forecasting also happens at different time scales. At any one time there are lot of different processes happening to determine who pays what and how much.
When the sum of the price intervals equals a fixed amount administered pricing kicks in. This is a damage control system to prevent the spot price from bankrupting everyone.
Complication 9 - Outages are complex
A single unplanned outage can enforce a whole bunch of new constraints and limits. Suddenly the model has to reconfigure itself and make the network safe by imposing the correct constraints. Often outages are multi-faceted - eg a storm impacting multiple transmission lines, generators and loads. Or an under frequency / over current event could cause generators to tripped in parallel unexpectedly. You might lose six units at a powerstation due to a workers strike.
Complication - Closing….
The NEM is complex. I’ve only just scratched the surface here. Like the very very very surface. If you want to learn more much of the NEM is documented by AEMO and publish online. WattClarity also have very good learning resources and explain interesting events.
During unrelated research I came across SNOCOM. Apparently Australia’s first transistor based computer which was used for the Snowy Hydro project in the 1960’s. I became a little obsessed with it. It’s a fascinating piece of Australian computing history. Given its age it would be amazing to read the computer programs and even run them. My brain suddenly latched onto the idea of building a SNOCOM emulator.
Unfortunately the project just isn’t going to happen. I’d really like to work on something like this but time and money constraints means I have to let this one go. I’m hoping in writing this post someone else has the opportunity to give it a go though.
SNOCOM was made by PhD student David Wong at Sydney University. The design was to be a general purpose computer faster and more flexible than ADA. David adapted the design of LGP and ADA to make a transistor based machine. It uses a magnetic drum for memory for about 8KB of RAM.
The NMA contains a lot of SNOCOM artefacts including journals, books, and punch tape! The problem is the artefacts aren’t indexed very well, and the NMA doesn’t seem to really have the skills to handle computing related history. This means that while they can photograph the artefacts obtaining the contents of the punch tape will likely be very hard.
I’m sure it will be possible but it’ll require finding the right people and process. It’s also likely that the programs are also written down in one of the books, however I can’t determine which books it would be in. NMA have sent me some low res photos of some of the artefacts and I haven’t been able to determine which ones would be best to request photographing.
I could ask them to photograph or digitise them however the cost becomes very expensive very quickly. I could view the artefacts however I would need to get to Canberra. Even then its unlikely I could flip through pages. Just look at the covers.
Even if I was to magically gain access to the paper punch tape, I don’t have any equipment to read it. Photographing it might be an option, but processing it would be painful. One of the pictured punch tapes is ripped as well.
Then if the punch tape is processed, what program is it, whats its inputs and outputs. Is there enough information to make that tape useful?
As such I just can’t dedicate myself to a project like this. But maybe you or someone you know can?
If your interested here are some useful resources:
NAA has several pictures of the configuration sheets