what i found inside the akatsuki patcher

i started looking at the akatsuki loader because i wanted to know what it was connecting to. a tool that patches osu! should be something you can understand before you let it run on your computer.

the part that bothered me was in the code it downloads. that payload builds a report about the other programs running on your pc. the report includes visible window titles, executable locations and hashes of those executables. it then replaces a field in osu!'s score submission with an encrypted copy of that report.

that means the collection reaches beyond the game. the list isn't restricted to programs the patcher has identified as cheats. it includes other running programs, with whatever titles and paths windows lets it obtain.

i consider that spyware behaviour, and it's why i consider this payload malware. the finding behind that assessment is specific: a gameplay patcher contains broader process reporting that i couldn't find explained on the public pages i reviewed. the legal question needs its own explanation; a malware assessment and proof of a crime aren't the same thing.

this review covers the supplied loader and the stable payload downloaded on 11 october 2026. i manually traced the relevant code paths, using static decoding and scripts to extract and check the byte data, without running either file. i haven't captured a live submission or inspected the private service that reads these reports.

what the loader actually downloads#

the loader first checks an update endpoint:

GET https://air_conditioning.akatsuki.gg/loader/loader-updates

when you launch the game, it requests the selected patcher branch. for stable, that's:

GET https://air_conditioning.akatsuki.gg/patcher/patcher-version?branch=stable

the second endpoint returns executable code. in my request it redirected to stable-20261007.dll in akatsuki's Wasabi storage bucket. a DLL is a library of code. the loader's injection code puts that downloaded library into the osu! process and calls its setup method. it launches the game with -devserver akatsuki.gg.

so the local exe is only part of what you're trusting. the service chooses the code that gets loaded into your game. inspecting the loader's update calls alone misses what that downloaded code does.

the update metadata also offered a replacement loader. i inspected that file too. its download and injection paths matched the supplied loader; the relevant changes were around launching the game as an unelevated windows user and checking whether that worked. the process report described here is in the downloaded patcher.

what it collects from your pc#

the payload has genuine gameplay features: relax miss handling, ranking panels, live pp, cursor trails and other changes. alongside those features is a required feature called Submission.

its report contains a running_processes list. the code enumerates processes and excludes the current game process. for each entry it tries to obtain:

windows permissions and errors can leave fields unavailable. the code selects a window title for a process; it doesn't capture every browser tab or read the whole document. hashing an executable also doesn't mean the executable itself is uploaded.

even with those limits, a window title can say a lot. a document name, a conversation title or the name of a page can expose what you're doing outside osu!. an executable path can include your windows username and details of your folders. those are examples of what the fields can reveal, not someone's actual desktop captured in this review.

the broad process list is separate from the cheat checks. one heuristic looks for gosumemory and a path containing package, then emits an assist.games detection. another looks for Discord Canary together with the windows username user. those labels are results the code produces; they don't establish that a person is cheating. assist.games wasn't an outbound address in this path.

the complete report also contains client_hash, detections, method_coverage, misc_detections and timestamp. it is a structured report about the client and its surroundings.

how it gets into the score request#

when osu! submits a score, it builds a request with named fields. the patcher hooks the function that adds those fields, AddParameter.

for most names, the original value passes through. when the name is fs, the hook replaces the value with the patcher's report. it serializes the report as JSON, encrypts it with AES-CBC using a key embedded in the DLL, then wraps the result in Base64.

the flow is:

other running programs
    -> window titles, executable paths and hashes
    -> JSON report
    -> encrypted envelope
    -> replacement fs value in the score request

that encryption protects the report's contents from a casual look at the request. the titles and paths remain inside the encrypted JSON; they aren't reduced to hashes or anonymised by encryption.

i checked what fs originally held using a decoded client i've had since july. its protected submission routine encrypts a string containing six gameplay and visual settings, including background dim and sample, skin and storyboard settings. the patcher replaces that settings value with its wider report.

the supplied client's exact build provenance is unknown. comparisons with a fresh official stable executable found matching surrounding getter and request-class code. that supports the reference, but i haven't independently decoded the fresh client's protected submission body.

this is a demonstrated replacement in the managed request builder. i haven't established a patch to the native osu!auth.dll. calling it a proven hijack of that DLL would go beyond what i recovered.

where the report is meant to go#

the important carrier is the game's score request. a check that only looks for an extra telemetry domain can miss this code path.

akatsuki's public server source registers POST /web/osu-submit-modular-selector.php. its score handler preserves fs in an event sent to an internal queue for accepted passed-score submissions. the public routing configuration maps game web routes on osu.akatsuki.gg and .pw to that service.

that supports the intended route from the score field into akatsuki's infrastructure. i haven't verified the deployed commit, captured the actual upload, or established who decrypts the report, where it's stored or how long it's retained. i also didn't find a separate fixed telemetry host in the main payload or its reviewed embedded libraries.

why i consider this malware#

the concern is the combination of unrelated-program collection and how players are told about the software. injection and obfuscation alone wouldn't settle that question. here, the recovered code collects information outside the game and substitutes it into a request field players aren't going to inspect.

i reviewed the download page, FAQ, troubleshooting guide and terms on 11 october. i couldn't find an explanation of this process and window-title reporting on those pages. that doesn't prove a notice never existed anywhere, or that every version behaved identically. it does leave a serious gap between the advertised features and what this payload contains.

the troubleshooting guide also recommends disabling windows defender and adding exclusions for the patcher and temporary folder. i'm uncomfortable with that advice next to code that gathers information about other applications. i haven't established that the payload itself disables defender.

microsoft's classification criteria treat compromised user security as a malware concern, and separately describe software that fails to provide clear notice and consent for storing or transmitting user data as unwanted software. those distinctions matter. i'm using the criteria to explain the concern; i haven't obtained a vendor verdict on these files.

my assessment is that undisclosed reporting about unrelated applications crosses into spyware behaviour. the fact that the same DLL also improves gameplay doesn't make that collection acceptable to me. if the reporting is part of anti-cheat, explain it plainly before someone installs the tool and give them a real choice about running it.

the legal problem#

i'm in australia, so i've checked the australian rules rather than pretending one law applies to every player and operator.

for organisations covered by the Privacy Act, APP 3 limits personal-information collection to what is reasonably necessary and requires lawful and fair means. the OAIC says covert collection is usually unfair, while recognising circumstances such as fraud investigations. it also treats excessive or unreasonably intrusive collection as a fairness problem. calling something anti-cheat doesn't, by itself, establish that a broad window-title report meets those requirements.

APP 5 requires reasonable steps to make people aware of matters including the collection, its purpose and usual disclosures, generally before or at collection, or as soon as practicable afterwards. a download page describing gameplay changes wouldn't automatically explain reporting about other applications.

ordinary personal information doesn't always require consent under these rules. sensitive information generally has an additional consent requirement unless an exception applies. a window title could expose sensitive information, but i haven't observed a real report containing it. the necessity and fairness requirements still matter. OAIC's APP 3 guidance

there are also questions about whether the operator is covered at all. the Privacy Act has small-business exemptions and rules for overseas organisations with an australian link. i haven't established akatsuki's legal entity, turnover or jurisdictional position. OAIC's explanation of coverage

if the Act applies, and the actual collection lacks the required fairness, necessity or notification, it can breach privacy law. those are concrete legal concerns raised by this design. the code review and four public pages don't establish every fact needed to find a breach.

a criminal computer-access claim needs more again. section 478.1 of the Criminal Code concerns intentional, knowingly unauthorised access to or modification of restricted data. section 476.2 also says an ulterior purpose alone doesn't make otherwise authorised access unauthorised. i haven't established those elements here.

so i consider the reporting invasive and spyware-like, and i think its disclosure and legality deserve scrutiny. i can't honestly turn a static finding into a confirmed criminal offence.

the evidence behind this post#

the loader i reviewed has SHA-256:

87f8dadbe18cac959194dfb173eea9f1076cc8943279cb018e40b25073193002

the stable payload returned during the review was stable-20261007.dll, with SHA-256:

7dbc3efcbff2dba1d38ba2fecec46ed69828d38349eb2e1f087ae640aadb5441

the remote payload can change independently of the local loader. these findings describe those bytes, not every past or future download.

the technical report records the collection APIs, method tokens, reconstructed reporting code and original fs argument flow. the network report records the loader requests and server-route evidence. both open as readable pages, with a markdown source view and download. local paths have been redacted and temporary signed download queries are omitted.

a controlled windows run with synthetic window titles would be the next step for confirming the submitted bytes and which fields succeed at runtime. the service's disclosure, decryption, access and retention practices also need answers. until then, i'm keeping the confirmed code behaviour separate from the parts nobody outside that service has established.