[Mukesh Sankhla] has been tinkering in the world of Point of Sale systems of late. His latest creation is a simple, straightforward kiosk system, and he’s open sourced the design.

The Latte Panda MU single-board computer is at the heart of the build, handling primary duties and communicating with the outside world. It’s hooked up to a touchscreen display which shows the various items available for purchase. As an x86 system, the Latte Panda runs Windows 11, along with a simple kiosk software package written in Python. The software uses Google Firebase as a database backend. There’s also an Xiao ESP32 S3 microcontroller in the mix, serving as an interface between the Latte Panda and the thermal printer which is charged with printing receipts.

It’s worth noting that this is just a point-of-sale system; it executes orders, but doesn’t directly deliver or vend anything. With that said, since it’s all open-source, there’s nothing stopping you from upgrading this project further.

We’ve featured other interesting point-of-sale systems before; particularly interesting was the San Francisco restaurant that was completely automated with no human interaction involved

youtube.com/embed/sL1OeTtPDf0?…

hackaday.com/2025/10/01/buildi…

In the middle of the 20th century, the atom was all the rage. Radiation was the shiny new solution to everything while being similarly poorly understood by the general public and a great deal of those working with it.

Against this backdrop, Firestone Tire and Rubber Company decided to sprinkle some radioactive magic into spark plugs. There was some science behind the silliness, but it turns out there are a number of good reasons we’re not using nuke plugs under the hood of cars to this day.

Hot Stuff

The Firestone Polonium spark plug represented a fascinating intersection of Cold War-era nuclear optimism and automotive engineering. These weren’t your garden-variety spark plugs – they contained small amounts of polonium-210. The theory behind radioactive spark plugs was quite simple from an engineering perspective. As the radioactive polonium decayed into lead, it would release alpha particles supposed to ionize the air-fuel mixture in the combustion chamber, making an easier path for the spark to ignite and reducing the likelihood of misfires. Thus, the polonium-210 spark plugs would theoretically create a better, stronger spark and improve combustion efficiency.
Firestone decided polonium, not radium, was the way to go when it filed a patent of its own. Credit: US Patent
These plugs hit the market sometime around 1940, though the idea dates back at least a full 11 years earlier. In 1924, Albert Hubbard applied for a patent (US 1,723,422), which was granted five years later. His patent concerned the use of radium to create an ionized path through the gas inside an engine’s cylinder to improve spark plug performance.

Firestone’s patent (US 2,254,169) came much later, granted in 1941. The company decided that polonium-210 was a more viable radioactive source. Radium was considered “too expensive and dangerous”, while uranium and thorium isotopes were found to be “ineffective.” Polonium, though, was the bee’s knees. From the patent filing:

Frequently, conditions will be so unfavorable that a spark will not occur at all, and it will be necessary to turn the engine over a number of times before a spark occurs. However, if the alpha rays of polonium are passing through the gap, a large number of extra ions are formed by each alpha ray (10,000 ions per-alpha ray) and the gap breaks down promptly after the voltage begins to rise and at a lower voltage value than that required by standard spark plugs. Thus, it might be said that polonium creates favorable conditions for gap breakdown under all circumstances. Many tests have been run which substantiate the above explanations. The most conclusive test of this type consisted in comparing the starting characteristics of many polonium-containing spark plugs with ordinary spark plugs, all plugs having had more than a year of hard service, in several engines at -15° F. It was found that thirty per cent fewer revolutions of an engine were required for starting when the polonium plugs were used.

Firestone was quite proud of its new Atomic Age product. Credit: Firestone
As per the patent, the radioactive material was incorporated into the electrodes by adding it to the nickel alloy used to produce them. This would put it in prime position to ionize the air charge in the spark gap where it mattered most.

The science seems to check out on paper, but polonium spark plugs were only on the market for a short period of time, with the last known advertisements being published sometime around 1953. If the radioactive spark plugs had serious performance benefits, one suspects they might have stuck around. However, physics tells us they may not have been that special in reality.

In particular, polonium-210 has a relatively short half-life of just 138 days. In a year, 84% of the initial polonium-210 would have already decayed. Thus, between manufacturing, shipping, purchase, and installation, it’s hard to say how much “heat” would have been left in the plugs by the time they even reached the consumer. These plugs would quickly lose their magic simply sitting on the shelf. Beyond that, there are some questions of their performance in a real working engine. Firestone’s patent claimed improved performance over time, but a more sceptical view would be that deposits left on the spark plug electrodes over time would easily block any alpha particles that would otherwise be emitted to help cause ionization.
Examples of the polonium-impregnated spark plugs can be readily found online, though the radioactive material decayed away long ago. Credit: eBay
Ultimately, while the plugs may have had some small benefit when new, any additional performance was minor enough that they never really found a market. Couple this with ugly problems around dispersal, storage, and disposal of radioactive material, and it’s perhaps quite a good thing that these plugs didn’t really catch on.

Despite the lack of market success, however, it’s still possible to find these spark plugs in the wild today. A simple search on online auction sites will turn up dozens of examples, though don’t expect them to show up glowing. The radioactive material within will long have decayed to the point where they’re not going to significantly exceed typical background radiation. Still, they’re an interesting call back to an era when radioactivity was the hottest new thing on the block.

hackaday.com/2025/10/01/the-ho…

Broadcom ha risolto una grave vulnerabilità di escalation dei privilegi in VMware Aria Operations e VMware Tools, che era stata sfruttata in attacchi a partire da ottobre 2024. Al problema è stato assegnato l’identificativo CVE-2025-41244. Sebbene l’azienda non abbia segnalato alcun exploit nel bollettino ufficiale, il ricercatore di NVISO Maxime Thibault lo ha segnalato a maggio che gli attacchi sono iniziati a metà ottobre 2024. L’analisi ha collegato gli attacchi al gruppo cinese UNC5174.

La vulnerabilità consente a un utente locale senza privilegi di inserire un file binario dannoso in directory che corrispondono a espressioni regolari generiche. Una variante osservata in attacchi reali è l’utilizzo della directory /tmp/httpd. Affinché il malware venga rilevato dal servizio VMware, è necessario eseguirlo come utente normale e aprire un socket di rete casuale.

Di conseguenza, gli aggressori ottengono la possibilità di aumentare i privilegi di root ed eseguire codice arbitrario all’interno della macchina virtuale. NVISO ha anche pubblicato un exploit dimostrativo che mostra come questa falla venga utilizzata per compromettere VMware Aria Operations in modalità con credenziali e VMware Tools in modalità senza credenziali.

Secondo Google Mandiant, UNC5174 opera per conto del Ministero della Sicurezza di Stato cinese. Nel 2023, il gruppo ha venduto l’accesso alle reti di appaltatori della difesa statunitensi, agenzie governative britanniche e organizzazioni asiatiche sfruttando la vulnerabilità CVE-2023-46747 in F5 BIG-IP.

Nel febbraio 2024, hanno sfruttato la vulnerabilità CVE-2024-1709 in ConnectWise ScreenConnect, attaccando centinaia di istituzioni negli Stati Uniti e in Canada.

Nella primavera del 2025, il gruppo è stato osservato anche mentre sfruttava la vulnerabilità CVE-2025-31324 , un errore di caricamento file in NetWeaver Visual Composer che consentiva l’esecuzione di codice arbitrario. Anche altri gruppi cinesi hanno partecipato ad attacchi ai sistemi SAP, tra cui Chaya_004, UNC5221 e CL-STA-0048, che hanno installato backdoor su oltre 580 istanze NetWeaver, comprese quelle in infrastrutture critiche negli Stati Uniti e nel Regno Unito.

L'articolo Un bug critico in VMware Aria Operations e VMware Tools utilizzato da mesi dagli hacker cinesi proviene da il blog della sicurezza informatica.

Dopo tre anni, perfino i ricercatori di OpenAI ammettono che le "allucinazioni" sono una caratteristica intrinseca dei modelli linguistici. Dopo tre anni, perfino il Wall Street Journal comincia a parlare di bolla speculativa dell'AI. Preparatevi.

spreaker.com/episode/dk-10x04-…

You can buy all kinds of keyboards these days, from basic big-brand stuff to obscure mechanical delicacies from small-time builders. Or, you can go the maker route, and build your own. That’s precisely what [Lambert Sartory] did with their Clavier build.

This build goes a bit of a different route to many other DIY keyboards out there, in that [Lambert] was keen to build it around an FPGA instead of an off-the-shelf microcontroller. To that end, the entire USB HID stack was implemented in VHDL on a Lattice ECP5 chip. It was a heavy-duty way to go, but it makes the keyboard quite unique compared to those that just rely on existing HID libraries to do the job. This onboard hardware also allowed [Lambert] to include JTAG, SPI, I2C, and UART interfaces right on the keyboard, as well as a USB hub for good measure.

As for the mechanical design, it’s a full-size 105-key ISO keyboard with one bonus key for good measure. That’s the coffee key, which either locks the attached computer when you’re going for a break, or resets the FPGA with a long press just in case it’s necessary. It’s built with Cherry MX compatible switches, has N-key rollover capability, and a mighty 1000 Hz polling rate. If you can exceed that by hand, you’re some sort of superhuman.

The great thing about building your own keyboard is you can put in whatever features you desire. If you’re whipping up your own neat interface devices, don’t hesitate to let us know!

hackaday.com/2025/10/01/an-fpg…

Introduction

When it comes to digital forensics, AmCache plays a vital role in identifying malicious activities in Windows systems. This artifact allows the identification of the execution of both benign and malicious software on a machine. It is managed by the operating system, and at the time of writing this article, there is no known way to modify or remove AmCache data. Thus, in an incident response scenario, it could be the key to identifying lost artifacts (e.g., ransomware that auto-deletes itself), allowing analysts to search for patterns left by the attacker, such as file names and paths. Furthermore, AmCache stores the SHA-1 hashes of executed files, which allows DFIR professionals to search public threat intelligence feeds — such as OpenTIP and VirusTotal — and generate rules for blocking this same file on other systems across the network.

This article presents a comprehensive analysis of the AmCache artifact, allowing readers to better understand its inner workings. In addition, we present a new tool named “AmCache-EvilHunter“, which can be used by any professional to easily parse the Amcache.hve file and extract IOCs. The tool is also able to query the aforementioned intelligence feeds to check for malicious file detections, this level of built-in automation reduces manual effort and speeds up threat detection, which is of significant value for analysts and responders.

The importance of evidence of execution

Evidence of execution is fundamentally important in digital forensics and incident response, since it helps investigators reconstruct how the system was used during an intrusion. Artifacts such as Prefetch, ShimCache, and UserAssist offer clues about what was executed. AmCache is also a robust artifact for evidencing execution, preserving metadata that indicates a file’s presence and execution, even if the file has been deleted or modified. An advantage of AmCache over other Windows artifacts is that unlike them, it stores the file hash, which is immensely useful for analysts, as it can be used to hunt malicious files across the network, increasing the likelihood of fully identifying, containing, and eradicating the threat.

Introduction to AmCache

Application Activity Cache (AmCache) was first introduced in Windows 7 and fully leveraged in Windows 8 and beyond. Its purpose is to replace the older RecentFileCache.bcf in newer systems. Unlike its predecessor, AmCache includes valuable forensic information about program execution, executed binaries and loaded drivers.

This artifact is stored as a registry hive file named Amcache.hve in the directory C:\Windows\AppCompat\Programs. The metadata stored in this file includes file paths, publisher data, compilation timestamps, file sizes, and SHA-1 hashes.

It is important to highlight that the AmCache format does not depend on the operating system version, but rather on the version of the libraries (DLLs) responsible for filling the cache. In this way, even Windows systems with different patch levels could have small differences in the structure of the AmCache files. The known libraries used for filling this cache are stored under %WinDir%\System32 with the following names:

• aecache.dll
• aeevts.dll
• aeinv.dll
• aelupsvc.dll
• aepdu.dll
• aepic.dll

It is worth noting that this artifact has its peculiarities and limitations. The AmCache computes the SHA-1 hash over only the first 31,457,280 bytes (≈31 MB) of each executable, so comparing its stored hash online can fail for files exceeding this size. Furthermore, Amcache.hve is not a true execution log: it records files in directories scanned by the Microsoft Compatibility Appraiser, executables and drivers copied during program execution, and GUI applications that required compatibility shimming. Only the last category reliably indicates actual execution. Items in the first two groups simply confirm file presence on the system, with no data on whether or when they ran.

In the same directory, we can find additional LOG files used to ensure Amcache.hve consistency and recovery operations:

• C:\Windows\AppCompat\Programs\Amcache.hve.*LOG1
• C:\Windows\AppCompat\Programs\Amcache.hve.*LOG2

The Amcache.hve file can be collected from a system for forensic analysis using tools like Aralez, Velociraptor, or Kape.

Amcache.hve structure

The Amcache.hve file is a Windows Registry hive in REGF format; it contains multiple subkeys that store distinct classes of data. A simple Python parser can be implemented to iterate through Amcache.hve and present its keys:
#!/usr/bin/env python3

import sys
from Registry.Registry import Registry

hive = Registry(str(sys.argv[1]))
root = hive.open("Root")

for rec in root.subkeys():
print(rec.name())
The result of this parser when executed is:

AmCache keys

From a DFIR perspective, the keys that are of the most interest to us are InventoryApplicationFile, InventoryApplication, InventoryDriverBinary, and InventoryApplicationShortcut, which are described in detail in the following subsections.

InventoryApplicationFile

The InventoryApplicationFile key is essential for tracking every executable discovered on the system. Under this key, each executable is represented by its own uniquely named subkey, which stores the following main metadata:

• ProgramId: a unique hash generated from the binary name, version, publisher, and language, with some zeroes appended to the beginning of the hash
• FileID: the SHA-1 hash of the file, with four zeroes appended to the beginning of the hash
• LowerCaseLongPath: the full lowercase path to the executable
• Name: the file base name without the path information
• OriginalFileName: the original filename as specified in the PE header’s version resource, indicating the name assigned by the developer at build time
• Publisher: often used to verify if the source of the binary is legitimate. For malware, this subkey is usually empty
• Version: the specific build or release version of the executable
• BinaryType: indicates whether the executable is a 32-bit or 64-bit binary
• ProductName: the ProductName field from the version resource, describing the broader software product or suite to which the executable belongs
• LinkDate: the compilation timestamp extracted from the PE header
• Size: the file size in bytes
• IsOsComponent: a boolean flag that specifies whether the executable is a built-in OS component or a third-party application/library

With some tweaks to our original Python parser, we can read the information stored within this key:
#!/usr/bin/env python3

import sys
from Registry.Registry import Registry

hive = Registry(sys.argv[1])
root = hive.open("Root")

subs = {k.name(): k for k in root.subkeys()}
parent = subs.get("InventoryApplicationFile")

for rec in parent.subkeys():
vals = {v.name(): v.value() for v in rec.values()}
print("{}\n{}\n\n-----------\n".format(rec, vals))

InventoryApplicationFile subkeys

We can also use tools like Registry Explorer to see the same data in a graphical way:

InventoryApplicationFile inspected through Registry Explorer

As mentioned before, AmCache computes the SHA-1 hash over only the first 31,457,280 bytes (≈31 MB). To prove this, we did a small experiment, during which we got a binary smaller than 31 MB (Aralez) and one larger than this value (a custom version of Velociraptor). For the first case, the SHA-1 hash of the entire binary was stored in AmCache.

First AmCache SHA-1 storage scenario

For the second scenario, we used the dd utility to extract the first 31 MB of the Velociraptor binary:

Stripped binary

When checking the Velociraptor entry on AmCache, we found that it indeed stored the SHA-1 hash calculated only for the first 31,457,280 bytes of the binary. Interestingly enough, the Size value represented the actual size of the original file. Thus, relying only on the file hash stored on AmCache for querying threat intelligence portals may be not enough when dealing with large files. So, we need to check if the file size in the record is bigger than 31,457,280 bytes before searching threat intelligence portals.

Second AmCache SHA-1 storage scenario

Additionally, attackers may take advantage of this characteristic to purposely generate large malicious binaries. In this way, even if investigators find that a malware was executed/present on a Windows system, the actual SHA-1 hash of the binary will still be unknown, making it difficult to track it across the network and gathering it from public databases like VirusTotal.

InventoryApplicationFile – use case example: finding a deleted tool that was used

Let’s suppose you are searching for a possible insider threat. The user denies having run any suspicious programs, and any suspicious software was securely erased from disk. But in the InventoryApplicationFile, you find a record of winscp.exe being present in the user’s Downloads folder. Even though the file is gone, this tells you the tool was on the machine and it was likely used to transfer files before being deleted. In our incident response practice, we have seen similar cases, where this key proved useful.

InventoryApplication

The InventoryApplication key records details about applications that were previously installed on the system. Unlike InventoryApplicationFile, which logs every executable encountered, InventoryApplication focuses on those with installation records. Each entry is named by its unique ProgramId, allowing straightforward linkage back to the corresponding InventoryApplicationFile key. Additionally, InventoryApplication has the following subkeys of interest:

• InstallDate: a date‑time string indicating when the OS first recorded or recognized the application
• MsiInstallDate: present only if installed via Windows Installer (MSI); shows the exact time the MSI package was applied, sourced directly from the MSI metadata
• UninstallString: the exact command line used to remove the application
• Language: numeric locale identifier set by the developer (LCID)
• Publisher: the name of the software publisher or vendor
• ManifestPath: the file path to the installation manifest used by UWP or AppX/MSIX apps

With a simple change to our parser, we can check the data contained in this key:
<...>
parent = subs.get("InventoryApplication")
<...>

InventoryApplication subkeys

When a ProgramId appears both here and under InventoryApplicationFile, it confirms that the executable is not merely present or executed, but was formally installed. This distinction helps us separate ad-hoc copies or transient executions from installed software. The following figure shows the ProgramId of the WinRAR software under InventoryApplicationFile.

When searching for the ProgramId, we find an exact match under InventoryApplication. This confirms that WinRAR was indeed installed on the system.

Another interesting detail about InventoryApplication is that it contains a subkey named LastScanTime, which is stored separately from ProgramIds and holds a value representing the last time the Microsoft Compatibility Appraiser ran. This is a scheduled task that launches the compattelrunner.exe binary, and the information in this key should only be updated when that task executes. As a result, software installed since the last run of the Appraiser may not appear here. The LastScanTime value is stored in Windows FileTime format.

InventoryApplication LastScanTime information

InventoryApplication – use case example: spotting remote access software

Suppose that during an incident response engagement, you find an entry for AnyDesk in the InventoryApplication key (although the application is not installed anymore). This means that the attacker likely used it for remote access and then removed it to cover their tracks. Even if wiped from disk, this key proves it was present. We have seen this scenario in real-world cases more than once.

InventoryDriverBinary

The InventoryDriverBinary key records every kernel-mode driver that the system has loaded, providing the essential metadata needed to spot suspicious or malicious drivers. Under this key, each driver is captured in its own uniquely named subkey and includes:

• FileID: the SHA-1 hash of the driver binary, with four zeroes appended to the beginning of the hash
• LowerCaseLongPath: the full lowercase file path to the driver on disk
• DigitalSignature: the code-signing certificate details. A valid, trusted signature helps confirm the driver’s authenticity
• LastModified: the file’s last modification timestamp from the filesystem metadata, revealing when the driver binary was most recently altered on disk

Because Windows drivers run at the highest privilege level, they are frequently exploited by malware. For example, a previous study conducted by Kaspersky shows that attackers are exploiting vulnerable drivers for killing EDR processes. When dealing with a cybersecurity incident, investigators correlate each driver’s cryptographic hash, file path, signature status, and modification timestamp. That can help in verifying if the binary matches a known, signed version, detecting any tampering by spotting unexpected modification dates, and flagging unsigned or anomalously named drivers for deeper analysis. Projects like LOLDrivers help identify vulnerable drivers in use by attackers in the wild.

InventoryDriverBinary inspection

In addition to the InventoryDriverBinary, AmCache also provides the InventoryApplicationDriver key, which keeps track of all drivers that have been installed by specific applications. It includes two entries:

• DriverServiceName, which identifies the name of the service linked to the installed driver; and
• ProgramIds, which lists the program identifiers (corresponding to the key names under InventoryApplication) that were responsible for installing the driver.

As shown in the figure below, the ProgramIds key can be used to track the associated program that uses this driver:

Checking program information by ProgramIds

InventoryDriverBinary – use case example: catching a bad driver

If the system was compromised through the abuse of a known vulnerable or malicious driver, you can use the InventoryDriverBinary registry key to confirm its presence. Even if the driver has been removed or hidden, remnants in this key can reveal that it was once loaded, which helps identify kernel-level compromises and supporting timeline reconstruction during the investigation. This is exactly how the AV Killer malware was discovered.

InventoryApplicationShortcut

This key contains entries for .lnk (shortcut) files that were present in folders like each user’s Start Menu or Desktop. Within each shortcut key, the ShortcutPath provides the absolute path to the LNK file at the moment of discovery. The ShortcutTargetPath shows where the shortcut pointed. We can also search for the ProgramId entry within the InventoryApplication key using the ShortcutProgramId (similar to what we did for drivers).

InventoryApplicationShortcut key

InventoryApplicationShortcut – use case example: confirming use of a removed app

You find that a suspicious program was deleted from the computer, but the user claims they never ran it. The InventoryApplicationShortcut key shows a shortcut to that program was on their desktop and was accessed recently. With supplementary evidence, such as that from Prefetch analysis, you can confirm the execution of the software.

AmCache key comparison

The table below summarizes the information presented in the previous subsections, highlighting the main information about each AmCache key.

AmCache-EvilHunter

Undoubtedly Amcache.hve is a very important forensic artifact. However, we could not find any tool that effectively parses its contents while providing threat intelligence for the analyst. With this in mind, we developed AmCache-EvilHunter a command-line tool to parse and analyze Windows Amcache.hve registry hives, identify evidence of execution, suspicious executables, and integrate Kaspersky OpenTIP and VirusTotal lookups for enhanced threat intelligence.

AmCache-EvilHunter is capable of processing the Amcache.hve file and filter records by date range (with the options --start and --end). It is also possible to search records using keywords (--search), which is useful for searching for known naming conventions adopted by attackers. The results can be saved in CSV (--csv) or JSON (--json) formats.

The image below shows an example of execution of AmCache-EvilHunter with these basic options, by using the following command:
amcache-evilhunter -i Amcache.hve --start 2025-06-19 --end 2025-06-19 --csv output.csv
The output contains all applications that were present on the machine on June 19, 2025. The last column contains information whether the file is an operating system component, or not.

Basic usage of AmCache-EvilHunter

CSV result

Analysts are often faced with a large volume of executables and artifacts. To narrow down the scope and reduce noise, the tool is able to search for known suspicious binaries with the --find-suspicious option. The patterns used by the tool include common malware names, Windows processes containing small typos (e.g., scvhost.exe), legitimate executables usually found in use during incidents, one-letter/one-digit file names (such as 1.exe, a.exe), or random hex strings. The figure below shows the results obtained by using this option; as highlighted, one svchost.exe file is part of the operating system and the other is not, making it a good candidate for collection and analysis if not deleted.

Suspicious files identification

Malicious files usually do not include any publisher information and are definitely not part of the default operating system. For this reason, AmCache-EvilHunter also ships with the --missing-publisher and --exclude-os options. These parameters allow for easy filtering of suspicious binaries and also allow fast threat intelligence gathering, which is crucial during an incident.

Another important feature that distinguishes our tool from other proposed approaches is that AmCache-EvilHunter can query Kaspersky OpenTIP (--opentip ) and VirusTotal (--vt) for hashes it identifies. In this way, analysts can rapidly gain insights into samples to decide whether they are going to proceed with a full analysis of the artifact or not.

Threat intel lookup

Binaries of the tool are available on our GitHub page for both Linux and Windows systems.

Conclusion

Amcache.hve is a cornerstone of Windows forensics, capturing rich metadata, such as full paths, SHA-1 hashes, compilation timestamps, publisher and version details, for every executable that appears on a system. While it does not serve as a definitive execution log, its strength lies in documenting file presence and paths, making it invaluable for spotting anomalous binaries, verifying trustworthiness via hash lookups against threat‐intelligence feeds, and correlating LinkDate values with known attack campaigns.

To extract its full investigative potential, analysts should merge AmCache data with other artifacts (e.g., Prefetch, ShimCache, and Windows event logs) to confirm actual execution and build accurate timelines. Comparing InventoryApplicationFile entries against InventoryApplication reveals whether a file was merely dropped or formally installed, and identifying unexpected driver records can expose stealthy rootkits and persistence mechanisms. Leveraging parsers like AmCache-EvilHunter and cross-referencing against VirusTotal or proprietary threat databases allows IOC generation and robust incident response, making AmCache analysis a fundamental DFIR skill.

securelist.com/amcache-forensi…

There’s an old saying (paraphrasing a quote attributed to Hoare): “I don’t know what language scientists will use in the future, but I know it will be called Fortran.” The truth is, there is a ton of very sophisticated code in Fortran, and if you want to do something more modern, it is often easier to borrow it than to reinvent the wheel. When [Valgriz] picked up a textbook on aircraft simulation, he noted that it had an F-16 simulation in it. In Fortran. The challenge? Port it to Unity3D.

If you have a gamepad, you can try the result. However, the real payoff is the blog posts describing what he did. They go back to 2021, although the most recent was a few months ago, and they cover the entire process in great detail. You can also find the code on GitHub. If you are interested in flight simulation, flying, Fortran, or Unity3D, you’ll want to settle in and read all four posts. That will take some time.

One limitation. The book’s simulator was all about modeling the aerodynamics using data from wind tunnel tests. However, the F-16 is notorious for being a negative stability aircraft — meaning it’s virtually impossible to fly by hand. It is very maneuverable, but only if you let the computer drive using the flight control system. When you direct the aircraft, the control system makes your desire happen, while accounting for all the strange extra motions the plane will create as it flies.

The problem: the book doesn’t include code for the flight controller. [Valgriz], of course, wrote his own. He uses some PID controllers along with limiters for G-force and angle of attack. Interestingly, to do this, the simulator actually runs its own stripped-down simulator to determine the effects of different control inputs.

This is one of those projects we aren’t sure we would attempt, but we’re glad someone did, and we can watch. Just be careful. An interest in flight simulation can lead to reduced space in your garage. We know of at least one F-16, by the way, that has an Arduino in it. However, it is probably the only one.

youtube.com/embed/2HZQnnxdISM?…

youtube.com/embed/7vAHo2B1zLc?…

hackaday.com/2025/10/01/portin…

Un argomento meravigliosamente diffuso nel campo largo di chi svolge attività sui dati personali è quello di sottovalutare i rischi o non volerli guardare affatto è quello secondo cui non occorre farsi particolari problemi nel caso in cui siano trattati dati “non sensibili”. La premessa ontologica per la ricerca di soluzioni e correttivi in ambito di liceità e sicurezza è la capacità di farsi le giuste domande. Motivo per cui la propensione al troppo facile skip non può comporre una strategia funzionale o minimamente utile.

Certo, i dati sensibili esistono nel GDPR e richiamano elevate esigenze di protezione. Questo non comporta però che tutte le altre tipologie di dati (impropriamente chiamati comuni da chi ha proprio bisogno di creare categorie inutili) consentano di prescindere da una corretta gestione dei rischi a riguardo. Non sensibile non può in alcun caso significare “non protetto”, nemmeno attraverso il diaframma dell’interpretazione più spregiudicata che possa essere concepita.

Spregiudicatezza o incoscienza?

Mentre la spregiudicatezza consiste in comportamenti che selezionano opzioni di risparmio in spregio delle regole facendo pagare i costi di sicurezza agli interessati, la fonte dei comportamenti che portano a sottostimare l’importanza di proteggere ogni dato personale è spesso riconducibile ad una vera e propria carenza di consapevolezza. Attenzione: questa ipotesi non apre la porta a scenari meno gravi o in cui può essere configurabile un minore margine di responsabilità.

Violare un dato non sensibile, ovverosia un semplice dato identificativo, può comportare conseguenze impattanti per l’interessato. Basti pensare che la maggior parte del phishing avviene con dati di contatto, con una probabilità di successo maggiore se si dispone di informazioni quali le abitudini di consumo o altre che possono essere espresse o dedotte ma che comunque non hanno una sensibilità rilevante. La possibilità di correlare informazioni ad un interessato, in concreto, lo espone infatti a maggiori rischi di subire furti di identità, frodi o una gamma di spiacevoli conseguenze che purtroppo compongono la quotidianità della vita digitale.

La disponibilità di questi dati per i cybercriminali deriva da attività di OSINT, ma anche dalla possibilità di reperire database violati. Database violati per effetto di azioni svolte impiegando semplici dati di contatto e che si arricchiscono attraverso violazioni ulteriori, aumentando l’efficacia delle successive campagne d’attacco.

Non essere consapevoli di tutto questo è, al giorno d’oggi, ingiustificabile per un’organizzazione che svolge attività su dati personali, a prescindere dalla data maturity.

Ragionare sull’utilizzo sostenibile dei dati personali.

L’aspetto della sicurezza e delle violazioni è dunque un argomento particolarmente convincente per non sottovalutare la protezione di tutti i dati personali, ma c’è un elemento ulteriore: la liceità dei trattamenti. Premesso che la sicurezza dei trattamenti è un obbligo previsto dal GDPR, ci sono infatti anche altre ipotesi di violazione ricorrenti che dovrebbero far ragionare proprio su quanto impattante sia violare le “regole del gioco” sin da principio, come ad esempio:

• non informare in modo chiaro e completo gli interessati (=violare il principio di trasparenza);
• aggirare le regole e non garantire i diritti (= violare il principio di correttezza);
• raccogliere e trattare dati senza seguire una logica (= violare il principio di liceità, limitazione delle finalità e minimizzazione);
• non cancellare mai i dati non più utili (= violare il principio di limitazione della conservazione).

Ovviamente, tutto questo porta alla creazione di database al di fuori di un controllo consapevole da parte dell’interessato. E costituisce facile opportunità di guadagno per i cybercriminali, dal momento che una mancanza di strategia qual è quella che può emergere dalle violazioni prese come esempio conduce ad un accumulo di dati senza creazione di valore. E in assenza di valore, non c’è percezione di alcun asset da dover proteggere.

La soluzione è quella di ragionare sull’impiego sostenibile del dato personale. La norma precisa e regola le responsabilità, ma un corretto approccio strategico sa ragionare secondo valore generato e non esclusivamente concentrandosi su componenti di costo come la ricerca di scuse o giustificazioni per fare il minimo necessario.

Altrimenti, si cade facilmente in trappole come quella della convinzione di dover proteggere o prestare attenzione ai soli dati sensibili. Con tutti i punti ciechi di gestione che portano all’inevitabile inadeguatezza delle misure predisposte.

Spoiler: gli interessati se ne accorgono. E difficilmente selezioneranno i servizi di chi non sa garantire un impiego sostenibile dei loro dati.

L'articolo La trappola del “dato non sensibile”: l’errore che costa caro alle aziende proviene da il blog della sicurezza informatica.

Un team di ricercatori ha sviluppato un semplice strumento hardware che sfida i principi fondamentali del trusted computing nei moderni ambienti cloud.

Utilizzando un dispositivo dal costo inferiore a 50 dollari, sono stati in grado di aggirare le protezioni hardware di Intel Scalable SGX e AMD SEV-SNP, che abilitano i Trusted Execution Environment (TEE).

Queste tecnologie sono alla base del confidential computing utilizzato dai principali provider cloud e proteggono i dati in memoria da attacchi privilegiati e accessi fisici, inclusi riavvii a freddo e intercettazioni del bus di memoria.

Il dispositivo sviluppato è un interposer DDR4 che viene inserito tra il processore e la memory stick. Manipola le linee di indirizzo e crea alias di memoria dinamici non rilevabili dagli strumenti di sicurezza integrati. A differenza degli attacchi statici basati sulla modifica dei chip SPD, che Intel e AMD hanno già affrontato nel loro nuovo firmware, la natura dinamica dell’interposer gli consente di bypassare i controlli all’avvio e di operare in tempo reale. Questo trasforma costosi attacchi che coinvolgono hardware dal costo di centinaia di migliaia di dollari in un metodo accessibile che richiede investimenti minimi e competenze ingegneristiche di base .

Utilizzando i sistemi Intel Scalable SGX, gli scienziati hanno dimostrato per la prima volta che l’utilizzo di una singola chiave per l’intero intervallo di memoria consente di leggere e scrivere dati arbitrari all’interno di enclave protette. Hanno anche estratto sperimentalmente la chiave di sicurezza della piattaforma alla base del meccanismo di attestazione remota. Ciò compromette completamente la credibilità del sistema: un aggressore può generare attestazioni false senza accedere all’hardware effettivo. Ciò compromette il meccanismo di verifica dell’integrità fondamentale nei servizi cloud.

Nel caso di AMD SEV-SNP, i ricercatori hanno dimostrato un bypass dei nuovi meccanismi ALIAS_CHECK progettati per proteggere dagli attacchi di tipo BadRAM. Il loro metodo ha permesso loro di riprodurre scenari precedentemente considerati sicuri, tra cui la sostituzione di blocchi di testo cifrato e la riproduzione. L’attacco consente di creare macchine virtuali fittizie che superano la verifica remota come legittime, distruggendo di fatto il sistema di fiducia nell’ecosistema SEV .

Il dispositivo è realizzato utilizzando componenti facilmente reperibili: un circuito stampato, un microcontrollore Raspberry Pi Pico 2 e una coppia di interruttori analogici. L’intero progetto è costato meno di 50 dollari, il che lo rende di gran lunga più economico degli analizzatori DDR4 professionali. Inoltre, gli attacchi sono deterministici e rapidi, senza la necessità di apparecchiature costose o condizioni complesse.

Lo studio ha dimostrato che anche le piattaforme aggiornate con firmware Intel e AMD sono vulnerabili a semplici attacchi fisici se un avversario ha accesso temporaneo al server. Potrebbe trattarsi di un dipendente di un provider cloud , di un agente della supply chain o persino delle forze dell’ordine con accesso alle apparecchiature. Gli autori sottolineano che tali minacce non possono essere ignorate, poiché la crittografia della memoria basata su hardware è stata introdotta proprio per prevenirle.

I ricercatori hanno divulgato i dettagli a Intel nel gennaio 2025 e ad AMD a febbraio. Entrambe le aziende hanno riconosciuto la vulnerabilità, ma hanno dichiarato che gli attacchi fisici andavano oltre i loro modelli di minaccia. Arm, dopo aver ricevuto notifica della potenziale applicabilità del metodo all’architettura CCA, ha anche affermato che l’accesso fisico non era coperto dalle garanzie delle sue soluzioni. Dopo la fine dell’embargo, il progetto, inclusi il codice sorgente e il firmware per l’interposer, è stato pubblicato pubblicamente su GitHub.

Gli autori sottolineano che la transizione verso TEE scalabili è stata accompagnata da un indebolimento delle garanzie crittografiche a vantaggio delle prestazioni e del supporto completo della memoria. Questa soluzione, precedentemente considerata sicura, si è rivelata vulnerabile ad attacchi hardware a basso costo. La sicurezza futura può essere rafforzata solo tornando a metodi crittografici più potenti o passando alla memoria integrata, dove l’accesso fisico al bus è impossibile.

L'articolo Con 50 dollari e l’accesso fisico al server, il Cloud si va a far benedire proviene da il blog della sicurezza informatica.