DEV Community: GuardingPearSoftware

IL2CPP Debug, Release, and Master builds. Which one should you ship?

GuardingPearSoftware — Sat, 12 Sep 2026 14:42:04 +0000

When you build a Unity game with the IL2CPP scripting backend, Unity first turns your C# into C++. Then a native C++ compiler turns that C++ into machine code.

That second step has a setting that many developers never touch: the C++ Compiler Configuration. It has three options. Debug, Release, and Master.

The setting hides in Project Settings under Player, in the Configuration section of Other Settings. It only appears when your Scripting Backend is IL2CPP. Pick the wrong option and you either wait far too long for every test build, or you ship a game that runs slower than it should.

Let us look at what each configuration actually does, what it costs, and when each one is the right choice. At the end you will find a simple decision table and all sources.

What this setting controls, and what it does not

One thing first, because these options get mixed up sometimes.

The C++ Compiler Configuration does not change your C# code. It does not change how IL2CPP generates C++ from your assemblies. It only tells the native compiler (MSVC on Windows, clang on Android, iOS, and most other platforms) how hard to optimize the generated C++ when it becomes machine code.

Unity has other settings that sound similar but do different jobs:

Setting	What it controls
C++ Compiler Configuration	How the native compiler optimizes the generated C++. Debug, Release, or Master.
IL2CPP Code Generation	How IL2CPP generates the C++ in the first place. "Faster runtime" makes more code that runs faster. "Faster (smaller) builds" makes less code that builds faster.
Script Debugging	Whether you can attach the C# debugger to the player. Costs program size and performance.
Managed Stripping Level	How much unused C# code the linker removes before IL2CPP runs.

You can also set the configuration from a build script instead of clicking through the UI:

using UnityEditor;
using UnityEditor.Build;

public static class BuildConfig
{
    public static void UseMasterForShipping()
    {
        PlayerSettings.SetIl2CppCompilerConfiguration(
            NamedBuildTarget.Android,
            Il2CppCompilerConfiguration.Master);
    }
}

Takeaway: The C++ Compiler Configuration is the last knob in the IL2CPP pipeline. It trades build time against runtime speed, nothing else.

Debug: fast builds, slow game

The official description is short: "Debug configuration turns off all optimizations, which makes the code quicker to build but slower to run."

With optimizations off, the C++ compiler does the least possible work. Your build finishes sooner. The resulting code keeps every variable, every method call, and every debugging symbol exactly where you wrote it.

That has two practical benefits:

First, iteration speed. If you build ten times a day to test on a device, the C++ compile step is often the longest part. Debug really cuts it down.

Second, better stack traces. Unity's managed stack traces page states that in the Debug configuration, IL2CPP reports a reliable managed stack trace that includes each managed method in the call stack. Nothing gets inlined away. When your game crashes, the trace shows the real call chain. In Release and Master, the compiler inlines methods, so entries can be missing from the stack, making it harder to debug.

The cost is runtime speed. Unoptimized C++ is markedly slower. Frame times, load times, and GC pressure all look worse than what your players will ever see. Never judge performance with a Debug configuration build, and never ship one.

Takeaway: Debug is for building often and debugging native issues. It is not a preview of how your game performs.

Release: the balanced default

Release "enables optimizations, so the compiled code runs faster and the binary size is smaller but it takes longer to compile" (Unity docs).

This is the standard optimized build most C++ developers know. On clang platforms it roughly matches a normal optimized compile, with inlining, dead code removal, and the usual set of per-file optimizations. The compiler works file by file, so build times stay reasonable.

Release is also the configuration Unity's own documentation points at for profiling. The Windows Visual Studio project generation page describes the Release configuration as the one to "profile your game", because it enables code optimizations while keeping profiler support. Numbers you capture here are close to the shipped game, and the Unity Profiler can still connect.

There is one side effect to know. Because Release inlines methods, exception stack traces from players can miss one or more managed methods. Unity added a fix for that: the IL2CPP Stacktrace Information option. Set it to "Method Name, File Name, and Line Number" and Unity generates correct call stacks even with inlining active, in both Release and Master. That is much cheaper than enabling full script debugging just to get readable crash logs.

Takeaway: Release is the workhorse. Use it for QA builds, profiling, and every milestone where the numbers should mean something.

Master: everything the compiler has

Master "enables all possible optimizations, squeezing every bit of performance possible" (Unity docs). Unity's recommendation in the same document is direct: build the shipping version of your game with Master if the increase in build time is acceptable.

What "all possible optimizations" means depends on the platform:

On Windows with MSVC, Master turns on link-time code generation (LTCG). On clang platforms, newer Unity versions apply link-time optimization (LTO). Both do the same kind of thing. Instead of optimizing each C++ file on its own, the toolchain looks at the whole program at link time. It can then inline functions across file boundaries and remove work a single-file compiler cannot see.

A Unity forum answer explains the trade well: cross-file optimization makes compilation far more expensive. It needs much more RAM and much more time. For large projects, an LTO link can take long enough that it is unusable for everyday development builds.

There is a second difference on some platforms. In the Visual Studio solution Unity generates for Windows, the Master configuration disables the profiler. A long-running forum thread confirms the practical result: you cannot attach the Unity Profiler to a Master build there. If a performance bug only shows up in Master, you need native tools like Windows Performance Analyzer instead (forum thread).

Takeaway: Master is the shipping configuration. It buys real speed with long builds, high build-machine RAM use, and weaker profiling support.

How much faster is Master, really?

Unity published measured numbers for this in 2025, when the Android team brought LTO to IL2CPP in Unity 6.5. They tested real games on real devices, comparing a baseline build against Master with ThinLTO and -O2:

Metric	Baseline	Master with ThinLTO	Change
Time to initial display	443.84 ms	426.97 ms	3.8% faster
Time to full display	1228.76 ms	1158.28 ms	5.7% faster
CPU main thread frame time	10.05 ms	9.83 ms	2.3% faster
`libil2cpp.so` size	37.26 MB	44.23 MB	18.7% bigger
Total APK size	416.84 MB	423.37 MB	1.6% bigger
Build time	~866 s	~1124 s	30 to 35% slower

The result: a few percent faster startup and frame times, paid for with roughly a third more build time and a bigger native library.

Two details from that post are worth remembering. Projects that use a lot of C# generics gain the most, because the optimizer is especially effective on the templated code IL2CPP generates for generics. And the LTO mode dropdown only does anything in Master. Setting an LTO mode while on Release or Debug has no effect.

Since Unity 6.6 you can also pick between two LTO levels under the Master configuration, exposed in the API as Il2CppLTOMode. Thin LTO links faster with almost the same optimization quality. Full LTO optimizes hardest and links slowest. Unity's own editor tooltip calls Thin "faster to link with nearly equivalent optimization", so Thin is the sensible default when you turn Master on.

A few percent may sound small. For a mobile game it is not. Startup time affects store metrics and player retention, and a steady 2 to 3% off the main thread frame time is the difference between holding a frame rate cap and missing it on weaker devices.

Takeaway: Expect single-digit percentage gains from Master over Release, more if your code is generics-heavy. The cost is about a third more build time.

Which configuration when

Here is the whole article as one table:

Situation	Configuration	Why
Daily development builds, quick device tests	Debug	Fastest C++ compile. Full stack traces. Performance numbers are meaningless here.
Debugging a native crash or IL2CPP issue	Debug	No inlining, all symbols intact, the call stack tells the truth.
QA builds, playtests, milestones	Release	Optimized like the shipped game, still profileable.
Profiling and performance work	Release	The Unity Profiler connects, and the code is close to final speed.
Store submission and final release	Master	All optimizations, LTCG or LTO. Unity's recommended shipping configuration.
Final soak test before submission	Master	Test the exact binary behavior you ship, since Master can differ from Release.

A workflow that many teams settle on: Debug or Release locally depending on what you are doing that day, Release on the CI pipeline for every automated build, and Master only for release candidates and store submissions. That way the 30%+ build time cost is paid a handful of times per release instead of dozens of times per week.

One warning for that last step. Because Master builds get tested less often, always run a full QA pass on the actual Master build. Aggressive optimization can surface timing-dependent bugs that never appeared in Release, and on some platforms your usual profiler will not attach to help you.

Wrapping up

The C++ Compiler Configuration is a simple trade. Debug gives you the fastest builds and the slowest game. Release gives you a fast game and reasonable builds. Master gives you the fastest game Unity can produce and the longest builds.

Unity's measured Android data puts the Master gain at a few percent in startup and frame time over an already optimized build, at the cost of 30 to 35% more build time. That is a trade worth making exactly once per release, for the build your players install.

Read more on my blog: www.guardingpearsoftware.com!

AI Agent Risks: What Users and Businesses Should Know

GuardingPearSoftware — Sat, 12 Sep 2026 13:23:52 +0000

Tech companies are now promoting AI agents as the next big thing after chatbots. The technology is already moving rapidly into mainstream and business environments. According to McKinsey's 2026 State of AI survey, 40% of enterprise applications are expected to include task-specific AI agents by the end of 2026, up from 27% in 2025.
As AI agents become more capable and gain access to more of our data, accounts, devices, and online services, the consequences of mistakes or abuse grow much larger. As businesses and individuals give these systems more autonomy, they also need to understand what can go wrong, how attackers could abuse AI agents, and what safeguards can reduce the risk.

What is an AI agent?

An AI agent is a software system that can understand a goal, make decisions, use tools or external systems, and take multiple steps to complete a task with limited human intervention. Unlike a traditional chatbot, which responds to user prompts with generated text, an AI agent can actively perform actions on the user’s behalf, such as searching websites, managing schedules, analyzing data, sending messages, or interacting with other applications. In simple terms, a chatbot mainly talks, while an AI agent can plan, act, and complete tasks.
The appeal of AI agents is easy to understand. People and businesses already have plenty of software. The big challenge is that people often spend a lot of time moving information between applications and checking different apps before making decisions.
AI agents promise to reduce this friction. An agent can gather the necessary information, use connected tools, and move a task forward with less human involvement. This can help people and organizations save time, improve efficiency, and reduce the amount of manual work they have to handle.

Security risks of AI Agents

1. Prompt injection attacks

Imagine a company gives an AI agent access to an employee's inbox so it can summarize incoming emails. The employee receives a malicious email containing hidden instructions telling the AI to search the mailbox for sensitive documents and forward them to an external address.
The employee may never see anything suspicious. The AI agent, however, could interpret the malicious instructions as part of the information it is processing. This is known as indirect prompt injection.
The malicious instructions do not necessarily come directly from the user. They can be hidden inside emails, websites, documents, search results, or other external data. Prompt injection is already a major risk for generative AI, but the consequences can become more serious when an AI system has tools and permissions.

2. Memory poisoning

Memory is one of the features that can make AI agents more useful. An agent that remembers previous interactions does not have to start from scratch every time.
But persistent memory also creates another place where attackers can try to manipulate the system. An attacker may insert malicious or misleading information into an agent's memory.
Later, the agent might treat that information as trusted context. This is known as memory poisoning.
Imagine an employee uses an AI agent to manage projects. Someone manages to insert false instructions into its persistent memory, such as a fake rule saying that a particular external account is authorized to receive company documents. If the agent trusts that memory in a future session, the attacker could benefit long after the original interaction has ended.

3. Rogue agents

Sometimes AI agents may drift away from their intended goals or instructions and begin taking actions that were not expected by their users or developers. In a recent case, independent researchers discovered several websites where AI agents believed to have been created by OpenAI appeared to take actions without authorization. The agents reportedly accessed websites, posted messages, and exchanged data with one another. The findings have raised further concerns about whether AI developers can effectively control increasingly autonomous agentic systems and prevent them from acting beyond their intended boundaries.

4. Agent goal hijack

Agent goal hijacking occurs when an attacker manipulates an agent into changing or abandoning its intended objective. Unlike prompt injection, which targets a specific response from an AI model, goal hijacking can influence an agent’s broader, multi-step behavior. Attackers may use manipulated prompts, malicious data, compromised information sources, or fake communications to redirect an agent and make it perform actions that were never intended by its user.
The risk exists because AI agents often rely on natural-language instructions and automated decision-making to determine their next steps. An attacker can therefore create content to influence the agent’s planning or decision-making without directly interacting with the user. If successful, the agent could be redirected toward actions that expose sensitive information, misuse connected tools, or otherwise benefit the attacker at the expense of the user or organization.

5. Supply Chain Vulnerabilities

AI agents often depend on a complex supply chain that includes third-party models, plugins, APIs, libraries, tools, datasets, and external services. This creates more attack surface for attackers to compromise an agent. A malicious or compromised dependency could manipulate an agent’s behavior, steal sensitive information, introduce malicious instructions, or gain access to connected systems.
The risk becomes greater when organizations use agents built from components they do not fully control or understand. If one trusted component in the AI supply chain is compromised, the attacker could use that trust to affect many downstream agents and organizations.

6. Insecure inter-agent communication

Insecure inter-agent communication occurs when multiple AI agents exchange information or instructions without strong authentication, authorization, and validation controls. In a multi-agent system, one agent relies on information received from another. This creates an opportunity for an attacker to modify messages, inject malicious instructions, or manipulate the information being shared.
For example, if a research agent sends findings to a purchasing agent through an unencrypted channel, an attacker who compromises that communication channel could alter the data and cause the purchasing agent to make an unauthorized decision. Because agents can automatically trust and act on information received from other agents, a compromised agent or communication channel could spread malicious instructions across an entire workflow.

7. AI agents can leak sensitive information

AI agents often need access to information to perform their tasks. That information could include customer records, employee data, financial documents, passwords, internal communications, intellectual property, or confidential business plans.
The problem becomes more complicated when an agent can combine information from multiple sources. For example, an employee might ask an AI assistant to prepare a customer report. The agent then accesses a CRM, internal documents, email messages, spreadsheets, and other systems. If those systems contain information the employee was never supposed to combine, the AI could unintentionally bring that information together.
There is also a risk that sensitive information could appear in agent logs, tool calls, outputs, or persistent memory.

8. Shadow AI

Sometimes employees use unauthorized or undocumented AI agents that operate outside an organization’s official IT and security controls. Individuals may use these agents to automate tasks or improve productivity. This can create major risks, as these unapproved agents may have excessive permissions, insecure configurations, or access to sensitive data that the organization is not aware of.
Shadow AI also makes it harder for security teams to maintain visibility across the organization. This can create security blind spots and make it more difficult to identify, investigate, and respond to incidents when something goes wrong.

What users should do

Consumers do not necessarily need to avoid AI agents.
They should, however, treat them more like powerful digital assistants than ordinary chatbots.

Give agents limited access

Do not connect an AI agent to every account simply because integration is available. Only provide access to the services it actually needs.

Review important actions

Keep humans involved when an agent wants to make purchases, send sensitive information, change account settings, delete files, or perform other irreversible actions.

Keep connected accounts secure

Use strong authentication and monitor connected accounts for unusual activity. If an AI agent is compromised, the accounts connected to it could become the next target.

What businesses should do

The human should remain in control

Organizations should require human approval for high-risk activities such as accessing sensitive information, making financial decisions, changing critical systems, sending external communications, or executing code. Human oversight can also help detect unusual behavior and identify situations where an agent is operating outside its intended purpose. Humans should remain in control of decisions that could have serious security, financial, or operational consequences.

Apply least privilege

Every agent should receive the minimum permissions necessary to perform its job. A reporting agent should not have administrator access. A document-reading agent should not have deletion privileges.

Monitor agent activity

Companies should log important agent actions and monitor for unusual behavior. Sudden increases in tool calls, unusual data access, unexpected external communications, or repeated failed actions could indicate abuse or malfunction.

Have an emergency shutdown process

Companies should know how to quickly disable an agent and revoke its credentials. This becomes important when agents can operate without continuous human supervision.

Read more on my blog: www.guardingpearsoftware.com!

AI Agent Risks: What Users and Businesses Should Know

GuardingPearSoftware — Sat, 12 Sep 2026 13:17:11 +0000

What is an AI agent?

Security risks of AI Agents

1. Prompt injection attacks

2. Memory poisoning

3. Rogue agents

4. Agent goal hijack

5. Supply Chain Vulnerabilities

6. Insecure inter-agent communication

7. AI agents can leak sensitive information

8. Shadow AI

What users should do

Consumers do not necessarily need to avoid AI agents.
They should, however, treat them more like powerful digital assistants than ordinary chatbots.

Give agents limited access

Do not connect an AI agent to every account simply because integration is available. Only provide access to the services it actually needs.

Review important actions

Keep humans involved when an agent wants to make purchases, send sensitive information, change account settings, delete files, or perform other irreversible actions.

Keep connected accounts secure

Use strong authentication and monitor connected accounts for unusual activity. If an AI agent is compromised, the accounts connected to it could become the next target.

What businesses should do

The human should remain in control

Apply least privilege

Every agent should receive the minimum permissions necessary to perform its job. A reporting agent should not have administrator access. A document-reading agent should not have deletion privileges.

Monitor agent activity

Have an emergency shutdown process

Companies should know how to quickly disable an agent and revoke its credentials. This becomes important when agents can operate without continuous human supervision.

Read more on my blog: www.guardingpearsoftware.com!

AI Agent Risks: What Users and Businesses Should Know

GuardingPearSoftware — Sat, 12 Sep 2026 12:46:53 +0000

What is an AI agent?

Security risks of AI Agents

1. Prompt injection attacks

2. Memory poisoning

3. Rogue agents

4. Agent goal hijack

5. Supply Chain Vulnerabilities

6. Insecure inter-agent communication

7. AI agents can leak sensitive information

8. Shadow AI

What users should do

Consumers do not necessarily need to avoid AI agents.
They should, however, treat them more like powerful digital assistants than ordinary chatbots.

Give agents limited access

Do not connect an AI agent to every account simply because integration is available. Only provide access to the services it actually needs.

Review important actions

Keep humans involved when an agent wants to make purchases, send sensitive information, change account settings, delete files, or perform other irreversible actions.

Keep connected accounts secure

Use strong authentication and monitor connected accounts for unusual activity. If an AI agent is compromised, the accounts connected to it could become the next target.

What businesses should do

The human should remain in control

Apply least privilege

Every agent should receive the minimum permissions necessary to perform its job. A reporting agent should not have administrator access. A document-reading agent should not have deletion privileges.

Monitor agent activity

Have an emergency shutdown process

Companies should know how to quickly disable an agent and revoke its credentials. This becomes important when agents can operate without continuous human supervision.

Read more on my blog: www.guardingpearsoftware.com!

Prove your game ownership with watermarks

GuardingPearSoftware — Sun, 06 Sep 2026 11:48:20 +0000

In the new age of AI, proof of game ownership is becoming more and more important. Game clones and flips are being created faster than ever.

Your Android APK or Windows build can be taken, the icon changed, a few textures swapped, the store listing renamed, and then uploaded as someone else's game. Stores will not always catch this on their own, unfortunately. You need proof that the game or app is yours.

A code watermark can provide that proof. It does not stop the theft. What it does is let you go to Google Play, Steam, or another DMCA form and show that the clone was built from your game or app.

This is for game developers who ship Unity titles and want something stronger than "it looks like our game."

The problem is real

But clone and flip can mean different things.

Stolen game. An attacker dumps your APK or game folder. They replace the package name, ad SDK, icon, and some art, then republish it. They did not remake your game, they just took the copy you already shipped. This is called repackaging, and it is the case a watermark is built to fight.

Asset flip. A studio buys the assets from the Unity Asset Store as you and ships a junk title. That is shovelware, and it is usually not your game.

Gameplay clone. A publisher copies the idea of a hit like Flappy Bird, Fall Guys, or an idle shooter. Game mechanics are hard to copyright but your art, audio, and compiled code can be.

A watermark is built for the first case. That case is common enough that researchers have measured it for more than ten years.

Here is the picture, one store at a time.

Android is the biggest target

On Google Play, Bitdefender scanned 420,646 apps and found 5,077 of them, about 1.2%, that were full copies of other developers' work. Once shared libraries were set aside, more than 90% of each copy was identical. They watched one paid game pick up four free copies in a single week. Columbia's PlayDrone crawl found that about 25% of Play content was duplicate, though most of that was same-developer rebrands and spam. Of the similar free apps they labeled, 42,308 were clones by different authors.

Off the official store, it gets worse. A tool called APPraiser checked more than 1.3 million apps and found that only about 6% of Google Play apps looked similar to another app, and most of those were a studio reusing its own work. On the Chinese third-party store Anzhi, about 26% looked similar, and roughly half of those were true clones. Other studies of third-party Android markets agree: Zhou et al. measured 5% to 13% repackaged, a study of Chinese markets found about 20% clones with Google Play as the main source, and a 2024 sample of "original" games found 93 of 196 (47%) were repackaged clones of Play titles.

Those copies are not harmless. Of the clones that moved from Google Play onto third-party stores, APPraiser found 76% carried malware. It is an old trick: Zhou and Jiang showed that 1,083 of 1,260 Android malware samples (86%) were real apps with an added payload, so someone steals the game, injects ads or spyware, then redistributes it. AdRob estimated that cloned developers lost about 14% of ad impressions and 10% of users to the copies.

iOS looks safer than it is

Apple says less about clones, but its store is not clean. Apple puts out a yearly fraud report, and in 2025 it turned away more than 371,000 app submissions for being spam, copycats, or misleading, and it stopped nearly 7,800 apps it judged deceptive from ever showing up in search. Researchers have studied this side too. One project trained a tool on 10,100 iOS action games over five years just to tell copycats apart from originals. So on iPhone the problem is real and measured, even though Apple never prints a single "percent stolen" number. "It is on the App Store" does not mean anyone checked whether it is yours.

Steam and the PC stores

Windows is a different market. There is no matching study on how much of Steam is stolen Unity executables. Selling someone else's finished .exe under a new Steam page is a worse business than dumping a crack on a download site. What Steam does have is a lot of shovelware. In 2017 Valve removed 173 titles from one operator who had been mass-shipping nearly identical products. The flood is easy to see today. In 2024 about 19,000 games launched on Steam, and roughly 79% of them were tagged "Limited," a status Valve gives titles that have not sold or been played enough. Valve treats it as its main filter against shovelware, scams, and asset flips. It also runs cleanup waves, like a 2023 sweep that pulled about 90 asset-flip and bootleg games and banned the accounts behind them. Those cases are flips and clutter, not stolen copies of one indie game. If you ship on Steam, expect piracy first. If you ship a Unity game on Android, expect someone to try the APK.

The smaller stores lean on you

The smaller stores have the least public data and the lightest screening, so there the work falls even more on you. Epic's store bans scams and impersonation in its rules, and it does act. A crypto game called Paradise faked an Epic partnership and reused Grand Theft Auto assets, Epic delisted it, and it came back under a new name. On itch.io there are no clean numbers at all, only a steady run of reports from developers whose games, and even profile pictures, were re-uploaded by fake accounts to spread malware. Itch's own staff say they mostly act once someone reports the page. On stores like these, the report you file, with proof attached, is the whole enforcement system.

Even well-funded games are wide open

None of this needs a skilled hacker. Promon's 2023 game security report tested 357 high-revenue mobile titles. Only 15.7% had any repackaging detection, and the testers could repackage about 85% of them. This is not only a game problem: in a separate test Promon repackaged 61% of the banking and trading apps it looked at, and those are supposed to be the careful ones. If the top-grossing studios ship builds this open, an indie title is an easy target.

A real Unity case

In 2020 a Unity developer posted that someone had stolen their Play APK. The thief replaced the bundle identifier and ad units, added location, calendar, and phone permissions, and published it on another account. It was not a remake, it was a full copy of files matched an older version by name and size. The developer's company name was still sitting in globalgamemanagers.

Google did not catch it on upload. The first DMCA reply was "are you the authorized copyright agent?" That is a paperwork problem, not a technical one, but it is also why the leftover strings and matching file sizes mattered. The store does not know the clone is yours until you can show it.

That leftover string worked as an accidental watermark, but you should not rely on accidents.

The stores remove millions and still miss yours

The big stores are not sitting still. In 2024 Google blocked about 2.36 million apps that broke its rules and banned 158,000 developer accounts. In 2025 it blocked another 1.75 million and banned 80,000 more. Apple turned away over 371,000 copycat, spam, or misleading submissions in 2025.

Those are huge numbers, and none of them are your clone. Those systems hunt for malware, spam, and rule-breaking across millions of apps at once. They do not know that one reskin, with a new name and new ads, was built from your code. Making that link is the one part of the job only you can do, and only if you saved something to compare against before the theft. The watermark is that something.

Why the store name will not save you

Unity writes the product name and application identifier into the player. Both can be read at runtime and they are useful for your UI, deep links, and telling which build a normal user has installed.

But they are useless as proof of ownership against a copy cat.

Application.productName is just a display string, and the clone will have a new one. Application.identifier is the Android package name or the bundle id you typed in Player Settings. The package name is the first thing a republisher changes, because they cannot sign and upload a second listing without changing it. On a normal Windows game there is no store-enforced package identity at all.

So a runtime check that says "the package name must be com.studio.mygame" fails the moment the APK is re-signed. And a listing that uses their name proves nothing about whose code is inside.

Platforms act on your rights, not on a similar title. Google Play keeps impersonation (the listing misleads users) separate from copyright and trademark (they copied your work). Pick the wrong form and the case stalls. A practical takedown guide and DMCA templates for game developers all come back to the same point: you have to show that the content is yours.

"It looks like our game" is a start. But "the binary is ours" is what gives you legal standing.

What a code watermark actually is

A watermark is a secret you pick at build time, turn into a signature, and hide inside the game or app.

You choose a phrase that only your team knows. Then place it in locations only you know, or in completely random places.

That is the whole idea. The signature is not a license check, it is just a fingerprint you can identify later.

Open or download the suspect game or app, and look for that fingerprint. A match tells you this game or app went through your watermark pass, with your text, for that build. It is much stronger than "this skins looks like ours." It says "this is our code."

Do not want to build this yourself? Use the GuardingPearSoftware Obfuscator

You do not have to write any of this. The GuardingPearSoftware Obfuscator brings with the release 2026.6.0 a feature called Assembly Watermark. You turn it on enter a custom phrase and when you build, it writes a unique fingerprint into every assembly (compatible with Mono/CoreCLR and IL2CPP). Every module gets the same mark, tied to your app and your secret. Players never see it, and nothing runs while the game is playing. The created fingerprint then gets printed in the Unity console, for an easy copy and paste for later proof usage.

If you suspect a clone, you can open the suspect game or app and look for that fingerprint. A match tells you this game or app went through your watermark pass, with your text, for that build.

How you use it against a platform

When you find a listing that is your game with a new coat of paint:

Download their package. Save any relevant infos. Screenshot the store page and the developer account.
Show the match. Point at the same fingerprint in their binary that only your watermark pass would have written. Putting it side by side with your own build is stronger than a screenshot of gameplay.
File the right claim, on the store's own form. Each store has its own official page. Send the same evidence pack to whichever one hosts the clone.
- Google Play: the copyright complaint form or the Play IP policy. If they also faked your name or icon, add an impersonation report.
- Apple App Store: the App Store Content Dispute form, one of Apple's dispute forms.
- Steam: Valve's Notice of Copyright Infringement form.
- Epic Games Store: Epic's copyright and trademark infringement page.
- itch.io: use the report link in the page footer, or send a DMCA notice as described in its terms.
Say who you are. The Unity thread above stalled first on "authorized copyright agent," not on any technical doubt. File as the rights holder, or attach the assignment.

Stores are not courts, this is important to know. They want a short, plain packet: you own it (with your proof), here is the clone, here is the overlap, take it down. A watermark turns "we think they stole it" into "here is a signature we put in before they ever saw the APK."

What a watermark is not

It will not stop the dump. Promon's numbers are clear that most commercial mobile games can be repackaged. IL2CPP makes code theft harder, but it does not hide your textures.

It will not survive someone who strips the unused metadata and rewrites the whole IL. Few people do that much work. Plenty of people do "new package name, new ads, old levels."

It is not a runtime Application.identifier check. Those APIs describe the install you are running right now, and the thief already changed them.

It is not legal advice, and it is not a replacement for registering copyright where that helps you. It is evidence you can attach to the process platforms already run.

What to do on your next build

Add a watermark or fingerprint to every next build you ship.
Make sure to keep a reference build, and the watermark.
When you find a clone, collect the package first, then file for copyright.

If you have to file a claim to a store that has no custom form, feel free to use this template:

Subject: DMCA Takedown Notice - [YOUR GAME NAME] - [INFRINGING LISTING NAME]

To the Designated Copyright Agent of [STORE / HOST NAME],

This is a notice of copyright infringement under the Digital Millennium
Copyright Act, 17 U.S.C. § 512(c), or the equivalent provisions of your
local law.

1. The copyrighted work
I am [YOUR NAME], [YOUR ROLE] at [YOUR COMPANY NAME], the owner of the
copyright in the game "[YOUR GAME NAME]", a [GENRE] game for [PLATFORMS].
The work includes its compiled code, artwork, animations, audio, level
data, and characters. It was first published on [DATE] and is available
here: [URL TO YOUR OFFICIAL STORE LISTING]

2. The infringing material
The following listing is a repackaged copy of our build, republished under
a different name, icon, and developer account:
[URL TO THE INFRINGING APP / GAME]
Developer account: [INFRINGING DEVELOPER NAME]
Package or app ID: [INFRINGING PACKAGE NAME / APP ID], if known

3. Evidence
Our build carries a private code watermark that we embedded before release.
The same fingerprint is present in the infringing binary:
- Watermark: [THE WATERMARK PROOF]
- Location in the infringing file: [FILE NAME AND WHERE THE MATCH WAS FOUND]
Additional evidence is attached: [LIST OF ATTACHMENTS, e.g. side-by-side
screenshots, matching file names and sizes, hash of the downloaded package,
date of download]

The infringing listing profits from our work through [ADVERTISEMENTS /
IN-APP PURCHASES / PAID DOWNLOAD].

4. Statements
I have a good-faith belief that the use of the material described above is
not authorized by the copyright owner, its agent, or the law.
I swear, under penalty of perjury, that the information in this notice is
accurate and that I am the copyright owner or am authorized to act on the
owner's behalf.

5. Request
Please remove or disable access to the infringing listing and let me know
once this has been done. If I do not hear back within [10] business days,
I will take further steps to protect our rights.

6. Contact and signature
[FULL LEGAL NAME]
[ROLE], [YOUR COMPANY NAME]
[STREET ADDRESS]
[CITY, POSTAL CODE, COUNTRY]
[PHONE NUMBER]
[EMAIL ADDRESS]

Signed: [FULL LEGAL NAME]  (typed name counts as an electronic signature)
Date: [DATE]

Read more on my blog: www.guardingpearsoftware.com!

Will GPT-6 Astra change game development forever?

GuardingPearSoftware — Sat, 05 Sep 2026 12:36:58 +0000

OpenAI released GPT-6 Astra, a brand new model. They promise a near-AGI-ready model, and the release interestingly focuses on game development.

You might already have seen videos of GPT-6 Astra-built games in Unity or Godot on X (Twitter) or other social platforms. The demos look really great, but does it really change game development forever? And will it change the industry?

In this article, we will explore the release, the numbers, and the reality of GPT-6 Astra in game development and whether the AGI promise is real.

When GPT-6 Astra released

OpenAI released GPT-6 Astra on September 3, 2026. The official announcement calls it a new generation model for computer use, software engineering, science, and professional work.

But not everyone got access on day one.

Who	When they get it
A first wave of approved organizations	September 3, 2026
ChatGPT Plus, Pro, Business, and Enterprise	Rolling out over the following days
OpenAI API (`gpt-6-astra`) and Amazon Bedrock	Same staged rollout
Free ChatGPT	No public date

Usage inside ChatGPT counts against the usual subscription limits. Extra credits are for sale if you run out. Pro, Business, and Enterprise also get GPT-6 Astra Pro. On Enterprise, Astra starts off. An admin has to turn it on.

If you opened ChatGPT on launch day and did not see the model, that is the staged rollout. As of this writing, a few days after launch, paid users are still getting access.

Here the current numbers:

Spec	GPT-6 Astra
Context window	1.05 million tokens
Max output	128,000 tokens
Knowledge cutoff	April 30, 2026
API name	`gpt-6-astra`

Takeaway: Astra is out. But most ChatGPT and API users still have to wait.

How it compares to GPT-5.6 Sol, Fable 5, and Fable 5.1

OpenAi advertises Astra as the new frontier model, and sure it is really good. But it does not beat Anthropic's Claude Fable on every test.

Claude Fable 5 shipped earlier in 2026. Claude Fable 5.1 arrived on September 1, two days before Astra. GPT-5.6 Sol is still OpenAI's previous flagship, and it is much cheaper per token.

Token price

Prices below are vendor list prices per 1 million tokens, short context. OpenAI charges more once a prompt goes past 272,000 input tokens. Sol's $4 / $20 rate is promotional through at least November 21, 2026.

Model	Input	Output	Cache read	Long context surcharge
GPT-5.6 Sol	$4	$20	$0.40	Yes, above 272K input
GPT-6 Astra	$10	$50	$1.00	Yes, above 272K input (2x input, 1.5x output)
Claude Fable 5	$10	$50	$1.00	No extra band like OpenAI's
Claude Fable 5.1	$10	$50	$0.25	No extra band like OpenAI's

Astra Fast mode runs about 2x Standard price for up to 2x speed. Batch and Flex are half of Standard.

The list price is easy to compare. For an agent that builds a prototype, it is the wrong number to trust. An agent that finishes in fewer loops can cost less even when each token is more expensive.

OpenAI's own Astra page says Astra beats Sol and Fable 5.1 on DeepSWE (a long software-engineering test) at about 57% lower API cost per finished task in the best-performing setup of each model. That is a vendor claim, not an independent lab result. Treat it as a hint, then measure on your own project.

Takeaway: Sol is cheaper per token. Astra and Fable 5.1 cost the same on paper. Fable 5.1 is cheaper when the same big context gets re-read from cache. Astra can still win on total bill if it needs fewer retries.

How well they solve tasks

These scores here come mostly from OpenAI's Astra launch tables.

Task type	Benchmark	GPT-5.6 Sol	Claude Fable 5	Claude Fable 5.1	GPT-6 Astra
Terminal / agent coding	Terminal-Bench 4.0	37.3%	42.0%	55.8%	57.9%
Long software work	DeepSWE v1.1	72.7%	69.9%	67.4%	74.1%
Independent coding agents	Artificial Analysis Coding Agent Index	65.1	67.2	70 (Claude Code)	67.0
Computer use	OSWorld 2.0 (OpenAI setup)	65.7%	not in that table	different setup	72.6%
Computer use speed	Time per OSWorld task	about 75 min	n/a	n/a	about 40 min
Automation	AutomationBench	18.1%	17.4%	31.4%	41.4%
Broad intelligence	Artificial Analysis Intelligence Index	60.9	62.1	65.7	61.2
Hard exam with tools	Humanity's Last Exam	not listed	63.8%	65.0%	57.2%
Spatial / CAD style work	BenchCAD	83.3%	67.5%	84.3%	95.9%

Astra is stronger when the job is "do the work inside software." Computer use and automation both jump from Sol. So does finishing a loop in the terminal. OpenAI also says Astra finishes computer-use tasks about 47% faster than Sol on OSWorld, and about 1.9x faster than the current Sol Codex setup on Mind2Web.

Fable 5.1 is stronger on some independent "how smart is this agent" scores. It leads the Intelligence Index. In independent coding-agent tests, Claude Code still looks slightly ahead. If your workflow is a long reasoning session over a big repo, Fable 5.1 is not the old model.

Fable 5 is the older sibling. Same $10 / $50 list price as 5.1. The cache price is worse, and it is a clear step behind 5.1 on Terminal-Bench and AutomationBench.

Sol is the budget workhorse. It is close to Astra on DeepSWE. It is far behind on Terminal-Bench 4.0 (37.3% vs 57.9%) and AutomationBench (18.1% vs 41.4%). For "write me a player controller" it is often enough. For "open the editor, change the scene, play, fix, repeat" it is the previous generation.

Astra also got better at spatial work and at judging how things look. That is the part game developers will feel. And Playco (Game Company) said the model placed objects in a way that made more sense. It also copied reference images better. Inside Unity, the UI it made responded more cleanly.

Takeaway: Use Sol when tokens are the budget. Use Fable 5.1 when a long coding agent has to think through a big project. Use Astra when the agent has to act inside a tool, see the result, and keep going.

What Playco and OpenAI actually did

Playco started as an instant-gaming studio. The idea was games you can play without installing an app, on platforms like Facebook, LINE, Zoom, Discord, and similar social apps. Titles such as EverWing came from that world.

What they built with Astra is Playbot, an AI-powered IDE for professional game developers. OpenAI published the customer story on launch day: Playco cut manual fixes 50% prototyping games with GPT-6 Astra.

The important sentence in that story is this: Playbot connects directly to engines such as Unity and Godot, so models can edit scenes, play and test games, check changes, and work in parallel inside the tools developers already use.

The experiment they reported:

The team asked Astra to build an unthemed grey box from simple primitives.
They made a few gameplay and art passes on that foundation.
From the same grey box, Astra produced three themed prototypes in one go.
Most of those prototypes worked on the first take. One cyberpunk version needed a performance fix. The others did not need another engineering pass.
Compared with the previous model, Playco reports about 50% fewer manual fixes.

Joao Vieira, Playco's lead product engineer, said the first prototype was already strong. The remaining changes were about their gameplay taste, not about fixing a broken build.

They also said Astra was better at placing objects in space, copying reference images, making UI that scales in Unity, and game feel. Because Playbot can let the model play the game, Astra caught bugs and flagged player-experience issues without waiting for a human to notice.

Read that 50% figure as a customer story, not a lab benchmark. It still tells you something useful. Playco is paying for Astra and connecting it to Unity and Godot for real prototype work.

The stack looks like this:

You: "Make me a small zombie shooter"
        |
        v
GPT-6 Astra (the model)
        |
        v
Playco's tooling layer (Playbot)
        |
        v
Unity or Godot
  - create / edit scene
  - create / edit scripts
  - change objects and components
  - run the game
  - inspect the result
  - fix, then run again

Playco sits in the middle box. OpenAI supplies the model. Unity and Godot stay the engines. The unanswered public question is what that middle box is made of. That is the next section.

Takeaway: Playco developed with Playbot, a new AI native IDE. For the development they used Astra as the model.

How Astra can be integrated: MCP, native tools, or desktop control

OpenAI's demo video looked like Astra is a new desktop control agent. It can control the mouse and keyboard and the screen. But it is not the only way to integrate Astra into a game development workflow.

1. Native or custom engine tools

This is the Playco-shaped path.

The model does not click GameObject > Create Empty. It calls operations the engine already understands:

create a game object
add a component
set a transform
create or open a scene
attach a script
enter Play Mode
read the console
capture a screenshot or a bit of game state

Those calls can be a custom OpenAI connector, a Unity Editor plugin, a Godot editor plugin, or a mix. OpenAI's public Playco write-up does not say the transport is MCP. It only says the model is connected to Unity and Godot and can edit, play, and check the result.

This difference matters in Unity. A Unity scene is not just a folder of .cs files. It is saved editor data: GameObjects, prefabs, components, lighting, UI canvases, addressable groups. A model that only edits scripts is not the same as an agent that can change the scene.

Godot is easier if you only edit files, because scenes are text (.tscn) and scripts are ordinary files. Even there, being able to run the game, read errors, and tweak nodes through the editor is a different product than a chat that dumps GDScript.

2. MCP (Model Context Protocol)

MCP is one standard way to expose those same operations.

Think of MCP as a plug format. ChatGPT, Codex, Cursor, or another host speaks MCP. A Unity or Godot MCP server offers tools. The model then reasons in a loop:

"I need a player, so I call create_game_object(), add a character controller, attach a script, run the game, read the console, fix the jump bug, run again."

A Unity MCP server might offer tools such as:

create_game_object()
modify_component()
create_scene()
set_transform()
run_game()
inspect_console()
capture_game_state()

This is much more powerful than generating a C# file in chat. It is also not magic. The model can only do what the server exposes, and only with the permissions you gave it.

You can already try this path. Community Unity MCP bridges exist, including CoplayDev/unity-mcp and CoderGamester/mcp-unity. Unity is also building a more official AI Gateway with a relay, a tool registry, and project-level permissions. Godot has community MCP servers as well.

None of those are Playbot. They are the same kind of interface: structured tools into the editor.

I already wrote more about the security side of MCP in Is MCP a security concern for game developers?. Short version: tools that can edit your project are powerful, and they expand what a bad prompt or a bad server can touch.

3. Desktop control (computer use)

The third setup is the one people picture from the videos.

GPT-6 Astra
    |
    v
computer-use actions
    |
    v
mouse, keyboard, and screen
    |
    v
the Unity or Godot editor, used like a human

Astra is unusually good at this. That is a big part of why OpenAI is pushing it. In principle it can open the editor, click through menus, type into the Inspector, press Play, and read the Game view.

In practice this is the fragile path. UI layouts change. A modal dialog blocks the next click. A pixel-level miss creates the wrong object. A long playtest is expensive, because the model is watching frames instead of calling run_game().

Desktop control is a fallback when no engine API exists. It is a poor first choice if you can expose real tools.

A fourth path people mix in: the game never leaves ChatGPT

There is another demo that looks like "Astra made a game" and has nothing to do with Unity or Godot.

ChatGPT can host an interactive widget. Apps SDK or MCP can serve a small React (or similar) game that runs inside the chat:

ChatGPT
  ├── the conversation
  ├── MCP tools
  └── a game widget
         └── the game runs inside ChatGPT

OpenAI also points at Sites in ChatGPT, where Astra can create websites, web apps, and games from a prompt, then host and share them. That is fine for a toy or a pitch. It also works for a web mini-game. It is not your Unity player, and it is not your Godot export.

Takeaway: If a video shows GPT building in Unity, do not assume it is driving your desktop. It may have a tool connection into the engine. It may also be a web game that never opened an editor.

What is possible yet

Here is the honest "today" list, a few days after launch.

Possible, if you have access and you build the connection:

Grey-box prototypes from a short brief, then several themes on the same foundation (this is the Playco result).
An agent that edits scenes and scripts, then plays the result, if you give it engine tools (Playbot-style, or MCP, or a custom plugin).
Faster first takes on layout, simple combat loops, menus, and "make this look more like the reference image."
Parallel helpers inside the same project, if your tools allow it. One agent can work on the player while another works on enemies or a UI screen.
Supervision from ChatGPT or Codex: you review diffs, reject a bad scene edit, and steer the next pass.
Small playable games inside ChatGPT, with no engine install.
Community MCP into a local Unity or Godot editor, if you accept the setup work and the security tradeoff.

Possible in principle, but a worse idea:

Letting Astra click through the Unity or Godot UI with computer use, the same way a junior would. It can work for a short demo. It will fight you on a real project.

What from Playco's demo you can copy:

The big change is not better C#. It is this loop:

old:  LLM → code → you paste → you press Play → you fix
new:  LLM → agent → engine → observe → test → modify → repeat

The model is no longer only saying "here is a player controller." It is closer to "I will add the controller, put it in the scene, run the game, notice that jumping does not work, inspect the console, change the script, and run again."

That is why the Playco demo looks more capable than a chat that only writes a script.

What is not possible yet

A short list, so hype does not set your sprint plan.

You cannot install Playbot as a public Unity or Godot package today. Playbot is Playco's product. OpenAI did not ship a "GPT-6 Astra for Unity" button.
The public story does not prove Playco uses MCP. The connection exists. The protocol is not named. Do not wait for an official "OpenAI MCP for Unity" stamp that may never arrive. You can still build an MCP server yourself.
Astra will not ship your game. Art direction, economy, live ops, platform cert, accessibility, and the last 20% of game feel still need people. Playco's own quote is about taste being the remaining work after the first prototype.
A prompt is not a design document. "Make me a small zombie shooter" can produce a grey box. It will not produce your combat identity. It also will not produce your retention loop or a store page that sells.
File-only agents are not engine agents. In Unity especially, generating .cs files is not the same as editing the scene, prefabs, and serialized components.
Broad access is still rolling out. If your team is not in the first wave, you cannot treat Astra as the default model on Monday morning.
Tokens are not free. A play-and-fix loop can burn a lot of context. Sol is cheaper per token. Fable 5.1 is cheaper on cache. Astra can be cheaper per finished prototype, or it can be a surprise bill if the agent keeps retrying and never gets there.
Safety gates can stop a session. Astra is a more tightly monitored model than Sol. Some long tool sessions may pause for review. That is annoying in a game jam. It is also why OpenAI shipped it this way.

People still sit between the model and the engine. OpenAI's own Unity case study talks about developers who build these workflows, inspect them, and supervise them. They are describing a job that still needs a person.

How this changes Unity and Godot development

Astra will not replace Unity or Godot developers. It will change a normal workday, first on prototypes, then on production chores.

For Unity developers

Unity is where engine tools matter most. A lot of a Unity project lives in YAML scenes and prefabs. Inspector values are in there too, and a code model never sees that data.

If you only let Astra write scripts, you will get the 2024 experience. You get a decent PlayerController.cs. The scene is still broken, and a reference is missing in the Inspector.

If you expose editor operations (native plugin or MCP), Astra can do the parts that used to eat a morning:

spawn a player and a floor, add a camera, then wire the references
add a canvas and a health bar that actually stretches
press Play, notice the character falls through the floor, fix the collider, press Play again
duplicate a grey box into a second theme without you rebuilding the hierarchy by hand

That is a real change for pre-production. Grey boxes get cheaper, and so do theme variants. A solo developer can test more combat ideas in a day.

It does not remove the Unity-shaped problems you already know: Addressables, IL2CPP, platform plugins, render pipelines, and "why is this prefab override different in the build." Those still need a person who has shipped a player.

If you want to try a local version of the loop, start with a dedicated test project. Use a trusted MCP server or a small Editor tool API. Make a hard rule that the agent cannot touch your main branch. Watch the console. Treat every scene diff like a pull request.

For Godot developers

Godot already stores a lot of the game as text. A strong coding agent (Astra, Fable 5.1, or even Sol) can get further on files alone than it can in Unity.

The Playco story still applies. Prettier GDScript is not the win. The win is the agent running the scene. It can see that the character controller feels floaty, then change the node properties until a playtest looks right.

Godot's lighter editor and smaller project sizes also make MCP or a custom plugin easier to set up than a giant Unity repo. If you already use version control and read .tscn diffs, watching an agent is closer to reviewing a normal pull request.

What will actually change in studios

In the near term, expect this:

Work	What changes
Grey box and first playable	Much faster, if the engine connection exists
Theme / skin variants of a prototype	The Playco "three from one" pattern becomes normal
Boilerplate systems	Player move, simple AI, menus, debug overlays
Playtest and "does jump work"	Agents can run and report, not only write
Direction and game feel	Still human, including shipping. Maybe more human, because more prototypes exist
Live title work	Unchanged. A faster prototype is not a safer live game, and it does not fix cheats or economy

The job shifts. You spend less time typing the first version. You spend more time defining the outcome and reviewing what the agent did. You also decide which tools the agent is allowed to use.

That is a skill. Teams that treat the agent like an unpaid intern with root access will make a mess. Teams that treat it like a junior with a checklist will ship more experiments.

So, will GPT-6 Astra change game development?

It changes the prototype loop. The model can act inside the editor instead of only generating code. For Unity and Godot, the teams that get there will not be the ones who paste better scripts. They will be the ones who give the model a safe, structured door into the editor. A person still owns taste and systems. They also own everything that happens after the grey box works.

The rest of game development (the part players pay for) is still yours.

Read more on my blog: www.guardingpearsoftware.com!

How Cybercriminals Are Targeting Job Seekers

GuardingPearSoftware — Fri, 04 Sep 2026 14:25:00 +0000

As more companies recruit online and millions of professionals rely on remote work, freelance marketplaces, and job boards, attackers have found new ways to disguise scams as career opportunities.

These scams can not only waste your time, but they can also lead to financial loss, steal your identity, or even compromise your entire digital life. As online recruitment continues to grow, so does the need for job seekers to stay vigilant. This guide will help you recognize the red flags, protect your personal information, and navigate your job search safely, without letting scammers derail your future.

Why job seekers are targets of cybercriminals

Job seekers are vulnerable because they are already expecting to receive communications from unfamiliar people and organizations.

A recruiter contacting someone through LinkedIn, SEEK, or a freelance marketplace may therefore not immediately appear suspicious. A message offering a remote position, interview, contract, or freelance assignment fits naturally into the person's expectations.

The same is true for freelancers. Professionals on platforms such as Upwork and Fiverr routinely communicate with strangers, receive project proposals, download documents, and exchange files with clients. This creates opportunities for attackers to hide malicious activity inside an otherwise normal business interaction.

Employment-related information can be extremely valuable for cybercriminals. A resume may contain a person's full name, phone number, email address, employment history, education, professional qualifications, location, and other information that can be used for identity theft or additional social-engineering attacks.

How Cybercriminals target job seekers

1. Fake job advertisements

One of the simplest techniques is the fake job posting.

Criminals create advertisements for positions that appear real but do not actually exist. The advertisements may promise unusually high salaries, remote work, flexible schedules, minimal qualifications, or immediate hiring.

The objective varies. Some scammers simply attempt to steal money from applicants. Others collect personal information or direct victims to phishing websites.

Freelance marketplaces are also affected. Upwork warns that common scams include unrealistic offers, vague job descriptions, requests to communicate outside the platform, phishing messages, and demands for money or gift cards.

AI has made the creation of these fake advertisements easier. Attackers can generate polished descriptions tailored to specific professions.

2. LinkedIn

LinkedIn is a valuable platform for networking, sharing insights, and discovering career opportunities, but its visibility can also make users attractive targets for cybercriminals. Attackers create LinkedIn profiles using stolen photographs, copied employment histories, or AI-generated profile information. They can then approach professionals directly with supposedly attractive opportunities.

Even seemingly casual conversations can be used to gather sensitive information about individuals or organizations.

To reduce the risk, regularly review your LinkedIn privacy settings, avoid publicly sharing sensitive recruitment or workplace details, and be cautious when accepting connection requests from unfamiliar accounts. Check details such as the person's job title, email address, location, follower count, and how long the account has been active.

If you don't know or trust someone, consider declining their connection request.

3. Malicious interview documents and coding tests

Perhaps one of the most dangerous developments is the use of malware disguised as part of the hiring process. A candidate may receive a document described as an interview assignment, job description, technical test, company presentation, contract, or application form. Instead, the file may contain malicious code or direct the victim to a website designed to compromise their computer.

North Korean-linked threat actors have repeatedly used this approach to target software developers on LinkedIn through a sophisticated social engineering campaign. The approach involves establishing a fabricated online persona with a credible professional background, which is used to build a rapport with a developer over an extended period.

After gaining the target's trust, the attacker will usually steer the conversation toward a lucrative job opportunity or a coding project, eventually asking the developer to download and run a "test" file or a coding challenge. This file is usually malware. Once executed, the malware can compromise the developer's system, allowing the attackers to steal credentials or gain a foothold into the developer's corporate network for further espionage.

4. Building Trust Before Making Their Move

The most sophisticated social engineering attacks don't necessarily look suspicious at the beginning. An attacker may spend considerable time communicating with the target.

They can discuss the victim's experience, ask about career goals, explain the company's supposed culture, and answer questions about the position. They may even conduct multiple rounds of interviews. This gradual approach exploits an important psychological principle: people tend to become more comfortable with requests after establishing familiarity with the person making them.

Once that relationship has been established, a malicious request can appear to be simply another step in the hiring process.

How job seekers can protect themselves

Research the employer independently.

Do not rely solely on the contact information supplied by the recruiter. Search for the company through independent sources. Check whether the company's website, email domain, physical address, employee profiles, and job advertisements are consistent.

Verify recruiters.

Check whether the person's employment history is consistent, whether the profile appears recently created, and whether the recruiter can be independently verified through the organization's official channels. Never open or download unsolicited files, especially PDFs and Word documents, until you have verified the sender.

Use a dedicated email for job search

To minimize your exposure during a job search, it's wise to use a dedicated, separate email address exclusively for applications and outreach. This can help you organize and track which companies, platforms, or individuals have access to your contact information, and also protects your primary personal or work email.

Do not pay.

Requests for deposits, cryptocurrency payments, gift cards, or transfers are major warning signs. Do not pay for training, equipment, or background checks.

Apply through official channels

Stick to secure application channels by submitting your applications directly through official company career pages or well-established, trusted recruitment platforms.

Slow down

Social engineering depends heavily on urgency and emotional pressure. Taking time to independently verify an opportunity can break the attacker's momentum.

Alert others

If you encounter these kinds of scams, let your friends and family know about the scam so they can avoid falling for it too.

Companies Also Have a Role to Play

The responsibility shouldn't fall entirely on job seekers. Organizations should recognize that attackers can impersonate their recruiters and hiring managers to target candidates.

Companies can help by clearly communicating how their recruitment works. Companies should also monitor for fraudulent job advertisements and impersonating recruitment accounts, particularly when their brand is being used to target large numbers of candidates.

Conclusion

Job seekers are becoming targets because the hiring process naturally requires people to communicate with strangers, exchange documents, share professional information, and trust unfamiliar organizations. As remote employment and freelance work continue to expand, the job search itself is becoming another major vector in the fight against cybercrime.

Read more on my blog: www.guardingpearsoftware.com!

Unity is replacing Mono with CoreCLR. What changes

GuardingPearSoftware — Mon, 31 Aug 2026 06:13:47 +0000

When you build a Unity player today, you pick a scripting backend. For a long time the choices were Mono or IL2CPP.

That list is about to change. Unity is replacing Mono with CoreCLR. But no worries, IL2CPP stays. So the new choice is CoreCLR or IL2CPP.

It is a real change after many years of Mono.

So let us explore what this switch mean for you as a game developer and your games runtime.

What is a runtime?

A runtime is the program that takes your compiled C# and makes it run. It loads assemblies, manages memory, starts threads, and talks to the operating system.

You do not write the runtime. You write MonoBehaviour scripts. Unity then picks a backend and that backend runs those scripts.

The backend is why a Windows Mono build ships Assembly-CSharp.dll, and why an IL2CPP build ships GameAssembly.dll.

What is Mono?

Mono is the runtime Unity has used for years for JIT (Just In Time) builds and for the Editor. JIT means the runtime compiles your C# on the machine that runs the game.

In a Mono player, your game scripts usually live in managed DLLs. Assembly-CSharp.dll is the common one. A Mono virtual machine loads those DLLs and runs them.

Unity does not use stock Mono from the wider C# world. It uses a custom fork. That fork is why Unity C# often sat behind current .NET. New language features, a newer garbage collector, and many current libraries arrived late or not at all.

What is CoreCLR?

CoreCLR is Microsoft's current open source .NET runtime. It is the runtime that powers modern .NET apps. Which Unity now also will use for its games.

CoreCLR is still a JIT runtime. Your C# is still managed code, but the runtime under that C# is newer.

A few concrete differences:

Feature	Mono	CoreCLR
Runtime	Old fork	Modern .NET
JIT	Old JIT	RyuJIT with tiered compilation
Garbage collector	Boehm GC (slow)	CLR GC (fast)
.NET surface	Older APIs	Newer APIs (.NET 10, C# 14 planned)

Tiered compilation means the runtime compiles your code twice. The first pass is fast to produce but not fully optimized, so your game starts quickly. Then, while the game runs, the runtime recompiles the hot paths (the code that runs most often) with heavier optimizations. Because of this, a fresh start can measure slower than a session that has already warmed up. Unity also notes that the CoreCLR player is still in active development, so don't treat a first timed run as the final performance number.

Takeaway: CoreCLR is not a new language. You still write C#. The runtime under that C# is changing.

Where this lands in Unity versions

Unity has used both "6.8" and "Unity 7" in public posts while this work landed. The order of the work is easier to follow than the names.

Release	What happens	What you do
Unity 6.6	Fast Enter Play Mode is the default for new projects. You can serialize `Dictionary` fields. Unity starts using the mimalloc allocator. Burst becomes a built-in module.	Turn on Fast Enter Play Mode in an existing project. Fix static state that Play Mode used to wipe.
Unity 6.7 LTS	Last release built on Mono. An experimental CoreCLR player exists for Windows, macOS, and Linux, next to Mono and IL2CPP.	Test CoreCLR in a branch. Do not ship that experimental player.
Unity 6.8 / Unity 7	Mono is removed as a scripting option. CoreCLR becomes the C# foundation. Unity 7 (beta planned for December 2026, full release in Q1 2027) is built on that core.	This is the upgrade you plan for.

Unity's 6.7 manual is clear about the experimental player. It is a technical preview for testing. It is not for production. It is only for macOS, Windows, and Linux build profiles. It also stays on the current .NET Standard 2.1 and C# 9 surface. You do not get .NET 10 in that preview.

Unity is also aiming for performance parity at the cutover. Some things will be faster, others will be slower. The bigger speed work is planned after the new runtime is in place.

And one detail that is easy to miss: the 6.7 Editor still embeds Mono. If you pick CoreCLR in Player Settings, that choice is for the desktop player you build. Play Mode in the Editor is still Mono.

Takeaway: With Unity 6.7, you can test the CoreCLR player in the Editor. But you should not ship it yet.

The garbage collector

Mono uses the Boehm–Demers–Weiser Garbage Collector (Boehm GC). It is very conservative, that means it does not move objects in memory. It cannot always tell a live object from a random number that looks like a pointer, and it never packs memory back together. That is one reason GC spikes show up as frame hitches.

CoreCLR uses a precise, moving, generational collector. It knows which objects are still alive. It can compact memory. Unity staff have said the CoreCLR large object threshold is 85 KB. That is a different rule than the old Boehm setup on desktop and mobile.

If you profile a Mono editor or a Mono desktop player, this is the change you will notice first. If you ship on IL2CPP, you unfortunately will not see this change at the moment. IL2CPP keeps the Boehm collector.

Unity 6.6 also starts using mimalloc, Microsoft's allocator. It handles multithreaded allocation better than the old path. Code that uses the C# Job System can get more stable allocation from the engine update alone.

Faster Play Mode, and static fields that stop resetting

For years, entering Play Mode meant a full domain reload. Static fields reset. The editor paused while that happened.

Fast Enter Play Mode has existed since 2019 but finally in 6.6 it becomes the default for new projects. By the CoreCLR cutover it is the only option. Unity will no longer unload the whole managed world for a script change. Later they want finer reloads, so only the assemblies you changed come back in.

Static variables then stop resetting for free. If your game "works" because Play Mode wiped a static cache, it will look broken until you clear that cache yourself.

// This used to look fine. Domain reload reset the list every time you pressed Play.
// With Fast Enter Play Mode, the list keeps growing across Play sessions.
public static class EnemyCache
{
    public static readonly List<Enemy> Alive = new List<Enemy>();

    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)]
    static void Reset()
    {
        Alive.Clear();
    }
}

Unity also added helpers such as [AutoStaticsCleanup]. Project Auditor can list the static fields that will keep old values.

Serialization and BinaryFormatter

Unity 6.6 can serialize Dictionary<TKey, TValue> with [SerializeField]. You can stop writing wrapper lists or ISerializationCallbackReceiver just to keep a dictionary in the Inspector.

BinaryFormatter is on the way out. .NET 10 marks it obsolete cause of long standing security problems. If your save system or a plugin still uses it, replace it before the cutover. Unity points people at JsonUtility, DataContractSerializer, System.Text.Json, or a plain BinaryReader / BinaryWriter pair.

IL2CPP is not going away

CoreCLR is a JIT runtime, which works well on desktop players and will work in the Editor once CoreCLR ships there. For now, in 6.7, the Editor's Play Mode still runs on Mono.

iOS, the consoles, and some other platforms do not allow JIT. Those targets need ahead of time compilation. That is what IL2CPP already does. Unity compiles your C# to IL first. Then il2cpp turns that IL into C++, and a native compiler turns the C++ into a platform binary.

Unity has said it has no plan to retire IL2CPP. CoreCLR's NativeAOT path does not cover every Unity platform.

So the old Mono versus IL2CPP choice becomes CoreCLR versus IL2CPP.

Target	Backend after Mono is gone	What you get
Editor (6.7)	Mono (even if the player uses CoreCLR)	Fast Enter Play Mode practice, not a CoreCLR test
Windows / macOS / Linux player	CoreCLR (JIT)	New GC now, current .NET later
iOS, consoles, many mobile stores	IL2CPP (AOT)	The same AOT path as today
IL2CPP desktop or mobile	IL2CPP	Still Boehm GC; .NET 10 / C# 14 later

If you ship on iOS or a console, your production build will very likely still go out through IL2CPP. The editor will be faster and the C# version will be newer. But the on-device GC is still Boehm.

Takeaway: Check where CoreCLR actually runs before you promise a smoother frame time on every platform.

What will break

Unity says most gameplay C# should keep compiling. The problems sit at the edges, mostly where C# meets native code.

Mono's garbage collector did not move objects. A lot of native plugin code assumed that. CoreCLR's collector can move objects. Unity had to rework its own marshaling. Third party plugins that pin memory the old way, or pass raw pointers into C++, need a close look.

Calls into Mono helper libraries such as MonoPosixHelper.dll will not even fail at compile time. Unity will stop shipping those libraries. At runtime you get DllNotFoundException.

Some old .NET habits will compile and then fail later:

BinaryFormatter and some other old serializers
Thread.Abort
AppDomain.CreateDomain and the old DomainUnload cleanup path
AppDomain.CurrentDomain.GetAssemblies() during reload
Assembly.Location (it can come back empty)
Direct P/Invoke into Mono libraries

If your code still has #if ENABLE_MONO, plan a replacement. Unity documents ENABLE_MONO and ENABLE_IL2CPP today, but there is no public ENABLE_CORECLR symbol in the 6.7 scripting reference. When Mono leaves, those Mono-only branches go with it.

A few behaviors also change. CoreCLR follows IEEE 754 more strictly than Mono's JIT did, so a few float results can differ. IL2CPP and Burst are not affected the same way. Static constructors can run later, or on a background thread, because they fire when the type is first used. CoreCLR is stricter about public and internal at runtime (reflection still works). Some conversions throw OverflowException where they used to wrap, for example IntPtr.ToInt32() on a 64-bit build.

A green Editor compile is not a CoreCLR test. You have to build a player and play it.

What to check before you upgrade

You can start with a list.

Write down your native plugins, DllImport calls, and any code that pins managed memory for C++. Gameplay scripts are usually fine. The native edge is where things break.

Search your project and your plugin DLLs for BinaryFormatter, SoapFormatter, and Thread.Abort. Grep will miss a compiled vendor DLL, so open those assemblies too.

Turn on Fast Enter Play Mode and run Project Auditor's domain reload checks. Fix static lists, static events, and caches that never clear.

Check Asset Store packages and SDKs for CoreCLR notes. An old analytics plugin can block the whole upgrade.

On a spare branch, open Player Settings, find Scripting Backend, and pick CoreCLR (Experimental). Build a Windows, macOS, or Linux player. Play through login, saves, purchases, and any native store or video SDK.

If the project compiles in the Editor but the CoreCLR build fails, start small. Build fewer scenes. Turn off optional plugins one at a time. Read the first real error in the log, not the pile of errors that follow it.

If the player starts and then dies, open the player log first. Look for TypeLoadException, FileNotFoundException, or a static constructor that threw. A missing native file next to a managed wrapper is a common cause.

Unity's Path to CoreCLR upgrade guide is the page to keep open. They have been updating it through 2026.

Does it affect the Obfuscator?

The GuardingPearSoftware Obfuscator is built on Mono.Cecil. Despite the name, Mono.Cecil is not the Mono runtime; it is a library for reading and editing .NET assemblies. So yes, the Obfuscator will keep working with CoreCLR.

A practical mindset

The CoreCLR switch is a runtime change. Your gameplay C# stays C#. The Editor, the player, and IL2CPP do not all switch on the same day.

The work is at the native boundary, in old serializers, and in static state that Play Mode used to wipe for you. The time to look is while 6.7 still lets you compare Mono and CoreCLR side by side.

Read more on my blog: www.guardingpearsoftware.com!

Cybercrime-as-a-Service: How Hacking is Becoming a Subscription Business

GuardingPearSoftware — Sat, 29 Aug 2026 13:27:46 +0000

For decades, launching a serious cyberattack required a combination of technical knowledge, programming skills, patience, and access to specialized infrastructure. That barrier has steadily eroded.

Today, someone with limited technical knowledge can gain access to capabilities that once required an experienced hacker. The result is a fundamental change in the cyberthreat landscape.

The arrests of individuals linked to the Scattered Spider collective are an example. A 19-year-old was allegedly involved in $115 million in extortion targeting thousands of organizations after joining the cybercrime collective at the age of 15 or 16.

Why The Barrier to Entry Is Falling

Cybercrime-as-a-Service

One of the biggest forces behind this transformation is the rise of Cybercrime-as-a-Service (CaaS).

The concept mirrors legitimate cloud and software businesses. Rather than building infrastructure from scratch, customers purchase access to an existing service.

Criminal markets have adopted a similar model. This creates an environment in which cybercriminals can specialize while relying on other criminals for capabilities they do not possess.

A technically inexperienced individual does not necessarily need to become proficient in penetration testing, reverse engineering, exploit development, or malware programming. They may only need enough knowledge to operate an existing platform.

Phishing Kits

Phishing provides one of the clearest examples of how cyberattacks have become easier to launch.

Historically, creating a convincing phishing campaign required some combination of web development, hosting knowledge, email infrastructure, social engineering expertise, and an understanding of how authentication systems worked.

Modern phishing kits can package much of that complexity into relatively accessible tools.

Criminals can obtain templates that imitate familiar login pages, configure campaigns, collect credentials, and monitor victims through centralized interfaces.

Some kits imitate widely used services and corporate authentication portals. Tycoon 2FA, currently considered one of the best phishing kits on the market, costs around $120 for 10 days of access through Telegram. It comes with documentation, customer-support channels, and regular feature updates.

Stolen Credentials Eliminate the Need to Break In

Another major factor is the enormous supply of stolen credentials available to criminals.

Why spend time discovering how to compromise an organization when valid credentials may already exist?

Infostealing malware has created a large underground supply of usernames, passwords, session information, cookies, and other authentication data. Criminals can trade this information, and specialized actors can use it to obtain access to corporate environments.

This has helped create the market for initial access brokers.

Initial-access brokers specialize in obtaining access to organizations and selling that access to other criminals. The buyer may have little interest in how the original compromise occurred.

They simply want access. That separation between access acquisition and attack execution lowers the barrier to entry. A criminal who lacks the skills to compromise a corporate network may be able to purchase access and then use other services to conduct the next stages of an attack.

Automation Is Replacing Technical Labor

Automation is another reason the barrier to entry is falling.

Cyberattacks involve many repetitive tasks: identifying potential targets, scanning systems, testing credentials, distributing messages, monitoring compromised machines, and processing stolen information. Automation allows criminals to perform these activities at a scale that would be impossible manually.

A tool that automatically identifies potential targets can replace hours of reconnaissance. Automated credential testing can replace manual login attempts. Automated phishing infrastructure can handle large numbers of victims.

Botnets can distribute malicious activity across thousands of compromised devices. Automation therefore changes the economics of cybercrime. Instead of asking how many targets one attacker can handle, criminals can ask how many targets their infrastructure can handle.

Artificial Intelligence

AI does not magically turn someone with no cybersecurity knowledge into an elite hacker. Advanced attacks still require expertise, operational security, infrastructure, and an understanding of complex environments. However, AI can reduce the amount of technical expertise required to carry out many individual tasks.

An inexperienced attacker can use AI systems to create convincing social-engineering messages, translate the messages, and research potential targets.

They can use AI to fill gaps in their knowledge and overcome technical obstacles they might otherwise struggle with. This lowers the knowledge threshold for cybercrime. This may lead to more people experimenting with offensive capabilities, while criminal marketplaces can develop new services to serve these less-skilled users.

Group-IB reported that organizations worldwide suffered nearly $350 million in verifiable losses from deepfake fraud during the second quarter of 2025 alone.

Humans remain the weakest link

The falling technical barrier also reinforces the importance of social engineering.

Technical vulnerabilities remain critically important, but criminals do not always need to exploit a sophisticated software flaw if they can convince an employee to surrender access. The human element can be considerably easier to manipulate than a hardened technical system.

AI-generated text, voice cloning, fake profiles, and convincing websites can make these impersonation campaigns more persuasive. An example is when a company’s CFO transferred $25 million to an attacker-controlled account after participating in a Zoom call with individuals who appeared to be the company’s CEO and other executives. The attackers used deepfake technology to impersonate company leaders and persuade the CFO to complete the transaction.

Why Organizations Should Be Concerned

The democratization of cyberattacks changes the threat model for organizations.

Today, the organization may face thousands of low-skilled attackers using automated tools simultaneously. Most of those attempts will fail.

But attackers do not need a high success rate when the cost of attempting an attack is extremely low. If automation allows one criminal to target thousands of organizations, even a tiny success rate can produce meaningful results.

This also increases the workload for defenders, who may need to investigate alerts, protect accounts, patch vulnerabilities, monitor endpoints, and respond to incidents individually.

What organizations can do

Defenders Must Also Democratize Security

If attackers benefit from automation and commoditized expertise, defenders need to do the same. Security teams should increasingly automate repetitive defensive tasks.

The objective is not to automate security completely. It is to ensure that defenders can operate at a scale comparable to the threats they face.

Defensive artificial intelligence can be particularly useful here, provided organizations maintain appropriate controls and human oversight. The same technologies that help attackers reduce technical barriers can help defenders reduce the workload created by increasingly automated attacks.

Train employees

Security awareness training also needs to evolve. Traditional training often teaches employees to identify obvious phishing emails. That is no longer enough. Employees may encounter highly personalized messages that reference real projects, coworkers, suppliers, job opportunities, invoices, or business relationships.

Organizations therefore need security cultures built around verification rather than suspicion alone. Employees should have simple ways to verify unusual payment requests, credential requests, account changes, and sensitive instructions.

The goal is not to expect employees to become cybersecurity experts. It is to create processes that prevent a single convincing interaction from becoming a catastrophic compromise.

Collective defense

One of the strongest defenses against the growing cybercrime-as-a-service ecosystem is collective defense, where organizations rapidly share threat intelligence, indicators of compromise, and emerging attack patterns rather than confronting threats in isolation. If security teams can identify a new phishing infrastructure, impersonation tactic, or credential-theft campaign early and distribute that intelligence across industries, other organizations can strengthen their defenses before they become targets.

Conclusion

Organizations may be putting themselves at greater risk by assuming that sophisticated attacks can only be carried out by highly skilled attackers. Security teams must now prepare for a much larger pool of threat actors whose access to automated tools, AI, and ready-made services gives them a far higher baseline level of capability. This does not mean technical hackers are disappearing. Sophisticated threat actors still develop advanced exploits, custom malware, and novel intrusion techniques. Instead, their expertise is increasingly being packaged into products and services that other criminals can consume.

Read more on my blog: www.guardingpearsoftware.com!

Designing Aevryn Candy: Five Lessons From Building a Match-3 Around "No Ads. Ever."

GuardingPearSoftware — Thu, 27 Aug 2026 11:57:28 +0000

Aevryn Candy is a colorful Android match-3 game I’ve been building around a simple idea: a relaxing mobile puzzle game should let you play without advertising constantly interrupting the experience.

That led to one of the project’s core rules: No Ads. Ever.

At first, that sounds mainly like a monetization decision. During development, though, I realized it affects much more than monetization. It influences pacing, progression, feature decisions, and even how I think about the scope of the game.

Here are five lessons I’ve taken from building it so far.

"No Ads" became a design constraint

A lot of free mobile games use advertising as part of the gameplay loop: an ad between levels, a rewarded video for another attempt, or a video to obtain an extra resource.

Once I decided Aevryn Candy wouldn’t do that, those interruptions disappeared from the design toolbox.

That means the game itself has to create the rhythm. A player should be able to open it, play a few levels, enjoy the puzzle, and stop naturally. Optional in-app purchases can exist, but watching an advertisement is never required to continue playing.

The broader lesson for me was that monetization choices are also game-design choices. Removing a system can influence the experience just as much as adding one.

Difficulty doesn’t have to be a straight line

Once those interruptions were gone, the remaining rhythm had to come from the levels themselves. Balancing progression has been one of the more interesting problems.

The obvious approach is to make each group of levels progressively harder. But if the goal is a relaxing game, an endless upward difficulty curve eventually works against that goal.

Around level 100, I started experimenting with a different rhythm. On selected groups of levels, I reduce the number of candy colors available, making useful matches easier to find, while keeping harder levels between those groups.

Instead of thinking:

hard → harder → harder → harder

I started thinking:

challenge → breathing room → challenge → breathing room

It’s a relatively small balancing change, but it has changed the way I think about progression. Difficulty can have pacing just like music or storytelling does.

Change a parameter before inventing another mechanic

When a level or system doesn’t feel right, the developer instinct is often to add something: another booster, another rule, another mechanic.

Aevryn Candy has taught me to try the opposite first.

The candy-color example is a good illustration. Changing how many colors are present can substantially change the probability of matches, cascades, and available moves. The player experiences a noticeably different level without having to learn anything new.

Before adding another system, I now try to ask: can the mechanics that already exist solve this problem?

For a small project, that can also mean less UI, less balancing, fewer edge cases, and less maintenance later.

Scope is itself a design problem

The same instinct — try the smaller change first — also applies to the project as a whole.

It’s easy to keep adding ideas to a game, especially when you’re close to implementation and can imagine dozens of possible features.

But every feature has a cost beyond the initial code. It needs presentation, balancing, testing, maintenance, and eventually compatibility with everything that comes after it.

So one question has become increasingly useful during development:

Does this actually make the puzzle experience better, or am I adding it simply because I can?

That question doesn’t mean the game should never grow. It means additions should earn their place.

Decide what your game will not do

This may be the most useful lesson I’ve taken from Aevryn Candy.

We usually define games by their features: what mechanics they have, what progression they offer, what players can unlock. But constraints can create identity too.

“No Ads. Ever.” is one of those constraints for Aevryn Candy. It gives me a simple test for future decisions: if something damages the relaxed, interruption-free experience I’m trying to create, it probably doesn’t belong — even if it is common practice elsewhere in mobile gaming.

Having a clear list of things a project won’t do can make the things it should do much easier to see.

Still learning

Aevryn Candy is still evolving, and releasing a game changes the learning process: design assumptions eventually meet real players.

But these five ideas have already changed how I approach the project — particularly the idea that good design isn’t always about adding more. Sometimes it’s about removing an interruption, changing a small variable, giving the player some breathing room, or deliberately saying no to a feature.

Play Aevryn Candy

Aevryn Candy is a game by Aevryn Studios developed by Ricardo Tavares Santos. You can find it on Google Play.

Google Play

Read more on my blog: www.guardingpearsoftware.com!

GuardingPearSoftware Obfuscator vs Eazfuscator.NET

GuardingPearSoftware — Thu, 27 Aug 2026 10:09:20 +0000

Unity does not encrypt your gameplay code when you press Build. A .NET decompiler or an IL2CPP metadata dump can still show type names, walk your systems, and print the strings you left in your original C# code.

To protect your code, you might come across: Eazfuscator.NET (a well-known commercial C# obfuscator from Gapotchenko) and also GuardingPearSoftware Obfuscator (a dedicated Unity asset and tool).

Both tools make C# code harder to reverse engineer, but they serve different environments. Eazfuscator is designed for a .NET SDK project: add the NuGet package, and Release builds are protected. Unity is not that project. GuardingPearSoftware Obfuscator lives in the Unity Editor and the player or cloud build.

This comparison breaks down how both tools work, where their features differ, and which one fits your game development workflow.

Short answer

GuardingPearSoftware Obfuscator Pro costs $79.99 (one-time purchase). It includes symbol renaming, string obfuscation, fake code injection, method control flow, anti-tamper checks and more hardening features. It runs directly inside your Unity build pipeline and patches your game assets when it renames MonoBehaviour classes and other serialized types.

Eazfuscator.NET offers renaming, string encryption, control flow, and code virtualization. A single developer license is $399 perpetual (1 year of updates, then $99 to renew). A site license is $1,699 ($419 to renew). The single-dev license caps CPU cores at 16. There is no Unity asset patcher and no full licensing API.

In simple words:

Choose GuardingPearSoftware Obfuscator for Unity games.
Choose Eazfuscator.NET for a normal .NET app where you want virtualization with almost no extra build UI.

Eazfuscator does not understand Unity assets. It cannot patch prefabs or Addressables when code names change.

Quick comparison

Topic	GuardingPearSoftware Obfuscator	Eazfuscator.NET
Vendor	GuardingPearSoftware	Gapotchenko
Based in	Germany	Ukraine
Main focus	Unity games	.NET SDK / Visual Studio
Price	$79.99 one-time	$399 or $1,699
Integration	Unity build pipeline	NuGet and attributes
Deterministic builds	Yes	Site license feature
Unity prefab patching	Yes	No
String obfuscation	Yes	Yes
Control flow	Yes	Yes
Virtualization	No	Yes
Homomorphic encryption	No	Yes
Anti-tamper	Yes	No
Watermarking	Yes	No
Best fit	From Indie to Enterprise Studio	C# app teams

The table is simple on purpose. Eazfuscator wins on virtualization and a quiet .csproj workflow. GuardingPearSoftware Obfuscator wins on Unity daily use and price.

What GuardingPearSoftware Obfuscator does

GuardingPearSoftware Obfuscator is a Unity cybersecurity asset. After you enable it, protection runs when you press Build. You do not export a DLL, open a second Windows GUI, then copy files back. The same hooks fire for a custom BuildPipeline.BuildPlayer script and for cloud builders that run a normal Unity player build.

The package can rename namespaces, classes, methods, fields, properties, and events. And also rename the Unity types that most generic tools skip: MonoBehaviour, ScriptableObject, and Playable classes. After the rename pass, it updates scenes, prefabs, and other assets that still store those names.

Unity stores a lot of meaning as text. A button in the Inspector may keep the method name it should call. An animation event may keep a string. A serialized field on a component keeps its field name. Addressable bundles can keep script references too. Obfuscator has compatibility settings for those cases: Inspector values, UnityEvents, animation events, reflection and coroutines, UI Toolkit, and Addressables (JSON and binary catalogs, custom local or remote paths, and Addressable Shield on Unity 6 and newer).

It also hides strings, adds random fake code, and can suppress simple ILDasm inspection. Mono builds can get control flow and assembly signing. Standalone builds can get integrity checks. Mapping files stay available so crash logs are still readable after release. A Free tier exists if you want to test the pipeline first. MonoBehaviour and namespace renaming are Obfuscator Pro features.

The tool stays local. You do not send the game to a cloud protector. Because it runs inside Unity and Tuanjie, it works on any platform where those editors run, including Windows, macOS, and Linux build machines.

What Eazfuscator.NET does

Eazfuscator is known for a quiet workflow. You install Gapotchenko.Eazfuscator.NET, and Release builds get protected. Settings live in C# attributes, not a second GUI if you do not want one.

Feature notes from public pages:

Full lexical obfuscation
String encryption
Control flow
A custom VM that can change its instruction set per run
Claims around homomorphic-style work on encrypted values
Resource encryption and compression
Assemblies merging and embedding
Deterministic obfuscation on the site license

It does not sell a Unity story. You would export or hook assemblies yourself, then keep every Unity-required name by hand. Sometimes people try it on a Unity assembly. Support and success depend on your Unity version, backend, and how much reflection you use. It is not the documented happy path.

You pay for a general .NET product with a VM, not for Unity scene patching. Pro does not include virtualization. Its depth is Unity coverage, not a custom IL VM.

The biggest difference

Eazfuscator is a polished .NET developer tool. GuardingPearSoftware Obfuscator is a polished Unity developer tool.

Virtualization can hide a payment formula in a desktop app. It will not fix a missing script on a prefab if the class name changed and the scene file did not.

A renamed PlayerHealth on a prefab that still says PlayerHealth in the scene is still easy to find. Unity tools that patch assets attack that problem. Eazfuscator has no such pass.

If you run it on a Unity assembly, it can rename your MonoBehaviour classes in the DLL. It cannot update your binary scene files, prefab assets, or Addressables bundles. When you launch the game, Unity reports missing script errors and your game objects break.

To avoid that, you must exclude every MonoBehaviour, ScriptableObject, serialized field, and UnityEvent callback. That leaves your most important game logic exposed with plain names.

Why Unity-aware renaming matters

Unity does not only compile C#. It also saves type names and member names inside assets. That is how the Inspector, scenes, and prefabs keep working after you close the Editor.

public class PlayerHealth : MonoBehaviour
{
    [SerializeField]
    private int maxHealth = 100;

    public void TakeDamage(int amount)
    {
        maxHealth -= amount;
    }
}

If a generic protector renames PlayerHealth or maxHealth, the prefab can lose the script or reset the value. If it leaves those names alone so the prefab stays valid, attackers still search for PlayerHealth and find the logic.

GuardingPearSoftware Obfuscator is built for that tradeoff. It can rename the class and the serialized field, then update the related assets so the GameObject still points at the new names. Eazfuscator has no such Unity pass. Its safe default is to skip the names Unity stores as data.

Which one should you pick?

Pick GuardingPearSoftware Obfuscator if you want:

Unity integration
Asset-aware renaming
A lower one-time price
Mapping files for crash reports

Pick Eazfuscator.NET if you want:

Virtualization on a .csproj
Attribute-based config in C#
No game engine in the stack

Final thoughts

Eazfuscator.NET is one of the nicer commercial C# obfuscators for normal software.

For Unity, GuardingPearSoftware Obfuscator is the better choice on workflow and price. Use Eazfuscator when the app is not a Unity player.

Read more on my blog: www.guardingpearsoftware.com!

What 920 indie developers actually expect from their games

GuardingPearSoftware — Wed, 26 Aug 2026 13:18:07 +0000

I have been working with the Unity platform around 12 years now. I have met many developers working with many engines like Unity, Unreal Engine, GameMaker, and later newer engines like Godot. All of them created lovely games, but they all have one thing in common: they did not enjoy getting out there and marketing their games. But they all want to make money. And that is where the marketing comes in.

Many did not know how to get started with marketing their games. What competition is out there? What are the best practices? And so on.

So to give a first head start, I created a small free market insights calculator for game developers.

I researched a lot of statistics, and based on that, I created a calculator that gives developers a better insight into where they stand with their game and their expectations. It also includes info on wishlists, revenue, etc., showing how important marketing is.

I made it public in August 2025, and now one year later, in 2026, I wanted to share the results. At that point the calculator only supported the desktop platform, but now it also supports the mobile platform. So the following stats are based on 920 developers who filled out the calculator for the desktop platform.

So in the following sections I share results I found interesting.

Development Platform Distribution

You can select a variety of development platforms in the calculator. But the three biggest, by far, as submitted by the developers, are Unity, Unreal Engine, and Godot.

Unity: 50.2%
Godot: 33.6%
Unreal Engine: 10.4%

As you can see, Unity is the clear winner here. But it is not really surprising that Godot is in second place here too, because Godot is currently the top platform by developer usage. Still very interesting for me, because my website focuses on the Unity platform, but 34% still entered Godot.

Platform	Submissions	%
Unity	460	50.2
Godot	308	33.6
Unreal Engine	95	10.4
Other	22	2.4
Custom	18	2.0
GameMaker Studio	10	1.1
Construct	1	0.1
Flutter	1	0.1
React Native	1	0.1
Android Studio	1	0.1

Table 1: The development platform distribution

Some interesting observations:

Unity and Godot together make up almost 84% of all submissions. After that, the drop-off is steep: Unreal sits at 10%, and everything else is noise.
Custom engines (2.0%) outnumber GameMaker (1.1%). For a tool with such a long indie history, GameMaker is almost absent here.
Tools built for mobile (Flutter, React Native, Android Studio) barely appear, which makes sense: this dataset is desktop only.

Platform vs. Genre Breakdown

A game also has a main genre, next to keywords like tags. First place is the Action genre across the big three platforms:

Unity: 30.0%
Godot: 18.8%
Unreal Engine: 28.4%

Here is a detailed breakdown of how each development platform's submissions split across genres. Each row adds up to 100% of that platform's entries. This can help you see which genres are the most popular on each platform.

Platform	Action	Strategy	Casual	Adventure	Simulation	Other	Role Playing	Racing	Sports
Unity	30.0	12.2	10.9	11.5	12.8	11.3	7.4	2.6	1.3
Godot	18.8	17.2	14.9	11.7	9.4	12.7	12.7	1.9	0.6
Unreal Engine	28.4	16.8	11.6	14.7	14.7	4.2	6.3	3.2	0.0
GameMaker Studio	40.0	30.0	10.0	0.0	0.0	10.0	10.0	0.0	0.0
Custom	16.7	27.8	11.1	0.0	0.0	11.1	22.2	5.6	5.6
Other	4.5	9.1	13.6	31.8	13.6	4.5	22.7	0.0	0.0
Android Studio	0.0	0.0	0.0	0.0	100.0	0.0	0.0	0.0	0.0
Flutter	0.0	0.0	0.0	0.0	100.0	0.0	0.0	0.0	0.0
Construct	100.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0
React Native	0.0	0.0	0.0	0.0	100.0	0.0	0.0	0.0	0.0

Table 2: Genre share of each development platform's submissions (%)

Some interesting observations:

Action is the default on Unity (30.0%) and Unreal (28.4%), but Godot is much more even: Action is only 18.8%, with Strategy close behind at 17.2%.
Role Playing is much more common on Godot (12.7%) than on Unity (7.4%).
Sports is basically dead across the board: 1.3% Unity, 0.6% Godot, 0% Unreal.

Platform vs. Revenue Expectations

You want to make money with your game. And that is why you are here. So let's see what the developers expect in terms of revenue. The median revenue expectation per unit:

Unity: $10.00
Godot: $9.99
Unreal Engine: $12.00

As you can see, Unity and Godot developers have similar expectations of a listing price of $10 per unit, median-wise. Unreal is at $12, which is 20% higher.

Here is how each development platform's submissions split across expected revenue per unit buckets. Each row adds up to 100% of that platform's entries.

Platform	Free	$0-5	$6-10	$11-15	$16-20	$21-25	$26-30	$36-40	$46-50	$56-60	$96-100
Unity	13.0	12.2	34.3	17.4	13.0	4.1	4.8	0.4	0.2	0.2	0.2
Godot	11.4	24.0	28.9	18.2	12.7	2.3	1.9	0.3	0.3	0.0	0.0
Unreal Engine	9.5	8.4	30.5	22.1	15.8	7.4	5.3	0.0	0.0	0.0	1.1
GameMaker Studio	20.0	20.0	10.0	30.0	20.0	0.0	0.0	0.0	0.0	0.0	0.0
Custom	27.8	11.1	22.2	27.8	5.6	5.6	0.0	0.0	0.0	0.0	0.0
Other	22.7	40.9	13.6	18.2	4.5	0.0	0.0	0.0	0.0	0.0	0.0
Android Studio	100.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0
Flutter	100.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0
Construct	0.0	100.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0
React Native	0.0	100.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0

Table 3: Expected revenue per unit share of each development platform's submissions (%)

Some brief observations:

$6-10 is the most common bucket for all three big engines, which matches the ~$10 median.
Godot is the cheap-game engine: 24.0% sit in $0-5, vs 12.2% Unity and 8.4% Unreal.
Almost nobody prices above $30. The $36+ tail is 1.0% of Unity, 0.6% of Godot, and 1.1% of Unreal (one $96-100 outlier).

The share of free desktop games is around 10% for all of them, which makes sense. In the desktop market, a large share of revenue comes from the unit price. For mobile it is mostly ads-based, so free is the way to go (but that is not included in these charts) — just my guess.

Platform vs. Team Size

Developing a game is a team effort. So let's see how many people are working on a game on each platform. The average team size for the big three platforms:

Unity: 4
Godot: 2
Unreal Engine: 4

As you can see, Unity and Unreal Engine developers have similar average team sizes, around 4 people. Godot is at 2, half the size.

Here is how each development platform's submissions split across team size buckets. Each row adds up to 100% of that platform's entries.

Platform	Personal (1)	Small (2-5)	Medium (5-25)	Large (25-100)	Major (100+)
Unity	55.9	35.9	7.2	0.7	0.4
Godot	70.5	27.9	1.6	0.0	0.0
Unreal Engine	46.3	46.3	6.3	1.1	0.0
Other	63.6	36.4	0.0	0.0	0.0
Custom	88.9	5.6	0.0	0.0	5.6
GameMaker Studio	80.0	10.0	10.0	0.0	0.0
Construct	0.0	0.0	100.0	0.0	0.0
Flutter	100.0	0.0	0.0	0.0	0.0
React Native	0.0	100.0	0.0	0.0	0.0
Android Studio	100.0	0.0	0.0	0.0	0.0

Table 4: Team size share of each development platform's submissions (%)

Some interesting observations:

Godot is a solo engine in this sample: 70.5% personal vs 55.9% Unity and 46.3% Unreal. That is why the average team size is 2.
Unreal is the most team-shaped of the three: personal and small (2-5) are tied at 46.3% each.
Large studios barely show up here: 1.1% of Unity, 1.1% of Unreal, and 0% of Godot.

What do you think? Did you expect such numbers?

If you are interested, please feel free to check out the calculator here:

https://www.guardingpearsoftware.com/calculator/market

Read more on my blog: www.guardingpearsoftware.com!