---

We all love a good bit of bounce now and then, with everything from trampolines to bouncy castles and bouncy balls forming the staple of a wholesome childhood for many. That said, most of our bouncy experiences in day to day life concern bouncy objects that meet immovable or rigid objects, including said child having a blast in a bouncy castle. Where the physics get arguably more interesting and less intuitive is when you combine two objects that are both bouncy, with [Steve Mould] recently taking a look at the tuning of said bounciness to even kill the bounce completely.

Understanding how to achieve this tuning means understanding how the kinetic energy is stored in each flexible material, and how to dissipate it in a way that doesn’t result in the aforementioned bounciness. In the simple physical demonstration setup the addition or removal of weights to the lower sprung platform tunes the response to the bouncy ball that is dropped on top of it.

After going through the science behind bounciness and springiness using the practical application of this science in the context of golf balls and clubs, [Steve] introduces the simulation tool that he created. This allows you to tweak the parameters of such a double spring system, which may bring back some high school physics lessons for some.

In a system like that of a golf club and the ball, having undesirable oscillations (bouncing) reduces the final kinetic energy transferred to the ball. Although ‘bouncy’ is perhaps not the first thought that comes to mind when handling a golf ball or a club, ultimately they are just as bouncy as a bouncy ball or an electric switch, just on their own scales, with their own opportunities for optimization and analysis.

youtube.com/embed/EP1mYq8hLIY?…

---

hackaday.com/2026/06/30/how-to…

---

Laser diodes are convenient light sources, but for precise optical work their often-elliptical beam profile leaves something to be desired. One way to get around this is to couple the beam into a single-mode optical fiber, which then emits a circular Gaussian beam from the other end. For more advanced experiments, therefore, [Diffraction Limited] built this fiber-coupled laser source.

The simplest approach is to place the fiber directly against a light source, but this results in most of the light missing the three-micron fiber core. Optical fibers have an acceptance cone, and only light approaching from within this cone is coupled into the fiber. The design therefore uses an aspheric lens to focus light from the laser diode down to a tiny point matching the diameter of the fiber core, creating a cone of incoming light narrower than the acceptance cone.

The body of the laser source was CNC machined out of brass, with the laser-diode press-fit in one end. The lens stands in front of the diode, and was glued in place so that its focal point was just above the end of a mounting pin for the glass fiber. Positioning and fixing the fiber in place was the biggest challenge; [Diffraction Limited] could use the micro-manipulator from a previous video to position the fiber, but the UV-set glue used to fix it in place shrinks during curing, pulling it out of position. To deal with this, two set screws under the mounting pin allowed its position to be adjusted slightly after gluing. As expected, adhesive shrinkage meant that the completed source initially produced no light, but after the set screws were adjusted, the beam appeared.

For more on fiber-coupled lasers, check out [Les Wright]’s work. If you don’t have access to an aspheric lens, an anti-bumping bead could be a reasonable alternative.

youtube.com/embed/l26sCJn0sB4?…

---

hackaday.com/2026/06/30/buildi…

---

The phenomenon of cable-shaped indents in the plastic cases of retro systems is one that’s probably painfully familiar to many a collector of such systems. Although in these situations neither side got hot enough to cause any melting – especially while disconnected in storage – it still has that same melted appearance. The real cause here is not heat, but plasticizer migration, as detailed in a recent video by [Run Stop Restored] over on YouTube.

Plasticizers are an additive to many plastics that aim to make it more flexible (‘plastic’), as well as improve other characteristics of the base material, with PVC in particular relying on plasticizers to give it its desired properties for applications where PVC has to be flexible. Here the flexible cable insulation of these devices generally uses PVC, which over time can migrate to other polymers when brought into close contact for extended periods of time.

The – usually ABS – enclosures of e.g. Commodore tape drives as in this video demonstration thus get correspondingly inundated with the same type of plasticizers that ABS is also highly susceptible to. Since in storage the cables tend to be wrapped – tightly – around the device they’re attached to, this results in a solid contact which thus enables this gradual process to work its magic, whether it’s a Commodore datasette or a power supply brick.

Correspondingly the PVC insulation becomes brittle as it loses its plasticizer, with the process sped up by higher environmental temperatures. To prevent this, never wrap a PVC cable around a device, and keep it physically separated from susceptible plastics like ABS as much as reasonably possible. Along with a cool environment this should prevent plasticizer migration from ruining what used to be a pristine case.

This problem is particularly significant for retro gear from the 1980s and thereabouts, before phthalate-free plasticizer alternatives were developed, along with other changes such as more stable formulations that prevent this migration process. Adding a coating can also help, especially for protecting older gear, but flexible PVC in particular should be viewed with suspicion and treated carefully.

youtube.com/embed/CONn2snfbpk?…

---

hackaday.com/2026/06/30/retro-…

---

Every experienced machinist knows the value of taking regular measurements. If one works carefully and checks dimensions frequently, it’s possible to make a part much more precise than could be made by relying on the machine’s accuracy alone. In a similar vein, it’s possible to make a measuring device out of comparatively crude parts, as long as their behavior is well understood. Related to both principles is [BubsBuilds]’s displacement sensor, which uses a 3D printed frame but reaches precision better than two micrometers.

Admittedly the printed parts aren’t the source of the sensor’s precision, that comes from an opto-interrupter. This design has a central stylus, one end of which contacts the object under measurement. The other end flattens to a knife-edge blade, which fits between the diodes of the opto-interrupter. As the stylus point is pressed in, the blade blocks off more light from reaching the photodiode, creating an output signal proportional to displacement. To keep the stylus from twisting or moving side-to-side, two flat, circular flexures hold the stylus in the center of a cylindrical housing.

[Bubs] printed several flexure variations to see how well they resisted and permitted various torques and forces, and a symmetrical flexure design proved best for his purposes. Once the sensor was assembled, he tested it against the measurements recorded by a laser confocal displacement sensor. This design was an update from a previous version, and it improved in a few regards: the non-linearity had decreased, and the repeatability was now better than two microns, though the range had been halved. Significantly, though, it’s now much easier to mount, making this an actually practical tool.

If, however, this doesn’t fit your needs, there are many other ways to build a linear displacement sensor, ranging from capacitive to magnetostrictive. On the manual side of things, we’ve also covered a comparison of calipers.

youtube.com/embed/eN5aZ2vHxeg?…

---

hackaday.com/2026/06/30/buildi…

---

A central problem with the arguably overhyped field of quantum computing remains the difficulty in objectively ascertaining performance and new developments, as much here relies on indirect measurements. Such is especially the case with topological quantum computing, with its use of Majorana fermions. For a few years now Microsoft’s quantum computing department (Azure Quantum) has made claims here of major progress, which have subsequently repeatedly been shot down in peer review. Their most recent attempt at said progress in topological quantum computing now got a blistering response (PDF) by Henry F. Legg in an article in Nature.

We previously reported on Microsoft’s attempts here in early 2025, when they claimed the detection of the crucial Majorana Zero Mode (MZM), before it faced the criticisms of peer review, including by Legg, which included academically vicious language by some researchers, including terms like ‘essentially fraudulent’.

This raises the awkward question of whether Microsoft’s quantum researchers are just too eager to confirm a discovery, or whether a more benign reason exists.

Majorana Versus Dirac

The unitary operation corresponding to exchanging anyons depends only on the topology of the braid. (Source: Wikimedia)
In traditional quantum computing generally Dirac fermions are used as the qubits for quantum computations, but so far this approach has been fraught with complications and challenges, with decoherence and noise intrusion making long-running computations extremely hard and necessitating the need to run computations multiple times for error-correction algorithms to have a shot at divining a plausible result.

This is where topological quantum computing comes into play, as although it imposes some limitations on its feature set, it would be much more resilient to outside influences. Some confusion here may exist with the referencing of Majorana particles, as fermions come in Dirac, Majorana and Weyl flavors. What is referenced here is actually a Majorana anyon, a quasiparticle that just happens to have the same property as Majorana fermions of being its own antiparticle.

By combining these anyons with braid theory using the intertwining of the anyon world lines it becomes possible to perform operations, which theoretically can be used to create a topological quantum computer.

Essentially, this swaps the very fickle, trapped quantum particles for significantly more stable braided Majorana anyons, which – if confirmed – could herald a significant breakthrough in the world of quantum computing.

Is It Majorana Shaped?

Even if you have created a device that theoretically should create Majorana fermions, the next challenge is to confirm that this is in fact the case. This, roughly speaking, is the challenging point where Microsoft’s attempts the past years have repeatedly ending up beaching themselves. As mentioned earlier, the evidence here is determined indirectly rather than through simple direct measurements or experiments.

When the first semiconductor transistor was demonstrated at Bell Laboratories in 1947 in the form of the world’s first point-contact transistor, it came after many years of theorizing and failed attempts starting in at least the 1920s.

Here the evidence of a working transistor was impossible to ignore, as it obviously worked as an amplifier of current, with even the simple current- and voltage-measuring devices of the era sufficing to establish the simple truth. Subsequently this design was commercialized before eventually being replaced with the bipolar junction transistor and a flurry of other devices that followed once the basic principles had been demonstrated.

In the case of quantum processors, whether traditional or topological, there is no obvious way to replicate such a basic demonstration at this point in time. Even the far more basic case of quantum annealing in the form of D-Wave’s commercial offerings is mired in controversy whether there is any ‘quantum advantage’ to be found here. This is territory where even mighty IBM has seen its quantum advantage claims trolled and outperformed by researchers using a lowly Commodore 64.

Where it concerns Majorana anyons and evidence of MZM, you can of course try to build a finished device that demonstrates a clear quantum advantage, or you can build a more limited device where you deduce the existence of these fundamental elements based on what remain mostly theoretical assumptions.

For its most recent attempt at proving that they had succeeded at creating these anyons and with it topological superconductors, Microsoft’s team used a new procedure they called the Topological Gap Protocol (TGP), which purportedly was able to perform a parity readout from their manufactured devices and use this to prove that they had really achieved their goal this time.

Broadside Peer Review

Consequently, Legg’s most recent critique comes as response to Microsoft Azure Quantum’s paper in Nature which got published as a result of that new approach. In this paper it’s claimed that this time they really did detect topological qubits in this improved test setup with TGP, based on – again – indirect measurements and analysis of recorded data. In Legg’s critique it is this analysis of the measurements that’s being attacked as having been performed incorrectly.

The main issue that he identifies is a selective interpretation of the measurements, focusing on the data that supports the experiment’s assumptions, in what would essentially be confirmation bias. There’s also the argument that Microsoft’s researchers made a number of mistakes in their Python code, where they use the array index rather than its value. After adjusting for said basic Python errors, Legg then got entirely different results based on the same measurements.
Impact of coding artefacts on transport based topological gap detection (Credit: Legg, Nature, 2026)
As noted by Legg, you can get very similar data signatures from sources like quantum dots. Along with the somewhat fundamental data processing issues, this obviously puts into question just how close the Microsoft team was to actually having created these topological qubits.

Microsoft Strikes Back

Model of Microsoft’s system, example energy spectra and the gate layout for the interference loop. (Credit: Microsoft Azure Quantum)
Of course, Microsoft’s team got in their reply (paywalled) after taking that broadside salvo. Their main arguments seem to be that TGP has no role in interpreting the RF results – being just a tune-up procedure – that form the basis of the original conclusions, nor do they recognize the issues with TGP that Legg indicated as being valid.

Another point is that Legg offers no alternative physical model that is capable of reproducing the capacitance signal or the RTS phenomenology, and thus the response basically seems to boil down to a curt ‘nuh uh’.

They did acknowledge an off-by-one pixel bug in the TGP processing, but insist that it is only a minor issue.

Effectively, the criticism is rejected, with the original 2025 paper maintained as being valid. This would mean that these topological qubits were truly detected, and with this knowledge a functional topological quantum processor could be constructed and integrated into a larger system.

The Science Continues

As much as academics and science in general can often appear to resemble a shooting gallery where the parties involved are happy to do some sniping, ultimately the scientific method has to prevail. This means the publishing of results, of experimental setups and methods with sufficient details that other researchers can attempt to reproduce the results from fundamentals.

If the Microsoft researchers are correct, then this might be a point-contact transistor moment within the world of quantum computing, which would naturally quickly be confirmed by other teams who would create their own devices and run their own tests, making it a historical fact.

Of course, just in the past few years we saw the Korean LK-99 room temperature superconductor and the controversial EmDrive meet a dismal end at the uncaring hands of peer review, while cold fusion is clinging on in a continuous state of limbo, even as it’s now called ‘low-energy nuclear reactions’.

Perhaps the best part of science is that even if nothing comes out of a research direction, it still offers a fascinating opportunity to learn more about physics, mathematics and so much more. Just in the course of writing this article I had to expand my knowledge of some subjects and refresh it on others. Ultimately this makes even something as controversial as topological quantum computing such a delightful topic to occasionally dive into.

---

hackaday.com/2026/06/30/micros…

---

The NOISFERATU is an open source generative textural sound synthesizer, or as creator [Robert Heel] puts it, “a sound designer’s dream and audiophile’s worst nightmare”.

NOISEFERATU offers 45 different sound algorithms grouped into five banks produce a dazzling range of evolving soundscapes and patterns that resist repetition or settling, each influenced and shaped — the word controlled does not quite apply — by a volume slider and a few hardware knobs.

So what does it actually sound like? Check out the video embedded below to give it a listen, it’s pretty trippy.

Hardware-wise NOISEFERATU is centered around the Seeed Studio XIAO SAMD21 microcontroller, takes power over USB-C, and has a headphone jack for sound output. We love the artwork on the dual-sided front panel, too.

DIY synthesizers based on logic chips have a long and proud history, and seeing the different directions people can go by incorporating microcontrollers is always a delight.

If NOISEFERATU’s experimental sound and noise sounds up your alley, the design files and code on GitHub have everything one should need to build one. Kits are for sale direct from the designer, as well.

youtube.com/embed/kAjsbi65Gq8?…

---

hackaday.com/2026/06/30/bite-i…

---

When you’re driving your car, you’re probably regularly looking at the speedometer to make sure you comply with the local speed limits. The method by which it works is simple enough: the rotation of the wheels is sent mechanically via a cable to a dial on the dash, or an electronic sensor counts the rotations of the drivetrain and an electronically-controlled needle or display shows the speed.

But what about if you were in an aircraft, and the wheels had nothing to do with how fast you were going? How would you even begin to measure speed? There are two ways: there’s a convenient solution to this problem rooted in simple fluid mechanics, and a far-more-complex modern solution. Today, we’ll explore how planes and helicopters are able to figure out how fast they’re going, by the old ways and the new.

Classical Methods

Measuring airspeed can be achieved by measuring stagnation pressure with a pitot tube, and comparing this to static pressure. This can be done at different points on the aircraft, or a pitot-static tube can be used, which measures both stagnation pressure and static pressure in a single probe. Credit: Chaos386, CC BY-SA 3.0
A key thing most aviators want to know is how fast their aircraft is going. Specifically, it’s nice to know how fast it’s moving relative to the airstream around it, which is referred to as airspeed. This is important, because it’s the aircraft’s velocity relative to the flow, such as wind, that determines the performance of the airfoils, how much lift is generated, and whether or not the aircraft is approaching a stall condition where it might fall out of the sky.
Bernoulli’s equation, rearranged to find airspeed (u), by subtracting static pressure from stagnation pressure, multiplying it by 2, dividing by fluid density, and taking the square root of that result.
Measuring airspeed is most commonly achieved with the use of a device called a Pitot tube. The pitot tube is a tube with a hole in one end that points directly into the airflow in the direction of travel of the aircraft.

As air flows in, it reaches a dead end and the flow slows to a stop, or stagnates, since it has nowhere to go. This allows a pressure sensor or a manometer or other device to measure the stagnation pressure at this point. The stagnation pressure measurement is related to the flowspeed of the incoming air since the kinetic energy of the flow is converted to pressure as the flow comes to a halt.

A secondary tube, pointing perpendicular to the airflow, is then used to measure the static pressure of the surrounding air, without the ram effect of the air being forced in by the aircraft’s forward motion. Then, it’s possible to calculate the velocity of the aircraft relative to the airstream by plugging the stagnation pressure and static pressure into a rearranged Bernoulli’s equation. If the pitot tube and static tube are hooked up to electronic sensors, the airspeed can be calculated electronically, and fed to a display or digital gauge.
A classic airspeed indicator has the pitot tube and static tube feeding right into the gauge in the cockpit. The pressure differential causes the diaphragm to expand as the airspeed increases, which mvoes a mechanism causing the needle to move on the gauge. Credit: FAA, public domain
Alternatively, it’s possible to effectively do this “calculation” mechanically. In earlier days, static and stagnation pressure captured by each tube would be fed to a gauge. Inside, the stagnation pressure would be fed to a diaphragm which moved due to the difference relative to the static pressure which is fed into the gauge body, and the movement of the diaphragm would, via a simple mechanism, shift the needle on the gauge.

A small General Aviation aircraft might mount a single pitot tube on the aircraft, feeding the air speed instrument in the cockpit. Commercial aircraft might mount two or more for safety’s sake, in case one becomes inoperable, while large airliners may have four or even more to provide a high level of redundancy and error checking. Heaters are commonly included on pitot tubes to ensure they can be kept free of ice, which can otherwise completely block a tube and make it impossible to obtain an airspeed reading.
Pitot tubes sticking out in the airstream underneath a Boeing 777-381. Credit: Cassiopeia sweet, public domain
For pilots, not knowing how fast (or slow) the aircraft is going can be highly dangerous, as it can lead to entering unstable flight regimes such as stall. Thus, it’s imperative that the pitot tubes remain unobstructed and functional for safe flight. Many aircraft accidents have occurred because of blocked or malfunctioning pitot tubes or airspeed instruments.

The New Way

Of course, you could fuss about with pitot tubes and pressure sensors and deicing measures, but that’s all very fiddly and old hat. There is an entirely different way to figure out a plane’s speed, though it’s only been available for the last few decades. It’s as simple as throwing a GNSS receiver on the aircraft.

Yes, whether your particular poison is GPS, Baidou, GLONASS, or Galileo, any major satellite navigation system will be able to tell you the speed of your receiver. Simply measuring the change in the receiver’s position over time is enough to calculate out the speed, and any off-the-shelf receiver will present this information as standard. It’s generally not used as a primary indicator in aircraft, because it reports ground speed, not airspeed, the latter being more relevant for aviation purposes. Still, it can prove to be a useful sense check when traditional airspeed indicators are non-operative or reporting confusing data, and GNSS devices are widely used on many aircraft today.

Flying High

Many modern aircraft have so-called “glass cockpit” displays that include feeds from GNSS receivers, which can provide supplementary data such as satellite-based ground speed measurements. However, these readings are generally not used for the primary task of flying the aircraft. Credit: Bluedisk, CC BY-SA 3.0
If you’ve ever wondered how an aircraft measures its speed as it floats through the amorphous gas cloud we call an atmosphere, now you know. Even to this day, where electronics and computer wizardry control our fanciest aircraft, airspeed measurements are still done with the same simple physics, just with some fancier sensors for help. The fundamentals haven’t changed at all. Now you know, you can always dig deeper into the many other rich applications of Bernoulli’s equation and fluid mechanics in general. Happy learning.

---

hackaday.com/2026/06/30/how-ai…

---

IT'S TUESDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and I have a confession: I have World Cup fever. And despite England's poor performances against Ghana and Panama, I can't help but whisper: It's coming home.

A couple of housekeeping points: Apologies for the newsletter coming to you a day early. That's down to travel, but no excuses. I'll also be on vacation next week, so there won't be a Digital Politics edition on July 6. Finally, happy early July 4th to all US readers.

— Regulators and companies are speaking past each other when it comes to the litany of new digital regulatory challenges that lie ahead.

— Europe has drunk the kool-aid on tech sovereignty. It risks putting its ambitions over the practicalities of implementing those proposals.

— Four out of every 10 Americans now use AI chatbots at work.

Let's get started:

---

---

digitalpolitics.co/digital-reg…

---

Reverse-osmosis (RO) systems are one way to ensure that you get very clean drinking water. The Waterdrop G3P600 variety that [Tomasz Wasilczyk] recently purchased is definitely among the fanciest and ‘smartest’, with the faucet having its own 7-segment display and gaggle of LEDs connected to the actual RO unit with a four-pin connector. This naturally meant that whatever protocol runs on this cable had to be reverse-engineered for science.
Now with more custom PCB.
The main practical benefit here is to make the system smarter — such as plugging it into a home automation system with ESPHome support, as well as make it play nice with refrigerator lines.

What automation and monitoring options exist here thus depend on what data gets sent between the RO unit and the faucet. Fortunately this turned out to be quite extensive, ranging from filter health, the water quality and pump status as well as air temperature and faucet state.

Unsurprisingly the four-pin connector turned out to be a basic serial link, with 5 V, ground and a 9,600 baud connection. From this it was easy enough to deduce the protocol, and by looking at what lit up on the faucet, a custom PCB wasn’t far behind.

After one blown-up fuse later due to getting 24 V instead of 12 V on the RO unit when tapping off power, the unit popped to life and was able to be connected to Home Assistant, from where the entire functionality and what triggered what could be mapped out. Of course, there’s still more to be discovered and reverse-engineered in the unit, but this seems like a good place to start.

---

hackaday.com/2026/06/30/hackin…

---

Introduction

We continue to share details on the malicious techniques and toolsets used by the ToddyCat APT group. In the first part of this report, we examined the group’s attacks aimed at stealing data from browsers, as well as from local and cloud email services. The methods used in that campaign indicated that ToddyCat was attempting to access corporate correspondence while evading monitoring tools. However, all of the group’s methods we described previously are effectively detected by EPP and EDR solutions.

The attackers continued their search for ways to bypass security solutions and developed a new tool to gain access to a victim’s cloud account via the Google API. Armed with this tool, the group automated all stages of the attack and managed to remain undetected by monitoring systems.

In this part of the report, we break down the mechanics of this new attack and analyze the tool that was used to automate it. We’ll also discuss how to detect and defend against this threat.

Umbrij

In this campaign, the attackers focused their attention on corporate email communications hosted on Gmail, targeting access compromise via APIs. Because the Google API relies on the OAuth 2.0 protocol for authorization, applications can use an OAuth token to access requested email resources. To acquire this token, the threat actors developed a tool called Umbrij and used it to connect to the browser’s management console in headless mode via a remote debugging port. Through a series of requests, they obtained an OAuth authorization code, which they subsequently exchanged for an access token to reach the target resources via the API. We have dubbed this technique Shadow Token via Remote Debug (STRD).

This attack is viable on Chromium-based browsers. If the user has not logged out of their Gmail account, the browser maintains an active session. The attackers exploit this: they launch the browser, connect via the remote debugging port to take control, and send a request to the Gmail service to grant access to the Google account resources within the context of the user’s saved session.

During our investigation of this attack, we discovered several versions of the Umbrij tool. These versions included a variety of helper functions designed for debugging, as well as for searching and selecting user accounts within the browser, among other tasks.

Kaspersky solutions detect this tool with the following verdicts: HEUR:Trojan-PSW.MSIL.Umbrij.gen, HEUR:Trojan.MSIL.Agent.gen, HEUR:Trojan-PSW.MSIL.Agent.gen.

Execution

The Umbrij tool was discovered during a proactive threat hunting operation: a scheduled task, KasperskyEndpointSecurityEDRAvp, was running on a user host, launching a digitally signed file. Kaspersky solutions do not create scheduled tasks with that name; the attackers were attempting to masquerade their malicious activity as a legitimate process.

The signed file then used the DLL sideloading technique to load the malicious tool.

Umbrij execution events within Kaspersky Managed Detection and Response

Throughout our observation period, we identified the following legitimate files vulnerable to the DLL sideloading technique that were used to launch Umbrij:

1. BDSubWiz.exe: a component of the Submission Wizard in Bitdefender ConnectAgent, which is used to support connection features and interaction with other Bitdefender services or agents. This file insecurely loads a file named log.dll.
2. VSTestVideoRecorder.exe: a component of the video-recording tool used for testing with Visual Studio (VS Test). This executable insecurely loads a file named Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll.
3. GoogleDesktop.exe: the discontinued Google Desktop Search application for indexing files and performing quick searches on a local Windows computer. This executable insecurely loads a file named GoogleServices.dll.

These files were used to load different versions of Umbrij; the same legitimate file could be leveraged to launch more than one variant. In total, we discovered three versions of Umbrij, which we refer to as a, b, and c for convenience.

The tool itself is a DLL written in .NET and obfuscated with ConfuserEx, an open-source obfuscator for .NET applications.

Example of an obfuscated code snippet

Umbrij is managed with the help of parameters passed through a command line at startup, although it is occasionally executed without any parameters. Below are examples of the command lines observed in attacks against users:
"c:\Users\Public\BDSubWiz.exe" -regex <name> -deepsearch
c:\windows\vss\bds.exe
However, these are not the only parameters the tool can accept and process. During the analysis of its executable code, we discovered additional parameters that vary depending on the version of Umbrij. See the table below for the parameters and their descriptions.

Version	Command	Description
a	-regex <string>	Used in conjunction with the -deepsearch parameter. Specifies a substring to search for within the user_name field of the user profile file, which typically contains the email address. The tool will utilize the user profile that matches this specified substring
a	-user <username>	Specifies the system username under which the tool will run
a	-runas-currentuser	Configures Umbrij to run within the execution context of the current user
a	-deepsearch	Enforces additional checks on the user_name field in the user profile: verifying that it is not empty and that it contains the substring specified in the -regex parameter
a, b, c	-path <path>	Specifies the full path to the directory containing the browser’s executable file
a, b, c	-browser <both|msedge|chrome>	Specifies which browser the tool should target: Google Chrome, Microsoft Edge, or both
a, b, c	-debugport <port>	Specifies the remote debugging port number
a, b, c	-sync	When this parameter is specified in the URL, the value 1095133494869 replaces 279448736670 in the permission request
b	-domainAd	Specifies the domain name if the user account is a domain account
b	-savepdf	Instructs Umbrij to save a screenshot of the user profile as a PDF file
c	-lport	Same as debugport

Environment preparation

At startup, the tool evaluates several prerequisites required to carry out the attack and performs preparatory actions to subsequently compromise the Gmail account.

First, Umbrij verifies the availability of the port that will be designated for browser debugging. To accomplish this, the tool utilizes a function named ChekPortAvailable() (original spelling retained), which accepts the target port number as a parameter. It then retrieves information about active connections on the host using the .NET GetActiveTcpConnections() function from the System.Net.NetworkInformation namespace. The tool iterates through each connection in a loop, comparing the port number to the one it is checking.

The ChekPortAvailable function used to verify open ports

After this, the tool retrieves the user context. It searches the system for the explorer.exe process and duplicates its token, retaining all of its privileges (T1134.003 Access Token Manipulation: Make and Impersonate Token). This is the exact same mechanism used by another tool in the group’s arsenal, TomBerBil, which we covered previously.

The ImpersonateWithProcess function used to retrieve user context

By default, Umbrij duplicates the token of the first explorer.exe process it encounters. If multiple users are logged in to the system, the -user <username> switch can be used to specify the name of the target user whose token to duplicate. If the -runas-currentuser switch is specified, the tool will execute within the context of the current user without duplicating any tokens.

Next, Umbrij constructs the path to the browser application folder within the user’s local application data repository. To do this, it uses the Environment.SpecialFolder.LocalApplicationData command to retrieve the repository directory from the environment variable and appends the directory of the target browser. The tool then searches for the Local State file in the following folders:

• %LOCALAPPDATA%\Google\Chrome\User Data\Local State
• %LOCALAPPDATA%\Microsoft\Edge\User Data\Local State

See below for an example of the Local State file structure.

Structure of the Local State JSON file

Within this file, the tool searches for the info_cache array, which stores information about browser user profiles. Umbrij enumerates all user profiles and looks for those containing a user_name field that includes an email address. The presence of an email address indicates that the user is authenticated to a Google service. While the tool can interact with every profile it finds, if the -regex <string> parameter is passed through a command line, it searches for the specified substring within the email addresses being enumerated and proceeds exclusively with those matches.

Next, Umbrij creates the following directories for Google Chrome and Microsoft Edge, respectively:

• %LOCALAPPDATA%\Google\Chrome\BackupFiles\
• %LOCALAPPDATA%\Microsoft\Edge\BackupFiles\

The tool copies the following user files and folders of each target user profile into these directories:

• IndexedDB: a folder containing a relational database used for client-side storage of structured data
• Local Storage: a component of the browser’s web storage that provides a key-value mechanism for storing data on the client side
• Network: a folder where the browser stores files related to network requests and caching, such as the network cache and session files
• Login Data: a file that stores saved passwords for various websites and applications
• Login Data For Account: a file that stores credentials associated with a Google account or other synchronized accounts within the browser
• Preferences: a file containing profile-level browser settings
• Secure Preferences: a file that stores protected configurations, such as security and synchronization data
• Web Data: a file that stores auto-fill data

If these files are locked by other processes, the tool includes a dedicated function to force-copy them.

The ForceCopyFolder function used to copy files locked by other processes

As the next step, the tool searches the “Program Files” and “Program Files (x86)” directories for the browser installation folder. Once it locates the executable file and successfully copies all required files, it is ready to proceed with acquiring the authorization code.

Acquiring the authorization code

In the next phase of execution, Umbrij launches Google Chrome, Microsoft Edge, or both browsers sequentially, depending on the parameters passed in the command line. It then passes arguments to the browser based on the following template:
"\"{1}\" --user-data-dir=\"{0}\" --remote-debugging-port={2} --profile-directory=\"Default\" --headless google.com/
It populates the template with the following values:

• {0}: the path to \BackupFiles\, where the user profile files were copied
• {1}: the path to the browser executable file
• {2}: the remote debugging port number

The table below describes the parameters used in this browser launch template:

Parameter	Description
–user-data-dir	Specifies the path to the root directory that will store the shared browser data and user profiles
–remote-debugging-port	Opens a port for remote browser debugging over the DevTools protocol. This switch is commonly used for automated testing with frameworks like Selenium
–profile-directory	Specifies the name of the specific profile folder within the user-data-dir
–headless	Launches the browser in headless mode, that is, without a graphical user interface

The browser process runs in headless mode while utilizing the copied user profile. Consequently, all active user cookies are applied, which means sites with saved credentials will skip authentication prompts. Furthermore, the browser will log history to a new folder, keeping it completely hidden from the user’s primary account view.

Through this method, the threat actors gain access to the user’s authenticated sessions — specifically their Google account — along with the ability to erase any trace of their activity within the browser.

Code snippet showing Umbrij connecting to the browser via the debugging port

Next, the tool uses the Puppeteer Sharp library, a .NET version of Puppeteer, to connect to the remote debugging port. Puppeteer provides a high-level API to control Chrome or Chromium browsers over the DevTools protocol. Its primary use is for automated testing.

The Puppeteer module GitHub page

If the connection to the remote debugging port is successful, Umbrij sends a GET request to direct the browser to the following URL:
https[:]//accounts[.]google[.]com/o/oauth2/v2/auth/identifier?response_type=code&client_id=279448736670.apps.googleusercontent.com&redirect_uri=http%3A%2F%2Flocalhost&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar.readonly%20https%3A%2F%2Fwww.google.com%2Fm8%2Ffeeds%2F%20https%3A%2F%2Fwww.google.com%2Fm8%2Ffeeds%2F%20https%3A%2F%2Fmail.google.com%2F%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fgmail.insert%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fgmail.labels%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fadmin.directory.user%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Ftasks%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fadmin.directory.group.readonly%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fapps.groups.migration%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&flowName=GeneralOAuthFlow
The value specified in the client_id field belongs to Google Workspace Migration for Microsoft Outlook (GWMMO). This is Google’s official tool for importing email, calendar events, and contacts from Microsoft Exchange accounts or local PST files into a Google Workspace account.

Umbrij also includes the ability to switch the client_id value from 279448736670 to 1095133494869 by using the -sync parameter. This second identifier belongs to another application: Google Workspace Sync for Microsoft Outlook (GWSMO), which allows users to sync email, calendars, and other data from the cloud account directly into Microsoft Outlook.

Code snippet where the client_id replacement occurs

The remaining parameters used in the request differ from those typically utilized by the legitimate applications. See the table below for a comparison of these parameters:

GET request parameter	URL used by Umbrij	Original URL
flowName=GeneralOAuthFlow	Present	Absent
code_challenge (PKCE)	Absent	Present (method=S256)
state	Absent	Present
login_hint	Absent	Present
redirect_uri	http://localhost	http://localhost:61619/callback

As seen from the list above, Umbrij omits several parameters characteristic of the legitimate applications. For instance, Umbrij drops the code_challenge parameter, normally used for data protection when retrieving an authorization code. Additionally, the tool modifies the redirection address: while the legitimate application specifies a dedicated port and a callback path, the tool simply points to localhost.

The authorization code request specifies the set of permissions for Google services required by the application. This list also differs significantly between requests issued by the legitimate application and those generated by Umbrij. The table below details the variations in the requested scopes:

Service parameter	URL used by Umbrij	Original URL
google.com/m8/feeds/	Present (specified twice)	Absent
googleapis.com/auth/contacts	Absent	Present
googleapis.com/auth/admin.dire…	Absent	Present
googleapis.com/auth/peopleapi.…	Absent	Present

After the browser navigates to the URL provided by Umbrij, the Google account selection page opens.

Account selection

Because the attackers copied the victim’s profile folder and are operating within their specific environment, the account selection options will include the currently signed-in user’s authenticated session. Umbrij identifies the corresponding element within the page’s HTML source code.

Searching for HTML code elements on the page

The tool uses JavaScript to emulate a mouse click on the elements, allowing it to proceed to the next step.

Simulating a mouse click on a page element

The subsequent step opens a page displaying the list of requested permissions.

Confirming the list of requested access permissions

As shown in the screenshot, Umbrij requests full access to email, cloud storage, and contacts. Just like in the previous step, it uses JavaScript to click the “Allow” button, which completes the authentication process.

The browser is then redirected to the local address that was specified in the redirect_uri parameter of the initial request. The tool intentionally omits a port and a path to a specific page in the redirect_uri because the true objective of this action is simply to capture the code parameter from the context of the GET request. This parameter contains the OAuth authorization code. To retrieve it, Umbrij extracts the substring located between the code= and &scope parameters.

Extracting the authorization code from the GET request

Results

Umbrij, like most other tools in ToddyCat’s arsenal, logs its actions in detail and saves them to a file. It also saves the retrieved authorization code to this log file, which the operator subsequently exfiltrates from the compromised host.

Below is an example of a log file generated by version a of the tool.
------------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

switch to sync mode.
[!] port 11111 is available! Impersonate <username> success! browser switch to chrome .
Parsing C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Local State ... detected profile: Profile 4 ==> <email>@gmail.com ready auth for <email>@gmail.com. Browser Exe path C:\Program Files\Google\Chrome\Application\chrome.exe.
[!] CreateProcessAsUserW... Browser created with pid 3108
[???] <email>@gmail.com
[pup] mail : <email>@gmail.com
[pup] account choice click !
[pup] Allow click !
[<email>@gmail.com] 4%2F0AcvDMrDtzQaC-TT8<hash>uMhg RevertToSelf succeed!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The log indicates that the sync mode is selected (meaning the Google Workspace Sync for Microsoft Outlook application is used) and the debugging port is set to 11111. After locating the user profile and copying its folder, Umbrij launches Google Chrome. After this, the tool emulates clicks on the appropriate buttons to confirm permissions, ultimately outputting the final result of the operation: the stolen OAuth authorization code.

Since all requests occur within a background browser instance, the tool includes a feature to generate a PDF snapshot of the web page where the permission confirmation process halted in the event of an error.

Saving a web page as a PDF file in the case of an error

Additionally, the tool can create a PDF file for the user profile in Google Chrome and Microsoft Edge by navigating to the following internal addresses:

• edge://profile-internals
• chrome://profile-internals

Example contents of a generated PDF file

The acquired authorization code is then exchanged for an OAuth access token. The threat actors use that token to connect to the Gmail account through the API, thus compromising corporate email communications. The diagram below illustrates the complete attack workflow.

Umbrij workflow diagram

Detection

DLL sideloading

First and foremost, defenders should monitor library loading events (DLL loads) associated with the known applications vulnerable to DLL sideloading that are exploited by this tool: Bitdefender ConnectAgent, Visual Studio, and Google Desktop Search.
title: Possible Dll Hijacking Of Microsoft VisualStudio QualityTools dll
id: 246f1409-2993-46f6-9b77-e447a327df5d
status: experimental
description: Detects possible DLL hijacking of Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll by looking for suspicious image loads, loading this DLL from unexpected locations
author: kaspersky
date: 2025-08-11
tags:
- attack.defense-evasion
- attack.t1574.001
logsource:
product: windows
category: image_load
detection:
selection:
ImageLoaded|endswith: 'Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll'
filter:
ImageLoaded|contains: '\IDE\Extensions\TestPlatform\Extensions\'
condition: selection
falsepositives: Legitimate activity
level: high

Browser launch

Launching a browser with a remote debugging port specified is a highly unusual event on standard user hosts that are not running web application development or automated testing workflows. Consequently, monitoring for these specific command-line arguments can serve as a reliable indicator of this attack.
title: Launching Chrome With Debug Parameters
id: f072803f-3cf4-4537-82e6-e8b3a201d99f
status: stable
description: Detects the execution of Chromium based browsers launched with incognito mode and remote debugging enabled
author: kaspersky
date: 2025-12-11
tags:
- attack.lateral_movement
- attack.defense_evasion
- attack.t1550.001
logsource:
category: process_creation
product: windows

detection:
selection:
CommandLine|contains|all:
- '--remote-debugging-port'
- '--headless'
condition: selection
falsepositives: Opening a browser as part of web application testing. Legitimate activity
level: high

Revoking third-party access

To review the authorization codes granted to applications, navigate to the Google Account settings under the Third-party apps & services section, or access the following URL directly:
myaccount.google.com/connectio…
This page displays a comprehensive list of applications and services that currently have permission to access the account.

List of apps connected to the Google account

If the Google Workspace Migration for Microsoft Outlook or Google Workspace Sync for Microsoft Outlook applications appear in this list but are not actually used within your organization, revoke their access immediately. This will invalidate all potentially compromised OAuth tokens associated with them.

Risk mitigation

Launching a browser with a remote debugging port enabled is inherently suspicious for users who do not engage in web development. For these employees, you can completely disable Chromium-based browser developer tools.

This can be achieved by configuring the DeveloperToolsAvailability policy. To enforce this, set the registry value to 0x00000002 for the following Windows Registry key and restart the browser:
HKLM\Software\Policies\Google\Chrome\DeveloperToolsAvailability
To verify that the policy has been successfully applied, navigate to the browser’s internal policies page at chrome://policy:

Note that while disabling developer tools can successfully disrupt the automated retrieval of the OAuth authorization code, it will not help, however, if the adversary decides to leverage the browser’s graphical user interface (GUI) — though this manual approach is significantly less likely due to the friction it introduces for the attackers. Therefore, as a risk mitigation measure, users should be instructed to explicitly log out of their Google accounts as soon as their sessions are complete.

Takeaways

The ToddyCat APT group continues to search for ways of compromising corporate email communications. We have been tracking the group for a long time and we have observed continuous updates to its arsenal in an attempt to bypass security defenses, even as their core techniques remain consistent. For instance, the group has long relied on DLL sideloading to stealthily drop malicious utilities and scheduled tasks. However, their new tool, Umbrij, automates the attackers’ attempts to gain access to organizational email accounts. This automation not only helps increase the scale and frequency of their attacks but also demonstrates ToddyCat’s strong motivation and advanced technical skills.

To defend against these threats, corporate security teams must monitor for suspicious library loading events initiated by legitimate files, watch for instances of browsers launching in developer mode, and conduct regular audits of third-party applications and services with access permissions to Google accounts. Furthermore, deploying a robust, comprehensive security solution — such as Kaspersky Next — is critical to detect this type of malicious host-based activity in a timely manner.

Indicators of compromise

Additional information about this threat is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

Malicious files
1AB58838E5790EFB22F2D35AB98C0B7D Umbrij ver. a
A7D7D6C4C3F227F7117261C63B9E23A9 Umbrij ver. a
3D3A621F852C42D97FD7260681E42508 Umbrij ver. a
3432DD9AC0DF80EF86EB80BD080F839B Umbrij ver. a
22AAEB4946BA6D2F2E27FEB7DBB295DE Umbrij ver. b
F61FBFB7AA1CD5DC8F70B055B51563E2 Umbrij ver. b
F169D6D172DFB775895A5E2B1540C854 Umbrij ver. c

Legitimate files leveraged for DLL sideloading

MD5	File name	Name of DLL being loaded
9F5F2F0FB0A7F5AA9F16B9A7B6DAD89F	GoogleDesktop.exe	GoogleServices.DLL
28CB7B261F4EB97E8A4B3B0D32F8DEF1	BDSubWiz.exe	log.dll
BAE82A15D1DBFB024617B9B56A8E5F66	VSTestVideoRecorder.exe	Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll

Paths to DLL sideloading files

Path to the file that loads the DLL	Path to the DLL being loaded
C:\Users\<user>\AppData\Local\Temp\BDS.exe	C:\Users\<user>\AppData\Local\Temp\log.dll
C:\Users\Public\BDS.exe	C:\Users\Public\log.dll
c:\users\public\bdsubwiz.exe	C:\Users\Public\log.dll
C:\Windows\Temp\BDS.exe	C:\Windows\Temp\log.dll
c:\windows\vss\bds.exe	C:\Windows\Vss\log.dll
c:\windows\temp\GoogleDesktop.exe	c:\windows\temp\GoogleServices.DLL
c:\windows\temp\VSTestVideoRecorder.exe	c:\windows\temp\Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll

---

securelist.com/toddycat-apt-um…

---

One of the simplest robots to make is a bristlebot — a motor with an offset weight is attached to the head of a toothbrush, and the resulting vibrations will move the contraption across a flat surface. [Very Lazy Pixels] recently took this idea a bit further by turning the Steam Controller into a steerable, bristlebot-like robot.

To drive one’s Steam Controller across a desk, all that is needed is for a computer with a paired controller and a Chromium-based browser. From there, using the WASD buttons, the web interface converts traditional video game inputs into controller motion by spinning the controller’s rumble motors at a specific frequency. With precise control of these motors, the controller can move forwards and backwards and even turn, which is a great deal more advanced than the traditional bristlebots generally manage.

Part of what makes this possible is Valve’s willingness to release information about many of their products to the general public, enabling anyone to modify or upgrade those products to their liking. While not completely open source, it’s a step in the right direction and enables fun projects like these. We’ve seen other Valve products turned into surprisingly barebones single-board computers as well as custom portable workstations thanks to this philosophy.

youtube.com/embed/g-8S8zk4dn8?…

---

hackaday.com/2026/06/30/web-to…