[HN Gopher] Hacking the T2S+ Out of Fear: Get Lock-In Thermograp...
___________________________________________________________________
Hacking the T2S+ Out of Fear: Get Lock-In Thermography for Free
Author : Luc
Score : 283 points
Date : 2024-10-28 12:49 UTC (6 days ago)
(HTM) web link (dmytroengineering.com)
(TXT) w3m dump (dmytroengineering.com)
| kragen wrote:
| 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 naive 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!
| gsliepen wrote:
| > 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.
| daniel_reetz wrote:
| 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.
| sangnoir wrote:
| > 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.
| mschuster91 wrote:
| > In order to practically implement this we first close the
| shutter.
|
| Fun fact, Sony does the same once in a while for dead-pixel
| detection and remapping on their mirrorless cameras [1].
|
| [1] https://news.ycombinator.com/item?id=38579634
| tiagod wrote:
| Been thinking of getting one of these but was worried about the
| proprietary app. I guess I have no reason now : )
| buran77 wrote:
| 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.
|
| [0] https://github.com/leswright1977/PyThermalCamera
|
| [1] https://github.com/92es/Thermal-Camera-Redux
| TeMPOraL wrote:
| 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?
| buran77 wrote:
| Eevblog forum is the original source for most of the Github
| projects around these thermal cams. So that's a good place
| to start.
|
| https://www.eevblog.com/forum/thermal-imaging/new-
| software-f...
|
| https://github.com/Santi-hr/UNI-T-Thermal-Utilities
| pavel_lishin wrote:
| 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?
| sitkack wrote:
| It is just fuzzy from zooming up screenshots, a by product of
| the subpixel aliasing.
|
| If it doesn't, you could probably add a post processing filter
| to https://github.com/wez/wezterm or
| https://github.com/alacritty/alacritty
| _Microft wrote:
| GP is talking about the code sections and the "CRT effect"
| that was added via CSS. Press "Toggle glow" to make it
| obvious what effect that is.
| equestria wrote:
| 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.
|
| The magic is basically in
| https://dmytroengineering.com/css/terminal-syntax.css, but
| there's a lot of other ways to do it.
| a1o wrote:
| I haven't like, checked the code, but I have seen this glow in
| websites that used a JS library called prism (or PrismJS).
| wdfx wrote:
| Try this perhaps: https://github.com/Swordfish90/cool-retro-
| term
| tene wrote:
| I like this one for VSCode:
| https://marketplace.visualstudio.com/items?itemName=RobbOwen...
| vermon wrote:
| 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?
| seany wrote:
| 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.
| InvaderFizz wrote:
| 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.
| bpye wrote:
| 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.
|
| Some USB-C thermal imagers do claim to work, for example this
| one by HIKMICRO -
| https://www.hikmicrotech.com/en_us/industrial-
| products/mini2... - but I'm not sure how...
| fignews wrote:
| You are correct. I have the same camera as OP (v1?) but the
| usbc version does not work with iOS. Can't understand why.
| It's very infuriating.
| radicality wrote:
| 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.
|
| https://orion.tube/
| knowitnone wrote:
| FLIR sucks. from personal experience. They sell crap that doesn't
| even work with your smartphone.
| immibis wrote:
| 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.
| wbl wrote:
| FLIR is owned by Raytheon. They are very much not in the
| trash and make very good imagers. You just can't buy them.
| 0l wrote:
| Teledyne, not Raytheon
| wbl wrote:
| 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.
| stefan_ wrote:
| It's really just the framerate restriction to 9hz that the
| Chinese imagers don't suffer ftom
| dannyw wrote:
| Bodes well for our semiconductor and AI industry now that
| we're limiting exports to China...
| heroprotagonist wrote:
| 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.
| daghamm wrote:
| Alternative take: maybe the app developer is combining random
| snippets found online mostly without knowing what he is doing.
|
| Remember that not long ago, Facebook was caught having
| deliberately bad sample code with too broad permissions
|
| https://privacyinternational.org/report/2647/how-apps-androi...
| heroprotagonist wrote:
| Assuming ignorance, would you trust said app developer with
| remote management of your device if he accidentally asked for
| it?
| daghamm wrote:
| 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.
| dzdt wrote:
| 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.)
| mavamaarten wrote:
| 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".
| heroprotagonist wrote:
| 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:
|
| https://andpalmier.com/posts/stalkerware-
| analysis/#analysis-...
| stavros wrote:
| This costs $300, so, while cheaper than FLIR, still not cheap.
| fignews wrote:
| Much higher FPS and resolution than what FLIR even offers
| consumers.
| stavros wrote:
| True, I meant "it's not 'impulse purchase' cheap".
| blincoln wrote:
| 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.
| grishka wrote:
| I can't access this website without a VPN, I'm getting the
| dreaded "you're blocked" cloudflare page.
|
| Cool stuff though once you get past that.
| meowster wrote:
| Can we at least update the ITAR restrictions now, so we can get
| better resolutions and framerates?
|
| Can anyone from FLIR lobby on this?
| giantg2 wrote:
| 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.
___________________________________________________________________
(page generated 2024-11-03 23:01 UTC)