Key exfiltration via decompilation

I use mtpmount/Dokan to mount MTP as a drive in Windows. Mtpmount is a command-line tool (which isn’t going to be to everybody’s taste).

Seems to work well (but you need to be sure to unmount the disk).

Good point - another limitation of the (built-in) Windows method of accessing MTP devices is that you don't have command line access, unlike USB Mass Storage.

What you mentioned is good for ppl who prefer the command line and/or wish to use scripting. (And also people who don't want to deal with the other usual limitations of MTP.)

Like any security approach, one needs to decide on the maximum level of dedication you're going to protect against. Nothing is impenetrable. I think ultimately what I'll do is use a shared key like "superdupersecretkey" as an admission that protecting client-side secrets is in the too-hard basket. Were the PRG files to have been cleverly encrypted, this might be a different story. I had encountered https://github.com/pzl/ciqdb, but at first glance it didn't look like it was capable enough to help an attacker work through some XOR obfuscation after trying a string search. Hence my wishful thinking about it being good enough.

If I understand the rest of this discussion about MTP vs Mass Storage, it could be that the prg files are still accessible in newer devices, meaning that even if the app targets only newer devices, it's not protected. Someone please correct me if I misunderstand.

So I plan to transmit the System.getDeviceSettings().uniqueIdentifier, which AFAIK is a function of the device's private ID and the app's ID. But it's not enough to send this; I'm not concerned about MITM attacks, but I want some assurance that that requester is the client code I authored and not some guy wearing a hamburglar mask sending curl requests. If the server can successfully decrypt the client-encrypted payload then simultaneously it validates that the sender knows the secret, and also gets the encapsulated user's ID. As discussed though, ensuring the shared key remains secret is a challenging problem when the client-side code can be decompiled.

Brainstorming.... Maybe use another service, i.e some 3rd party payment. This won't stop someone using your API but to get a response they'll have to pay first 

Ah, this isn't actually for payment. I just don't want randoms to abuse my data service

zmullett said:

If I understand the rest of this discussion about MTP vs Mass Storage, it could be that the prg files are still accessible in newer devices, meaning that even if the app targets only newer devices, it's not protected. Someone please correct me if I misunderstand.

My educated guess is that in newer devices it's impossible for the end user to access PRG files.

At least that's my experience with FR955, and from reading what others have said, that's my understanding for all newer devices. Every few weeks there's a new thread from a dev who complains that they sideloaded a PRG but it apparently didn't work because the PRG "disappeared" (it was moved to user-inaccessible storage). Some end users have also noticed they cannot see PRGs now (savvy end users have sideloaded apps from old to new devices in the past, when their favourite app was unavailable for the newer device).

In this context, by newer devices, I mean modern watches which are still receiving firmware updates (FR255 / Fenix 7 and newer). For context, FR255 and Fenix 7 were released in 2022.

If you have one of these devices, you can try it for yourself.

My educated guess is that any device which supports monetization would def hide all PRG files, as well. (This is mostly newer watches, but it also includes Fenix 6 Pro family, which is sole pre-CIQ 5 group of watches on the list.)

Ofc I don't want to say I know for sure, because I haven't personally tried out all the models.

I can also say that based on what others have said, Edge has also moved to MTP (more recently than watches, I think), even though Edge doesn't support music. I can only guess that this means PRGs are now hidden on the newest Edges. [*]

So my educated guess is that if you stick to CIQ 5 watches, you can probably be fairly confident that PRGs for all app types will be hidden. But ofc I cannot make any guarantees.

What I can say with almost 100% certainty is that if you build a music provider app, the PRG will be hidden on the device, even on older devices.

[*] I don't think the use of MTP is a prerequisite for being able "hide" files, but I do think the use of MTP is a sign that PRGs are being hidden.

I noticed that even before music was supported, certain things were "hidden" (completely inaccessible) to the end user. For example, if you changed wi-fi settings, no file in the user-accessible drive was changed. And if you deleted certain FIT files (for activity profiles, on-device workout, etc.), they would be miraculously resurrected when you disconnected the watch from your computer. But in this case, there would have to be a completely separate volume to place the "hidden" data, since the user-accessible volume was completely accessible via USB Mass Storage. It would be impossible to truly hide anything in the user-accessible volume, since a saavy user could just access the file system using low-level tools to find such "hidden" data.

Contrast with MTP. Garmin could presumably use the same physical volume for "hidden" apps and "hidden" music as all the other user-accessible stuff, while truly preventing access to the hidden stuff by controlling access via MTP. Having everything on the same volume might actually be a requirement for music, since Garmin probably doesn't want to have a fixed-size "hidden" volume just for music, as:

- Garmin doesn't know exactly how much space the user needs or wants for music

- Garmin doesn't want to reserve space for music that can't be used for anything else (like maps)

Iow:

- Files can be hidden on Garmin USB Mass Storage devices too, but for user-related / dynamic data, this is probably limited to small settings files, for practical purposes. Any larger files that are hidden are probably static system files (like the files that would be used to repopulate the user drive if you were brave enough to delete all user-visible files, like I once did. *) [*] do *not* try this tho, unless you are ok with losing all your data

- For large amounts of hidden user / dynamic data, like music, MTP - or something like MTP which prevents direct access to the file system - is probably the only practical choice for Garmin.