Looking at those permissions, I think whatever fear he decompiled this out of was justified.
I guess that's one way to implement industrial espionage.
Build telemetry and malware, or code that can become malware with a little tweaking or remote checks, into a component that's likely to be used by technologists in whatever sector you're interested in.
Make it a bit better and a lot cheaper than all the alternatives. Get on their phone with lots of permissions, and use the telemetry. Once you know who they are you can decide on more targeted actions to turn them into a vector against their employer or whoever, or just watch what you can to collect information.
I'd have to look into the app myself, but at first sight the permissions are scary but the decompiled code he showed was just about enough to show a map using Baidu maps. Probably just a feature of the app. I honestly think that yes they are probably collecting too many analytics for comfort, but at the same time it's really not that easy for a random app to really collect anything useful these days. All apps are sandboxed by definition, so all they're getting is what you give them. Also don't forget that high-accuracy location permission could also mean they just want to use Bluetooth for pairing something.
I'm all for calling out espionage and malware. But I'd also like to see proof and not just "this could potentially be used for bad".
I agree someone needs to look into this more directly. The bits he was specifically interested in and wrote most about were the thermography pieces. And that's where the focus of the article was. The author notes only skimming the parts he found where the requested permissions were used, given that the experience of the author was not focused in either Android nor Java.
It's not a comprehensive analysis but what is there is very alarming.
There is absolutely NO reason for this app to need MDM_APP_MGMT. This is capability for remote administration of the device, including ability to install additional apps (which is likely where this vector would expand exploitation). We don't see where that permission is used from the few screenshots of non-thermo sections.
Same for a number of the other permissions. For an 'at-a-glance' review, compare this app's requested permissions to those requested by stalkerware in this stalkerware analysis and notice the similarities:
My point is that this could very well be incompetent instead of malice.
Doesn't really change anything and I would not install an app that requests all these permissions and I am also very careful with apps distributed outside the official store.
With that said, Android by default disables dangerous permissions and almost everything has to be opted in these days.
The horseshoe principle applies on the malice/incompetence dimension. Any sufficiently advanced malice is indistinguishable from incompetence. (Disguising ill intent by as incompetent design is one of the strongest deniability approaches.) But also any sufficiently advanced incompetence is indistinguishable from malice. (A bad actor can fully compromise an incompetently designed system as well as if the vulnerabilities had been intentional.)
This is fantastic! At a high level all he had to do for basic thermography was to flat-field the raw image with offsets acquired from the camera's shutter, without even having to derive per-pixel gains like you normally would, and mask out some bad pixels (and inpaint them for naïve consumers that can't handle NA data). Then as a bonus he implemented lock-in thermography, which turns out to be just lock-in amplification applied to thermography by modulating a heat source over time.
But the technical detail provided seems to be enough to make it easy for someone else to reproduce the whole setup. And provides ample evidence that you should, because the provided drivers are evidently malware.
Oh, and apparently you get a free FPGA with your thermographic sensor!
Very cool! I thought maybe I'll take a crack at building a better iOS application for these things, but then I remembered that for the Lightning connector you needed to get the permission of the manufacturer if you wanted to interface with a device (tried that once with a Lightning Yubikey and luckily they didn't have any objections).
Is this not an issue anymore with USBC iPhones?
USB-C iPhones work with all kinds of USB-C hubs, devices, keyboards, mice, Ethernet adapters, etc out of the box.
As far as I have seen, USB-C on iOS devices has no authentication restrictions for anything.
The device in the article already has an iOS app, so while there may be a needed app entitlement, I don't think there are any showstoppers for making an iOS app for this particular thermal camera.
I would love to be wrong, but I can't find anything that suggests USB webcams work on USB-C iPhones - I did try in the past for different reasons but couldn't find any way of making it work.
What surprised me is that iPadOS does have uvc functionality, but iOS doesn't. If you have an ipad with a USBC connector, can try it and will work. For example I used the Orion app for ipad and it will show me live feed of any connected uvc camera.
I built an interposer board to do this about 5 years ago (for a product that didn't go anywhere). Ended up using a beagle bone in USB gadget mode to expose an Ethernet adapter to the iPad I was using.
> At this point, I realized that I got the "V2" of the camera. This camera is regarded as worse than the "V1" mostly because the manufacturer removed the internal processing FPGA?
That's actually better. In-camera processing will just reduce the amount of information you can get out of the sensor. For example, even if it does exactly the same flat-fielding as you do, the in-camera flat-fielded image has to be requantized to 8-bit format before sending to the computer, therefore losing precision.
You can get even better accuracy by taking a dark or bias field (might be possible if you can set the exposure time to something very short, but this might not be possible with these thermographic cameras) and taking flatfields at different temperatures, so you can get per-pixel linearity curves. That's a lot of work though, and ideally each camera was indiviually calibrated by the producer, but I am guessing that is not done for these cheap cameras.
The article points out that the FPGA was not actually removed. However it is true in some circumstances having access to data earlier in the pipeline is useful. Microbolometer cameras like these have their own quirks.
> In-camera processing will just reduce the amount of information you can get out of the sensor
More information is not necessarily better. For instance, if the FPGA does calibration and removes sensor noise, removing the preprocessing adds literal noise to the data, which is worse.
Unrelated to the article, but I love the "glow" effect on the code snippets. Any chance this exists as a plugin for VSCode, for when I want to re-live my teenager dreams of what working on computers looks like?
Yeah, and it's pretty simple. You have essentially three composition layers: original text; a gaussian-blurred zero-offset "shadow" to add glow (CSS text-shadow); and then a pattern of darker horizontal stripes on top, produced with repeating-linear-gradient with an alpha channel.
There are a few open projects to support a lot of these thermal cams like the more popular Topdon or InfiRay models. PyThermalCamera [0] or Thermal-Camera-Redux [1] are good ones, I got my thermal cam working on my Linux laptop just fine.
Do you know of anything that can handle UNI-T cams, particularly something like UTi721M, which is a nice thermal cam that attaches to a smartphone via USB-C?
It seems like there's no great option for working with thermal on a budget. The FlIR Lepton has been a bit of a pain to work with on a Pi Zero or ESP. The FS is cheap, but like all Leptons it is slow and the resolution is low. Bosons are too expensive. The Chinese stuff seems to have terrible durability/longevity even if the prices are reasonable.
I heard the reason USA-made-and-designed thermal cameras suck is arms export regulations. They are considered military equipment unless they stick to certain limits. I guess China has no such rules, so the USA throws yet another manufacturing sector in the trash once again.
I looked up the history and you are completely correct. In my defense Raymarine was part of Raytheon long ago, and then a bunch of spinoffs and acquisitions happened.
There are FLIR consumer devices with 320x240 sensors, like the E8, but they're a lot pricier, and low-FPS due to ITAR. Consumers in the US can buy 60FPS FLIR monoculars as well, but they come with ITAR restrictions.
The T2S+ seems to be 256x192, 25FPS. Still a bargain, if you ask me, even if it's not as sharp.
I guess that's one way to implement industrial espionage.
Build telemetry and malware, or code that can become malware with a little tweaking or remote checks, into a component that's likely to be used by technologists in whatever sector you're interested in.
Make it a bit better and a lot cheaper than all the alternatives. Get on their phone with lots of permissions, and use the telemetry. Once you know who they are you can decide on more targeted actions to turn them into a vector against their employer or whoever, or just watch what you can to collect information.