250k is not a bad investment for a company doing "reverse engineering as a service" - say 1k a pop to extract the firmware. Naturally, a good business idea for somewhere in the world with less regulations...
> Sure, but if you’re defending against a nation state actor hopefully you aren’t expecting a raspberry pi to keep you secure.
Is there anything about these techniques that are raspberry pi specific? It seems like they're using lasers to identify and flip particular bits in registers.
There are HSMs that are effectively immune to this attack by way of their construction and packaging. You need an optical path to the secure device. The only way to get at this is to tamper with the tamperproof part of the system.
Some very high end HSMs must be actively powered at all times which makes disturbances in their local environments detectable at all times as well. Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
It sounds like a more cleaner method to obtain the keys versus using solvents and a lot of trial and error hardware. As described by Chris Gerlinsky with "How Do I Crack Satellite and Cable Pay TV?" [0] [1]
> Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
That's interesting. I suppose if that technology is in use, the attack would have to occur in a pressure-controlled chamber, so breaking the seal wouldn't cause a change in pressure.
A more likely measure, which I recall seeing years ago, is to measure the impedance of the enclosure of the thing you want to protect. If someone tampers with it, you would be alerted. It works at many scales, from a protective metal mesh over your IC to a PC case.
You can find the pressure through destructive trial-and-error if money is no object - which it isn't for governments when the target hardware is juicy.
Why would you make each device have the same pressure inside it? That's a bit like hardcoding the same password in each one. Any attacker is only going to have one shot on the actual device they care about no matter how much money they spend.
Your phone isn't going to have a "very high end HSM" any time soon. n
Not until you're paying mid range car prices or more for your very specialised secure phone (and then that phone will probably be factory backdoored AN0M-style).
I expect typical smart cards like the one in your credit card are harder to crack than the raspberry pi was. Those cards are (or were) also used in TV set-top boxes and back in the day, there was a decades-long arms race between the chip makers and cable TV pirates. The TV pirates were also willing to make large expenditures to crack the chips so they could clone them and sell the clones. There's more about this in Ross Anderson's book "Security Engineering".
I've also heard that the Google Titan security enclave chip (used in Pixel phones) is very hard to crack. Apple has something similar for Iphones, I believe.
Depending on what sort of important you're talking, those ICs don't have the usual "something important" environmental specs, like an extended temperature range, or certification for automotive use or safety critical applications, for one thing.
>Why wouldn't a person build that into the heart of something important?
Because it's inexpensive and not designed to be tamper-resistant. If preventing this type of thing is your goal there are chips out there designed to break irrepairably if tampered with.
Rp2350s are advertised as having quite a few anti-tamper functions. They had a bounty when it launched to find similar vulnerabilities and they worked to patch the ones that were found. This is a lot more credible than a lot of advertised anti-tamper features.
In 5 years, either $400,000 or $50 and a hammer, depending on whether the core piece of the process aligns with the needs of some fast-growing consumer tech product like e.g. drones.
I was referencing my own realization earlier today, when I was wondering if I can DYI a ground-penetrating radar to scan the allotment garden for hidden "surprises". A ground-penetrating radar is something I learned about as a kid watching a popular science videotape, back then a stupidly expensive high-tech piece of professional equipment.
But it hit me that there are two main forces keeping such technologies stupidly expensive and inaccessible to general public over time: costs of knowledge that went into their design (protected by patents and trade secrets), and specialized parts made in unique way or from unique materials, that don't happen to have alternate applications.
Nowadays, knowledge is not an issue - 20+ years is enough for all the relevant patents to expire, and information to have seeped through to the Internet, available in a combination of Wikipedia articles, textbooks, scientific papers, and blogs, plus we have good LLMs more than happy to synthesize that and transform into a DIY tutorial for dummies.
Which leaves the parts. Whether or not you can DIY such a tech really hinges on whether you can find the critical components somewhere. If they're still unique, you're paying $$$ for procurement (and it makes more sense to try and score broken/used equipment off eBay or something). But there's a chance there's a close equivalent that's part of mass consumer or prosumer device, at which point you just buy it and strip it for parts.
(Which way it is with ground-penetrating radars? Don't know, didn't bother to prompt an LLM with that question yet.)
Radar is cheap now, thanks to semiconductors getting smaller and faster the analog front-end which used to be a long expensive chain of components is now much smaller, the ADC is now faster, more accurate, and cheaper, the processor is now fast enough to keep up with a higher bandwidth signal. You could probably drive a very rough radar system directly off a Pico's GPIO and ADC, maybe toss in a decently fast op-amp for a receive amplifier.
Where you will run into issues is processing radar signals into usable data. If you're happy with the results that radar was giving 30 years ago then it's fine and dandy, but the magic of modern radar is in the software, not the hardware.
I thought it was a joke about inflation - the US is now trying to print its way out of debt as yields are soaring. This is the very beginning of how hyperinflation usually starts.
Very interesting. I spent a large part of my career in aerospace and never considered this failure mode before. It makes me wonder: how long is the pathological code allocation time? A few seconds, at most? We're talking about flight identification codes that are normally assigned upon takeoff and change at most a handful of times during a flight.
I assume the "manual request" is an aircraft squawking 7700 or similar, but why does the system need to interrupt an in-flight allocation in the first place? Any controllers here have insight?
One would think it would be sufficient to do something single threaded like
there will be some other tasks in the system that need time guarantees around when they get scheduled for very important (safety?) reasons. so when these higher priority tasks show up the lower priority tasks get suspended.
if they could guarantee hard bounds on how long low priority tasks take to complete they could implement your scheduling algorithm. but i think in reality the low priority tasks are either not boundable or they if they do have a provable bound the bound is too high.
In the Before Times, the vast majority of software was written in garbage collected language where a working knowledge of the relative merits of C memory allocators is not useful or particularly relevant.
Why would the scads of people writing JavaScript, Java, python, go, rails, etc need to be aware of jemalloc?
Memory allocation behaviour has visible impact also for users of managed languages, and the behaviour of software for end users.
In our Python program, a bit of numpy processing of large pictures led to 100 GB not being returned to the OS by glibc's default allocator and the machine running out of memory shortly after. With jemalloc's reliable memory return settings, those problems disappear.
I'm in the same boat, I just switched to using it for Kavita, which only does some basic open Image -> Thumbnail to smaller size -> write to disk when importing new comics/books and on linux, memory could swell to 10GB and never get released. Switched to jemalloc and instantly memory stayed well below 1GB.
Generally yes, but the wording of "instantly" begs for the following pedantic remark:
This is controlled by jemalloc settings `dirty_decay_ms`, `muzzy_decay_ms`, and their interaction with `background_thread`.
`dirty_decay_ms` currently defaults to 10 seconds, so it's not that instant.
That is important e.g. for single-threaded programs that start other programs, such as my Python example: If it starts a subprocess before the 10 seconds elapse after `free()`, Python (and jemalloc) do not run, and get no chance to return memory to the OS.
In such cases, either enable `background_thread`, or set the `_decay_` values to `0` to ensure immediate return to the OS upon `free()`. (This costs some performance.)
>...the vast majority of software was written in garbage collected language
and even then recently it costed (us) quite a few months to blame JVM and later the default glibc memory allocator for running out native (not java heap memory) - had to exclude all possible native libs (zlib, zstd via jna), direct buffers, sockets, thread stacks and so on. Changing the malloc to jemalloc solved the issue, even though initially it was done for its debugging capabilities.
I'm never sure if I should be upset or happy when I've been debugging a problem for long enough that I finally decide to switch something out in order to improve visibility and that immediately solves the problem for entirely unexpected reasons. Particularly all the times when I couldn't readily discern why.
We changed to jemalloc first on a jvm service which we could never get to run in its kube memory limit. with jemalloc its been dead stable for years, and we made it the default for all jvm services
Because unfortunately, the runtimes belonging to all or at least most of those languages perform a lot better with jemalloc than with the system default.
TL;DR: Because the runtime of most GC:d languages uses malloc for its internal data structures.
I work for the runtime team of JPG @ Oracle. We use malloc in Hotspot, quite a lot actually! Providing your JVM with a good malloc can improve the performance of the runtime, both in terms of CPU and memory, by quite a bit.
I don't think you need the details, but it's good to be aware that some mallocs are better than others, and there are multiple of them. Being aware of jemalloc is a good way of being aware of the facts I just mentioned :-).
The vast majority of professional developers are not in a position where they can just swap out allocators willy-nilly. They take what they get, and write the code they're assigned to write on the platform the CTO or their product lead or whoever has decided upon.
Okay, well, I guess all I can say is that if you strive to be one of the developers who do get the chance to care about this stuff, then you should know this stuff :-).
Because it's literally the least impressive thing you can build and in a world where I don't write the code anyway, a "hello world" example has lost its place (at least for human viewers).
It demonstrates CRUD at a small scale and is familiar, so we don't need to figure out what it's trying to demonstrate. It allows us to see how large the final product is and how much memory and CPU it uses.
It's not meant to be a showcase of what you can build with it; it's meant to give you the smallest complete application so you can get a good idea of what you need to know.
The thing that's meant to be a showcase is usually referred to as a Showcase or a Gallery.
Can't vouch for that but I can vouch for `Dreyer's English` as both hilarious (if you're the sort of person who relishes finding le mot juste, like me) and excellent as a style guide.
There are two visually similar sails. Some are rotating tubes that generate lift via the Magnus effect and even though they create low pressure zones, those are not “suction sails”, strictly speaking.
A suction sail is a more or less conventional airfoil that houses an axial compressor to basically suck in air which causes the boundary layer to stay attached which generates lift via the same mechanisms as an aircraft wing.
From a distance and to a casual observer they’re pretty similar.
TFA is the aerospace equivalent of rolling your own crypto. Outsiders often don’t know what they don’t know, resulting in fatally-naive “solutions” to the problems.
No it's not. It's an interesting article on how to use scikit-decide to optimise a problem. Nothing more.
Rolling your own crypto is considered bad practice because there are countless battle proven open source alternatives. Where are the open source alternatives for aircraft route optimisation that the article could talk about instead? And it would be a totally different article if it was talking about how to use them. This is an article about using optimisation tools to target a specific problem. Aircraft routing is just the example.
Not super practical, but neat attack
reply