DEV Community: MR storm

Web Testing Is Boring And That's The Whole Problem

MR storm — Mon, 26 Oct 2026 19:44:48 +0000

I've been poking at web apps for a while now, and I need to say something that'll probably annoy people who make money off bug bounties.

Most of it is the same five bugs.

Not similar bugs. Not "bugs in the same family." The same bugs. Same logic, same mistakes, same missing checks, copy-pasted across a thousand different products by a thousand different teams who all think their situation is unique.

The reason this matters is that the industry — bug bounties, pentest firms, the whole "become a hacker" content ecosystem — sells web testing as a hunt. A treasure hunt. You against the codebase, finding what nobody else could find. And that framing is a lie. What you're actually doing, most days, is walking the same hallway and trying every door handle in the same order, and every once in a while one of them is unlocked.

Let me back up, because if you're new you probably don't believe me.

The five bugs
There are five bugs. Everything else is a variation.

Broken access control. This is the big one. It's IDOR, it's privilege escalation, it's "the API endpoint returns another user's data because it trusts the ID you sent." It's an admin endpoint that a regular user can hit because nobody checked. It's a GraphQL query that lets you ask for fields you shouldn't see. It's the #1 bug on OWASP's list for a reason — it's everywhere, it's easy to miss, and it's usually devastating when found.

XSS. Reflected, stored, DOM-based. Pick your flavor. Somewhere, a user-controlled string is being dropped into HTML without escaping. Half the time it's a rich text editor that "sanitizes" input with a regex that doesn't work. The other half it's a template that interpolates raw. Same bug, infinite faces.

SSRF. Somewhere, an app fetches a URL that a user supplied. Maybe it's an image preview. Maybe it's a webhook. Maybe it's a PDF generator. And if you can point it at 169.254.169.254 or localhost or an internal service, you're in.

Auth issues. Weak password reset. Token not invalidated on logout. Session not rotated after privilege change. JWT with alg: none accepted. Email verification bypassed by just... not doing it. Password reset token sent in the URL. Password reset token that doesn't expire. Password reset token that's just the user ID base64'd.

Open redirect and its friends. The next= parameter that will happily send you to evil.com. The OAuth callback that doesn't validate the redirect URI. The "return to" parameter on the login page. All the same shape.

That's it. That's the list. If you've tested web apps for six months, you've seen all five. If you've tested for two years, you've seen all five dozens of times. And if you've tested for five years, you've written the same finding report so many times you could do it in your sleep.

The bit where it stops feeling like hacking
Here's what a real web testing session actually looks like.

You scope the target. You spend an hour mapping the app — endpoints, parameters, auth flows, what talks to what. You run your usual tools. You start at the top of your checklist and work down. Authentication. Session management. Access control. Input handling. Business logic. You poke at every parameter with a "user_id" in the name. You try to hit every endpoint with the wrong role. You check whether the API actually enforces what the UI suggests.

And somewhere along the way, you find one. Almost always, it's one of the five. You write it up. You report it. You get paid, or you get a dupe, or you get told it's "by design."

Then you do it again. And again. And again.

The exotic stuff — the chained exploit that goes from an XSS on a subdomain through a misconfigured CDN into an internal admin panel — is real, but it's maybe 5% of what you'll ever find. The other 95% is "this endpoint doesn't check the org ID, so I can read any customer's invoices by incrementing the number."

I've seen people celebrate finding a novel deserialization bug like they cured cancer. And it's cool. It is cool. But the guy who found the missing authorization check on the billing page did more damage with less effort, and nobody tweets about that.

Why it feels useless
So here's the actual complaint, and I think it's valid.

When every bug is one of five, and every tool finds those five, and every scanner is basically doing the same checks — what exactly are you bringing to the table?

The honest answer is: coverage. You're bringing coverage. You're the person who checked. You're not finding new categories of bugs. You're finding the same categories on a new target, or on a target that's been checked before but where the checks missed something. You're a smoke detector. Not a firefighter, not a chemist who invented a new fire suppressant. A smoke detector.

And for a lot of people, that's not why they got into this. They got into it because they watched Mr. Robot or read a blog about a $100k bounty or saw a DEF CON talk about some insane 0day chain. They wanted the hunt. What they got was a job that feels like QA with extra steps.

I've watched people burn out on this. Not because it's hard — because it's repetitive. Because after you've found your hundredth IDOR, the thrill is gone, and you're left with the realization that the thing you're doing is a maintenance activity, not an intellectual adventure.

The counterargument, which I actually believe
Okay. Everything I just said is true, and I still think the "web testing is useless" take is mostly wrong. Here's why.

Boring bugs are the ones that actually hurt people. Novel 0days are what get the conference talks. Broken access control is what gets the data breach headlines. A missing auth check on an internal API is how 100 million records get dumped on a forum. The "boring" bugs are boring because they're everywhere and they're easy, not because they're unimportant. They're the leading cause of everything.

Finding the same bug class over and over is a skill. Not the fun kind of skill, but a real one. The ability to systematically work through 500 endpoints in a week and find the four that are broken is not something everyone can do. It requires discipline, tooling, and a kind of patience that most security people don't have. It's the difference between a pentester and a CTF player.

Coverage is the entire job. The reason companies pay for pentests and bug bounties isn't to find the next billion-dollar 0day. It's to have someone other than the dev team check the obvious stuff. Because the dev team is tired and moving fast and has a hundred tickets, and the "obvious stuff" is exactly what they skipped. A bored tester doing the same five checks is doing something the dev team should have done but couldn't.

The exotic stuff pays more for a reason. And that reason is that it's rare. The market rewards rarity, and if you want to chase rarity, go ahead. Just know that you're not outperforming the guy doing IDORs by an amount that justifies the hours. You're just playing a different game with a different variance profile.

The real problem isn't web testing. It's the framing.
Here's where I land.

Web testing is fine. It's useful. It prevents real breaches and it pays real bills. What's broken is how it's sold, both to newcomers and to the companies buying it.

Newcomers are sold a fantasy. "Become a hacker." "Find bugs." "Make $50k on HackerOne." The reality is a grind with a long tail, where the top 1% of hunters take most of the payouts, and the median hunter makes less than minimum wage in their first year. The bug classes don't change. The tools don't change much. The whole thing is closer to running a QA pipeline than to being Elliot Alderson.

Companies are sold the same fantasy in reverse. "We'll find all your vulnerabilities." They won't. They'll find the common ones. If the tester is good, they'll find some of the less common ones too. But the exotic bugs — the ones that require understanding a specific business logic or chaining three things — are hit or miss, and often the answer is "miss, because there wasn't budget for the week of investigation that would have found it."

So the honest version of the story is this: web testing is a maintenance function. It's the security equivalent of brushing your teeth. You don't do it because it's exciting. You do it because the alternative is expensive and painful and involves lawyers. And if you approach it with that understanding — as a job, not a hobby, and certainly not as a lifestyle — you'll be a lot happier doing it.

The easy bugs are already gone
Something I want to come back to, because it changes the picture a lot.

The five bugs I listed? Most developers already know about them.

Not "know about them" the way a pentester knows about them. Know about them the way a builder knows where the load-bearing walls are. The frameworks handle it. React escapes by default. Rails has CSRF tokens on by default. Django autoescapes templates. Laravel's ORM parameterizes by default. Spring Security gives you authentication and authorization primitives that are correct if you use them the way they're meant to be used.

The modern dev who builds a new SaaS in 2025 using Next.js and Prisma and Clerk is starting from a baseline where XSS and SQLi and CSRF are largely handled for them unless they actively do something stupid. Which they sometimes do. But not as often as they used to.

Add to that: security training is now standard. SAST tools run in CI. Dependency scanners flag vulnerable packages. Code review catches a lot. Bug bounties start on day one for any company with funding. The bar has been raised. Not to where the bugs don't exist — they absolutely do — but to where the easy bugs have gotten rare on new targets.

That's the part nobody tells you when you're starting out. You read a blog about IDOR and think "wow, every app must be full of these." And then you test a modern app and find... nothing obvious. Because they're using a framework that gives every object an owner check by default, or they're using a pattern that just doesn't have the bug class you're looking for.

So what happens is this: the new, well-funded, well-engineered sites are where every bug hunter is looking, because they pay the most and they're the most visible. And they're also the hardest to find bugs on, because they've been hardened. The overlap between "high payout" and "easy to find bugs" is basically empty.

Which is why, honestly, the better targets are often the opposite.

The graveyard is where the bodies are
I'm talking about sites that haven't been touched in five years.

Small business sites. Local government portals. University systems. Hospital intake forms. Old forums. Trade association membership databases. Anything running on PHP 5 or an old version of Drupal or a custom MVC somebody's cousin wrote in 2013. Sites that were built once, launched, and then nobody ever looked at them again because "if it ain't broke."

These sites are archeological digs. They have every bug.

No CSRF tokens anywhere. Password reset that just emails you the password. Admin panels at /admin with no auth beyond a cookie that's literally admin=1. SQL injection in a search box because the query is built by string concatenation. Stored XSS in the comment system because the output encoding is nl2br($comment) and nothing else. Rate limiting? Never heard of it. Security headers? What are those. HTTPS? Yes, but only on the login page, and only because their host forced it.

I'm not exaggerating. I've seen all of this in the last year. Not in a lab, not in a CTF, on live production sites belonging to real organizations with real users.

The reasons these places still have these bugs are boring. They don't have a dev team. They have one guy who "does the website" along with his actual job. They don't have a security budget. They don't have a bug bounty program. They don't read Hacker News. They upgraded to PHP 7 in 2019 and thought that was the big modernization project for the decade. Nobody has ever reported anything to them because nobody has ever looked.

And here's the thing — nobody is looking because nobody gets paid to look.

The catch
That's the trap. The bugs are there. The bugs are easy. But:

Old sites don't have bug bounty programs, because they don't know what that is.

Old sites often don't have a security contact, because they don't have a security team.

Old sites, when you report a critical SQLi to them, will often respond with "who are you, why are you hacking us, we're calling the police" because they've never received a vulnerability report before and don't know how to handle one.

Old sites often won't pay. Ever. Not because they're malicious, but because the person reading your email doesn't know there's a market rate for this and thinks you're trying to extort them.

So the math is: the bugs are 100x easier to find and 100x harder to get paid for. Which is why the bounty hunters don't go there, and why the bugs stay unpatched for another five years, and why the whole thing is a self-reinforcing cycle where nobody wins except the people who eventually break in for real.

What this means for you
If you're doing this for money — bug bounties, the standard model — you're competing on the hardest targets, against the sharpest people, for the same bugs that everyone else is trying to find. That's a bad game to be in as a beginner.

If you're doing this because you want to actually find bugs — because the puzzle is interesting, because you want to sharpen your skills, because you want to build a reputation that isn't just "I found a low-hanging XSS on a program that pays out $50" — then the old, forgotten, unmaintained corners of the internet are where you want to be.

Not for the payout. For the practice. For the CVEs. For the writeups. For the experience of finding a bug that has been sitting there for eight years waiting for someone to notice it. That's the part of this job that still feels like what you imagined when you got into it.

And every once in a while, you find an old site that does have a security team — maybe they just launched a bounty, maybe they're a mid-size company that's finally getting serious — and you find the bug that would have been trivial for anyone to find five years ago but that nobody looked for because it was "just a small site." That payout lands, and it lands hard, because you were the only one looking.

The lesson, if there is one, is this: the crowd goes where the money is. The money goes where the bugs are hard. The bugs are easy where the crowd doesn't go. That's the whole map. If you want to find easy bugs, stop following the crowd.

But also — and this is the part that'll get me yelled at by the bounty bros — the reason those old sites have easy bugs is that nobody's paying anyone to find them. And the reason nobody's paying is that the people who own those sites don't know they need it. Which is a system-level failure, not a personal one. You can exploit the gap, or you can try to close it, or you can just note that it exists and move on. But it's worth knowing it's there.

If you actually want to do this
Then embrace the boredom.

Learn the five bugs cold. Not the OWASP descriptions — the actual patterns, in the actual code, in actual products. Build a checklist and refine it. Get fast at mapping an app. Get good at writing reports that developers will actually read instead of dismissing. Understand the business logic of each target, because the bug classes are the same but the impact of each bug is different per app, and impact is what gets paid.

Then go do it. Over and over. On targets nobody's talking about, in languages nobody's excited about, against companies that aren't on the front page of TechCrunch. That's where the money is. That's where the bugs that actually matter live.

And accept that the day you find a really novel bug — if you ever do — it'll feel great for about a week, and then you'll be back to checking whether ?user_id= lets you read someone else's data. Because that's what the job is. The novel bugs are a side effect of doing the boring work well, not the point of it.

The interesting bugs aren't extinct. They've just moved to where nobody's looking.

Sorry to ruin the fantasy. But it's better to know going in.

Spoofing WiFi MAC Addresses with a Windows Kernel Driver

MR storm — Sun, 18 Oct 2026 16:28:49 +0000

1. What a MAC address is

A MAC address is six bytes. Convention writes them as hex pairs separated by colons:

A4:5E:60:C3:1B:07

The first three bytes are the OUI — the Organizationally Unique Identifier — assigned by the IEEE to the manufacturer. The last three bytes are assigned by the manufacturer to the specific unit.

The OS uses the MAC address to:

Filter incoming frames (the NIC drops frames not addressed to it)
Identify itself on the local network segment
Report to routers, switches, and access points
Provide a stable identifier for DHCP lease assignment

Spoofing doesn't modify the hardware. It intercepts the OS at some layer between the NIC driver and the network stack and substitutes a different value.

2. Why userspace can't reliably set it

The registry approach

Windows network adapter drivers read the MAC address from a registry value called NetworkAddress during initialization. Setting that value and restarting the adapter works for some drivers.

It fails for others because:

Some drivers ignore NetworkAddress entirely
Some read it only at boot, not on adapter restart
Some read it but report the physical address to the network stack regardless
Some validate the value against a format whitelist
Some cache the physical address elsewhere and prefer the cache

From userspace there's no way to know whether the write succeeded, because the adapter can report one address to getmac while using a different one on the wire.

The driver IOCTL approach

Some drivers expose a proprietary IOCTL that changes the MAC. Intel PROSet and Realtek's utility use this. Most drivers don't support it, or support it only through undocumented interfaces, or require the manufacturer's signing certificate to call.

The NDIS OID approach

NDIS defines OID_802_3_CURRENT_ADDRESS for setting the current MAC. Userspace can send OIDs via DeviceIoControl, but on modern Windows the write permission for this OID is restricted to kernel-mode callers. Userspace can query the OID but not set it.

The remaining option

A kernel driver that sits between userspace and the NIC driver and performs the registry write from kernel mode, where the access checks don't apply.

3. The three driver models

WDM — Windows Driver Model

The base model. You create a DRIVER_OBJECT, register dispatch routines for IRP major functions (IRP_MJ_CREATE, IRP_MJ_DEVICE_CONTROL, etc.), create a device object with IoCreateDevice, and handle raw IRPs.

You manage the device object lifecycle, reference counting, I/O queueing, and cleanup manually.

KMDF — Kernel-Mode Driver Framework

A framework layered on WDM. You work with WDFDEVICE, WDFQUEUE, and event callbacks instead of raw IRPs. The framework handles reference counting, PnP, power management, I/O queueing, and cleanup on unload.

NDIS — Network Driver Interface Specification

For network drivers specifically. An NDIS filter driver registers with the NDIS stack, sits between protocol drivers (TCP/IP) and miniport drivers (the NIC), and can intercept every OID and every packet.

Filter drivers have strict requirements around IRQL, packet lifetime, and reentrancy.

4. KMDF implementation

Device extension

Every driver instance has a device extension — a structure attached to the device object holding per-instance state.

typedef struct _DEVICE_EXTENSION {
    PDEVICE_OBJECT DeviceObject;
    UNICODE_STRING DeviceName;
    UNICODE_STRING SymbolicLink;
    UCHAR TargetMAC[6];
    BOOLEAN IsActive;
} DEVICE_EXTENSION, *PDEVICE_EXTENSION;

TargetMAC holds the value set by the last IOCTL. IsActive flags whether the last set succeeded.

IOCTL codes

#define IOCTL_SET_MAC_ADDRESS CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_GET_MAC_ADDRESS CTL_CODE(FILE_DEVICE_UNKNOWN, 0x801, METHOD_BUFFERED, FILE_ANY_ACCESS)

CTL_CODE packs four fields into a 32-bit value:

Device type — FILE_DEVICE_UNKNOWN (0x22). A generic device class.
Function code — 0x800 and 0x801. Values >= 0x800 avoid Microsoft-reserved codes.
Method — METHOD_BUFFERED. The I/O manager copies user buffers into kernel memory before invoking the driver. Irp->AssociatedIrp.SystemBuffer points at the kernel copy.
Access — FILE_ANY_ACCESS. Any user who can open the device can send the IOCTL.

Driver entry

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) {
    WDF_DRIVER_CONFIG config;
    WDF_DRIVER_CONFIG_INIT(&config, WiFiMacSpoofEvtDeviceAdd);
    return WdfDriverCreate(DriverObject, RegistryPath, WDF_NO_OBJECT_ATTRIBUTES, &config, WDF_NO_HANDLE);
}

WdfDriverCreate registers WiFiMacSpoofEvtDeviceAdd as the device-add callback. The framework calls it when it's ready for the driver to create its device object.

Device add

NTSTATUS WiFiMacSpoofEvtDeviceAdd(WDFDRIVER Driver, PWDFDEVICE_INIT DeviceInit) {
    WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_UNKNOWN);
    WdfDeviceInitSetExclusive(DeviceInit, FALSE);
    WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoBuffered);

    WDF_OBJECT_ATTRIBUTES attributes;
    WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
    attributes.DeviceObjectExtensionType = sizeof(DEVICE_EXTENSION);

    WDFDEVICE device;
    NTSTATUS status = WdfDeviceCreate(&DeviceInit, &attributes, &device);
    if (!NT_SUCCESS(status)) return status;

    PDEVICE_EXTENSION deviceExtension = WdfObjectGet_DEVICE_EXTENSION(device);
    RtlZeroMemory(deviceExtension, sizeof(DEVICE_EXTENSION));
    deviceExtension->DeviceObject = WdfDeviceWdmGetDeviceObject(device);

    WDF_IO_QUEUE_CONFIG queueConfig;
    WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&queueConfig, WdfIoQueueDispatchParallel);
    queueConfig.EvtIoDeviceControl = WiFiMacSpoofEvtIoDeviceControl;
    queueConfig.EvtIoStop = WiFiMacSpoofEvtIoStop;

    status = WdfIoQueueCreate(device, &queueConfig, WDF_NO_OBJECT_ATTRIBUTES, NULL);
    if (!NT_SUCCESS(status)) return status;

    static const GUID WiFiMacSpoofGuid = {0x12345678, 0x1234, 0x1234, {0x12, 0x34, 0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC}};
    status = WdfDeviceCreateDeviceInterface(device, &WiFiMacSpoofGuid, NULL);
    if (!NT_SUCCESS(status)) return status;

    return STATUS_SUCCESS;
}

WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoBuffered) sets the buffering mode for all I/O on this device.

WdfIoQueueDispatchParallel allows multiple IOCTLs to run concurrently. Sequential would also work; parallel is only needed for handlers that can overlap safely.

WdfDeviceCreateDeviceInterface registers a device interface GUID. Userspace finds the device by calling SetupDiGetClassDevs with that GUID, or by opening the symbolic link if one is created.

Device control handler

VOID WiFiMacSpoofEvtIoDeviceControl(
    _In_ WDFQUEUE Queue,
    _In_ WDFREQUEST Request,
    _In_ size_t OutputBufferLength,
    _In_ size_t InputBufferLength,
    _In_ ULONG IoControlCode
) {
    NTSTATUS status = STATUS_SUCCESS;
    WDFDEVICE device = WdfIoQueueGetDevice(Queue);
    PDEVICE_EXTENSION deviceExtension = WdfObjectGet_DEVICE_EXTENSION(device);
    PVOID inputBuffer = NULL;
    PVOID outputBuffer = NULL;
    size_t bytesReturned = 0;

    switch (IoControlCode) {
        case IOCTL_SET_MAC_ADDRESS:
            if (InputBufferLength < 6) { status = STATUS_BUFFER_TOO_SMALL; break; }
            status = WdfRequestRetrieveInputBuffer(Request, 6, &inputBuffer, NULL);
            if (!NT_SUCCESS(status)) break;
            RtlCopyMemory(deviceExtension->TargetMAC, inputBuffer, 6);
            status = ChangeWiFiMAC(deviceExtension->TargetMAC);
            deviceExtension->IsActive = NT_SUCCESS(status);
            break;

        case IOCTL_GET_MAC_ADDRESS:
            if (OutputBufferLength < 6) { status = STATUS_BUFFER_TOO_SMALL; break; }
            status = WdfRequestRetrieveOutputBuffer(Request, 6, &outputBuffer, NULL);
            if (!NT_SUCCESS(status)) break;
            RtlCopyMemory(outputBuffer, deviceExtension->TargetMAC, 6);
            bytesReturned = 6;
            break;

        default:
            status = STATUS_INVALID_DEVICE_REQUEST;
            break;
    }

    WdfRequestCompleteWithInformation(Request, status, bytesReturned);
}

WdfRequestRetrieveInputBuffer returns a pointer to the kernel copy of the user's input. WdfRequestRetrieveOutputBuffer returns a pointer to the kernel buffer that will be copied back to the user's output buffer after the handler returns.

5. WDM implementation

Driver entry

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) {
    UNICODE_STRING deviceName;
    RtlInitUnicodeString(&deviceName, DEVICE_NAME);

    PDEVICE_OBJECT deviceObject = NULL;
    NTSTATUS status = IoCreateDevice(
        DriverObject,
        sizeof(DEVICE_EXTENSION),
        &deviceName,
        FILE_DEVICE_UNKNOWN,
        FILE_DEVICE_SECURE_OPEN,
        FALSE,
        &deviceObject
    );
    if (!NT_SUCCESS(status)) return status;

    PDEVICE_EXTENSION deviceExtension = (PDEVICE_EXTENSION)deviceObject->DeviceExtension;
    RtlZeroMemory(deviceExtension, sizeof(DEVICE_EXTENSION));
    deviceExtension->DeviceObject = deviceObject;

    UNICODE_STRING symbolicLink;
    RtlInitUnicodeString(&symbolicLink, SYMBOLIC_LINK);
    status = IoCreateSymbolicLink(&symbolicLink, &deviceName);
    if (!NT_SUCCESS(status)) {
        IoDeleteDevice(deviceObject);
        return status;
    }

    DriverObject->MajorFunction[IRP_MJ_CREATE] = CreateClose;
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = CreateClose;
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DeviceControl;
    DriverObject->DriverUnload = UnloadDriver;

    deviceObject->Flags |= DO_BUFFERED_IO;
    deviceObject->Flags &= ~DO_DEVICE_INITIALIZING;

    return STATUS_SUCCESS;
}

IoCreateDevice allocates the device object and the device extension in one block. The third parameter is the device name (\Device\WiFiMacSpoof).

FILE_DEVICE_SECURE_OPEN applies the device's security descriptor to all opens. Without an INF file that sets a specific descriptor, this falls back to defaults.

IoCreateSymbolicLink creates the \DosDevices\WiFiMacSpoof link that userspace CreateFile(L"\\\\.\\WiFiMacSpoof", ...) resolves to.

DO_BUFFERED_IO on the device object makes the I/O manager use METHOD_BUFFERED semantics for all IOCTLs, mirroring what KMDF does via WdfDeviceInitSetIoType.

Clearing DO_DEVICE_INITIALIZING tells the I/O manager the device is ready to receive I/O.

Device control

NTSTATUS DeviceControl(PDEVICE_OBJECT DeviceObject, PIRP Irp) {
    PDEVICE_EXTENSION deviceExtension = (PDEVICE_EXTENSION)DeviceObject->DeviceExtension;
    PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);

    ULONG inputLength = ioStack->Parameters.DeviceIoControl.InputBufferLength;
    ULONG outputLength = ioStack->Parameters.DeviceIoControl.OutputBufferLength;
    ULONG_PTR information = 0;
    NTSTATUS status = STATUS_SUCCESS;

    switch (ioStack->Parameters.DeviceIoControl.IoControlCode) {
        case IOCTL_SET_MAC_ADDRESS:
            if (inputLength < 6) { status = STATUS_BUFFER_TOO_SMALL; break; }
            PVOID inputBuffer = Irp->AssociatedIrp.SystemBuffer;
            if (!inputBuffer) { status = STATUS_INVALID_PARAMETER; break; }
            RtlCopyMemory(deviceExtension->TargetMAC, inputBuffer, 6);
            status = ChangeWiFiMAC(deviceExtension->TargetMAC);
            deviceExtension->IsActive = NT_SUCCESS(status);
            break;

        case IOCTL_GET_MAC_ADDRESS:
            if (outputLength < 6) { status = STATUS_BUFFER_TOO_SMALL; break; }
            PVOID outputBuffer = Irp->AssociatedIrp.SystemBuffer;
            if (!outputBuffer) { status = STATUS_INVALID_PARAMETER; break; }
            RtlCopyMemory(outputBuffer, deviceExtension->TargetMAC, 6);
            information = 6;
            break;

        default:
            status = STATUS_INVALID_DEVICE_REQUEST;
            break;
    }

    Irp->IoStatus.Status = status;
    Irp->IoStatus.Information = information;
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return status;
}

IoGetCurrentIrpStackLocation returns the current stack location, which holds the parameters for this request.

Irp->AssociatedIrp.SystemBuffer points at the kernel buffer for buffered I/O — the same buffer the KMDF version receives via WdfRequestRetrieveInputBuffer/WdfRequestRetrieveOutputBuffer.

IoCompleteRequest finalizes the IRP and returns it to the I/O manager.

Exception handling

__try {
    status = ZwOpenKey(&keyHandle, KEY_READ | KEY_WRITE, &attributes);
    // ...
}
__except(EXCEPTION_EXECUTE_HANDLER) {
    if (keyInfo) ExFreePoolWithTag(keyInfo, 'MAC1');
    if (keyHandle) ZwClose(keyHandle);
    return GetExceptionCode();
}

Kernel APIs can raise structured exceptions for conditions like an invalid registry path or an access violation. An unhandled exception in kernel mode triggers a bugcheck (blue screen). __try/__except catches the exception, allows cleanup, and returns an error to the caller.

Variables referenced inside the __except block must be declared outside the __try block, because the compiler scopes them separately.

6. NDIS implementation

Filter callbacks

NDIS_STATUS FilterAttach(NDIS_HANDLE FilterModuleContext, NDIS_HANDLE NdisFilterHandle, PNDIS_FILTER_ATTACH_PARAMETERS AttachParameters);
VOID FilterDetach(NDIS_HANDLE FilterModuleContext);
NDIS_STATUS FilterOidRequest(NDIS_HANDLE FilterModuleContext, PNDIS_OID_REQUEST OidRequest);
VOID FilterOidRequestComplete(NDIS_HANDLE FilterModuleContext, PNDIS_OID_REQUEST OidRequest, NDIS_STATUS Status);

FilterAttach is called when the filter binds to a miniport. FilterDetach is called when the binding is torn down. FilterOidRequest is called for every OID passing through the filter. FilterOidRequestComplete is called when an OID request completes.

Filter context

typedef struct _FILTER_CONTEXT {
    UCHAR SpoofedMAC[6];
    BOOLEAN IsSpoofing;
} FILTER_CONTEXT, *PFILTER_CONTEXT;

One instance per miniport binding. Holds the current spoofed MAC and a flag indicating whether spoofing is active.

What completing the filter requires

Call NdisFRegisterFilterDriver in DriverEntry, passing FilterAttach and FilterDetach
In FilterAttach, query OID_802_3_CURRENT_ADDRESS from the miniport and store it in FilterModuleContext
In FilterOidRequest, intercept OID_802_3_CURRENT_ADDRESS and OID_802_3_PERMANENT_ADDRESS requests. Complete them locally with the spoofed value instead of forwarding to the miniport
Handle OID set requests by updating the stored spoofed value

The registry path works without any of this. The filter path, if completed, would allow spoofing at the NDIS layer, which is invisible to software querying the adapter through standard OID paths.

7. The registry manipulation

The ChangeWiFiMAC function is the core of the driver.

Opening the class key

RtlInitUnicodeString(&registryPath, 
    L"\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\Class\\{4d36e972-e325-11ce-bfc1-08002be10318}");

InitializeObjectAttributes(&attributes, &registryPath, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);

status = ZwOpenKey(&keyHandle, KEY_READ | KEY_WRITE, &attributes);

The GUID {4d36e972-e325-11ce-bfc1-08002be10318} is the class GUID for network adapters. Under this key, subkeys named 0000, 0001, 0002, etc. correspond to individual installed network devices.

OBJ_KERNEL_HANDLE tells the Object Manager to create the handle in the kernel handle table, which prevents it from being inherited by userspace processes.

Enumerating subkeys

ULONG index = 0;
ULONG resultLength = 0;

while (TRUE) {
    status = ZwEnumerateKey(keyHandle, index, KeyBasicInformation, NULL, 0, &resultLength);
    if (status == STATUS_NO_MORE_ENTRIES) break;

    if (status == STATUS_BUFFER_TOO_SMALL) {
        keyInfo = ExAllocatePoolWithTag(NonPagedPool, resultLength, 'MAC1');
        if (!keyInfo) { status = STATUS_INSUFFICIENT_RESOURCES; break; }

        status = ZwEnumerateKey(keyHandle, index, KeyBasicInformation, keyInfo, resultLength, &resultLength);
        if (NT_SUCCESS(status)) {
            // process subkey
        }

        ExFreePoolWithTag(keyInfo, 'MAC1');
    }
    index++;
}

ZwEnumerateKey with a NULL buffer returns STATUS_BUFFER_TOO_SMALL and sets resultLength to the required size. The code then allocates a buffer of that size and calls again.

The two-pass pattern is standard for kernel registry enumeration.

Reading DriverDesc

UNICODE_STRING valueName;
RtlInitUnicodeString(&valueName, L"DriverDesc");

PKEY_VALUE_PARTIAL_INFORMATION valueInfo = NULL;
ULONG valueLength = 0;

status = ZwQueryValueKey(subkeyHandle, &valueName, KeyValuePartialInformation, NULL, 0, &valueLength);

if (status == STATUS_BUFFER_TOO_SMALL) {
    valueInfo = ExAllocatePoolWithTag(NonPagedPool, valueLength, 'MAC2');
    if (valueInfo) {
        status = ZwQueryValueKey(subkeyHandle, &valueName, KeyValuePartialInformation, valueInfo, valueLength, &valueLength);
        // valueInfo->Data points at the string
    }
}

Same two-pass pattern. KeyValuePartialInformation returns only the value data, not the name. The Data field is a PWCHAR for REG_SZ values.

Matching the WiFi adapter

PWCHAR driverDesc = (PWCHAR)valueInfo->Data;
if (wcsstr(driverDesc, L"Wireless") || 
    wcsstr(driverDesc, L"Wi-Fi") || 
    wcsstr(driverDesc, L"WLAN") ||
    wcsstr(driverDesc, L"802.11")) {
    // this is the WiFi adapter
}

String matching against DriverDesc. Alternative fields that could be checked:

*PhysicalMediaType — a REG_DWORD that specifies the media type
MediaType — another REG_DWORD
Characteristics — a REG_DWORD with bit flags including NCF_PHYSICAL and NCF_VIRTUAL

Writing the MAC

WCHAR macString[13];
WCHAR hexChars[] = L"0123456789ABCDEF";

for (int i = 0; i < 6; i++) {
    macString[i * 2] = hexChars[(NewMAC[i] >> 4) & 0x0F];
    macString[i * 2 + 1] = hexChars[NewMAC[i] & 0x0F];
}
macString[12] = L'\0';

UNICODE_STRING macStringUnicode;
RtlInitUnicodeString(&macStringUnicode, macString);

UNICODE_STRING macValueName;
RtlInitUnicodeString(&macValueName, L"NetworkAddress");

ZwSetValueKey(subkeyHandle, &macValueName, 0, REG_SZ, 
    macStringUnicode.Buffer, macStringUnicode.Length + sizeof(WCHAR));

MAC addresses are stored as 12-character hex strings without separators. NetworkAddress is the primary value.

Some drivers also read:

AlternateMACAddress
CurrentMACAddress
MACAddress
*NetworkAddress

Different drivers check different values. Writing all of them costs nothing and covers more drivers.

Why it works

When the adapter driver initializes, it reads NetworkAddress from its class key. If the value is present and passes the driver's validation, the driver uses it instead of the physical address.

The read happens at different times depending on the driver:

Some read at system boot
Some read when the adapter is restarted
Some read when the device is re-enumerated

Restarting the adapter after setting the value triggers the re-read for most drivers. Some require a full reboot.

Why it sometimes fails

Drivers that validate the format and reject values that don't match expected patterns
Drivers that cache the physical address and prefer the cache
Drivers that query the miniport for the "real" address and ignore the registry
Drivers that refuse the change when connected to a network

For these, the registry write has no effect, and the only path is an NDIS filter that intercepts the OID path.

8. The IOCTL interface

Two IOCTLs, both METHOD_BUFFERED.

METHOD_BUFFERED behavior

When userspace sends an IOCTL with METHOD_BUFFERED:

The I/O manager allocates a kernel buffer of size max(InputBufferLength, OutputBufferLength)
It copies the user's input into the kernel buffer
It calls the driver with Irp->AssociatedIrp.SystemBuffer pointing at the kernel buffer
After the driver returns, it copies the kernel buffer back into the user's output buffer

The driver never touches a user-mode pointer. Buffer validation and copying are handled by the I/O manager.

Access flags

FILE_ANY_ACCESS allows any user to send the IOCTL. Two alternatives:

#define IOCTL_SET_MAC_ADDRESS CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_WRITE_ACCESS)
#define IOCTL_GET_MAC_ADDRESS CTL_CODE(FILE_DEVICE_UNKNOWN, 0x801, METHOD_BUFFERED, FILE_READ_ACCESS)

With these, the I/O manager checks the caller's access against the device's security descriptor before invoking the driver. A caller without the required access gets STATUS_ACCESS_DENIED without the driver seeing the request.

For administrator-only access, either:

Use FILE_WRITE_ACCESS and set a security descriptor in DriverEntry that grants write access only to administrators
Set a security descriptor on the device object that restricts all access to administrators

Validation

Even with METHOD_BUFFERED, the driver should validate:

Buffer length (InputBufferLength >= 6)
MAC address content: not all zeros, not all 0xFF, and the multicast bit not set unless intended

9. Building and signing

Prerequisites

Visual Studio with the C++ workload
Windows Driver Kit (WDK) matching the SDK version
Test signing enabled on the target machine

Enabling test signing

bcdedit /set testsigning on

Reboot after running this.

Signing with a test certificate

makecert -r -pe -ss PrivateCertStore -n "CN=TestCert" TestCert.cer
signtool sign /v /s PrivateCertStore /n TestCert /t http://timestamp.digicert.com wifi_mac_driver.sys

Or with New-SelfSignedCertificate and Export-PfxCertificate.

Windows loads kernel drivers signed by a certificate in the trusted root store when test signing is on.

Building

With WDK installed, open the Developer Command Prompt for VS:

cl /c /W3 /WX- /sdl /O2 /Oi /GL /D WIN32 /D NDEBUG /D _WINDLL /D _MBCS /Gm- /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Gd /TP /errorReport:prompt wifi_mac_driver.c /Fo:wifi_mac_driver.obj

link /OUT:wifi_mac_driver.sys /NOLOGO /MACHINE:X64 /SUBSYSTEM:NATIVE /DRIVER /DEF:wifi_mac_driver.def wifi_mac_driver.obj

/SUBSYSTEM:NATIVE sets the PE subsystem to NATIVE, which is required for kernel drivers. /DRIVER configures the linker for a driver build. /DEF:wifi_mac_driver.def uses a module definition file to export DriverEntry.

Module definition file

LIBRARY wifi_mac_driver
EXPORTS
    DriverEntry

Without this file, the linker doesn't know DriverEntry is the export point.

10. Installing and testing

Using pnputil

If an INF file is present:

pnputil /add-driver wifi_mac_driver.inf /install

This uses the standard Windows driver installation path. The INF specifies the driver files, hardware IDs, and service configuration.

Using sc.exe

For a driver loaded as a service:

sc create WiFiMacSpoof type= kernel binPath= "C:\path\to\wifi_mac_driver.sys"
sc start WiFiMacSpoof

The spaces after type= and binPath= are required.

To stop and remove:

sc stop WiFiMacSpoof
sc delete WiFiMacSpoof

Testing

After sending the IOCTL, restart the adapter:

netsh interface set interface "Wi-Fi" admin=disable
netsh interface set interface "Wi-Fi" admin=enable

Then verify:

getmac /v

If the value matches the spoofed MAC, the write took effect. If it shows the original, the driver either ignored the registry value or hasn't re-read it.

Kernel debugging

Two-machine setup: a target running the driver and a host running WinDbg.

On the target:

bcdedit /debug on
bcdedit /dbgsettings net hostip:192.168.1.100 port:50000 key:1.2.3.4

Reboot, then connect WinDbg from the host:

windbg -k net:port=50000,key=1.2.3.4

For non-crashing bugs, DbgPrint statements in the driver and DbgView on the target work without the debugger setup.

11. Userspace interface

C

HANDLE h = CreateFile(
    L"\\\\.\\WiFiMacSpoof",
    GENERIC_READ | GENERIC_WRITE,
    0,
    NULL,
    OPEN_EXISTING,
    0,
    NULL
);

if (h == INVALID_HANDLE_VALUE) {
    DWORD err = GetLastError();
    // ERROR_FILE_NOT_FOUND — driver not loaded
    // ERROR_ACCESS_DENIED — not running as admin
    return;
}

UCHAR newMac[6] = {0xA4, 0x5E, 0x60, 0xC3, 0x1B, 0x07};
DWORD bytesReturned;
BOOL ok = DeviceIoControl(
    h, IOCTL_SET_MAC_ADDRESS,
    newMac, 6,
    NULL, 0,
    &bytesReturned, NULL
);

CloseHandle(h);

Python

import win32file, win32con

h = win32file.CreateFile(
    r"\\.\WiFiMacSpoof",
    win32con.GENERIC_READ | win32con.GENERIC_WRITE,
    0, None,
    win32con.OPEN_EXISTING,
    0, None
)

mac = bytes([0xA4, 0x5E, 0x60, 0xC3, 0x1B, 0x07])
IOCTL_SET_MAC = 0x00222003  # decode from CTL_CODE if needed
win32file.DeviceIoControl(h, IOCTL_SET_MAC, mac, None)

The IOCTL code depends on the four fields passed to CTL_CODE. For FILE_DEVICE_UNKNOWN (0x22), function 0x800, METHOD_BUFFERED (0), FILE_ANY_ACCESS (0):

(0x22 << 16) | (0x800 << 2) | (0 << 14) | 0 = 0x00222000

For FILE_WRITE_ACCESS (1), the low bits become 0x3:

(0x22 << 16) | (0x800 << 2) | (0 << 14) | 3 = 0x00222003

12. Technical limitations

Registry path. Drivers that validate the NetworkAddress format or cache the physical address elsewhere will ignore the write. The only path for these is an NDIS filter that intercepts the OID responses.

Adapter restart required. Setting NetworkAddress has no effect until the driver re-reads it. For most drivers that means restarting the adapter; for some it means a full reboot.

No content validation in KMDF and WDM paths. A userspace caller can set an all-zero or all-0xFF MAC. The adapter's behavior with an invalid MAC is driver-dependent. Validation must be added if the driver is exposed to untrusted callers.

FILE_ANY_ACCESS on both IOCTLs. Any user who can open the device can change the MAC. FILE_WRITE_ACCESS combined with a security descriptor on the device object restricts this to administrators.

No synchronization on TargetMAC. Concurrent IOCTLs can interleave reads and writes. A KSPIN_LOCK around the update serializes access.

swprintf is not a kernel API. It happens to compile in some WDK configurations but is a userspace CRT function. The manual hex conversion is the correct approach.

Paged pool allocation at PASSIVE_LEVEL. ExAllocatePoolWithTag(PagedPool, ...) requires PASSIVE_LEVEL. Parallel dispatch can invoke handlers at DISPATCH_LEVEL if the queue is configured that way. The current code runs at PASSIVE_LEVEL in practice because ZwOpenKey requires it, but separating the allocation from the registry call would introduce a latent bug.

Exception handling. ZwOpenKey, ZwEnumerateKey, and ZwQueryValueKey can raise structured exceptions. Without __try/__except, an unhandled exception in kernel mode triggers a bugcheck.

NDIS filter. The registry path in an NDIS driver works identically to the WDM and KMDF versions. The filter path — intercepting OID requests — requires registering the filter with NdisFRegisterFilterDriver, implementing FilterAttach/FilterDetach, and completing OID requests locally within FilterOidRequest.

Building a License Authentication System From Scratch

MR storm — Sun, 11 Oct 2026 01:40:24 +0000

Or: how to defend a desktop app when you've already handed the attacker the source code.

The problem
Why boolean checks fail
The core idea: server-gated data
The full architecture
The wire protocol
Picking your stack
Step 1 — Init and the encrypted payload
Step 2 — Password storage done right
Step 3 — Register and license activation
Step 4 — Login and session creation
Step 5 — Hardware binding
Step 6 — Heartbeat and rotating tokens
Step 7 — Fetching the gated data
Step 8 — Anti-relay with sequence counters
Step 9 — Binary integrity
Step 10 — SDK version gating
Step 11 — Rate limiting
Step 12 — Failed login tracking and auto-blacklist
Step 13 — Login anomaly detection
Step 14 — The admin side
Step 15 — The client side
What's real defense and what's theater
Common mistakes
Testing your system
The honest ending

1. The problem

If you've ever shipped a desktop application that people pay for, you've run into this: the moment your code runs on someone else's machine, you've lost control of it.

You can compile it, pack it, obfuscate it, but at the end of the day there's a binary on someone's disk, and that binary is theirs. They can read it, they can patch it, they can run it in a debugger, they can feed it fake network responses, they can do anything they want with it. And every check you put inside that binary to enforce payment runs inside code they control.

This is the fundamental asymmetry of software licensing. The defender has to get every check right. The attacker only has to find one hole.

The good news is that this asymmetry doesn't mean you're helpless. It means you have to shift your thinking. Instead of trying to protect the decision (is this user licensed?), you protect the data (what does a licensed user get that an unlicensed user doesn't have?).

That shift — from protecting decisions to protecting data — is what this entire post is about.

2. Why boolean checks fail

Start with the obvious approach. Somewhere in your code, you write:

def is_licensed():
    # check something
    return True

if not is_licensed():
    exit(1)

# premium features below

Anyone with a hex editor and thirty seconds finds that if not is_licensed(): branch and replaces it with a no-op. Now the app runs whether or not it's licensed. Your entire protection was one byte.

You can make it harder to find. Obfuscate the function name, scatter the check across multiple files, compute it from multiple values. All of that helps a little. All of it fails eventually.

Why? Because the result of the check has to be used by the client. And the client is attacker-controlled. The moment the app decides to enable a feature based on a value that lives inside the attacker's memory, the attacker can change that value. It doesn't matter how cleverly you computed it. It only matters that it's local.

This is the first law of client-side security: any decision the client makes, the client can lie about.

You can't get around this by being clever. You have to change the game.

3. The core idea: server-gated data

Here's the shift.

Instead of your app asking "am I licensed?" and getting a yes/no, your app asks the server for the data it actually needs to function. If the server says no, the app doesn't get a boolean False it can patch to True. It gets nothing. And nothing is unfakeable.

Concretely. Imagine a tool with a premium feature that generates reports. The naive design:

if user.is_premium:
    template = load_local_template()
    generate_report(template)

The secure design:

encrypted = server.fetch_gated_data()
template = decrypt(encrypted, local_key)
generate_report(template)

The attacker patches if user.is_premium — nothing happens. That was never the gate. The gate is that template doesn't exist on their machine in usable form until the server hands it over, encrypted, tied to their session, bound to their hardware.

They can't patch their way into data they don't have. They can only:

Steal a legit user's session and use it live (which you can detect)
Break the encryption (which is infeasible with proper crypto)
Run a proxy in front of a legit client (which you can defeat with sequence counters)
Get the actual data some other way (which is a social problem, not a technical one)

This is the single most important idea in modern license systems. Every technique below is defense in depth around this idea. The idea itself is the foundation.

If your system doesn't have server-gated data, nothing else in this post matters. You're polishing a broken design.

4. The full architecture

Before we write code, look at the whole picture.

┌──────────────┐          ┌──────────────┐          ┌──────────────┐
│   CLIENT     │          │   SERVER     │          │   DATABASE   │
│  (desktop)   │          │  (FastAPI)   │          │  (SQL/JSON)  │
└──────┬───────┘          └──────┬───────┘          └──────┬───────┘
       │                         │                         │
       │ 1. init                 │                         │
       │────────────────────────▶│                         │
       │                         │ create session          │
       │                         │ generate enc_key        │
       │                         │ store key server-side   │
       │◀────────────────────────│                         │
       │ sessionid, enc_payload  │                         │
       │                         │                         │
       │ 2. login (user,pass,hwid)                         │
       │────────────────────────▶│                         │
       │                         │ verify password ────────▶
       │                         │◀────────────────────────│
       │                         │ check HWID              │
       │                         │ bind session to hwid    │
       │◀────────────────────────│                         │
       │ decryption_key, session │                         │
       │                         │                         │
       │ 3. heartbeat            │                         │
       │────────────────────────▶│                         │
       │                         │ rotate hb_token         │
       │◀────────────────────────│                         │
       │ hb_token                │                         │
       │                         │                         │
       │ 4. fetchdata (hb_token, fetch_seq)                │
       │────────────────────────▶│                         │
       │                         │ verify token            │
       │                         │ verify seq > last_seq   │
       │                         │ encrypt with hwid_key   │
       │◀────────────────────────│                         │
       │ encrypted_data          │                         │
       │                         │                         │
       │ decrypt with derived key│                         │
       │ use data                │                         │

The client never receives the raw gated data. It receives encrypted data that only its own hardware can decrypt. The server never trusts the client's claims about itself — every request re-verifies HWID, session, token, and sequence.

5. The wire protocol

Before writing a line of server code, decide what the client and server actually say to each other. This is your contract, and changing it later is painful because every deployed client breaks.

Every request from the client looks roughly like:

{
  "type": "login",
  "name": "my-app-name",
  "ownerid": "abc123def456",
  "username": "user1",
  "password": "hunter2",
  "hwid": "9f3a2c7e1b4d...",
  "sessionid": "optional, set after init",
  "hb_token": "optional, set after first heartbeat",
  "fetch_seq": 0
}

And every response is JSON with at minimum:

{
  "success": true,
  "message": "human-readable",
  ...action-specific fields
}

Design the protocol so that every request carries the full context needed to verify it. Don't have a "stateful" protocol where the client says one thing on request 1 and another on request 2 — you'll get desync bugs. Every request should be verifiable on its own.

A minimal set of action types:

Action	Purpose
`init`	Start a session, get an encrypted payload the client can't yet decrypt
`register`	Create a user with a license key
`login`	Authenticate an existing user with username/password
`license`	Authenticate with just a key (no username/password)
`heartbeat`	Prove the session is alive, get a new rotating token
`fetchdata`	Retrieve the gated payload, encrypted per-HWID

Optional, add later:

Action	Purpose
`check`	Lightweight session validity check
`setvar` / `getvar`	Per-user variables stored server-side
`log`	Client-side event logging
`webhook`	Trigger outbound notifications

That's it. Everything else is a variation. Keep the protocol small.

6. Picking your stack

Server: FastAPI over Flask. Both work. FastAPI gives you:

Async request handling out of the box
Typed request models via Pydantic (so the request schema is the documentation)
Automatic validation (malformed requests get rejected before your code runs)
Better performance under concurrent load

For an auth server that gets hit constantly by heartbeats from every client, that last point matters. Flask with sync workers will run out of worker threads at low client counts. FastAPI handles thousands of concurrent requests per worker.

Storage: a real database, or careful file locking. JSON files are fine for a prototype. They stop being fine the moment two users register at the same time, because you get a race condition:

User A: read keys.json  → key "ABC123" is unused
User B: read keys.json  → key "ABC123" is unused
User A: mark ABC123 used → write keys.json
User B: mark ABC123 used → write keys.json  (overwrites A's write)

Both users think they registered with the same key. The second write wins, and now the audit log is wrong.

Two fixes:

Use SQLite. Transactions handle this for you. Add Postgres when you outgrow it.
If you must use JSON files, wrap every read-modify-write in a per-resource lock:

import threading
app_locks = {}
locks_guard = threading.Lock()

def get_app_lock(app_id):
    lock = app_locks.get(app_id)
    if lock is None:
        with locks_guard:
            lock = app_locks.setdefault(app_id, threading.Lock())
    return lock

# Every mutation:
with get_app_lock(app_id):
    data = read_json(f"app_{app_id}_keys.json")
    # ... mutate ...
    write_json(f"app_{app_id}_keys.json", data)

The lock only works within one process. If you run multiple server workers, they don't share locks and you're back to races. Either pin to one worker or use a real database.

Client: whatever the app is written in. The protocol is HTTP + JSON. The client just has to implement it. The decryption step requires HMAC and hashing primitives, which every language has.

7. Step 1 — Init and the encrypted payload

The very first thing a client does is init. The server:

Generates a random session ID
Generates a random encryption key for this session only
Encrypts a small metadata payload with that key
Stores the key server-side, keyed by the session ID
Returns the session ID and the encrypted blob, but not the key

import secrets, base64, hmac, hashlib, json, time

_enc_sessions = {}  # session_id -> {enc_key, mac_key, app_id, created, ...}

def encrypt_payload(session_id, app_id, payload):
    enc_key = secrets.token_bytes(32)
    mac_key = secrets.token_bytes(32)
    iv = secrets.token_bytes(16)

    plaintext = json.dumps(payload, separators=(",", ":")).encode()
    # PKCS7 pad to block boundary (even though we're using a stream, this
    # hides the plaintext length from anyone analyzing ciphertext size)
    pad_len = 16 - (len(plaintext) % 16)
    plaintext += bytes([pad_len]) * pad_len

    ciphertext = hmac_stream(enc_key, iv, plaintext)
    mac = hmac.new(mac_key, iv + ciphertext, hashlib.sha256).digest()

    _enc_sessions[session_id] = {
        "enc_key": enc_key,
        "mac_key": mac_key,
        "app_id": app_id,
        "created": time.time(),
        "authenticated": False,
        "hwid": None,
        "hb_token": None,
        "last_hb": None,
        "client_seq": 0,
    }
    return base64.b64encode(iv + ciphertext + mac).decode()


def hmac_stream(key, iv, data):
    """HMAC-SHA256 counter-mode keystream, XORed with the data."""
    out = bytearray()
    for i in range((len(data) + 31) // 32):
        block = hmac.new(key, iv + i.to_bytes(4, "big"), hashlib.sha256).digest()
        out.extend(block)
    return bytes(a ^ b for a, b in zip(data, out[:len(data)]))

A note on the cipher, because this will get flagged: rolling your own stream cipher is generally a bad idea. The construction above — HMAC-SHA256 in counter mode — is a reasonable PRF-based keystream, but it's not what cryptography engineers would reach for. If you're using the cryptography library for anything else (like Fernet, which is what most people use for at-rest encryption), you already have access to AES-GCM. Use it. It's authenticated, it's constant-time in the important places, it's been reviewed by everyone.

The reason I'm showing the HMAC construction is because it's what a lot of hobbyist auth systems end up writing, and it's instructive to see why it exists (no dep, simple to audit) and why it's inferior to AES-GCM (no formal security proof, easy to misuse, no nonce-misuse resistance).

If you want the honest short version: use AES-GCM. Everything below assumes that level of security.

The init handler itself:

def handle_init(name, ownerid, ver):
    app = find_app_by_name_and_owner(name, ownerid)
    if not app:
        return {"success": False, "message": "Application not found"}
    if not app.get("enabled", True):
        return {"success": False, "message": "Application is disabled"}

    session_id = secrets.token_hex(16)
    payload_data = {
        "app_id": app["id"],
        "app_name": app["name"],
        "version": app.get("version", "1.0.0"),
        "session_id": session_id,
        "nonce": secrets.token_hex(8),
        "ts": datetime.utcnow().isoformat() + "Z",
    }
    encrypted = encrypt_payload(session_id, app["id"], payload_data)

    return {
        "success": True,
        "message": "Initialized",
        "sessionid": session_id,
        "encrypted_payload": encrypted,
        "appinfo": {
            "version": app.get("version", "1.0.0"),
            "numUsers": count_users(app["id"]),
            "numKeys": count_keys(app["id"]),
        },
    }

The client now has a blob it can't read. It needs to authenticate to get the key. The init step is mostly theater on its own — the payload is just metadata — but it establishes the pattern: the client can't proceed without server cooperation.

Also notice: the server generates a fresh random key per session. This is important. It means if an attacker compromises one session key, they've compromised one session, not the entire app. The key never leaves the server until auth succeeds, and even then it's returned as a value that only works for this session.

8. Step 2 — Password storage done right

This is where almost every tutorial gets it wrong, and where I've seen more real-world breaches than anywhere else. So let's be blunt about it.

You do not encrypt passwords. You don't wrap them in symbols. You don't encrypt-then-hash.

Encryption is reversible by design. If you encrypt a password to store it, you must be able to decrypt it later — which means the key lives somewhere on your server. Any attacker who gets your database and your server code gets every password in plaintext. You've gained nothing.

You hash them. Specifically, you use a slow hash with a per-user salt.

Why hashing and not encryption

Hashing is one-way. You store hash(password), not password. When a user logs in, you compute hash(attempted_password) and compare it to the stored hash. If they match, the password was right.

If an attacker steals your database, they get hashes. Not passwords. And if you did it right, they can't reverse the hashes without brute-forcing each one, which is what we're going to make prohibitively expensive.

Why a salt

Without a salt, the hash of "hunter2" is the same for every user. An attacker can precompute a table:

"password"     → 5f4dcc3b5aa765d61d8327deb882cf99
"hunter2"      → 2ab96390c7dbe3439de74d0c9b0b1767
"letmein"      → 0d107d09f5bbe40cade3de5c71e9e9b7
...10 billion more...

Then every hash in your stolen database is a lookup. That's a rainbow table attack.

A salt is a random value generated per user, stored alongside the hash. You hash salt + password. Now every user's "hunter2" produces a different hash. The attacker has to brute-force each user individually, and precomputation is worthless.

Why a slow hash

SHA-256 was designed for speed. A modern GPU can compute billions of SHA-256 hashes per second. If your password has 8 characters from a 62-character alphabet, that's ~218 trillion combinations. Sounds like a lot, but at 10 billion hashes/second, that's 6 hours.

bcrypt, argon2, and scrypt are deliberately slow. They have a "cost" parameter that scales their runtime. Set bcrypt to cost 12 and each hash takes ~250ms. That turns 6 hours into 1.7 million years. Even scaling up the GPU farm doesn't help — the algorithms are memory-hard and don't parallelize the way SHA-256 does.

The right way

import bcrypt

def hash_password(password: str) -> str:
    return bcrypt.hashpw(
        password.encode("utf-8"),
        bcrypt.gensalt(rounds=12),
    ).decode("utf-8")


def verify_password(password: str, stored: str) -> bool:
    try:
        return bcrypt.checkpw(password.encode("utf-8"), stored.encode("utf-8"))
    except Exception:
        return False

That's it. bcrypt.gensalt handles salt generation, bcrypt.hashpw handles the hashing, bcrypt.checkpw handles verification. No manual salt, no manual comparison, no timing leaks.

bcrypt hashes have a known format: they start with $2a$ , $2b$ , or $2y$ followed by the cost, salt, and hash all in one string. So you can detect bcrypt hashes just by looking at them:

def is_bcrypt(stored):
    return isinstance(stored, str) and stored.startswith(("$2a$", "$2b$", "$2y$"))

Migrating from a worse scheme

If you already have users stored with SHA-256 or plaintext (maybe from an early prototype), you can't easily migrate them all at once — you don't have the plaintext passwords, so you can't re-hash them.

The trick is lazy migration: on each successful login, re-hash with the new scheme and save.

def verify_and_upgrade(password, user):
    stored = user["password_hash"]
    if is_bcrypt(stored):
        return bcrypt.checkpw(password.encode(), stored.encode()), False

    if is_sha256_hex(stored):
        ok = hmac.compare_digest(stored, hashlib.sha256(password.encode()).hexdigest())
        return ok, ok  # needs rehash if matched

    # Legacy plaintext
    ok = hmac.compare_digest(stored, password)
    return ok, ok

# In the login handler:
ok, needs_rehash = verify_and_upgrade(req.password, user)
if ok and needs_rehash:
    user["password_hash"] = hash_password(req.password)
    save_user(user)

Over time every active user migrates. Inactive users get migrated on their next login. Everyone else is old and irrelevant.

9. Step 3 — Register and license activation

Registration creates a user account and burns a license key. Two writes have to happen atomically:

Append the new user to the user list
Mark the license key as used

If either fails or if another registration races in between, you've either created a user without burning a key (free account), or burned a key without creating a user (customer loses their key). Both are bad.

Serialize the whole thing under a per-app lock:

def handle_register(req, ip):
    app_data, app_id = resolve_app(req)
    if not app_data:
        return {"success": False, "message": "Invalid app"}

    with get_app_lock(app_id):
        users = get_app_data(app_id, "users", [])
        keys = get_app_data(app_id, "keys", [])
        blacklist = get_app_data(app_id, "blacklist", [])

        # Check blacklists first (IP and HWID)
        if is_blacklisted(blacklist, "ip", ip):
            return {"success": False, "message": "IP is blacklisted"}
        if is_blacklisted(blacklist, "hwid", req.hwid):
            return {"success": False, "message": "HWID is blacklisted"}

        # Username collision
        if any(u["username"] == req.username for u in users):
            return {"success": False, "message": "Username already taken"}

        # Constant-time key lookup. hmac.compare_digest prevents timing
        # oracles — an attacker can't tell how "close" their guess was.
        req_key = req.key or ""
        key_idx = next(
            (i for i, k in enumerate(keys)
             if hmac.compare_digest(k.get("key", ""), req_key)),
            None,
        )
        if key_idx is None:
            return {"success": False, "message": "Invalid license key"}

        key_data = keys[key_idx]
        if key_data.get("used_by"):
            return {"success": False, "message": "License key already used"}

        # Compute expiry based on key's duration
        duration = key_data.get("duration", "1 month")
        td = DURATION_MAP.get(duration)
        sub_expiry = (datetime.utcnow() + td).isoformat() + "Z" if td else "lifetime"

        new_user = {
            "username": req.username,
            "password_hash": hash_password(req.password),
            "hwid": req.hwid,
            "ip": ip,
            "created_at": datetime.utcnow().isoformat() + "Z",
            "last_login": datetime.utcnow().isoformat() + "Z",
            "subscription": duration,
            "sub_expiry": sub_expiry,
            "banned": False,
            "session_id": secrets.token_hex(16),
            "user_vars": {},
            "total_logins": 1,
        }
        users.append(new_user)
        keys[key_idx]["used_by"] = req.username
        keys[key_idx]["used_at"] = datetime.utcnow().isoformat() + "Z"

        save_app_data(app_id, "users", users)
        save_app_data(app_id, "keys", keys)

    # Outside the lock: slow I/O that doesn't touch app data
    log_event(app_id, "auth", "info", f"User registered: {req.username}", req.username, ip)
    notify_customer(app_id, f"New user: {req.username}")
    return {"success": True, "message": "Registration successful", "info": user_info(new_user)}

A few things to notice:

The lock is per-app, not global. Concurrent registrations on different apps don't block each other. This matters when you have many apps and high traffic.

The lock covers only the mutation. Logging, Telegram notifications, and other I/O happen outside the lock. If you hold a lock while making a 10-second network call to Telegram, every other registration on that app stalls for 10 seconds. That's how you turn one slow API into a DDoS on yourself.

The key comparison uses hmac.compare_digest. This is a constant-time comparison. A naive k["key"] == req_key leaks information via timing — an attacker can learn the correct key byte by byte by measuring how long the comparison takes. compare_digest always takes the same time regardless of how much of the string matches.

The HWID is required. If req.hwid is empty, _validate_hwid rejects before we even get here. This is critical. Early in my own build I had a bug where an empty HWID skipped the HWID check entirely — meaning anyone could bypass hardware binding by omitting the field.

10. Step 4 — Login and session creation

Login is the most attacked endpoint in any auth system. Credential stuffing, brute forcing, and key enumeration all hit it. The handler has to do a lot.

def handle_login(req, ip):
    app_data, app_id = resolve_app(req)
    if not app_data:
        return {"success": False, "message": "Invalid app"}

    # Deferred events — set inside the lock, fired after release
    auto_blacklisted = None
    login_success = False
    user = None
    killed_sessions = 0

    with get_app_lock(app_id):
        users = get_app_data(app_id, "users", [])
        blacklist = get_app_data(app_id, "blacklist", [])

        if is_blacklisted(blacklist, "ip", ip):
            return {"success": False, "message": "IP is blacklisted"}
        if is_blacklisted(blacklist, "hwid", req.hwid):
            return {"success": False, "message": "HWID is blacklisted"}

        # Find user
        user_idx = next(
            (i for i, u in enumerate(users) if u["username"] == req.username),
            None,
        )
        if user_idx is None:
            # Don't reveal whether the username exists or the password
            # was wrong. Same message for both.
            _record_failed_login(app_id, ip, req.hwid)
            return {"success": False, "message": "Invalid credentials"}

        user = users[user_idx]
        ok, needs_rehash = verify_password(req.password, user.get("password_hash", ""))

        if not ok:
            _record_failed_login(app_id, ip, req.hwid)
            auto_blacklisted = _maybe_auto_blacklist(app_id, ip)
            failed_resp = {"success": False, "message": "Invalid credentials"}
        else:
            # Clear the failure counter on success
            _failed_logins.pop((app_id, ip), None)

            if user.get("banned"):
                return {"success": False, "message": f"Banned: {user.get('ban_reason', 'N/A')}"}

            if user["sub_expiry"] != "lifetime":
                try:
                    exp = datetime.fromisoformat(user["sub_expiry"].replace("Z", ""))
                    if datetime.utcnow() > exp:
                        return {"success": False, "message": "Subscription expired"}
                except Exception:
                    pass

            # HWID check + migration
            max_hwids = app_data.get("max_hwids", 1)
            stored_hwid = user.get("hwid", "")
            if req.hwid:
                if stored_hwid and stored_hwid != req.hwid and max_hwids <= 1:
                    return {"success": False, "message": "HWID mismatch. Contact support."}
                if not stored_hwid:
                    user["hwid"] = req.hwid

            # Rotate session ID — the old one dies now
            old_session = user.get("session_id") or ""
            user["session_id"] = secrets.token_hex(16)
            user["last_login"] = datetime.utcnow().isoformat() + "Z"
            user["ip"] = ip
            user["online"] = True
            user["total_logins"] = user.get("total_logins", 0) + 1

            if needs_rehash:
                user["password_hash"] = hash_password(req.password)

            users[user_idx] = user
            save_app_data(app_id, "users", users)

            # Kill any encryption sessions still bound to the old session ID
            if app_data.get("kill_prior_sessions", True) and old_session:
                killed_sessions = kill_prior_sessions(old_session)

            login_success = True

    # Outside the lock
    if not login_success:
        log_event(app_id, "auth", "warning", f"Failed login: {req.username}", req.username, ip)
        if auto_blacklisted:
            log_event(app_id, "security", "error",
                      f"Auto-blacklisted {ip} after repeated failures", req.username, ip)
        return failed_resp

    log_event(app_id, "auth", "info", f"User logged in: {req.username}", req.username, ip)
    if killed_sessions:
        notify_customer(app_id, f"Killed {killed_sessions} prior sessions for {req.username}")

    # Generate the session decryption key
    dec_key = None
    if req.sessionid and req.sessionid in _enc_sessions:
        dec_key = make_decryption_key(req.sessionid, req.hwid)
        _enc_sessions[req.sessionid]["user_session"] = user["session_id"]

    return {
        "success": True,
        "message": "Login successful",
        "info": user_info(user),
        "sessionid": user["session_id"],
        "decryption_key": dec_key,
        "heartbeat_interval": HEARTBEAT_INTERVAL,
    }

A few things worth pointing out:

"Invalid credentials" for both unknown users and wrong passwords. If you return "username not found" for one and "wrong password" for the other, you've built a username enumerator. Attacker fires 10,000 usernames and learns which ones exist. Always return the same message.

Session rotation on every login. When a user logs in, the previous session ID is invalidated and a new one is created. If an attacker stole the old session ID, it dies the moment the legit user logs in again. This is a strong defense against session sharing.

Killing prior encryption sessions. After rotating the user's session ID, any _enc_sessions entries still pointing to the old ID are evicted. A relay holding the old session can't keep fetching data — its session is gone.

The order of operations matters. Check blacklist → find user → verify password → check banned → check subscription → check HWID → rotate session → save. Never commit partial state. If any check fails, return without having written anything.

11. Step 5 — Hardware binding

Every authenticated request carries a hardware ID — a fingerprint derived from the machine's physical properties. The user's session becomes bound to that HWID. Any subsequent request from a different HWID is rejected.

Generating the HWID

The client computes something like:

import platform, uuid, hashlib, hmac

def get_hwid():
    parts = [
        platform.node(),      # hostname
        platform.machine(),   # CPU architecture
        str(uuid.getnode()),  # MAC address (best-effort)
        platform.processor(),
    ]
    raw = "|".join(parts).encode()
    # HMAC so it's not a plain hash of well-known inputs
    return hmac.new(b"hwid-salt", raw, hashlib.sha256).hexdigest()

On Linux you might also read /etc/machine-id. On Windows, wmic csproduct get uuid. The exact inputs don't matter much — what matters is stability. If the HWID changes when the user updates their GPU driver, you'll get false positives.

Server-side checks

Three rules for HWID comparison:

1. Use constant-time comparison.

if not hmac.compare_digest(stored_hwid, incoming_hwid):
    return reject()

Not ==. The difference is that == on strings short-circuits as soon as a byte differs, so the response time leaks how many bytes matched. An attacker can learn a 64-byte HWID one byte at a time with about 64 × 256 requests. compare_digest always takes the same time.

2. Reject empty HWIDs explicitly.

if not stored_hwid or not incoming_hwid:
    return reject()

The bug to avoid: if stored_hwid and not matches(stored, incoming): reject(). If incoming is empty and stored is set, the outer condition is stored_hwid and not matches(...). matches would need to return True for an empty incoming, which most implementations do (because "" == ""). So the check passes. Free bypass.

Make the rule: empty on either side = reject. No exceptions.

3. Support format migration.

If you ever change the HWID format (e.g. from 16 hex chars to 64), you need to accept the old format for existing users while enforcing the new format for new ones. Otherwise every existing user is locked out.

def hwid_matches(stored, incoming):
    if not stored or not incoming:
        return False
    if hmac.compare_digest(stored, incoming):
        return True
    # Migration window: old (16-char) stored, new (64-char) incoming
    if len(stored) == 16 and len(incoming) == 64:
        return True  # accept, and upgrade stored value
    return False

Then when the check passes via migration, update user["hwid"] = incoming. The next login uses the new format.

12. Step 6 — Heartbeat and rotating tokens

Once authenticated, the client starts a timer. Every N seconds (typically 20-60), it sends a heartbeat. The server:

Confirms the session still exists
Confirms the HWID still matches
Confirms the subscription hasn't expired mid-session
Generates a new random hb_token, stores it on the session, and returns it
Updates last_hb timestamp

HEARTBEAT_INTERVAL = 20  # seconds

def validate_heartbeat(session_id, hwid):
    session = _enc_sessions.get(session_id)
    if not session:
        return {"success": False, "message": "Invalid session"}

    if not session["authenticated"]:
        return {"success": False, "message": "Not authenticated"}

    # HWID must match — empty counts as mismatch
    if session["hwid"] and not hwid_matches(session["hwid"], hwid):
        _enc_sessions.pop(session_id, None)
        return {"success": False, "message": "HWID mismatch"}

    # Absolute session lifetime
    if time.time() - session["created"] > SESSION_MAX_AGE:
        _enc_sessions.pop(session_id, None)
        return {"success": False, "message": "Session expired"}

    # Cross-check against the database: is the user still valid?
    app_id = session["app_id"]
    user_session = session.get("user_session")
    if user_session:
        users = get_app_data(app_id, "users", [])
        user = next((u for u in users if u.get("session_id") == user_session), None)

        if not user:
            _enc_sessions.pop(session_id, None)
            return {"success": False, "message": "User no longer exists"}

        if user.get("banned"):
            _enc_sessions.pop(session_id, None)
            return {"success": False, "message": "User banned"}

        if user["sub_expiry"] != "lifetime":
            try:
                exp = datetime.fromisoformat(user["sub_expiry"].replace("Z", ""))
                if datetime.utcnow() > exp:
                    _enc_sessions.pop(session_id, None)
                    return {"success": False, "message": "Subscription expired"}
            except Exception:
                pass

    # Rotate the heartbeat token
    new_token = secrets.token_hex(16)
    session["hb_token"] = new_token
    session["last_hb"] = time.time()
    session["hb_count"] = session.get("hb_count", 0) + 1

    return {
        "success": True,
        "message": "Heartbeat OK",
        "hb_token": new_token,
        "next_heartbeat": HEARTBEAT_INTERVAL,
    }

Why rotate the token?

The rotating token is what makes replay attacks impractical. Suppose an attacker captures a valid fetchdata request. If the token is static, they can replay that request forever within the session window. With rotation:

The legit client sends fetchdata with token T1
The attacker replays the same request 5 seconds later
In between, the legit client sent a heartbeat, and the server rotated the token to T2
The attacker's replay now presents T1, which is stale
Server rejects

The window of usefulness for a captured request is one heartbeat interval — typically 20-60 seconds. Long enough for legitimate network jitter, short enough that replay is a dead end.

The client's obligation

Every request after the first heartbeat must include the current hb_token. The client's job is to:

Parse hb_token from the heartbeat response
Store it
Include it in every subsequent fetchdata (and any other authenticated call)

If the client fails to include it, the server rejects with a message that tells them to update their SDK.

What this defends against

Session replay — captured requests go stale in seconds
Session sharing — two clients sharing a session can't both keep up with token rotation
Delayed attacks — even if an attacker captures a full session, they can't reuse it after the legitimate client moves on

What this does not defend against

A relay. A relay is a proxy that sits between the legit client and the server and forwards traffic live. The legit client does all the auth, all the heartbeats, all the token rotations, and the relay forwards the responses to N cracked clients.

To defeat relays, you need sequence counters (next section).

13. Step 7 — Fetching the gated data

This is where the actual protection lives. Every request here goes through multiple gates:

Valid session exists
Session is authenticated
HWID matches
Session hasn't aged out
Last heartbeat is recent
Heartbeat token matches the current one
Sequence counter is strictly increasing
User isn't banned, isn't expired, isn't blacklisted

Only then does the server construct the gated payload, encrypt it with a key derived from (session_key, hwid), and return it.

def handle_fetchdata(req, ip):
    app_data, app_id = resolve_app(req)
    if not app_data:
        return {"success": False, "message": "Invalid app"}

    # Find the encryption session (by either init session or user session)
    session = None
    for sid, s in _enc_sessions.items():
        if s.get("user_session") == req.sessionid or sid == req.sessionid:
            session = s
            break

    if not session:
        return {"success": False, "message": "No encryption session"}
    if not session["authenticated"]:
        return {"success": False, "message": "Not authenticated"}
    if session["hwid"] and not hwid_matches(session["hwid"], req.hwid or ""):
        return {"success": False, "message": "HWID mismatch"}
    if not session.get("last_hb"):
        return {"success": False, "message": "Heartbeat required first"}
    if time.time() - session["created"] > SESSION_MAX_AGE:
        return {"success": False, "message": "Session expired"}
    if time.time() - session["last_hb"] > HEARTBEAT_INTERVAL * 3:
        return {"success": False, "message": "Heartbeat stale"}

    # Heartbeat token check — constant time
    client_token = req.hb_token or ""
    server_token = session.get("hb_token") or ""
    if not client_token:
        return {"success": False, "message": "Missing heartbeat token"}
    if not hmac.compare_digest(client_token, server_token):
        return {"success": False, "message": "Stale heartbeat token"}

    # Sequence counter — must be strictly greater than the last seen value
    last_seq = session.get("client_seq", 0)
    if req.fetch_seq is not None:
        if req.fetch_seq <= last_seq:
            log_event(app_id, "security", "warning",
                      f"fetch_seq regression: {req.fetch_seq} <= {last_seq}")
            return {"success": False, "message": "Replay detected"}
        session["client_seq"] = req.fetch_seq
    elif app_data.get("require_fetch_seq"):
        return {"success": False, "message": "fetch_seq required"}

    # Database cross-check
    users = get_app_data(app_id, "users", [])
    user = next((u for u in users if u.get("session_id") == req.sessionid), None)
    if not user:
        return {"success": False, "message": "Invalid user session"}
    if user.get("banned"):
        return {"success": False, "message": "User banned"}

    # Blacklist checks
    blacklist = get_app_data(app_id, "blacklist", [])
    if is_blacklisted(blacklist, "hwid", req.hwid):
        return {"success": False, "message": "HWID blacklisted"}
    if is_blacklisted(blacklist, "ip", ip):
        return {"success": False, "message": "IP blacklisted"}

    # Construct the gated payload
    app_vars = get_app_data(app_id, "vars", {})
    gated = {
        "username": user["username"],
        "subscription": user["subscription"],
        "expiry": user["sub_expiry"],
        "level": user.get("user_vars", {}).get("level", "0"),
        "app_vars": app_vars,
        "app_name": app_data.get("name", ""),
        "version": app_data.get("version", "1.0.0"),
        "hwid": req.hwid,
        "nonce": secrets.token_hex(8),
        "ts": datetime.utcnow().isoformat() + "Z",
        "hb_token": session["hb_token"],
        "fetch_seq": session.get("fetch_count", 0) + 1,
    }
    session["fetch_count"] = session.get("fetch_count", 0) + 1

    # Encrypt with HWID-derived key
    encrypted = encrypt_for_hwid(session["enc_key"], req.hwid, gated)

    return {"success": True, "message": "Data retrieved", "encrypted_data": encrypted}

Why per-HWID encryption

The critical line is this:

encrypted = encrypt_for_hwid(session["enc_key"], req.hwid, gated)

The encryption key is derived from both the session key and the HWID. Two users with the same app have different session keys and different HWIDs, so their encrypted payloads are different and non-interchangeable.

Even if an attacker captures a full response and tries to use it on another machine:

# Client-side decryption, using the local machine's HWID
hwid_key = hmac.new(session_key, f"fetch-{local_hwid}", "sha256").digest()
plaintext = decrypt(captured_blob, hwid_key)  # → garbage

The decryption produces garbage because the key derivation used a different HWID. The MAC check fails, the client refuses to use the data.

What the client does with the response

def load(self):
    if not self.decryption_key:
        return False

    next_seq = self._fetch_seq + 1
    r = self._req({
        "type": "fetchdata",
        "hwid": self._hwid(),
        "fetch_seq": next_seq,
    })
    if not r.get("success"):
        return False

    enc = r.get("encrypted_data")
    if not enc:
        return False

    # Derive the HWID-bound key
    session_key = base64.b64decode(self.decryption_key)
    hwid = self._hwid()
    ek = hmac.new(session_key[:32], f"fetchdata-enc-{hwid}".encode(), "sha256").digest()
    mk = hmac.new(session_key[:32], f"fetchdata-mac-{hwid}".encode(), "sha256").digest()

    # Verify MAC before decrypting (encrypt-then-MAC pattern)
    raw = base64.b64decode(enc)
    iv, ct, mac = raw[:16], raw[16:-32], raw[-32:]
    expected_mac = hmac.new(mk, iv + ct, "sha256").digest()
    if not hmac.compare_digest(mac, expected_mac):
        return False

    # Decrypt
    plaintext = hmac_stream(ek, iv, ct)
    plaintext = plaintext[:-plaintext[-1]]  # strip padding
    self._data = json.loads(plaintext)
    self._fetch_seq = next_seq
    return True

Notice: MAC before decrypt. This is the encrypt-then-MAC pattern. If you decrypt first and check the MAC second, an attacker can submit malformed ciphertexts and learn things from how decryption fails (padding oracles, timing). Always verify the MAC first.

14. Step 8 — Anti-relay with sequence counters

A relay is the strongest attack against a session-based system. The attacker runs a proxy that connects to a legit licensed client on one side and to cracked copies on the other. The legit client does all the auth. The cracked copies just receive the decrypted data.

Standard session checks don't catch this because the relay is live. It's not replaying captured traffic, it's forwarding current traffic. The session is real, the heartbeat is real, the token is real.

The defense: give the client a strictly increasing counter that it must send with every fetchdata. The server tracks the highest value it's seen. Any request whose counter isn't strictly greater is rejected.

# Server side
last_seq = session.get("client_seq", 0)
if req.fetch_seq <= last_seq:
    log_event(app_id, "security", "warning", f"Replay: {req.fetch_seq} <= {last_seq}")
    return {"success": False, "message": "Stale fetch_seq"}
session["client_seq"] = req.fetch_seq

Now consider a relay fronting N clones off one license. Each clone has its own local _fetch_seq counter. When clone #1 sends fetch_seq=5, the server records 5. Clone #2 sends fetch_seq=3 — rejected. Clone #2 retries with fetch_seq=6 — accepted, server now records 6. Clone #1's next call is fetch_seq=6 — rejected, it thinks the server is at 5.

Within a couple of requests, all but one clone is out of sync. The server logs a security warning every time.

Why not strictly require it?

The counter has to be added to the client SDK. If you turn on strict enforcement before all clients have updated, you break every old client. So make it opt-in per-app:

# App config
"require_fetch_seq": False  # or True once clients are updated

# Server check
if req.fetch_seq is not None:
    if req.fetch_seq <= last_seq:
        return reject()
    session["client_seq"] = req.fetch_seq
elif app_data.get("require_fetch_seq"):
    return {"success": False, "message": "fetch_seq required"}

Start with soft mode (accept clients that don't send it, enforce for ones that do). Once you've rolled out the new SDK to your users, flip the app to strict mode. Old clients get rejected with a clear message.

The honest limitation

A patched client can just send fetch_seq incrementing integers regardless of what it's actually doing. The defense is cost — the attacker now has to reverse-engineer the counter semantics and get every clone to agree on a shared counter. It's not a wall, it's a speed bump. But it raises the cost of a relay from "run a proxy" to "write a coordinated multi-client sync layer," which is a much higher bar.

15. Step 9 — Binary integrity

The client's executable hashes itself and sends the hash with every request. The server compares against an allowlist the customer has curated. If it doesn't match, the server refuses.

# Client side
def binary_hash():
    """SHA-256 of the running executable."""
    import sys, os, hashlib

    if getattr(sys, "frozen", False):
        path = sys.executable  # PyInstaller / cx_Freeze
    elif __file__ and os.path.isfile(__file__):
        path = __file__  # Plain script
    else:
        return ""

    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(65536), b""):
            h.update(chunk)
    return h.hexdigest()

# Server side
def check_binary_hash(app_data, incoming_hash):
    approved = app_data.get("binary_hashes") or []
    if not incoming_hash:
        return False
    if not is_valid_sha256(incoming_hash):
        return False
    return incoming_hash.lower() in {h.lower() for h in approved}

How the allowlist gets populated

Two modes:

Soft mode: log every observed hash but don't reject. The dashboard shows the customer "here are the hashes hitting your app — click the one that's your real build to approve it."

Strict mode: reject any hash that isn't approved. The customer flips this on once their allowlist is set.

# In the request handler
observed_ok = check_binary_hash(app_data, req.binary_hash)

if req.binary_hash:
    record_observed_hash(app_id, req.binary_hash, req.hwid, ip, observed_ok)

if app_data.get("binary_hash_required") and not observed_ok:
    log_event(app_id, "security", "warning", f"Binary hash rejected: {req.binary_hash[:16]}...")
    return {"success": False, "message": "Binary integrity check failed"}

What this defeats

Modified executables. If an attacker patches the binary, the hash changes. Unless they also patch the hash function, they're rejected.
Repacked builds. Enigma, VMProtect, or custom packers change the binary. The resulting hash won't match.

What this doesn't defeat

Hash function patching. An attacker who replaces binary_hash() to always return the approved value gets around this. That's why you want to also do:
- SDK version gating (next section)
- Obfuscation so the hash function is hard to find
- Multiple hash checks scattered through the binary so patching one doesn't help

The observed-hash buffer

A nice feature to include: keep a per-app circular buffer of recently-seen hashes with metadata (first seen, last seen, hit count, sample HWID). The dashboard shows this. When a customer ships a new build, they see the new hash appear in real time, click it, and it gets added to the allowlist. No more manual sha256sum workflows.

_observed_hashes = {}  # app_id -> {hash -> {first_seen, last_seen, count, hwid, approved}}

def record_observed_hash(app_id, h, hwid, ip, approved):
    if not is_valid_sha256(h):
        return
    h = h.lower()
    bucket = _observed_hashes.setdefault(app_id, {})
    entry = bucket.get(h)
    now = datetime.utcnow().isoformat()
    if entry is None:
        if len(bucket) >= 50:  # cap
            oldest = min(bucket, key=lambda k: bucket[k]["last_seen"])
            bucket.pop(oldest)
        bucket[h] = {
            "hash": h, "first_seen": now, "last_seen": now,
            "count": 1, "sample_hwid": hwid[:12], "approved": approved,
        }
    else:
        entry["last_seen"] = now
        entry["count"] += 1
        entry["approved"] = approved

16. Step 10 — SDK version gating

Every time the customer ships an update to their app's SDK, any bypass written against the previous build stops working. SDK version gating is what forces clients to stay current.

The client sends its SDK version with every request:

SDK_VERSION = "1.3.0"

def _req(self, data):
    data["sdk_version"] = SDK_VERSION
    # ... rest

The server compares against a per-app minimum:

def sdk_version_ok(client_ver, min_ver):
    if not min_ver:
        return True  # gate not enabled
    if not client_ver:
        return False

    def parse(v):
        return tuple(int("".join(c for c in p if c.isdigit()) or 0)
                     for p in str(v).split("."))

    try:
        return parse(client_ver) >= parse(min_ver)
    except Exception:
        return str(client_ver) >= str(min_ver)

In the request handler:

_min_sdk = app_data.get("min_sdk_version")
if _min_sdk and not sdk_version_ok(req.sdk_version, _min_sdk):
    return {
        "success": False,
        "message": f"SDK update required. Minimum version: {_min_sdk}",
        "min_sdk_version": _min_sdk,
        "your_sdk_version": req.sdk_version or "unknown",
    }

Why this works

Any patch written against SDK 1.2 has two options:

Keep reporting sdk_version = "1.2.0" → server rejects (gate at 1.3)
Report sdk_version = "1.3.0" → but the patch was written against 1.2's protocol, so any differences break

The attacker has to keep up with every SDK release. Each release is a cost they have to pay again.

Default off

Set min_sdk_version = None by default. Only flip it on after the customer has actually rolled out a new SDK to their users. Otherwise you lock out every existing client.

17. Step 11 — Rate limiting

Every public endpoint needs per-IP rate limiting, and login needs two — one per IP, one per account.

The implementation:

_rl_buckets = {}  # key -> [timestamps]

def rate_check(key, max_calls, window_seconds):
    now = time.time()
    cutoff = now - window_seconds
    bucket = _rl_buckets.setdefault(key, [])
    while bucket and bucket[0] < cutoff:
        bucket.pop(0)
    if len(bucket) >= max_calls:
        return False
    bucket.append(now)
    return True

Usage as a FastAPI dependency:

def rate_limit(max_calls, window_seconds, scope=""):
    async def _dep(request: Request):
        ip = get_client_ip(request)
        key = f"{scope or request.url.path}:{ip}"
        if not rate_check(key, max_calls, window_seconds):
            raise HTTPException(429, "Too many requests")
    return _dep

@app.post("/api/login", dependencies=[Depends(rate_limit(10, 60, scope="login"))])
async def login_endpoint(req):
    ...

The critical detail: default-reject unknown types

If your API has a type field that dispatches to different handlers, and you only apply rate limits for known types, an attacker can bypass rate limiting by sending an unknown type:

# BAD
limits = {"login": (20, 60), "register": (5, 60), "heartbeat": (240, 60)}
lim = limits.get(req.type)
if lim and not rate_check(...):
    return reject()
# Falls through to dispatch, then "unknown type"

An attacker sends 10,000 requests with type = "xyz". None are rate-limited. All hit your dispatcher, all fail, but they've burned CPU.

Fix: apply a default limit for unknown types before dispatch:

lim = limits.get(req.type, (30, 60))  # default bucket
if not rate_check(f"sdk-{req.type}-ip:{ip}", *lim):
    return reject()

Per-account throttling

IP-based limits don't help against distributed credential stuffing. An attacker with a botnet rotates through thousands of IPs, each making 1 request. Total: millions of attempts. Per-IP limit: never trips.

Per-account throttling fixes this:

if req.type == "login" and req.username:
    account_key = f"login:{app_id}:{req.username.lower()}"
    if not rate_check(account_key, 8, 300):
        return {"success": False, "message": "Too many attempts on this account"}

Now the account can only be tried 8 times per 5 minutes, no matter how many IPs the attacker uses. Combined with per-IP limits, you've covered both attack modes.

18. Step 12 — Failed login tracking and auto-blacklist

Beyond rate limits, track failures and auto-blacklist after too many:

FAILED_LOGIN_LIMIT = 6
_failed_logins = {}  # (app_id, ip) -> {"count": int, "hwid": str, "last": float}

def record_failed_login(app_id, ip, hwid):
    key = (app_id, ip)
    rec = _failed_logins.get(key, {"count": 0, "hwid": "", "last": 0})
    rec["count"] += 1
    rec["last"] = time.time()
    if hwid:
        rec["hwid"] = hwid
    _failed_logins[key] = rec
    return rec["count"]

def maybe_auto_blacklist(app_id, ip):
    key = (app_id, ip)
    rec = _failed_logins.get(key)
    if not rec or rec["count"] < FAILED_LOGIN_LIMIT:
        return False

    blacklist = get_app_data(app_id, "blacklist", [])
    now = datetime.utcnow().isoformat() + "Z"

    if not is_blacklisted(blacklist, "ip", ip):
        blacklist.append({
            "id": secrets.token_hex(4),
            "type": "ip",
            "value": ip,
            "note": f"Auto-blacklisted after {rec['count']} failed logins",
            "added_at": now,
            "added_by": "system",
        })

    if rec.get("hwid") and not is_blacklisted(blacklist, "hwid", rec["hwid"]):
        blacklist.append({
            "id": secrets.token_hex(4),
            "type": "hwid",
            "value": rec["hwid"],
            "note": f"Auto-blacklisted after {rec['count']} failed logins",
            "added_at": now,
            "added_by": "system",
        })

    save_app_data(app_id, "blacklist", blacklist)
    del _failed_logins[key]
    return True

Blacklisting both IP and HWID is important. If you only blacklist IP, an attacker on a dynamic IP gets a fresh start after a router restart. HWID blacklisting survives IP changes.

Notification

When auto-blacklist fires, notify the customer:

notify_customer(app_id,
    f"🚨 Auto-blacklisted\n\n"
    f"IP: {ip}\n"
    f"HWID: {rec['hwid'][:16]}...\n"
    f"After {rec['count']} failed logins\n"
    f"Last username tried: {req.username}")

This is a critical part of the system. Without notifications, the customer has no idea they're being attacked. With them, they can manually escalate (ban the account, block a range) or let the auto-blacklist handle it.

19. Step 13 — Login anomaly detection

Beyond obvious attacks, there's the subtler stuff: legitimate credentials used from a suspicious location, an account that's suddenly being accessed from a new device, impossible travel between two logins.

None of these alone prove an account is compromised, but together they build a picture.

The simple scoring approach

Track each login and score it:

def score_login(user_id, ip, ua, geo):
    score = 0
    flags = []
    history = get_login_history(user_id)

    if not history:
        return {"score": 0, "flags": ["first_login"], "recommendation": "ok"}

    known_ips = {h["ip"] for h in history}
    known_countries = {h["country"] for h in history if h.get("country")}
    known_devices = {h["device"] for h in history if h.get("device")}

    # New IP
    if ip not in known_ips:
        score += 1
        flags.append("new_ip")

    # New country — higher weight
    country = geo.get("country", "Unknown")
    if country and country not in known_countries:
        score += 3
        flags.append("new_country")

    # New device
    device = parse_user_agent(ua)
    if device not in known_devices:
        score += 1
        flags.append("new_device")

    # Impossible travel
    if history and geo.get("lat") and geo.get("lon"):
        last = history[-1]
        if last.get("lat") and last.get("lon"):
            dist_km = haversine(
                last["lat"], last["lon"],
                geo["lat"], geo["lon"],
            )
            elapsed_hours = max((time.time() - last["ts"]) / 3600, 0.01)
            speed_kmh = dist_km / elapsed_hours
            # > 900 km/h is faster than a commercial jet
            if speed_kmh > 900 and dist_km > 100:
                score += 4
                flags.append(f"impossible_travel_{int(dist_km)}km")

    if score >= 6:
        return {"score": score, "flags": flags, "recommendation": "kill"}
    if score >= 3:
        return {"score": score, "flags": flags, "recommendation": "warn"}
    return {"score": score, "flags": flags, "recommendation": "ok"}

Using the score

risk = score_login(user_id, ip, ua, geo)

if risk["recommendation"] == "kill":
    log_event(None, "security", "warning", f"Blocked login: {risk['flags']}")
    raise HTTPException(403, "Login blocked: suspicious activity detected")

if risk["recommendation"] == "warn":
    response["security_alert"] = {
        "message": "Unusual activity detected on your account",
        "flags": risk["flags"],
    }

GeoIP lookup

For country/city/lat/lon, use a free service like ipwho.is:

def ip_geo(ip):
    if ip in ("127.0.0.1", "::1"):
        return {"country": "Local", "city": "localhost", "lat": 0, "lon": 0}
    try:
        with urllib.request.urlopen(f"https://ipwho.is/{ip}", timeout=2) as resp:
            data = json.loads(resp.read())
        if data.get("success"):
            return {
                "country": data.get("country", "Unknown"),
                "city": data.get("city", "Unknown"),
                "lat": float(data.get("latitude", 0)),
                "lon": float(data.get("longitude", 0)),
            }
    except Exception:
        pass
    return {}

Cache the results for 24 hours per IP so you're not hitting the API on every request.

User agent parsing

Rough device fingerprint:

def parse_user_agent(ua):
    ua_lower = ua.lower()
    if "windows" in ua_lower: os_tag = "Windows"
    elif "mac" in ua_lower: os_tag = "macOS"
    elif "linux" in ua_lower: os_tag = "Linux"
    elif "android" in ua_lower: os_tag = "Android"
    elif "iphone" in ua_lower or "ipad" in ua_lower: os_tag = "iOS"
    else: os_tag = "Other"

    if "edg" in ua_lower: br = "Edge"
    elif "chrome" in ua_lower: br = "Chrome"
    elif "firefox" in ua_lower: br = "Firefox"
    elif "safari" in ua_lower: br = "Safari"
    else: br = "Other"

    return f"{br} on {os_tag}"

It's crude but effective. "Firefox on Windows" vs "Chrome on Android" is enough to distinguish a normal login from a suspicious one.

Why this matters for licensing

For an app license system, anomaly detection catches:

Shared accounts (many logins from different locations)
Stolen sessions (sudden jump in location)
Account trading (multiple distinct device fingerprints on the same account)
Test-account abuse (a key marked for a demo suddenly being used by 100 different IPs)

None of these are security holes in the traditional sense, but they're the ways customers actually lose money.

20. Step 14 — The admin side

None of this matters if the customer can't see what's happening and take action. The admin dashboard needs:

Viewing

All apps owned by the customer
All license keys, sorted/filtered
All end-users, sorted/filtered
Active sessions, with kill buttons
The observed-hash buffer
Event log with severity filter

Actions

Generate new license keys (bulk)
Ban/unban end-users
Reset HWID for an end-user
Kill sessions (single or all)
Add to blacklist (IP, HWID, username)
Add/remove binary hashes from the allowlist
Toggle binary_hash_required, require_fetch_seq, etc.
Set min_sdk_version

The tier structure

If you're building this as a product, define plans:

PLANS = {
    "trial":      {"max_apps": 1,   "max_users_per_app": 100,   "price": 0},
    "solo":       {"max_apps": 3,   "max_users_per_app": 1000,  "price": 1900},
    "studio":     {"max_apps": 10,  "max_users_per_app": 10000, "price": 4900},
    "enterprise": {"max_apps": -1,  "max_users_per_app": -1,    "price": 14900},
}

Enforce limits on app creation and key generation:

def assert_customer_can_create_app(principal):
    if is_admin(principal):
        return
    customer = principal["_customer"]
    limits = PLANS.get(customer["plan"], PLANS["trial"])
    max_apps = limits["max_apps"]
    if max_apps == -1:
        return
    current = len(customer_apps(customer["id"]))
    if current >= max_apps:
        raise HTTPException(402, f"App limit reached ({max_apps}). Upgrade to add more.")

Notifications

The customer needs to know when something interesting happens:

New end-user registered
License key burned
End-user banned / auto-blacklisted
Concurrent sessions evicted (possible account sharing)
Binary hash rejected (tampered build)
Suspicious login on their own account

Route these through the customer's own notification channel (their Telegram bot, their Discord webhook, their email). Don't send them through the platform's channel — you want each customer's alerts to be private to them.

21. Step 15 — The client side

The client is the other half. Its responsibilities:

Compute HWID
Run init → auth → heartbeat → fetch in order
Decrypt the fetched payload
Periodically re-fetch, verify heartbeat
Die cleanly-ish if any check fails

The skeleton

import requests, json, hashlib, hmac, base64, platform, socket, threading, time, sys, os

SDK_VERSION = "1.3.0"

class Auth:
    def __init__(self, api_url, app_name, owner_id):
        self.api = api_url
        self.name = app_name
        self.owner_id = owner_id
        self.session_id = None
        self.decryption_key = None
        self.hb_token = None
        self.fetch_seq = 0
        self.data = None
        self._alive = True
        self._hb_interval = 30

    def _hwid(self):
        raw = "|".join([
            platform.system(),
            platform.machine(),
            socket.gethostname(),
            platform.processor() or "",
        ]).encode()
        return hmac.new(b"hwid-salt", raw, hashlib.sha256).hexdigest()

    def _req(self, data):
        data["name"] = self.name
        data["ownerid"] = self.owner_id
        data["sdk_version"] = SDK_VERSION
        if self.session_id:
            data["sessionid"] = self.session_id
        if self.hb_token:
            data["hb_token"] = self.hb_token
        r = requests.post(self.api, json=data, timeout=10)
        return r.json()

    def init(self):
        r = self._req({"type": "init", "ver": "1.0.0"})
        if r.get("success"):
            self.session_id = r["sessionid"]
        return r

    def license(self, key):
        r = self._req({"type": "license", "key": key, "hwid": self._hwid()})
        if r.get("success"):
            self.session_id = r["sessionid"]
            self.decryption_key = r["decryption_key"]
            self._hb_interval = r.get("heartbeat_interval", 30)
        return r

    def load(self):
        """Fetch and decrypt gated data. Returns True only if everything works."""
        if not self.decryption_key:
            return False

        next_seq = self.fetch_seq + 1
        r = self._req({
            "type": "fetchdata",
            "hwid": self._hwid(),
            "fetch_seq": next_seq,
        })
        if not r.get("success"):
            return False

        enc = r.get("encrypted_data")
        if not enc:
            return False

        try:
            km = base64.b64decode(self.decryption_key)
            hwid = self._hwid()
            ek = hmac.new(km[:32], f"fetchdata-enc-{hwid}".encode(), hashlib.sha256).digest()
            mk = hmac.new(km[:32], f"fetchdata-mac-{hwid}".encode(), hashlib.sha256).digest()

            raw = base64.b64decode(enc)
            iv, ct, mac = raw[:16], raw[16:-32], raw[-32:]

            expected_mac = hmac.new(mk, iv + ct, hashlib.sha256).digest()
            if not hmac.compare_digest(mac, expected_mac):
                return False

            pt = hmac_stream(ek, iv, ct)
            pt = pt[:-pt[-1]]

            self.data = json.loads(pt.decode())
            self.fetch_seq = next_seq
            if self.data.get("hb_token"):
                self.hb_token = self.data["hb_token"]
            return True
        except Exception:
            self.data = None
            return False

    def _heartbeat_loop(self):
        fails = 0
        while self._alive:
            time.sleep(self._hb_interval)
            if not self._alive:
                break
            try:
                r = self._req({"type": "heartbeat", "hwid": self._hwid()})
                if r.get("success"):
                    fails = 0
                    if r.get("hb_token"):
                        self.hb_token = r["hb_token"]
                else:
                    fails += 1
            except Exception:
                fails += 1

            if fails >= 3:
                # Corrupt state and exit — NOT a clean exit that can be hooked
                self.data = None
                self.decryption_key = None
                self.session_id = None
                os._exit(0xFF)

    def start(self):
        threading.Thread(target=self._heartbeat_loop, daemon=True).start()

    def ready(self):
        return bool(self.data and self.data.get("username"))

Usage

auth = Auth("https://api.example.com/api/1.2/", "my-app", "ownerid123")

if not auth.init().get("success"):
    sys.exit(1)

key = input("License key: ")
if not auth.license(key).get("success"):
    sys.exit(1)

auth.start()
time.sleep(auth._hb_interval + 1)  # wait for first heartbeat

if not auth.load():
    sys.exit(1)
if not auth.ready():
    sys.exit(1)

# App logic — all values come from the server
username = auth.data["username"]
max_level = auth.data["app_vars"].get("max_level", 10)

The failure mode matters

Notice the os._exit(0xFF) on three heartbeat failures. Not sys.exit(). Not exit(0). os._exit() kills the process immediately without running cleanup handlers, without flushing buffers, without giving the app any chance to gracefully close.

Why? Because if the app exits cleanly, a patch can intercept the exit and prevent it. But if the app loses its state and then crashes, there's nothing to patch — the data is gone, the keys are gone, and the only path forward is a restart that re-runs the auth flow.

The more hostile the failure mode, the harder the app is to patch.

22. What's real defense and what's theater

After building this stuff for years, here's my honest assessment of each layer.

Real defenses

Server-gated data. The foundation. Everything else is built on it.
Proper password hashing (bcrypt/argon2). Non-negotiable. If your passwords aren't hashed with a slow algorithm and salt, nothing else matters.
Per-session random keys. Blast radius containment.
Constant-time comparison for tokens and HWIDs. Prevents timing oracles.
Heartbeat + rotating tokens. Kills replay. Real defense.
Per-account rate limiting. Defeats distributed credential stuffing. Real defense.
Session rotation on login. Kills stale sessions. Real defense.
Encrypt-then-MAC. Correct AEAD construction. Non-negotiable.
HWID binding (as a speed bump, not a wall). Slows attacks, doesn't stop them. But combined with everything else, useful.
Sequence counters. Real defense against relays, but defeatable by a patched client.

Theater (with a caveat)

Binary integrity checks. Defeated by patching the hash function. But: raises the bar, especially when combined with obfuscation and multi-point checks. Worth having.
SDK version gating. Defeated by a client that lies. But: forces the attacker to keep up with updates. Worth having.
Anti-debug checks. Trivially defeated by patching IsDebuggerPresent or using a debugger that hides itself. Pure theater on their own. Useful as speed bumps.
Packing / obfuscation (VMProtect, Enigma). Raises the cost of static analysis. Doesn't stop a determined attacker. Real value at scale.
Heartbeat required for fetchdata. Slows attacks that skip the heartbeat step. Theater if the client can just send a heartbeat first.

Things that feel secure but aren't

Encrypting passwords before hashing. Encryption is reversible — the key must live somewhere, so you've gained nothing. Hash, don't encrypt.
Adding "salt" by wrapping strings in symbols (##value@#). Not a cryptographic salt. Known format. Attacker can strip it.
Custom ciphers. Unless you have a formal security proof, you don't. Use AES-GCM.
Storing secrets in the client. Anything shipped to the client is compromised. Full stop.
Long expiry times. A 30-day session token is a 30-day window for a stolen token to be useful. Shorter is better.

The rule of thumb: if it makes the attacker's job harder, it's worth having. If it only makes you feel safer, it's theater. Most systems have both. The best systems know which is which.

23. Common mistakes

Every one of these has bitten someone.

1. Empty HWID skipping the check.

if stored_hwid and not hwid_matches(stored, incoming):
    reject()

If incoming is empty, hwid_matches(stored, "") might return True (empty == empty or short-circuit). Free bypass. Always require non-empty.

2. Timing-attackable comparisons.

if client_token == server_token:

Short-circuits on first differing byte. Use hmac.compare_digest.

3. The same message for "user not found" and "wrong password."

if not user:
    return "User not found"  # BAD — leaks usernames
if not verify_password(...):
    return "Wrong password"

Always return "Invalid credentials."

4. Token/user info in URL parameters.

GET /fetchdata?token=abc123&user=alice

Tokens end up in logs, browser history, referrer headers. Always POST, always in the body or a header.

5. Rolling your own crypto.
Yes, I'm repeating this. It's that important. Use AES-GCM, bcrypt, HMAC-SHA256. Standard primitives, standard constructions. If your code has a novel cipher, it's wrong.

6. Trusting the client to compute anything sensitive.
Anything the client computes can be recomputed wrongly. Anything the client stores can be extracted. The client's job is to talk to the server; the server's job is to decide.

7. Not rate-limiting by account, only by IP.
IP limits are trivially defeated by botnets. Account limits aren't.

8. Long-lived sessions.
A 30-day session means a stolen token is useful for 30 days. Refresh tokens should be short, access tokens shorter.

9. Storing secrets in plaintext on the server.
Telegram bot tokens, API keys, webhook secrets — all of them need at-rest encryption. A filesystem read shouldn't be enough to compromise everything.

10. No alerting on security events.
If you don't tell the customer when their app is being attacked, they can't respond. Notify on: auto-blacklist, concurrent session evictions, binary hash rejections, suspicious logins.

11. Assuming the attack isn't coming.
The day after you launch, someone will try. Assume it. Plan for it. Test it.

24. Testing your system

Before you ship it, test the attacks yourself. Every one of these should be blocked.

Session replay

Log in as a user with a valid key
Capture the exact fetchdata request and response
Wait 60 seconds
Replay the request
Expected: rejected with "stale heartbeat token"

Session sharing

Log in from machine A
Copy the session ID and token to machine B
Try to fetchdata from machine B
Expected: rejected with "HWID mismatch"

Relayed clones

Log in from one machine
Run two processes that both call fetchdata with the same session
Expected: one succeeds, one gets rejected with "stale fetch_seq"

Brute force from one IP

Fire 100 login requests to the same account from one IP
Expected: rate-limited after 8 requests; auto-blacklisted after 6 failures

Distributed brute force

Fire 1 request per IP from many IPs (use a proxy service)
Expected: account-level rate limit trips after 8 requests across all IPs

HWID bypass with empty field

Send login with hwid: ""
Expected: rejected with "HWID required"

Modified binary

Patch the client executable
Enable binary_hash_required on the app
Log in with the patched binary
Expected: rejected with "Binary integrity check failed"

Old SDK

Set min_sdk_version = "1.3.0" on the app
Send a request with sdk_version = "1.2.0"
Expected: rejected with "SDK update required"

Token tampering

Capture a valid hb_token
Modify one character
Send a request with the modified token
Expected: rejected with "stale heartbeat token"

Password timing

Time 10,000 requests with wrong passwords of varying prefix-lengths
Expected: all requests take approximately the same time (no correlation with prefix match)

Run these before you have customers. Run them again after every significant change.

25. The honest ending

Everything is crackable.

Not "might be." Has been. Every commercial license system — Denuvo, BattlEye, KeyAuth, Auth.gg, iLok, Steam DRM — has been broken, repeatedly, by people who know what they're doing. There is no such thing as uncrackable software.

What you're building isn't a wall. It's a cost curve. The question isn't "can someone crack this?" — the answer to that is always yes. The question is:

How long does it take?
How much specialized skill does it require?
Does the crack survive your next update?

If cracking your app takes an afternoon, one person, and works forever — you've built nothing. If it takes weeks, requires deep reverse engineering skill, and breaks every time you ship a patch — you've built something real.

Not unbreakable. Just not worth it.

The layers in this post each raise the cost. Server-gated data makes patching impossible. HWID binding makes sharing detectable. Heartbeat tokens make replay useless. Sequence counters make relays desync. Binary integrity makes modification detectable. SDK versioning makes bypasses age out.

No single layer is a wall. Together they're a slope. The attacker has to keep climbing, and every step up costs them time and skill they'd rather spend elsewhere.

And that's the goal. Not perfection. Not certainty. Just a system expensive enough that the person attacking you decides their time is worth more somewhere else.

That's what real security looks like. Not paranoia, not theater — just an honest assessment of what each layer buys you, and the judgment to know when you've done enough.

Ship something simple first. Add layers only when you can justify them. And remember the foundation underneath everything:

You can't patch your way into data you don't have.

Everything else is commentary.

DEV Community: MR storm

Web Testing Is Boring And That's The Whole Problem

Spoofing WiFi MAC Addresses with a Windows Kernel Driver

1. What a MAC address is

2. Why userspace can't reliably set it

The registry approach

The driver IOCTL approach

The NDIS OID approach

The remaining option

3. The three driver models

WDM — Windows Driver Model

KMDF — Kernel-Mode Driver Framework

NDIS — Network Driver Interface Specification

4. KMDF implementation

Device extension

IOCTL codes

Driver entry

Device add

Device control handler

5. WDM implementation

Driver entry

Device control

Exception handling

6. NDIS implementation

Filter callbacks

Filter context

What completing the filter requires

7. The registry manipulation

Opening the class key

Enumerating subkeys

Reading DriverDesc

Matching the WiFi adapter

Writing the MAC

Why it works

Why it sometimes fails

8. The IOCTL interface

METHOD_BUFFERED behavior

Access flags

Validation

9. Building and signing

Prerequisites

Enabling test signing

Signing with a test certificate

Building

Module definition file

10. Installing and testing

Using pnputil

Using sc.exe

Testing

Kernel debugging

11. Userspace interface

C

Python

12. Technical limitations

Building a License Authentication System From Scratch

Table of contents

1. The problem

2. Why boolean checks fail

3. The core idea: server-gated data

4. The full architecture

5. The wire protocol

6. Picking your stack

7. Step 1 — Init and the encrypted payload

8. Step 2 — Password storage done right

Why hashing and not encryption

Why a salt

Why a slow hash

The right way

Migrating from a worse scheme

9. Step 3 — Register and license activation

10. Step 4 — Login and session creation

11. Step 5 — Hardware binding

Generating the HWID

Server-side checks

12. Step 6 — Heartbeat and rotating tokens

Why rotate the token?

The client's obligation

What this defends against

What this does not defend against

13. Step 7 — Fetching the gated data