I get why they made their own high level language to some extent, instead of shoehorning in something else. But making your whole stack from scratch must lead to lots of holes like these.
But a very nice blog post. Learned loads more about what's going on under the hood, very interesting.
Weird how permissions is mainly a UI thing. Aka how they're used is that if you have them you can use them, and it's mainly a UI thing to just show the same list in the app store. So not really enforced. I guess the fix then is to make sure it's not possible to lie in the app store?
For a long time this didn’t really matter since the Apple Watch and Garmin devices really appealed to two very different market segments - Garmin had a huge moat in first party fitness capabilities, maps, and battery life, and Apple had a huge moat in UX, their app ecosystem, the screen quality and device style, and smartwatch functionality.
Now, both companies are closing the gap in both directions on many of these aspects. It will be interesting to see what effect (if any) this will or will not have on the CiQ tooling and the CiQ ecosystem.
[0]: https://github.com/anvilsecure/garmin-ciq-app-research/blob/... [1]: https://github.com/anvilsecure/garmin-ciq-app-research/blob/...
The list of languages the documentation claims MonkeyC takes inspiration from also denotes a certain type of programmer background:
> C, Java™, JavaScript, Python™, Lua, Ruby, and PHP all influenced the design for Monkey C
(source: https://developer.garmin.com/connect-iq/monkey-c/)
If I asked an embedded hardware expert to design a novel programming language for my highly resource-constrained wearables platform, I would be very surprised if these were the language touch points they used as their references in the design brief.
I've never had to activate a Garmin watch or register it online in order to use it. Not connecting it to Garmin Services and apps may limit access to 3rd party apps, or at least make it harder to load them load though. (I haven't researched side loading since base features are fine for me).
MyTourBook supports FIT/GPX/TCX/etc, has maps, calendars, charts and activity classification. It's built with Java so can run at least on Windows and Linux. There may be other good programs now, but as of a couple years ago it appeared to be among the better options.
It's open source (and they were supportive of PRs for improving Garmin import).
https://mytourbook.sourceforge.io/mytourbook/index.php
Edit: It's also not limited to Garmin devices. There is support for formats from Suunto, Polar and some other companies. https://mytourbook.sourceforge.io/mytourbook/index.php/docum...
Edit 2: This is with syncing over USB btw.
Nevermind it is not worth the trouble, vs handing in anonymized data with a temp email
As far as I know, Tizen smart watches can function well on their own after setting up the account once and I believe cloud synchronization is even optional. However, Tizen for smart watches is a dead end, with Samsung getting back to Android Wearable.
There's PineTime (https://www.pine64.org/pinetime/), which is very barebones but open source. Popular firmware, such as InfiniTime (https://github.com/InfiniTimeOrg/InfiniTime) can also be flashed onto several smart watches available on your favourite Chinese import stores (for example: https://github.com/StarGate01/p8b-infinitime for the Colmi P8).
I've also seen this one mentioned in my research but would love to hear from anyone who's used it: https://banglejs.com/
Thanks for the InfiniTime links, I'll check that out.
regarding the passive tracking I dont have a clue
To avoid waiting up to several minutes to get the GPS data when I start my workout, I'll switch to an exercise mode to start acquiring the GPS data while I change into my workout gear and leave the watch near a window.
By the time I've finished changing, the GPS data is available and the watch will behave almost like I had downloaded the EPO/CPE files from Garmin Connect.
The battery life is also nowhere near the advertised length (13 days). Most disappointing is that their support people say to expect about 60% of that, which is what I’m getting.
That said, this will likely be the replacement for my Pebble. Battery life over 6 days, buttons to control music playback, and an English-first UI (amazfit falls down here).
No other smartwatch released before or since has even come close to Pebble's Pebbles.
Kickstarter page is still up: https://www.kickstarter.com/projects/getpebble/pebble-2-time...
https://codeberg.org/Freeyourgadget/Gadgetbridge
FOSS, doesn't have network permissions, can export data or interface with other apps
I just wish it could export SpO2 values and update the AGPS almanac. Because of this a GPS lock takes very long.
I use it with a MiBand 6.
As discussed in https://news.ycombinator.com/item?id=35671245
But without source that can't ever happen I guess.
Also I think they encrypt firmware after the 5 series in the Fenix 6/7 models
Coros has proved it is possible to use cheap hardware to make clones but their metrics are supposedly nowhere near as good as the Firstbeat algorithms.
They did start encrypting the firmware of their latest devices. I noted that the firmware images for Forerunner 55, 945 and 955 were encrypted. Most likely others are as well.
In the live demo I did at Hack in the Box a couple of days ago (slides available [0]) I've shown how to exploit one of the vulnerabilities to read the memory of the Forerunner 55, making it possible to dump the firmware unencrypted. The CIQ demo app is also on our GitHub repo [1].
[0]: https://conference.hitb.org/hitbsecconf2023ams/materials/D2T... [1]: https://github.com/anvilsecure/garmin-ciq-app-research/tree/...
I’m somewhat surprised garmin made their own language for apps but considering the low power processors they target was their any other options?
Fitbit - after hiring many Pebble staff - supports third party apps written in JavaScript. These run on the pre-existing JerryScript engine, and are still sandboxed on the native side should the VM have holes. This made it much easier to get started as a developer, but imposed an upper limit on app performance vs. the native apps seen on Pebble.
I am surprised as well, especially considering that their compiler does little to actually no optimization. For instance, it won't remove dead code or unused variables. These seem like low hanging fruits that could save memory and cycles on low power devices.
If I cared about that kind of thing I'd be wearing an Apple Watch. I like the Garmin devices cause they're so much simpler and does the specific built in sports functionality very very well. They are also far more tailored towards being functional whether or not you have internet connectivity.
I would far far prefer Garmin to make Garmin Connect on iOS/Android work without internet connectivity than almost anything else. It's ridiculous the devices (this is not just watches) can't sync to the phone for you to review data on the phone if you there is no internet. What they do right now is send everything from the device right to the cloud, then have the phone download something else from the cloud.
In my case one of my devices (Edge 1030) is completely capable of mapping and navigation without any internet connectivity but you can't do anything on the phone with the data till you return to internet connectivity.
Garmin even has another app (Explore) that has mapping on the phone without internet connectivity once you download the maps. The mapping data in that app is amazing. Yet Garmin Connect only works with Apple Maps data, not Garmin's own map data. When you're on the Garmin device you get a vastly superior map compared to what Apple maps can provide!
I wholeheartedly concur with your point. Garmin watches excel at sports tracking as their primary focus, with notifications and messaging features taking a backseat. Conversely, Apple and Google watches prioritize communication functions.
Previously, I owned an Android Wear watch, primarily for monitoring my runs. Although it sufficed, I found myself wearing it exclusively during runs. The device required daily charging, had an irritating touchscreen, and lacked navigation capabilities without being paired to a phone, despite its built-in LTE modem.
A few months ago, I opted to purchase a Garmin Fenix 6 watch. Upon using it for several days, I recognized that this was the device I had initially sought. The battery life spans two weeks—although heavy GPS use reduces this to about one week—and the watch includes maps for the entire United States. I have found it invaluable for hiking, running, and more, and its exceptional performance has led me to wear it continuously rather than solely during activity tracking.
How can seemingly talented developers KEEP MAKING THIS MISTAKE? It is like almost every police officer shooting themselves in the foot with their service gun.
In this case: C is riddled with these easy-to-make mistakes, and it's not enough to think that "a smart developer" is able to avoid these mistakes, but that everyone will make these (or similar) mistakes as long as we're allowed to.
It's one reason why I'm so big on Rust: because these mistakes are much harder to make.
NuttX is the only one I can think of off the top of my head with this feature.
I'm not up to date on embedded programming vernacular, but isn't that just a regular OS with apps? (Apple Watch OS, Android Wear, etc)
Tangent: that bluetooth uplink comes with some bewildering differences for those monkeyC apps, e.g. a request started to be consumed as json will happily talk to localhost on the companion app's host. A request started to consume a navigation itinerary will also do, except when the host isn't on the internet, then it fails to read localhost.
They get access to the internet via the Garmin Connect companion app. But if you're asking to know if they can be exploited from the internet, that's not what we showed yeah.
The vulnerabilities we've disclosed require a malicious app to be installed (e.g. from the CIQ app store) so let's not cry wolf.
What I think this project highlights and what we should remember is the current level of security of Garmin devices.
GarminOS deploys none of the security mitigations one would expect in modern devices (let's exclude crappy IoT devices flooding the market). No stack canaries, no W^X, etc. It does not implement isolation between user-supplied code and the rest of the OS either. And their C code base does not appear to receive much scrutiny in terms of security review.
It would be much easier to exploit the watch (e.g. sending a malicious message to the user's phone that sends it to the watch to show the notification) than exploit the user's smartphone. And this could be performed from the internet.
https://forums.garmin.com/outdoor-recreation/outdoor-recreat...
I wonder if these are secured differently or merely obscured behind the encrypted firmware on newer models.
