Last week, Anthropic introduced a new system prompt designed to stop its Claude models from re-creating specific, existing video games. While that move could help shield Anthropic from some liability, it's unlikely to slow much of the massive wave of AI-assisted game porting and copying that has emerged in recent months.

A social media user and AI decompilation enthusiast going by the name "chasm" was among the first to note the prompt change late last week, saying a new rule seemed to be added to the Claude Code prompt on or around October 27. That rule—included in a json file under the name "tengu_heron_brook"—reads as follows:

Do build original games, games in a genre, and games from the user’s own designs and assets. Don’t build a recreation of a specific existing game, even if it is renamed or called original.

XDA later independently verified that the new rule appears in version 2.1.314 of the Claude Code binary, which was released on October 30. XDA also reported that the "tengu_heron_brook" rule had been used for other purposes in earlier versions and that the Claude Opus 5.5 model specifically seemed to have its own distinct and independent instructions restricting game recreations as part of its system prompt bundle.

Following chasm's initial report, Anthropic software engineer Addy Osmani confirmed on social media that the company had "added two sentences to Claude Code's prompt on Opus 5.5 to steer it away from recreating someone else's specific game because using Claude to infringe IP is against our usage policy."

He added that the new prompt was designed to still allow "original games, genre games, and games built from your own designs and assets," even as a handful of issue reports on Anthropic's GitHub suggest the new prompt is getting in the way of some game development use cases.

We added two sentences to Claude Code's prompt on Opus 5.5 to steer it away from recreating someone else's specific game because using Claude to infringe IP is against our usage policy.

Original games, genre games, and games built from your own designs and assets are meant to keep working.

We'll continue to iterate to ensure we're striking the right balance. In the meantime, if Claude turns down something that's yours, send it my way.

— Addy Osmani (@addyosmani) October 30, 2026

A massive wave

Anthropic's new prompt comes as AI coding tools are powering a deluge of game projects based on existing work in one way or another. That includes thrown-together copies of game demos that are making some developers afraid to show their early work publicly, as well as thousands of AI-powered decompilation and porting projects for retro games. Thanks to AI tools, what used to be a time-consuming process requiring painstaking human effort is now orders of magnitude more efficient (though some veteran coders complain that these vibe-coded ports and decomp projects fail to clear the same quality bar as human-centered efforts).

The trend has gotten so bad that decomp.dev—a years-old community devoted to the "brutally difficult, time-consuming task" of game decompilation—announced it was shutting down last month. Community maintainer Luke Street wrote that quickly improving AI tools had made it clear that "community aspect of decompilation has been broken" as newcomers "rac[e] to port games, especially utilizing decompilations that they did not contribute to."

"Decomp.dev was originally designed to gamify decompilation: watching the progress go up was a fun way to stay motivated when every fraction of a percent took real human effort," Street wrote. "Today, that same idea has warped decompilation into a hollow numbers game, exacerbated by folks who just want to burn tokens to make number go up or 'port game to PC,' all else be damned.

Like trying to stop the tides

While Anthropic's new prompt can be seen as a noble effort to push back against the flood of AI-powered, vibe-coded copying, it seems unlikely to have much impact overall. That's primarily because eager game copiers can simply shift to any of the other frontier models that haven't introduced such restrictions. And even if the AI industry as a whole began to bar this kind of use case, coders could switch to cheaper open-weight models that aren't subject to these kinds of restrictions and are not all that far behind in capabilities.

A fully playable web-slinging Spider-Man looks out over <em>Arkham Knight</em>'s Gotham City, thanks to AI coding tools. Credit: YouTube

The prompt may have a more immediate benefit for Anthropic, helping protect the company from potential liability for copyright infringement in these projects. We've seen how AI companies face legal headaches if their models generate images based on copyrighted works, for instance. As Osmani noted in confirming the new anti-game copying prompt, "Using Claude to infringe IP is against our usage policy"—a policy that's surely in place to protect the company legally.

Decompilation efforts based on reverse engineering code generally pass legal muster as long as "expressive elements" like art and sound assets are not included in the project. But there's no guarantee that individual vibe-coders using Claude would be so careful with their efforts, even with Anthropic guardrails against IP theft in place.

On the other hand, there's a risk that Anthropic's efforts could prove too restrictive, limiting transformative game projects that build off existing work. Take, for instance, the increasingly popular trend of using AI to merge two different game concepts into one, adding Mario to Elden Ring or Spider-Man to Batman: Arkham Knight, for instance. Are these the kinds of "recreations of a specific existing game" that Claude's new prompt should block? Or are they transformative works that are legally and creatively distinct from what inspired them? And how does the use of copyright-protected characters and images factor in?

Beyond mashups, how should a model like Claude ensure there's a difference between a direct re-creation of Tetris (ostensibly disallowed by the new prompt) and a mere game in the Tetris genre (ostensibly allowed by the prompt)?

These are issues that even courts can have trouble adjudicating in the best circumstances. Asking an AI model to reliably draw the line between acceptable and unacceptable game clones is a tall order, even with a new two-sentence prompt in place.

Read full article

Comments

The year was 1998. Britney Spears topped the charts, Bill Clinton was impeached, and a couple of little websites called Google and Ars Technica came online. It was also the year Nintendo released The Legend of Zelda: Ocarina of Time on the Nintendo 64. Google, which has come to dominate the Internet (Ars is still working on that), is celebrating the imminent release of the Ocarina of Time remaster by temporarily transporting us back to that storied year with a search Easter egg.

To access the Google time machine, you just have to search for either "Zelda" or "Ocarina of Time." Google will load the standard 2026 results page, but you'll see an animated Master Sword in the lower right corner. It appears on both mobile and desktop—just click the sword and enjoy the show.

After a little time-skipping animation and a Link shout (you know the one), you'll swear it's 1998 again. The search page is transformed into a simple list of blue links with retro Google branding. This is particularly apt given the time-shifting mechanics in Ocarina of Time.

Behold the simplicity of '90s search. Credit: Google

Classic Google used to provide a list of 10 links on each page, but there are only seven included in the Easter egg. This is a curated list of links rather than a real search. You get the official Nintendo Zelda page, Zelda on Wikipedia, Zelda games on Amazon, and a couple more.

You can go back to the modern version of Google's search results at any time by clicking the sword again. Oh, you don't want to do that? Sadly, this is a very limited experience. The Google of today is much different, and if you try to search for anything from the retro interface, you are immediately booted back to 2026 with all the AI, sponsored content, suggested searches, and social media links.

Web links are way down the page in today's Google search results. Credit: Google

The Ocarina of Time left its mark on a generation of gamers, and clearly, some of them went on to work at Google. The company's intention is probably to leverage nostalgia to build hype for Nintendo's big launch, but there's also something a little sad about this. Google's push into generative AI is transforming search in a way that many people don't like. Seeing the simple, minimalist roots of Google search on display drives home how much the company's core product has changed.

The Ocarina of Time has changed a lot, too. The remastered game has been completely re-created, with slick Switch 2 graphics, modern controls for movement and camera, numerous quality-of-life improvements, and more. The game is available for preorder now at $60 for digital and $70 for physical. It launches on November 5 for Nintendo Switch 2.

Read full article

Comments

The end of the year is fast approaching and with it, the pre-Christmas release of Dune: Part Three, the final installment in Denis Villeneuve's acclaimed adaptation of sci-fi author Frank Herbert's novel(s). Warner Bros. gave us a broody and haunting extended teaser in March and a July trailer jam-packed with tantalizing hints of what to expect, along with plenty of Easter eggs to delight avid book fans. Now we've got one last action-packed trailer setting up the final act for iconic anti-hero Paul Atreides (Timothée Chalamet).

(Spoilers for first two films in the franchise below.)

Previously, 2021’s Dune culminated in the brutal defeat of House Atreides by rival House Harkonnen, with Paul and his mother, Lady Jessica (Rebecca Ferguson), fleeing to the desert and taking refuge among the Fremen. Among them is Chani (Zendaya), whom Paul has been seeing in visions all along.

In Dune: Part Two (2024), Paul ingratiated himself with the Fremen, learned to ride a sandworm, and won Chani’s love. A pregnant Lady Jessica had her own plans for Paul as a messiah figure to fulfill a Bene Gesserit prophecy. Ultimately, Paul challenges the emperor, defeats his champion, and demands the Princess Irulan (Florence Pugh) as his wife. The other Great Houses reject Paul as ruler, so he launches a holy war against them. And Chani rides off on a sandworm after refusing to bow down to Paul.

Dune: Part Three draws on Herbert’s novel Dune: Messiah and will take place roughly 17 years after the end of Part Two, according to Villeneuve, as Paul faces the consequences of his earlier actions. Specifically, an assassination plot is brewing, and Chani is "involved." Per the official synopsis:

Dune: Part Three is set nearly two decades after Paul Atreides seized control of the Imperium. Now a ruthless Emperor, Paul must face the consequences of his reign as old allies return, terrifying new threats emerge, and betrayal lurks in every shadow. Haunted by visions of Imperial collapse and the reappearance of his long-lost love, Paul is drawn into a sweeping conspiracy, with Chani at the heart of its unfolding mystery. As enemies close in, Paul must confront the true cost of power and the fate of those he loves the most.

Chalamet is back as Paul Atreides, along with Zendaya, Pugh, and Ferguson. Josh Brolin reprises his role as weapons master Gurney Halleck; Javier Bardem is back as Stilgar, leader of the Fremen tribe at Sietch Tabr; and Jason Momoa returns as Duncan Idaho/Hayt. Joining the cast are Anya Taylor-Joy as Paul’s younger sister, Alia; Robert Pattinson as the villainous Scytale, who plots to dethrone Paul; Isaach de Bankolé as Paul’s former Fedaykin, Farok; Nakoa-Wolf Momoa (son of Jason) as Paul and Chani’s son, Leto II Atreides; and Ida Brooke as Paul and Chani’s daughter, Ghanima Atreides.

Dune: Part Three opens in theaters on December 18, 2026, going head to head with Avengers: Doomsday.

Read full article

Comments

Defenders across the world face the burden of responding to yet another botched code-execution vulnerability, this time in boot-time firmware used by most of the world’s server vendors and data centers.

The vulnerability, with a severity rating of 9.5 out of 10, resides in the TianoCore EDK II, an open source codebase that hardware makers and cloud providers use to create the UEFI firmware that runs during the boot-up sequence. Last year, a representative of the UEFI Forum called EDK2 the "preeminent solution / implementation of the UEFI specifications." Virtually all UEFI suppliers (sometimes still called IBVs or independent BIOS vendors), including AMI, Insyde, and Phoenix, use the reference code extensively. Project Mu, Microsoft's hardened EDK2 fork, used the code containing the vulnerable component as well.

The vulnerability, tracked as CVE-2026-97631, is a memory-corruption flaw in an ICMP component that attackers can exploit to execute malicious code that runs before the operating system and firmware can implement defenses like Secure Boot, which establishes a chain of trust for all code, including the Trusted Platform Module (TPM), loaded during boot. While final payloads delivered by CVE-2026-97631 have no persistence—meaning they run only once—they can give attackers a wide opening to install other payloads that also run each time early in the boot process.

The cat has left the bag

The parties that discovered CVE-2026-97631—Alex Matrosov of Anthropic and Dan Holmes of Google—had arranged for it to stay under wraps until a coordinated disclosure that was scheduled for January. AMI, a maker of motherboards and other hardware, published this pull request last month that detailed the vulnerability and included a code fix. Once the post came to the attention of the discovering parties, TianoCore Project members published a public advisory last week.

With publicly available patch code, it will be trivial for advanced hackers to learn how the vulnerability is triggered and to build working exploits. Further compounding the urgency, patching UEFI code vulnerabilities in millions of end devices sold and used by thousands of hardware makers and cloud providers is cumbersome and time-consuming. Word of the vulnerability comes six days after another botched disclosure, this one involving a critical code-execution vulnerability in the PHP programming language.

“This vulnerability in the ICMP parser of the EDK2 network stack is interesting in terms of how it affects the chain of trust and the broader ecosystem,” said HD Moore, creator of Metasploit and chief research officer at security firm Dragos. “An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint's TPM. This could be used to break disk encryption for cases where an attacker has short-term network access (and it would be even easier in a theft scenario).”

CVE-2026-97631 is a 16-year-old buffer overflow in the PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe), which is responsible for allowing servers, storage equipment, and other devices to boot using code downloaded from a local network. During this process—known as the pre-execution environment boot—the driver uses a network listener to monitor for ICMP errors. Because the driver doesn’t enforce a memory copy limit of 504 bytes, overwriting adjacent data, a malicious insider or a hacker who has gained low-level access to a local network can send an error message that appends code past this limit. The IUEFI module running on the CPU then becomes corrupted.

As the official advisory puts it:

During network boot, the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps a receive request open for ICMP error messages and copies each received message into the fixed 504-byte field Mode.IcmpError of its private context structure. The copy loop's bounds handling is incorrect in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle): for a message longer than 504 bytes it still copies bytes into the field, and it advances the destination pointer by the cumulative rather than the per-fragment length, so an oversized message writes attacker-controlled bytes past the field. Nothing earlier on the receive path restricts the message length.

The malicious error can be delivered through a simple unicast sent from any network distance to a target device’s IP address, as long as it’s sent during the PXE boot sequence. An attacker can deliver a denial-of-service by causing the boot sequence to hang. When the attacker knows what the target firmware build is, it can plant a “counterfeit event” that executes the malicious code on the CPU in its UEFI firmware environment. The code runs in ring 0, a CPU's most privileged execution level. Because exploits bypass attestation processes designed to cryptographically prove to remote servers that the hardware is secure, they present a key opportunity for elevating limited privileges.

Yet another forever day

CVE-2026-97631 joins a long list of previously discovered vulnerabilities in UEFI or code that works closely with it. The most severe of them, LogoFail, stemmed from logo images included in the UEFI of just about every hardware maker. Rendering bugs allowed attackers to subvert the chain of trust UEFI enforces and go on to install malicious components before the OS loaded or Secure Boot ran. PixieFail was a vulnerability similar to CVE-2026-97631. It, too, was the result of faulty PXE boot flaws in EDK2. Following discovery of the vulnerability, researchers embarked on multiple fuzzing projects designed to surface other critical flaws in the open source code library. It appears those efforts failed to find this latest flaw.

Other recently discovered UEFI flaws include:

• PKFail, a supply-chain failure resulting from non-production test platform keys, public for more than a decade before they were discovered, used in hundreds of device models
• BootHole
• Bootkit and
• BlackLotus

Like CVE-2026-97631, exploitation or use of these payloads is appealing because it allows attackers to infect machines early in the boot process, before TPM and other defenses load, so they can inflict maximum damage. Given the ubiquity of CVE-2026-97631, Moore said it’s likely a "forever" bug that will live on in end-of-support systems.

There are important caveats and limitations to exploiting this latest vulnerability. As noted, some level of control over a local network is a prerequisite. That likely limits exploitation to insiders or attackers, such as nation-states or ransomware operators, who manage to gain low-level access inside a network and are looking for a way to elevate system rights. There’s no evidence yet that CVE-2026-97631 provides an initial entry point into a network. There are other hurdles to clear.

“For exploiting the vulnerability itself, an attacker needs to guess specific addresses within the target system, so it's not something that you can throw a single exploit at any target and get RCE across a diverse range of devices, but it needs to be tuned for each target model/version/configuration since the addresses will change based on those,” Jesse Michael, a principal researcher at firmware security firm Eclypsium, told Ars. “Unlike some of the previous, high-profile vulnerabilities like BootHole, Black Lotus, and Baton Drop, this vulnerability can be fixed with a basic code fix, which will require deploying a BIOS/UEFI update, but they don't need to deal with revocations, pk/kek/db/dbx key management updates, or making sure to update OS and provisioning media like you do with Secure Boot bypasses in the bootloader itself.”

CVE-2026-97631 doesn’t affect home and small office users, or any other users who boot their devices solely from disk drives. Instead, it applies only to organizations with machines that boot from local networks, or conceivably from Internet-connected resources. Even then, the targeted firmware must rely on EDK2, as opposed to a different reference implementation, and use the PXE functionality (which is turned on by default).

In an email, Intel said that none of its "commercial products currently under security support" are known to be affected. "Intel does not include the affected EDK2 functionality in its reference code, though it may be integrated by an OEM board vendor or system manufacturer," the company added. It advised customers to check with their system manufacturer for specific guidance. Publicly available Intel reference code, however, makes reference to EDK2. Further, TianoCore has said that each Intel-supplied UEFI development kit "is a fully validated implementation... for a specific revision of the EDK II source." Many other Intel documents reference EDK2 as well.

Arm, meanwhile, responded to a list of questions with: "CVE-2026-97631 is not directly applicable to Arm’s product portfolio." Like Intel, firmware the company makes available also borrows heavily from EDK2. TianoCore has also documented Arm's reliance on EDK2.

While it's possible some platforms are free of EDK2 code, it's prudent for users of all servers to investigate if CVE-2026-97631 affects them.

Questions sent to AMD, Phoenix Technologies, AMI, Microsoft, and Amazon—likely some of the other biggest organizations affected—went unanswered when this post went live. Without concrete answers to questions about the use of EDK2 by organizations like these, it’s impossible to say what or how devices are affected and what actions, if any, these organizations, or their users, should take. Representatives from the TianoCore Project also didn’t respond.

Some readers are likely to be unhappy at the lack of detail. Sometimes—particularly in cases involving botched disclosures that break embargoes months before they’re scheduled to lift—there’s no escaping the lack of actionable information in initial reporting.

Those affected should check with the maker of the firmware being used to boot their systems and ask for guidance. Beyond that, they should consider turning off network boot capabilities at least temporarily if possible. Firmware configurations should always enable security features such as TPM and Secure Boot whenever possible, although those defenses don't protect against this particular threat. It’s also a good idea to monitor logs for signs of exploitation attempts.

Read full article

Comments

Security personnel around the world are on high alert Tuesday following the discovery of eight TLS certificates with private keys so weak they could allow anyone to mint trusted browser and app credentials for any site on the Internet.

As of late morning Tuesday, browser makers and some major apps and programming languages had blocked all eight of the intermediate certificates. There are no reports of certificate transparency logs, which track the issuance of all browser-trusted certificates, showing the compromised keys being used maliciously. The threat remains far from over, however, because it will be hard and time-consuming to update other key parts of the Internet, such as Linux distributions and embedded and Internet of Things devices.

One word: bonkers

The eight intermediate certificates belong to India-based certificate authority eMudhra Limited. An informal advisory published to emudhra.we-have-a-problem.com over on Tuesday posted the message “We have a problem here - Wayne.” The words were digitally signed using the private key of one of the eMudhra certificates. With proof that the reporting party had control of the key, defenders scrambled because the same key could be used to sign unauthorized certificates that would be trusted by millions of servers worldwide.

“This will be a massive cleanup job, bigger than Heartbleed,” Filippo Valsorda, a cryptography engineer and a cryptography maintainer for the open source Go programming language, told Ars. “There will be a very, very long tail, IoT devices, Docker containers, forgotten Linux machines, unmaintained CLI tools that shipped their own copy of the roots (which is common in some ecosystems, like Python). Also, Linux distributions are still rolling out updates, some of them are not ready yet, and then system administrators will need to apply them to a lot of machines.”

Heartbleed is the name of a critical vulnerability in the OpenSSL cryptography library. In 2014, it came under mass exploitation. Exploits let many unaffiliated hackers decrypt TLS-protected exchanges between parties. They also recovered private TLS certificate keys, session cookies, and passwords. The attacks compromised thousands of servers, some belonging to large companies and government agencies around the world.

Recovery required a long series of steps that took years. Steps included patching OpenSSL on all affected devices, reissuing millions of TLS keys, revoking old certificates, rotating passwords and session tokens and updating embedded devices and other forgotten systems—something that was extremely time- and resource-intensive, especially at Internet scale.

“Every time you need a lot of different people in different contexts to do something, it will take a long time,” Valsorda explained. “This time it’s worse because there’s more contexts, more people, and more heterogeneity.”

The compromised eMudhra keys were defective at a level that’s challenging the imagination of many of the engineers studying the incident. A normal size for a NIST P-384 elliptic curve cryptography private key contains roughly 384 bits of entropy, a size allowing almost 2³⁸⁴, or a number with 116 digits, different possibilities. The private key sizes of the compromised keys ranged from 3 to 8 bits. Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.

“That is extremely in the ‘this should not be possible’ category,” Valdorda said. “Maybe some horribly dangerous key generation interface has a ‘size’ parameter and they set it to 1 by mistake???”

Ben Cartwright-Cox, director of BGP.tools, said: “My guess is that it's example code that accidentally leaked to production, but hard to know. But it’s bonkers that no one noticed.”

At this early stage, the most immediate threat appears to be for those using VPNs, especially in countries with governments likely to maliciously intercept traffic. There are likely many other cases for concern. End users largely have no recourse other than to hold off using many non-browser forms of TLS communication until they receive assurances updates are in place.

As noted, most browsers have already blocked the intermediate certificates. The exception appears to be Edge running on Windows 10, which at the time this article went live was still connecting to 12 vulnerable hosts. In response to questions asking why and if the company has plans to do so, a Microsoft representative the company will be in touch if it has anything to "share." Meanwhile, Signal, WhatsApp, Wireguard, and other apps that don’t rely on TLS for confidentiality aren’t affected. This page and the emudhra.we-have-a-problem.com site show apps known to be patched so far.

The incident is the latest to expose a fatal flaw in the TLS regimen. It's only as strong as its weakest link, which in this case was eMudhra. Fortunately, transparency logs account for much of that failure, but this measure requires parties to actively monitor massive feeds and works only after unauthorized certificates have been issued. eMudhra representatives weren't immediately available to answer questions.

One caveat: exploiting compromised certificates requires an active adversary-in-the-middle attack, meaning the attacker must act as a proxy between two TLS parties and receive encrypted traffic, decrypt it, reencrypt it, and send it to the other party. Such capabilities, in some cases, are usually limited to only the most well-resourced attackers. People with control of a local network—at a coffee shop, university, or other organization—face much less of a challenge.

Read full article

Comments