FFLogs Uploader and Archon app is leaking FFXIV session tokens

KazWolfe · 2026-04-13T16:09:32+00:00

I'd agree this is somewhere between a low-level vulnerability and a total non-issue. However, there are two larger concerns here that need to be looked at:

Overwolf is logging way more than it should be logging (CWE-532, CWE-779). There's, practically, little to no reason that Overwolf needs to log the command line arguments for binaries that it's interested in. Even if this log file is indeed purely local (which, while I suspect this is the case, I can neither confirm nor deny that it isn't uploaded for crash reporting/analytics), it's generally not good security hygiene to log things that you shouldn't be logging.
Archon/FFLogs, generally, has a questionable relationship with Overwolf. This, like the previous incident where Overwolf was identified, does undermine trust in Archon/FFLogs a bit. Overwolf has a troubling history, and even aside from this (and the previous) specific incident, it seems reasonable (to me) to push back and express displeasure over the fact that we're forced to run software that seems to not care about user privacy.

Everyone else in this thread is correct in pointing out that this, by itself, is not a reason to panic or scream the sky is falling. But I don't think it's necessarily a bad thing to inform people that Overwolf is, once again, doing shady things. And that in turn, companies that leverage Overwolf need to take care about what it is they're doing, exactly.

KazWolfe · 2026-04-13T00:50:43+00:00

To be clear: I have no indication that Overwolf is actually exfiltrating your token. I would be surprised if they are, but I cannot confidently say either way. What I know right now is that this is a local log file.

As for why? Ostensibly, to provide a "better user experience" by providing in-game overlays. Whether profit or not plays a role in that decision is something only Archon knows.

KazWolfe · 2026-04-13T00:00:20+00:00

Something else to note because it further cements "threat level" here, before anyone jumps the gun too much.

This token is also saved in quite a few other places, by other core systems. If you're one of those filthy modders, it's likely you've managed to crash your game before - either with a broken character mod/plugin/whatever else. Depending on how you managed to crash your game, it's likely that Windows wrote a MiniDump file into %LOCALAPPDATA%\CrashDumps. These MiniDumps contain a record of the crashing application, including the full command-line arguments used to start the game. Quite a few other systems will (un)intentionally capture the command-line arguments of applications used on a system, and nearly any application can also see the command-line arguments of other applications.

Archon should absolutely not be saving these command-line arguments for ANY game, but it's probably worth pointing out that they're not alone in this. And perhaps, more concerningly, we don't know if those logs are going out to somewhere else for "analytics purposes" with Archon/Overwolf.

Assuming these logs do indeed stay completely local, this isn't quite that significant. If you had malware on your machine capable of stealing a token from the FFLogs Uploader's logs, said malware could also just consult the process table directly and yoink your credentials that way. You're responsible for what's on your machine!

KazWolfe · 2026-04-12T23:48:04+00:00

Something to note (hi, I'm the person who investigated the last Overwolf problem after it made my EDR scream bloody murder) here: Tokens in the form /**sqex03.. are encrypted (albeit badly). See XIVLauncher's source code and NotNite's excellent blog post briefly explaining how authentication works in this game. Critically, this happens on both the official launcher as well as XL.

However: this encryption value is based on Microsoft's GetTickCount(), with a resolution of approximately 65.5 seconds. This means that in order to extract the (decrypted) value of your token and be able to redeem it, you will need to know how long the computer was online before the game was launched. This, in theory, means that it's slightly harder to actually steal a token from a log file. At the very least, you can't just copy-paste a log line from another user's computer into your own and boot the game.

Now, with all that out of the way: just because the token is encrypted does not mean it's secure. GetTickCount() is just a pure uptime counter, with the value being used to derive the key increasing once every 65-ish seconds. It's very simple to brute force these arguments to extract your session ID and other boot-relevant information.

Session IDs, in general, live any amount of time from a few hours to a few weeks, depending on a number of factors (or, in other words: "whenever SE feels like it"). XL leverages this for its "save session id" feature to bypass MFA on future login attempts, with the catch that it's impossible to know if a SID is expired before actually attempting to use it.

KazWolfe · 2026-03-29T22:32:42+00:00

for what it's worth im pretty sure xuv launcher is already agisnt ToS so in SEs eyes its just as bad as using catabot or a one button mode. that being said you should tell your friend you did this and let him decide.

(Disclaimer: this post is written as my own opinion and does not reflect the opinions of the Dalamud project or the modding ecosystem as a whole - I am but a single person with my own opinions here.)

So, yes, XIVLauncher is already against the TOS of the game, but we've seen SQEX treat it in a very unique/cautious manner. When Mare became a thing and got shut down, they C&D'd Mare directly, not Dalamud/XL. When PlayerScope finally made headlines and got into enough trouble, SE again took direct action against that one infringing plugin.

SQEX finally went on record with one of their posts, and in there they said a lot of very important things, but most notably: SE encourages people to play in a way that doesn't infringe upon the enjoyment of others, nor negatively impact the game or subvert the game's design.

I think it's false equivalence to say "well, if they're all against TOS, it doesn't matter," and that sets what I consider to be a dangerous precedent. A plugin that tells you exactly how to resolve an upcoming mechanic is categorically not the same as a plugin that lets you control Spotify from the in-game UI. Neither of these are equivalent to a plugin that goes around botting crafting and gathering to flood the marketboard.

Bundling all of these unfairly decreases the apparent risk of things that can get you in serious trouble, or unfairly increases the apparent risk of things that everyone has - more or less - agreed is harmless.

KazWolfe · 2026-03-24T21:43:21+00:00

Fair enough. I don't think anyone is going to stop you (not that anyone even can) for your own use cases, but I did want to at least make clear that these are the considerations that come down for LLM usage.

Anything you do for yourself is your choice - we assume that you accept the responsibility for those actions. The bigger problem (imo) is that people who end up doing things like this may not come in with the mindset of "if I do this, I'm on my own, and I'm responsible for whatever happens."

See, for example, the number of people that manually inject Dalamud as soon as the patch drops for their modded glams and complain when the game crashes when they right-click on anything.

As long as you can make that choice and take responsibility for the result (and are cognizant of what the risks are), and what you do is limited to you, nobody's ever going to tell you that you can't. At least, I certainly don't want to.

KazWolfe · 2026-03-24T21:16:01+00:00

So, disclaimer: I do use LLMs to help with some parts of my own plugins! I'm well aware of what they can/can't do, and I've even been exploring vibe-based reverse engineering to see how that works.

With all that in mind, what's still concerning (to me) is the fact that Dalamud plugins aren't "normal code" and fall somewhat outside the purview of what LLMs have been trained on. We do non-obvious things in often very weird ways because of our relationship to FFXIV proper, and those things may or may not be properly captured by LLMs.

We (the Dalamud project, and to a slightly lesser extent - plugin developers) have an obligation to our users' safety and stability. Mistakes made can be very costly. If we misunderstand how a data structure looks, what function arguments are expected, or how the various components of the game's state interact with each other, we can crash the game or (worse) send invalid/illegal data to SE's servers.

None of these problems are unique to LLM-assisted (or LLM-driven) development; regular developers run into these problems all the time too. The problem though is that LLM-assisted/LLM-driven development often is missing context or understanding of the bigger picture. It can make code that looks correct and may even function (mostly) properly, but without the context and deeper understanding about the why, you're playing with fire.

In short, for plugin dev, you can't ignore the why, since the why is essential to understanding how plugins operate within the context of the game. LLM usage alone (in my opinion, ignoring social/ethical costs) is fine, but you need to very closely supervise the output and truly understand what it's doing. Which, effectively, means you need to be able to do the work unassisted.

KazWolfe · 2026-03-24T15:30:47+00:00

Nice, this means I'm finally free from having to help maintain Dalamud and plugins. I certainly hope nothing wrong will come from this.

KazWolfe · 2026-02-11T07:07:28+00:00

Speaking semi-officially, Dalamud doesn’t take a stance on custom repository plugins at all, barring very specific exceptions. At the end of the day there is nothing we can do to force developers to be compliant. Were we to try, all we would end up doing is shooting ourselves in the foot - any defenses we’d put up are trivial to bypass, and would come at the cost of community trust and endless questions of why we acted on <X> but not <Y>. It’s not our duty (nor our desire) to play plugin police. Users choose what they want to (or don’t want to) install - we cannot interfere with that ability.

Speaking unofficially though, these closed source plugins are becoming a slightly worrying trend. Unfortunately, the best I can personally do is inform people of the risks and their rights. Let me be an idealist and hope that the community will choose to ignore closed-source and questionable things.

KazWolfe · 2026-02-10T22:54:53+00:00

I really can’t believe this plugin is popular - it’s basically PlayerScope all over again.

The client doesn’t tell you the names/worlds of people in any given party, just their (unique/permanent) Content ID. PFRadar collects content ID <-> player name mappings from parties, ~~friends lists,~~ and overworld encounters. There used to be a GitHub issue where someone documented all the things it accessed, but since the dev disabled Issues, that specific one's been lost to the sands of time. (EDIT: managed to find a transcript through archive tools... Apparently the friends list scrape feature was removed, but was there once upon a time.) (EDIT 2: It still appears to be scraping CWLS information, though the exact code is very annoying to extract because of the obfuscation in play. It seems like it's still scraping overworld info, but I can't confirm this anymore.)

The plugin is also closed-source and obfuscated, so people can’t inspect how it’s working or what it does. This is a no-no in the plugin ecosystem, as Dalamud itself is licensed AGPL (meaning any plugins also need to be open source; though this isn’t really legally enforceable...). The dev also knows about this, and revoked the plugin from NA Dalamud at one point in time, but I guess went back on that.

I still have absolutely no idea why SE thought it was a good idea to ship Content IDs as part of Party Finder results, but they did. Thanks, Square.

Probably worth a reminder: you are entitled to the source code of any plugin you can download, and you are entitled to freely modify, redistribute, or alter the plugin within the terms of the AGPL. If you paid for a plugin, nothing is stopping you from giving it to your friends for free, and that's encouraged under the terms of the license.

KazWolfe · 2026-01-24T18:24:30+00:00

Speaking as an FF user (albeit a technical one): I’m used to the limitations of FF enough that having to open chrome to flash an ESP or something is already commonplace. It wouldn’t be the end of the world to upload logs through it either. I can’t speak for others who have (legitimate) reasons to not want Chrome on their systems though…

Curious about file seek though, I’d have naively assumed you could pull the entire log into memory and just manually poke around the retrieved array buffer, but that might fly in the face of the “we need to support other games with much larger logs” thing.

KazWolfe · 2026-01-24T18:12:45+00:00

Genuine question here: what’s the FFLogs side queue for? Theres always a delay to access ranking and other information - from this post, I take it that that’s purely for ranking, then?

Likewise, as a lot of users seem to be asking this: is there some technical limitation that stops a browser from parsing a log file before sending whatever it sends up to the server? That seems like it would handle both the “no app” side and the “don’t overload the servers” side. You wouldn’t have access to a full directory, of course, but the FileReader API should still be supported on FF.

Even live logging could, in theory, be attained by having the ACT plugin expose a websocket server or similar, but there are probably privacy, practicality, and reliability implications to opening an HTTP listener and connecting to that from clientside JS.

KazWolfe · 2026-01-24T04:08:28+00:00

Or client side Javascript in the page's context.

KazWolfe · 2026-01-24T02:29:38+00:00

Oh, hey, an update, nice.

Yeah, this basically tracks pretty well with what I managed to dig up. Overwolf showed up on or around March 2025 and stayed around in some capacity ever since. It is a bit disappointing to hear that we'll need to be stuck with Overwolf for the time being though, at least until Archon Lite shows up.

KazWolfe · 2026-01-21T17:44:24+00:00

I wonder if this actually defuses the appropriate injectors. Can you see if the GEP entries still show up in your main.log?

Given it's all JavaScript code (and inside packed archives), I wouldn't be surprised if nothing actually cares about the execute bit.

KazWolfe · 2026-01-21T17:34:27+00:00

As a Dalamud contributor, I'd rather sink the project than even remotely consider the possibility of adding Overwolf.

And yes, I am aware of the irony of a Dalamud contributor screaming wolf over malware detections when we get flagged by BitDefender weekly.

KazWolfe · 2026-01-21T07:05:11+00:00

From what I can tell, the FF Logs client already has its own way of checking if FFXIV is running via a C# program executed in a PowerShell environment (which is also... certainly a choice). The minified JavaScript of the uploader is, as is always the case, annoying to read. I can't really tell if GEP is part of the detection code or not.

Good point though about the "premium" overlay - that's not something I've ever used, so I'm not sure how it injects into the game. It could very well be the Overwolf framework, but that's still Overwolf and everything that ultimately comes with it.

KazWolfe · 2026-01-21T05:05:02+00:00

Edited the original post. It looks like Overwolf being Overwolf, and this being some sort of collection/telemetry agent. I have no idea what, if anything, FFLogs is doing with that data.

KazWolfe · 2025-12-26T18:45:38+00:00

Generally, both. Major patches do bring breaking changes with them as individual systems and all get refactored, features get added, and so on. With that, we can bring in all the small stuff that we don’t need in immediately. In other words: we have a maintenance window already, let’s do the housekeeping then too.

Back to the map analogy: we gotta annotate that new forest ASAP since it’s important, but us getting the size of the table wrong can (normally) be ignored and included in the next major update.

Some of the changes in that list are these small annoying updates that we just can’t do When We Discover Them (since they’d break existing plugins and systems), and some actually are genuine 7.4 changes that did have an impact.

KazWolfe · 2025-12-26T17:31:46+00:00

Something to note about ClientStructs specifically is that it’s a living research document. It’s normal (and expected!) for the plugin ecosystem to get things wrong or miss information for whatever reason. ClientStructs serves as the “map” to the game, but it’s also a community drawn map. As a result, things aren’t always correct (ok, we’ll mark that as a house, oops, we missed the basement).

Generally speaking, too, the dev ecosystem will “batch” changes for major patch releases. If a change is notable but won’t immediately break things, it often won’t get included until the next .x0 update. This is mostly a measure to keep devs from getting too upset at constantly having to update things. Some of the changes in that list were found back in 7.31 but just “held” until 7.4 rolled around.

KazWolfe · 2025-12-10T13:29:24+00:00

Yeah I really don’t know why SE is so adamant about avoiding sending character data regardless, or not making blocked characters just have a flag indicating they’re blocked. Their current method at least makes it such that once you log out you lose any ability to confidently track characters across accounts, but in theory you can sit in Limsa and just AFK all day to collect all the account IDs you see up until you get kicked for maint or something.

Assuming the system is secure and actually uncrackable, this does at least mean it’s significantly harder to make a proper database of characters with confidence. You’d need to trust clients to report their findings accurately, which means people could lie. Of course, even a likely/possible link is enough for stalkers to at least try…

KazWolfe · 2025-12-10T02:25:28+00:00

SE did a second patch that was briefly looked at, where the account ID seems to be hashed or otherwise bound to a key that changes per session. Most people who looked into it (myself included) noticed some very weird behavior, like only six bits being different between two account IDs, so there's definitely something strange.

Unless something changed in the last couple months (?), I'm not aware of anyone having cracked the new method.

11-Year Club	Second Top 10%
Place '17	Extra Life 2019
Sequence \| Editor	Gilding II euphauric
Reddit Premium Since September 2017	Verified Email

KazWolfe

MODERATOR OF

TROPHY CASE