Domas (and maybe his team or colleagues?) has put out shit tons of very interesting materials over the past years on advanced malware, implants and things like Cantor Dust which are amazing things to dive into.
using his own cpu fuzzer, msr fuzzing techniques etc. he has found, reversed and implemented attacks through hardware bugs and backdoors.
It cant be confirmed if a backdoor is malicious or for debugging but essentially the capabilities gained through them are what is important.
These techniques he shows throughout his videos are not super tricky to replicate and I can recommend people who have interest to dive into it, reproduce things and try to help in this domain to raise awareness and findings.
Another good avenu is: Defcon 21 - Decapping Chips The Strike Easy Hard Way
People speak about supply chain issues in NPM and Pip etc. but these are much more severe and hard to detect.
Almost no one looks at it. Most vendors totally ignore it because you cannot sell products against it. (if ud detect it u need to trash the hw so its not handy... for sales...)
What can be done to mitigate this? One option would be to buy a large FPGA and flash it with an open-source CPU. Another would be to emulate a CPU, working with encrypted data and commands, so that even if the backdoor in a host CPU tries to overwrite memory, it would only crash the emulated OS. One more option would be to run the code in a Virtual Machine like QEMU which translates the code and prevents issuing unknown instructions.
Not a backdoor, but a documented CPU feature.
The whitepaper about rosenbridge cannot be published because it would constitute scientific fraud.
Almost exactly 8 years ago: https://news.ycombinator.com/item?id=17727140
I still remember the time when mnemonics were 2 or 3 characters. Good days.
In a nutshell, I understand them as a sort of "blockie" for binary data formats. Things like WAV audio files, bitmaps, ASCII text, machine code, etc. each generate their own distinct visual signature (but different examples within any of these categories tend to generate similar signatures). So once you learn the "blockies" for different types of data, they really pop out when content is viewed this way ("hey there's an image buried in that sequence of 1's and 0's!").
The explanation on this page isn't bad, and the bitmap example near the bottom is particularly illustrative (once you've seen the reference image for bitmaps earlier in the page):
https://inside.battelle.org/blog-details/battelle-publishes-...
My armchair-expertise here is only about 20 minutes old, but I hope this helps someone else looking for a starting point to learn about them!
Modern Intel and AMD chips also have separate CPU cores that neither the user nor the installed OS control.
Intel Management Engine:
https://en.wikipedia.org/wiki/Intel_Management_Engine
AMD Platform Security Processor:
https://www.wikipedia.org/wiki/AMD_Platform_Security_Process...
Intel added them in 2008. AMD followed suit about five years later.
For example, I am building a device that records motion data, video, audio, and lidar imaging. Inside the 6 dollar IMU and the 12 dollar lidar sensor are powerful processors that load binary blobs provided by the manufacturer. The lidar could potentially gain access to any of the system data stored on the SPI bus, which includes the bulk storage and secondary RAM for the system. It could exfiltrate that data using its laser to anyone within a few hundred meters in the laser fov. It could also receive remote c&c over its optical sensor. The only thing that prevents that from being the case is that I trust the blob does not include the code to do those things, but it would be trivial to replace the blob with one that does.
Millions of devices are made that include basic wifi functionality. often, this comes in the form of a dedicated WiFi module. Those almost entirely consist of a powerful processor running a proprietary binary blobs, connected to some internal bus of the system that may give it access to some or all of the functions of the device, or at the very least could cause the device to malfunction. These WiFi phy modules are sub$1, pervasive, and often built in to devices that do not have any advertised connectivity features. A threat actor that has knowledge of an attack surface for that opaque blob can probably cause >50% of the connected devices built with that product to malfunction, in some cases in serious and dangerous ways, and sometimes to exfiltrate data that might be compromising or valuable.
That’s what this article is really about.
Buy hardware used by government computers that are rivals to your country.
So if American, buy Chinese CPUs and install Chinese Linux or HarmoneyOS Assuming there is nothing you are doing of interest to them, as that will also have back doors
After Snowden, one can only imagine the worst and think everything has a backdoor.
But unless you are a high level terrorist or other person of interest, no state organization is going to target you at this level
P.s. you say no one can trust closed source, but a lot of open source is maintained by one or two people or a small group, just takes infiltration by one or two trusted contributors to push malicious code in and unless someone looks and finds that code amongst millions of lines of code, may never be discovered (more so as mainstream media won't publish any thing)
http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... (page 82)
...which along with the already publicly-known microarchitecture of the C3 makes this statement sound like total nonsense:
The rosenbridge backdoor is a small, non-x86 core embedded alongside the main x86 core in the CPU
I remember laughing at this with a few others knowledgeable in x86 when it first came out; a self-proclaimed "security researcher" who somehow failed to RTFM.
There's even a Wikipedia article about it now, with a link to the alternate instruction set documentation: https://en.wikipedia.org/wiki/Alternate_Instruction_Set
Stupid autistic policy of "Don't editorialize the title"...
Not so much for the hacking (White Hat, Black hat, other-color-hat) aspects (although they're certainly there too), but for the
visualization of higher-dimensional mathematics aspect...
In other words, have a look at the following URL's, then come back here:
https://gods.art/articles/equation_shadows.html
https://kettenreihen.wordpress.com/
See, there's Math (which typically generates graphs, graphics, other visuals), and then there's Higher-dimensional Math (you could almost call it 'Meta-math') -- which generates graphs about graphs, graphics about graphics, visuals about previous visuals...
That is, take a math equation that generates a graph. OK, so a simple example is that we could take the derivative... That generates a second graph which gives us information about the first graph... a "graph about a graph", so to speak, a "signal about a signal", information about the original information...
Point is, Cantor Dust looks like another great mathematical tool in any Mathematician's and/or Computer Scientist's and/or Engineer's visualization/understanding toolbox!
Oh sure, bad faith actors could use it for hacking (bad faith actors could use aspects of Isaac Newton's Calculus for hacking in various contexts, heck, any mathematical tool could be exploited in specific contexts!) -- but those people I'm sure, would not have an appreciation of the sheer mathematical beauty of such things! (Why use it to hack, when you can admire the mathematical beauty?)
Also, I should point out that humanity as a whole is far from discovering every single possible method, every single equation, every single way to visualize higher dimensional mathematics...
In other words, Cantor Dust is one such method... there will no doubt be many more in the future (I'd love to see fractal visualizations of higher dimensions!), and of course, we still have yet to understand all of the "old" previously discovered math in terms of all of the possible ways it can be used to visualize higher dimensions...
Anyway, great link!
See also ECB penguin [1]
5 here: https://cybersecuritynews.com/bug-bounty-platforms/
The issue are "bugs" could be randomly distributed, even across the same version number of some device.
Sample sizes and statistics come into play at that point.
Whistleblower protections are an avenue, but people can still be dealt with harshly (Schulte) and degree-of-protection can come down to motive. But motive itself is multivariate, is it not? A local-first Fediverse, with some type of "guaranteed anonymity" would work, though. But anonymity doesn't mean something can't be a hoax either, so it becomes a signal vs noise issue at that point. Yet, "nothing totally secure ever really is."
Source information can be embedded in the period of a printed sentence too.
A moral world is the answer to many problems. Something to ponder. People are said to only see the errors in their ways after death in the "hall of mirrors."
-- https://web.archive.org/web/20060102095331/http://maitreya-e...
Economic espionage is something to also think about. You may be doing everything right and that's what makes you a target. "If I'm not top dog, target anyone that is."
Perfect anonymity in crypto can also aid whistleblowing so that dump data = get paid.
I would be even more explicit and call it “Not a backdoor, but a documented feature of ancient de facto unused Via C3 CPU.”
IIRC there are also a few hints they at least considered exposing this alternative instruction set at runtime to get more performance out of the CPU core e.g. more useable registers, more three operand instructions, saturating and packed math for DSP workloads, etc.
Assuming bio-digital integration continues (i.e., humans keep pace with ASI via neural interfaces), the long term solution is total hardware sovereignty, aka the digital equivalent of bodily integrity and autonomy. We have to miniaturize and widely diffuse fab technology such that computer manufacturing can be done in local small businesses or even at home: automated chip fabbing, 3D printing, and assembly in one fridge-sized appliance you can buy at the nearest supermarket, and it can make parts to build another one of itself.
It's basically reproduction, but for the digital part of your body instead of the bio part. You should be able to design and fab your own custom chips, PCB, and chassis to build your neural interface from scratch, and write personal defense software that actively adapts to threats - a digital immune system. You'll also have the option to delegate some or all of that to a collective, but it would mean losing your individual sovereignty and becoming part of a larger organism in a symbiogenesis or multicellular evolution kind of way.
If you’re just an average dissident, it’s probably still good advice though.
The real recklessness would be allowing an ATM unfettered access to the internet on the assumption that the manufacturer has already protected the device from every known and unknown threat.
They had me download their app, link the air purifier, and give them its MAC address. Then they asked me to try pressing each of the buttons a few times and email them back. I did so, and they responded that they re-calibrated the buttons using my touch samples. It worked.
Documenting a backdoor doesn't make it not a backdoor, just means it's not a hidden backdoor.
The fact that a number of machines shipped with the backdoor accidentally enabled, and nobody noticed for over a decade shows just how dangerous even a documented backdoor can be. The oversight wasn't even detected by someone reading the manual, it was detected by a security researcher who wrote a generic tool to fuzz out such backdoors.
Via C3 CPUs are the only ones affected. A security problem sure, but a relatively obscure one that doesn't effect anyone's laptop, server in the cloud, etc.
A reasonable title is "Backdoor found in Via C3 cpus".
And "x86" sort of gives the wrong impression -- this isn't an AMD or Intel chip; it's a 2001-era VIA chip.
The CPU is not the most used vector, the firmware is.
Which you already do not have. And what you do have, is being eroded further.
You live in a world where you can be forcibly caged for a faulty manipulation of symbols you did not even consent to learning! You can be caged for doing things for your "own" body; in turn, repairs to your body can be denied and even deemed "impossible" because your physical existence threatens someone's illusions.
Maybe hunter-gatherer bands could've been said to have been autonomous. But the individual? Simply a replaceable embodiment for vast, impersonal forces. Your body and mind have always been property of the society that manufactured you. You do not own even your cherished the illusion of autonomy; it's just another behavior taught to you to make you produce more for your masters.
https://web.archive.org/web/20140130160743/http://datasheets...
sandsifter was lots of noisy PR, but no new encoding findings
Now, taking a pragmatic materialist stance: we are obviously bound by physics and cannot move in certain ways. We can predict what action a person will take from their brain activity before the person becomes aware of their decision themselves. But what the brain does to convince you that oneself is in control is probably the exact thing that's required for life to thrive. It was the evolutionary path taken, and it's also the future I strive for, and I hope others would do the same.
: hardware backdoors in x86 CPUs
github.com/xoreaxeaxeax/rosenbridge // domas // @xoreaxeaxeax

project:rosenbridge reveals a hardware backdoor in some desktop, laptop, and embedded x86 processors.
The backdoor allows ring 3 (userland) code to circumvent processor protections to freely read and write ring 0 (kernel) data. While the backdoor is typically disabled (requiring ring 0 execution to enable it), we have found that it is enabled by default on some systems.
This repository contains utilities to check if your processor is affected, close the backdoor if it is present, and the research and tools used to discover and analyze the backdoor.
The rosenbridge backdoor is a small, non-x86 core embedded alongside the main x86 core in the CPU. It is enabled by a model-specific-register control bit, and then toggled with a launch-instruction. The embedded core is then fed commands, wrapped in a specially formatted x86 instruction. The core executes these commands (which we call the 'deeply embedded instruction set'), bypassing all memory protections and privilege checks.
While the backdoor should require kernel level access to activate, it has been observed to be enabled by default on some systems, allowing any unprivileged code to modify the kernel.
The rosenbridge backdoor is entirely distinct from other publicly known coprocessors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply embedded than any known coprocessor, having access to not only all of the CPU's memory, but its register file and execution pipeline as well.
It is thought that only VIA C3 CPUs are affected by this issue. The C-series processors are marketed towards industrial automation, point-of-sale, ATM, and healthcare hardware, as well as a variety of consumer desktop and laptop computers.
The scope of this vulnerability is limited; generations of CPUs after the C3 no longer contain this feature.
This work is released as a case study and thought experiment, illustrating how backdoors might arise in increasingly complex processors, and how researchers and end-users might identify such features. The tools and research offered here provide the starting point for ever-deeper processor vulnerability research.
To check if your CPU is affected:
git clone https://github.com/xoreaxeaxeax/rosenbridge
cd rosenbridge/util
make
sudo modprobe msr
sudo ./bin/check
The provided utility must be run on baremetal (not in a virtual-machine), and is in an alpha state. It may crash, panic, or hang systems not containing the backdoor.
The utilities provided here are designed around a specific processor family and core; unfortunately, the tools will miss the backdoor if it has been even slightly modified from the researched form.
Some systems have the backdoor enabled by default, allowing unprivileged code to gain kernel level access without permission. If the steps in 'Checking your CPU' indicate that your CPU is vulnerable, you can install a script to close the backdoor early in the boot process:
cd fix
make
sudo make install
reboot
Note that, even with this, an attacker with kernel level access can still re-enable the backdoor. This script is provided as an outline for correcting the issue during the boot process, but will require adaptation for different systems.
The sandsifter utility is used extensively in this research for uncovering unknown instructions.
asm
An assembler for the Deeply Embedded Instruction Set (DEIS). It converts programs written in the custom rosenbridge assembly into x86 instructions, which, when executed following the launch-instruction, will send the commands to the hidden CPU core.
esc
A proof-of-concept of using the rosenbridge backdoor for privilege escalation.
fix
A rough outline for closing the vulnerability on affected systems, to the extent possible through model-specific-register updates.
fuzz
A collection of utilities used to fuzz both the x86 and rosenbridge cores, in order to isolate the unknown launch-instruction and bridge-instruction, and resolve the instruction format of the rosenbridge core.
deis
The fuzzer used to explore the effects and capabilities of the hidden CPU core.
exit
It is thought that, on some processors, an exit sequence is needed to switch back to the x86 core at the end of a DEIS sequence. This directory contains the utilities used to search for the exit sequence in early stages of the research, but was abandoned when a processor was found not requiring any such sequence.
manager
A collection of python utilities designed to monitor and manage fuzzing tasks distributed across a network of workers.
wrap
A stripped down version of the sandsifter fuzzer, used to identify the bridge-instruction that will send commands from the x86 core to the hidden rosenbridge core.
kern
A collection of helper utilities used to monitor kernel memory and registers for changes caused by fuzzed DEIS instructions.
lock
Utilities to lock or unlock the rosenbridge backdoor.
proc
A tool to identify patterns from the fuzzing logs to identify classes of DEIS instruction behaviors.
test
A tool used early in the research, to attempt to identify the hidden core's architecture by executing known RISC instructions.
util
An alpha-state tool to detect whether or not a processor is affected by rosenbridge.
(TODO: link to whitepaper)
(TODO: link to slides)
The details and implications presented in this work are the authors’ inferences and opinions, derived from the research described. The research is performed and provided with the goal of identifying and fixing a perceived security vulnerability on the described CPUs. VIA processors are renowned for their low power usage and excellence in embedded designs; we believe that the functionality described was created in good faith as a useful feature for the embedded market, and was unintentionally left enabled on some early generations of the processor. No malicious intent is implied.
project:rosenbridge is a research effort from Christopher Domas (@xoreaxeaxeax).
You might be surprised to learn that China has operated clandestine prisons in the US!
https://www.justice.gov/archives/opa/pr/two-arrested-operati...
Plus your data can be sold on the market. To US based entities. While the Chinese still hold on to the data for future uses ...
It's just that publicly known backdoors are of very limited usefulness, because people go out of their way to remove, disable, or avoid them. Or worse, use them for their own gains. There have been more than a few cases of governments trying to implement and enforce publicly known backdoors (with keys only the government knows), such as the Clipper cryptography chip in the 90s.
But... just because something is documented, doesn't mean it's publicly known. We have an example here of something obscure enough to be a useful backdoor (assuming someone knew about it).
And while the underlying feature might have been documented, the fact that many BIOSes enabled the feature was not documented anywhere. That does count as hidden.
The keyboard and trackpad was also way ahead of the competition (ie other netbooks). The GPU was the biggest issue as VIA only built a proprietary driver for the kernel that was used at the time by Suse Enterprise. Thanksfully someone quickly wrote an openchrome driver that allowed me to install my distro of choice at the time with a newer kernel.
I think it would still be a decent portable machine to write stuff and or use as a portable terminal emulator to connect to remote machines but completely unusable to do anything else. I remember resizing photos to create thumbnails for a web gallery was taking ages and that was with much fewer megapixel than today.
Intel Management Engine:
https://www.wikipedia.org/wiki/Intel_Management_Engine
As do AMD chips:
AMD Platform Security Processor:
https://www.wikipedia.org/wiki/AMD_Platform_Security_Process...
most ones that are routable are hackable real easily. the only reason no one does it is because they dont need to or dont want to.
more people should do this. there should be laws to prevent such systems to be connected to others.
main problem is often billing systems and sometimes OT stuff will need things like weather info or external data which makes it harder or more expensive to effectively airgap. remote places are also a pain to maintain if u cant connect into them.
this is why most of these places rely on not being routable over most internet, so u vpn to some place and connect in from there. Sibsequently many engineers will not properly secure OT because its not routable.
then a routing mistake happen at ISP and oops all the boxes are rooted -_-.
airgapping is not overkill.
Bruh, I am not "gaming the system", the CIA (Central Intelligence Agency) is gaming the system.
In the house analogy you don’t see the backdoor when approaching the front. If it was just “an alternative everyone knows about and can be broken easier than the front door” then it probably would have been called “a window”.
Most login forms have a weaker option like a SMS 2FA or password reset fallback. Nobody calls it a backdoor. It’s just a crappy second front door, or window.
It's meaningful that the Windows 10 install method has no (official) way to disable it, but I don't think making something optional could make it not a back door, if it was one before.
Even when automatic updates are disabled, I'm not going to be reading every update so the effect seems mostly the same, regardless of whether updates are automatic or not.
The FSF's definition of "back door" (at the bottom of the linked page) is "any feature of a program that enables someone who is not supposed to be in control of the computer where it is installed to send it commands" which leaves a lot of ambiguity with the words "supposed to be". I am not sure how to interpret this definition.
[1] https://www.gnu.org/proprietary/proprietary-back-doors.html#...
Can we refer to user data as “the garage”?
And instead of hackers they should be “coons”.
The headlines can read: ”Buncha Coons In The Garage Again”
It’s more quaint
Doesnt really matter which platform, automatic updates are bad news.
On windows it led to clownstrike. On BMW it led to dash ads.
Theres infinite examples of auto updates being an attack vector for OEMs and other bad actors.
Always disable updates on every product. Can always reenable as needed or even sideload updates.
As an advertised feature of the product.
Your personal definition doesn’t match the general understanding of the word and concept. By your definition every window on a house or car is a “backdoor”. Anything with an advertised fallback is a backdoor. And sometimes the “front door” is the back door: getting money from an ATM is less secure than with an ID at the bank teller.
I'm surprised the hidden aspect of backdoor is so forward in folks minds. In my thinking nothing in cyber security is hidden, I drop the obviously present hidden part of backdoor definition when it's used in yhe cyber security context.
>> I'm probably mistaken, but I've always referred to password resets as backdoors
> Password resets aren't "backdoors" unless they contain a flaw the defeats any security protections.
You really have to make up your mind. It was “always” but then it wasn’t, and even as you put it you’d have been wrong almost every time to call a reset “a backdoor”.
> I'm surprised the hidden aspect of backdoor is so forward in folks minds.
Only because you misunderstand the meaning of the term, as made very clear above. Go through the wiki page for a “backdoor”.
> In my thinking nothing in cyber security is hidden
I wonder what all those security researchers do all day, with everything being so out in the open and known by everyone.
> I drop the obviously present hidden part of backdoor definition when it's used in yhe cyber security context.
You can drop it but then you’re just using the wrong definition and wrong understanding.