Ti sei mai chiesto come i modelli di intelligenza artificiale trasferiscono i dati alla GPU? Questo articolo spiega in modo semplice i diversi livelli di memoria all'interno di un server AI, perché la memoria della GPU è diventata un collo di bottiglia e quali nuove tecnologie potrebbero migliorare le prestazioni dell'intelligenza artificiale.

buysellram.com/blog/inside-the…

#HBM #HBM4 #GPUMemory #AIInfrastructure #DataCenter #CXL #HighBandwidthFlash #AIHardware #MemoryHierarchy #AIInference #NVMe #ITAD

The 19th century was an absolutely electrifying era, including in a literal sense. Although the phenomenon of electricity had been known by that time for centuries, actually making it do useful work was a much taller order. Aside from big, coal-powered generators, there also was a need for a more compact electrochemical solution, such as in the form of a wet or dry cell. One of the first major commercial successes here came in the form of the Leclanché cell, such as the genuine version that [Big Clive] found in an old UK building’s attic and has now revived.

Invented in 1866 by French scientist Georges Leclanché, the Leclanché cell features an ammonium chloride electrolyte solution, carbon cathode and zinc anode. There’s also a manganese dioxide depolarizer for preventing hydrogen build-up. Here water is the solvent for the ammonium chloride (also known as sal ammoniac).

The version that [Clive] got his grubby mitts on features a glass container, an already partially consumed zinc electrode and a slightly cracked porous ceramic tub that contains the carbon electrode and the manganese dioxide. After placing the components inside the specially shaped glass jar and filling it with an electrolyte mixture of one part ammonium chloride and four parts water by weight, the cell starts generating its approximate 1.4 VDC.

This type of wet cell was very popular, being essentially ‘rechargeable’ by topping up the water and replacing the zinc electrode consumable. They did suffer from a voltage drop-off during use due to increasing internal resistance, something that got improved upon with the zinc-carbon dry cell. Itself effectively an evolution of the Leclanché wet cell.

From there zinc-carbon dry cells got replaced with alkalines, which itself got mostly replaced by NiMH and Li-ion cells. Despite more than a hundred years between the electrochemical cell that [Clive] featured in his video and today’s batteries, it’s clear that this wet cell was quite literally just the Victorian-era equivalent of an alkaline AA cell.

youtube.com/embed/BghbiZ8gtUY?…

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

While the original name of what much of the world knows as the NES was the Nintendo Family Computer, or Famicom for short, it was very rarely used as a family computer. Sure, there was a basic cartridge and an add-on keyboard sold in Japan, but it was always a sideshow to the games.

Nintendo recognized that when they brought their Entertainment System overseas. Most of the various famiclones — which date back to the mid-80s — are the same. BIT in Taiwan had a different idea: their Bit 79 would be a full home computer. Picture a C=64 that plays Nintendo games, and you might not be too far off. [Inkbox] tells the full story in his latest YouTube video, and it’s a must-watch for anyone interested in the history of 8-bit machines that are totally unknown in the West.

BIT were both game makers and system cloners; you may even have seen one of their NES or Atari games, as they were exported widely. By 1989 they’d already gone through a surprising number of Famicom clones, but those were pure clones and just played games. The Bit79 is obviously different — for one, it’s got a built-in keyboard in a wedge case. Apparently a pretty good one at that. For another, it starts with a bootloader that lets you choose between BASIC on ROM and loading the cartridge. For a third, it’s got a full 8K of RAM, quadrupling the Famicom’s offering– plus an additional 2K for the PPU, in what you might consider an early example of video RAM. Both CPU and PPU are knockoff chips made in Taiwan by UMC. The system even has what looks like a DB25 connect a printer. There’s also an expansion port, but no evidence that add-ons were ever sold, despite reports of a 64K memory add-on.

Back to the BASIC ROM for a moment– it’s not Famicom BASIC, as was clear in the manuals. [Inkbox] dumped the ROM to find that it is actually AppleSoft BASIC, of all things. That’s not only an odd bit of piracy, it’s also a big miss, since Apple’s BASIC doesn’t have any commands to make use of the PPU the way Famicom’s version does. POKING the registers during the vBlank integer is apparently not an easy thing to do. Perhaps that’s why we’ve never heard of this machine — well, that, and the fact we’re not located in East Asia where it was sold.

While the Bit79 didn’t sell particularly well, apparently it inspired a whole wave of “educational computer” famiclones in 1990s China that are largely unknown to the English-speaking world, making it an important part of computer history.

While BIT Corp is long gone, if you want to play around with their great experiment in turning a famiclone into a home computer, an emulator is available online, and the ROMs are preserved on the Internet Archive thanks to [InkBox].

Thanks, too, to [Stephen Walters] for the tip.

youtube.com/embed/IZH1rR7WogI?…

hackaday.com/2026/07/06/__tras…

Pity the poor Australians. Isolated on a jagged hunk of land far from everywhere else, these industrious people have to take two-legged flights (or more) to reach a great many destinations in the northern hemisphere. It’s expensive, time consuming, and makes planning a trip a complete headache when wars break out around popular hub airports.

One airline is trying to solve this problem. The nation’s flag carrier, Qantas, has been hard at work on Project Sunrise. The goal is to run some of the longest non-stop commercial passenger flights ever, with great effort going into solving the technical and economic challenges involved.

No Stops

When travelling from Australia’s major capital cities, flights to destinations like London, the rest of Europe, or the US, all involve stopovers in intermediate airports along the way. A great many routes stop in Dubai or Qatar, while others transit through Hong Kong, Singapore, or Thailand. The need for stopovers complicates air travel for the passenger, particularly when delays cause missed connections or baggage gets lost from one flight to another. It can also just be tedious—sometimes a stopover can last 10 hours or more, which is an incredibly uncomfortable amount of time to spend in even the nicest airport. The reason behind stopovers is simple enough—the average commercial airliner just doesn’t have the fuel range to haul many hundreds of passengers from Australia to Europe in a single hop.
Qantas has formerly run long-range routes with Boeing 787-9 aircraft, but they lack the legs to make it from east-coast capitals to major international destinations. Credit: Qantas media resources
Qantas has been trying to improve Australia’s passenger airline links for quite some time by finding ways to eliminate these tedious stopovers entirely. Thus was born Project Sunrise, which hoped to find more direct routes between popular world cities and suitable airliners that could fly those routes without stopping.

An early 2019 test flight probed the practicality of flying from New York to Sydney in a single hop. Due to the limitations of contemporary aircraft, sacrifices were made to get the flight over the line. Where the Boeing 787-9 would normally carry up to 280 passengers, the test flight would only haul 40 to save weight, and thus save fuel. No cargo was on board, and the tanks were brimmed to ensure maximum range was available. Even then, the 16,250 km route was considered to be at 115% of the plane’s normal range, and there was only 90 minutes of contingency when it came to fuel onboard if something went awry. Despite the challenges, the test was a success, and provided useful learnings on how to handle things like crew fatigue on a 19-hour continuous flight.

Qantas was also experimenting with practical revenue services at this time, too. In 2018, the airline had established a direct route from Perth to London, flying the Boeing 787-9 in a 236-seat configuration. Flying the 14,484-kilometer route was just within the practical range of the aircraft. It was a useful route that made travel easier for passengers departing Australia’s west coast, but far from the golden ideal of allowing direct flights to major international destinations from the major capitals of Melbourne and Sydney. The route has also since fell victim to geopolitical strife, as the Iran War shut down large swathes of airspace in early 2026. Qantas was forced to alter its flight paths, which added 30 to 45 minutes to the usual flight time—just enough to tip the route over the practical limitations of the aircraft’s range.

Future Goals

However, the crowing achievement of Project Sunrise is still yet to come. 39% of Australia’s population is concentrated in Sydney and Melbourne alone, with both capitals situated on the country’s east coast. It would be most advantageous from a business perspective for these cities to have direct links to major world destinations, and it would benefit the broadest swathe of Qantas’s customer base. Only, the problem comes back to geography, with these two capitals being over 16,000 kilometers from popular destinations like New York and London.
The A350-1000ULR is key to Qantas’s efforts to launch non-stop services to far-flung destinations. Picture Credit: Stuart Bailey, via Qantas media resources
Qantas has risen to the challenge, regardless. The airline challenged both Boeing and Airbus to develop aircraft intended to fly routes from Sydney, Melbourne, and Brisbane, to destinations like New York, London, Cape Town, Paris, and Rio de Janeiro. This was later whittled down to a narrower focus on the Sydney to New York and Sydney to London routes. Airbus would come out victorious, with Qantas ordering twelve examples of the Airbus A350-1000ULR. The specially-configured model features an additional rear centre fuel tank and a higher maximum take-off weight in order to fly routes up to 22 hours non-stop, along with a reduced seat configuration serving just 238 passengers. The extra range makes for a huge difference compared to more conventional routes out of Australia, which often pair two flights up to 14 hours each. The extra range of the new aircraft saves passengers both hours of flight time, along with the hours normally spent sitting around on layover in a hub airport along the way.
The new aircraft has been undertaking test flights ahead of a planned 2027 launch of revenue services. Credit: Qantas media resources
A typical flight from Sydney to New York or Sydney to London is expected to take 19 to 22 hours. The no-stop nature of the route will enable 99% of Australians to access either destination either direct, or with one-stop—such as by flying in from another major capital on a domestic flight. The flights are expected to run with a higher-than-usual ratio of premium seats, based on the expected demand for these services.

The main thing holding back the new service is aircraft delivery. Production is underway in earnest, with the first A350-1000ULR to be delivered in April 2027. Daily non-stop flights between Sydney and London will begin from October 2027, with tickets to be on sale from February.

youtube.com/embed/wICQ9UbA6J4?…

Aircraft cabins will be optimized to have more space and amenity to keep passengers comfortable on ultra-long-range routes. Key to this is a “Wellbeing Zone” for passengers to stretch their legs and move around more than is practical on a more typical 10- to 14- hour international flight.

The new Project Sunrise services will be a gamechanger for many people travelling to and from Sydney, and other Australian capitals. It will relieve a major pain point—layovers—that have become a dreaded fact of life for Australians headed far abroad. It will still perhaps be some time before Australians get more direct services to a wider range of destinations, because these new services will have to prove themselves. If the passenger numbers aren’t there, the services won’t make money, and it may not prove worth the hassle to operate these ultra-long-range routes. If, however, convenience truly is king, then there may be much greater investment in this area to link Sydney and Melbourne with more cities directly. The only losers in this case will be the hub airports across the world, which will grow just a little quieter for the loss of Aussie accents in the terminal.

hackaday.com/2026/07/06/ultra-…

Cheap vehicles are thin on the ground in 2026, but [Andy Didorosi] thinks he has the answer for low-speed applications with an open source kei truck.

Still in the early design phase, [Didorosi] has an old factory in Detroit that has been home to his bus transportation business for the last several years, as well as the Sendpai kei truck project to make the world’s fastest kei truck. His vision is to make an affordable kit car truck that anyone can build in the comfort of their own garage. The current plan includes hub motors, which have so far not made it into any production EVs in the US, likely due to the problem with high unsprung weight.

While making a new vehicle from scratch is difficult, the project is targeting a modest set of capabilities at the beginning. The truck will be eschewing safety for low cost, which is probably fine for low-speed off-road use as a utility vehicle. Safety will of course get more important as speed increases. Once the design is sufficiently nailed down, [Didorosi] hopes to sell fully assembled trucks that are compliant with US Low Speed Vehicle (LSV) requirements. This would allow it on roads with posted speed limits below 35 mph.

Will Mutiny succeed where efforts like OScar, CarBEN, or Wikispeed could not prevail? Only time will tell. We hope they’ll keep the Minimal Motoring Manifesto in mind, and in the meantime, you should check out this kei camper or an EV-swapped kei truck that looks like it runs on a giant drill battery.

youtube.com/embed/vJJa9zBDa6A?…

hackaday.com/2026/07/06/a-new-…

Blood pressure is one of the so-called “vital signs” that medical practitioners use to determine the basic state of a patient in any given moment. It’s exactly what it sounds like—a measurement of the pressure of the blood flowing through the body, with some complications to account for the pulsatile nature of human blood flow.

You might think measuring blood pressure is a solved concern, and it mostly is. With that said, some blood pressure monitors out there aren’t quite doing their job properly, and [Milos Rasic] came to Hackaday Europe 2026 to spell out the problem.

Under Pressure

youtube.com/embed/BfbqwYLECWM?…

Before exploring the issue, it’s worth first understanding how blood pressure is actually measured. On a baseline level, it’s the same as pressure being measured in any other fluid. Specifically, though, when it comes to blood, it’s important to measure the pressure at two points. There is the peak, when the heart muscle is contracting, referred to as systolic pressure, and the low point, when the heart relaxes, referred to as diastolic pressure. Thus, blood pressure is referred to with two numbers, such as “140 over 90” or 140/90, referring to systolic and diastolic pressures respectively. It’s sometimes important to track the mean arterial pressure, too. Typically, nominal blood pressure would be considered around 120/80 mmHg. High blood pressure, or hypertension, starts at figures over 130/80 mmHg, while low blood pressure, or hypotension, would be considered relevant below 90/60 mmHg.

Blood pressure can be monitored in a number of ways. Most of the time, non-invasive methods are preferred, whether in the doctor’s office or at home. [Milos] notes that the classic hand-pumped blood pressure cuff device (sphygmomanometer) and a stethoscope is still a perfectly excellent way to measure blood pressure in a clinical scenario. This is referred to as the Korotkoff method, where the doctor listens for pulsations in the artery to begin as the pressure of the cuff slowly drops below the systolic pressure, and then later ease as it reduces below the diastolic pressure, monitoring pressure in the cuff on a gauge as they go. Then there are digital versions of arm cuff blood pressure monitors, which [Milos] notes can have some problems. Meanwhile, there are advanced technologies in development to do live measurement with things like mmWave radar devices or ultrasonic tricks, but they’re still emerging and less established in clinical contexts.

Many cheap electronic blood pressure monitors use the oscillometric method to measure blood pressure. Few manufacturers share the algorithms they use, but [Milos] has found many use something similar to the above, approximating systolic and diastolic pressures from measurements taken to find the mean arterial pressure. Credit: presentation slides[Milos’s] talk focuses on the digital oscillometric analysis that is behind cheap electronic blood pressure monitors that commonly retail for $30-50. These devices start by pumping up an arm cuff to well above typical systolic pressures, before slowly letting it deflate. A sensor hooked up to the cuff is used to monitor the pressure during deflation. When the cuff is below systolic pressure but above diastolic pressure, the pressure in the cuff will oscillate with the pulsing of the blood flow. When isolated from the overall pressure loss from deflation, the amplitude of this oscillatory signal is maximum at the mean arterial pressure. According to [Milos], it’s common for electronic blood pressure monitors to then take some figure like 40% and 80% of the amplitude of the oscillation envelope, and grab the systolic and diastolic pressure values at those points. As far as accuracy goes, this method isn’t exactly perfect, being more of a useful approximation rather than something that’s rooted in a true direct measurement. Furthermore, [Milos] notes that, for example, Category A blood pressure monitors are only expected to land within a +/- 15 mmHg range, for 85% of their measurements. That’s not fantastic.

[Milos] has invested a great deal of time into the Open Cardiography Digital Measuring Device, hoping to better investigate alternative methods of measuring blood pressure in a non-invasive manner.[Milos] notes that it’s important to allow the patient to sit still for five minutes before measurement if numbers are to be at all comparable between checks, as many factors can influence blood pressure in the moment.The method used by these electronic devices tends to be a little inaccurate compared to the traditional clinical methods performed by trained professionals. For that reason, [Milos] developed the Open Cardiography Signal Measuring Device. It is specifically designed to test different algorithms for blood pressure measurement. It can measure pressure in an arm cuff, and also takes signals from a photopletyzmography (PPG) clamp for measuring blood oxygen saturation. There are also inputs for ECG and digital stethoscope signals, too. [Milos] has published the device’s design on Github for anyone to explore as desired. His talk explains how the device came together, and how he has been using it to evaluate the accuracy of off-the-shelf monitors and the use of alternative algorithms to those used in such units. He also discusses the challenges of measuring blood pressure accurately in this way when dealing with, for example, patients with less stable heart rates.

It’s an interesting exploration of a very specific part of vital sign measurement that few of us ever think about in detail. Sometimes it pays to know how the machines that you’re getting measurements from actually work, and whether you can trust what they’re saying. In the world of blood pressure measurement, [Milos] has done just that.

hackaday.com/2026/07/06/hackad…

What do you get when you take 8,192 CH570 MCUs, put them on custom PCBs, and write firmware for this interconnected gaggle of cores? In the case of [bitluni]’s project, you get something that’s decidedly cluster-shaped.

These cheap MCUs feature a QingKe 32-bit RISC-V core that’s clocked at a maximum of 100 MHz, with an RV32IMBC instruction set. This means that they support integers, integer multiplication and division, bit manipulation, and compressed instructions, but no atomic, vector, or floating-point instructions.

The basic concept was to use a single MCU per pixel, but once you start scaling up a measly 10 mA and ~$0.10 per MCU to literally tens of thousands of them, you’re suddenly talking about thousands of dollars in hardware as well as a cool 655.36A at 3.3V – or 2 kW – for something close to QVGA resolution at 320×200. Clearly this would be a rather crazy project to implement, which is why each MCU also got its own RGB LED to immediately create the pixel.

In order to fit so many MCUs, the design was split across multiple PCBs, or blades, connected to a backplane. On each blade, a group of MCUs is connected to a controller MCU, in the form of a larger MCU. With some prototype blades assembled and bodges implemented, each single MCU could then be programmed.

For the power supply, a 3 kW Corsair ATX PSU was used to supply power to the subsequent power stages. As a result, the first prototype looks like a pretty fancy addressable RGB LED matrix.

This is said to be only the first step, with this ‘Ultracluster GPU’ still getting a few more levels tacked onto it to make it into something that’s more GPU-shaped. Probably the biggest question here is whether the final version will be able to generate said QVGA output image without needing more power than what a typical 230 V, 16A European outlet can provide.

We think that [Jensen Huang] probably will be more scared of the ESP32-S3-based video card that [bitluni] made before, though at least [bitluni] seems to be having fun making more MCU-based clusters, such as this one from 2024 and this one from 2025.

youtube.com/embed/qMR3IXF2sWw?…

hackaday.com/2026/07/06/gluing…

One of the most common pieces of anti-phishing advice is to double-check the website’s domain name before providing your credentials. Typically, a fraudulent domain stands out to the trained eye, differing from the official URL by at least a few characters. Recently, however, we encountered a campaign where attackers instruct victims to input data directly into a legitimate, trusted corporate site: the Microsoft Identity Platform, which supports an OAuth 2.0 specification known as the Device Authorization Grant.

This specific protocol extension was designed to simplify the login experience for smart TVs, IoT hardware, printers, and other input-constrained devices that lack a full browser or keyboard. It allows users to use a nearby smartphone or PC for authorizing these devices to access their accounts. To complete the process, the user enters a one-time code on a designated authentication page. The Microsoft Identity Platform returns this code along with a link to enter it in response to a request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode; hence, an attack scenario exploiting this mechanism is called Device Code Phishing.
In this post, we break down how the Device Authorization Grant specification (also known as the Device Authorization Grant Flow or Device Code Flow) works, analyze real-world attacks leveraging this technology, and outline effective strategies to defend against Device Code Phishing.

Core steps of Device Authorization Grant

1. Requesting the authorization code

When a user launches an app on a client device, such as a streaming app on a Smart TV, the app detects that it is unauthenticated and sends a POST request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode. This request includes the client_id (the unique identifier of the app registered in Microsoft Entra ID / Azure AD) and the scope (the requested access permissions). In response, the application receives several parameters: device_code (a secret code for internal use), user_code (a short code displayed to the end-user), verification_uri (the login URL the user needs to visit), expires_in (the code’s lifespan), and interval (how frequently the app should poll the server).

2. Displaying the code to the user

The device displays both the user_code and the verification_uri to the user, instructing them to complete authentication on another device. For instance, a smart TV will display the code and URL — often rendering the verification_uri as a QR code — so the user can access it via their smartphone.

3. Entering the code and confirming access

By scanning the QR code with a smartphone camera or manually typing out the address, the user navigates to the verification_uri (such as microsoft.com/devicelogin) and enters the user_code.

4. Polling the server

The device (smart TV) begins polling the server to check the authorization status — essentially verifying whether the user has approved the access request. It does this by sending a POST request to the token endpoint: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. The request passes the grant_type parameter with the value urn:ietf:params:oauth:grant-type:device_code, indicating the use of the Device Authorization Grant method. This signals to the authorization server exactly which authentication method is being used to request access tokens. The server waits for the user to enter the user_code on their secondary device and approve access to their resources or data. Until that approval happens, the server responds with an error code like authorization_pending (keep waiting) or slow_down (reduce the polling frequency).

5. Issuing access tokens

Once the user successfully approves the application’s request, the server responds to the application by issuing an access_token (to access the data), a refresh_token (to renew access later), an id_token (containing user profile details like name and email), along with several other service parameters.

6. Automatic access renewal

The device (our smart TV) uses the refresh_token to silently renew the access_token without requiring any further user interaction. When the current access_token expires (typically after 1 hour), the device automatically sends a token refresh request containing the refresh_token to the token endpoint. It then receives a fresh pair of access and refresh tokens, ensuring the user remains authenticated seamlessly.

While this workflow is truly convenient for input-constrained devices, attackers can abuse it to hijack user accounts and maintain persistent access for extended periods using the issued refresh_token. Let’s use a real-world example to break down this attack vector.

Analysis of a Device Code Phishing attack

The phishing email

In a phishing campaign we observed spanning from early April to mid-May 2026, the initial email was styled as a notice from a law firm. Attached to the email was a password-protected PDF file.

Once the victim opened the PDF and entered the password, they were presented with a landing page listing several documents. However, viewing these documents required clicking a provided link.

PDF file with a malicious link

A close look at the target URL reveals that instead of pointing to a typical, easily recognizable phishing domain, it actually points to a legitimate Microsoft address. However, the URL parameters are configured to redirect the user to a phishing resource.

The link within the document does not keep the user on the Microsoft platform; instead, it immediately redirects them to a phishing page designed to mimic a corporate legal portal.

The phishing page

Interestingly, the landing page featured multiple CAPTCHAs, presumably deployed to filter out security crawlers. Once past these hurdles, the user was routed to a final page that instructed them to copy a one-time code. This code was the user_code that the attacker’s server-side application had already fetched by querying https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, as detailed in the workflow above.

The one-time code

The one-time codeClicking the displayed one-time code automatically copied it to the clipboard while simultaneously redirecting the user to Microsoft’s actual, legitimate authentication page (verification_uri), where they were prompted to paste and enter the code.

Official Microsoft authentication page

Once the user entered the code, it kicked off the Device Authorization Grant flow described earlier. The unsuspecting victim then completed the full MFA process directly on Microsoft’s official page. As soon as authentication succeeded, the attacker harvested the session’s access_token, refresh_token, and id_token. This enabled them to read and send emails from the victim’s mailbox, exfiltrate files from OneDrive, and access Teams conversations.

Adaptation of the attack method

This phishing campaign was limited in scope and spanned slightly more than a month. However, the threat actor continues to actively leverage this method, adapting it to target specific geographic regions. We’ve recently detected slightly modified Device Code Phishing campaigns shifting their focus toward users in Brazil, among others.

The Brazilian phishing variant

Translated from Portuguese:
“Hello!
Your order has just been processed, and the confirmation has been sent to you in PDF format. Please see the details below.
OPEN / DOWNLOAD PDF
A new quote is attached to this email.
Please let me know if you need any further assistance.”

Unlike the previous campaign, this email did not include a malicious PDF attachment. Instead, it embedded a link pointing to cacoo.com, a legitimate online diagramming platform owned by Nulab. Just as before, this trusted domain served as an open redirect to steer the user toward the phishing infrastructure.

The proxy link routes through the legitimate Cacoo.com domain before redirecting to the phishing site
Translated from Portuguese:
Request confirmation
Status Code = Success
DOWNLOAD OR VIEW THE DOCUMENT
Important note: Log in to the account that received this message to securely authenticate the document.

Clicking the link routed the user back to the familiar landing page displaying the one-time code.

Landing page displaying the code

From there, the potential victim was once again redirected to the official Microsoft portal to complete the Device Authorization Grant authentication process.

Official Microsoft page prompting for the user code

How to defend against Device Code Phishing attacks

As our research demonstrates, threat actors don’t always rely on harvesting credentials or deploying malware to access sensitive data — they can just as easily weaponize legitimate tools. Therefore, users must exercise vigilance not only when visiting suspicious sites, but also when navigating official platforms like Microsoft or Cacoo.com.

Recommendations for users

• If you did not personally initiate a login request on an external device using the Microsoft Device Authorization Grant, do not approve the authorization request.
• Never enter an authorization code received via unexpected emails or messages, even if the provided link points directly to an official Microsoft domain.
• Threat actors frequently leverage open redirects on legitimate domains, appending parameters like redirect_uri, return_url, or next after the question mark (?) to point to a malicious destination. Before clicking any link, hover your cursor over it to inspect both the primary domain and any suspicious redirect parameters. Once the page loads, verify that the final URL actually matches the expected asset — this is the absolute minimum requirement before entering corporate credentials.

We strongly advise enterprise teams to evaluate the business necessity of the Device Code Flow within their corporate infrastructure. If this authentication mechanism is not required for daily operations, it should be disabled globally via Conditional Access policies within Microsoft Entra ID. Additionally, security teams should set up dedicated monitoring for DeviceCodeSignIn events, strictly e nforce device compliance states, and configure alerts for anomalous sign-in behavior originating from unusual locations.

To establish a comprehensive defense against Device Code Phishing attacks, organizations should deploy robust email security solutions capable of securing both corporate and personal messages.

securelist.com/microsoft-devic…

[BillPg] has been designing a fantasy 1980s-era home computer. As part of the exercise, he’s reevaluating all the assumptions that have grown organically over time in the small computer landscape. Hindsight is, so they say, 20/20, but sometimes hindsight can also be colored by modern thinking. Sometimes an idea that seems stupid today made sense in the context of its time. In particular, [Bill] has thoughts on the much-maligned 8086 memory segments.

If you haven’t run into it before, the 8086/8088 had a problem. It wanted to be more or less conceptually software compatible with the 8080 and Z80 computers, which had 16-bit addresses, leading to a limit of 64K of memory. When Intel was designing the next generation of chips, it knew that 64K had to go, but telling developers that code would require huge reengineering was a non-starter. So the idea was to provide multiple 64K spaces broken up into segments.

As with most things, there is theory, and there is practice. In theory, a 16-bit segment provided four extra address bits to add to the existing 16-bit address, producing a 32-bit address, even though the CPU only had 20 bits of address bus. Code that fit in 64K could pretend like that was the whole world, and a tricked-out system could have 16 worlds. Future systems could, in theory, have had more.

In practice, Intel made the segment the top 16 bits of a 32-bit address and then added it to the ordinary 16-bit address. So address 0000:0010 (segment=0, address=10 hex) is the same memory location as 0001:0000. Address 0010:0010 is the same as address 0000:0110 and 0001:0100. This wasn’t really the intent, just a byproduct of how the chip worked.

Eventually, the segments would become indices into a table (like the title graphic), but by then, bad practices wiped out a good idea. It is doubtful that the original designers thought anyone would take advantage of the overlapping address, but, of course, they did.

By the time the 80286 and beyond produced segments that were really keys which defined a block of memory, everyone was already in the mode of using the segment and offset as a large pointer. C compilers even had “modes” that let you treat the segment as just more address bits. Because of that, even on newer processors, people had a tendency to build a “flat” segment and use it. That is, make a segment that starts at 0, ends at the end of memory, and then forget about segments.

In fact, many people independently discovered that you could define a flat segment in protected mode, return to real mode, and then enjoy a flat address space. This was later christened unreal mode, and a topic we’ve covered a few times before.

We agree with [Bill]. Segments were a good idea at the time and might have been more important if people had used them the “right” way. Of course, there would have been ups and downs. Proper segments might have allowed for easy virtual memory, for example. But at the price of possibly swapping in and out huge segments instead of relatively small pages. Today, most of what segments were supposed to do is part of the memory management unit and is mostly hidden from the application developer. Still, interesting to reflect on why Intel made that choice and how we got to where we are today.

hackaday.com/2026/07/06/he-com…