Final Fantasy XIV - Kiwi Free Company

1999 prick said:
M5 is a pain in the ass especially if your melee n has a groovy OST
Click to expand...
M5 is super easy, what're you struggling with? The only "difficult" part is keeping full uptime with those spotlight mechanics
 
Update on the most Nothing Ever Happens of all time, PlayerScope:

Limiana — Today at 12:52 AM Regarding Account IDs
Even though Square Enix has stated that "identification of account IDs has been prevented," it is, in fact, not true.
Account ID still remains available in the game, and it is still possible to track all alt characters, previously or newly created.
The only change that has been made to this account ID is that it is being modified before being sent to an observer in such a way that every different observer receives different IDs.
However, these modifications are always the same for the observer's account.
For example, I may receive your ID as 555, while my friend will receive your ID as 666, but these IDs will permanently stay the same for all of your previously and newly created characters.
What does this mean?
This means that stalking plugins will continue to work with no update required in local mode.
Crowdsourced versions can continue to work slightly less efficiently or even just as efficiently as before if the developer decides to spend no more than a couple of evenings to update it.
Click to expand...

Small indie company, please understand.
 
  • Informative
Reactions: poggies123_, Weapons Grade Autism, Quoth The Raven and 3 others
Tari said:
Update on the most Nothing Ever Happens of all time, PlayerScope:
Click to expand...
Lol hey, they did the thing I said to do. They hashed the account-IDs, which is like the most basic fucking thing. Only took... nine months? To implement an incredibly basic function that's like, a line or two of code, maybe. Describing the addon as working "slightly less efficiently" or "even just as efficiently" strikes me as a total misread, though.

For two characters played by the same guy named Sneed and Chuck, I have to see both of them to see their ID as 'a55f4gg0t5' and flag that there's a relationship between them. If I never see Chuck, but someone else sees Chuck as 'n1884,' the two won't match if just uploaded to some dude's SQL database because there's nothing to link them. Before, the addon just reported all pairings, which meant that each player-ID had its own set of character IDs to add to even if you only saw one message from one character. A player now has to see the both characters, match their own hashed PID, and then report that relationship - which is orders of magnitude less efficient.
 
  • Like
Reactions: Gravemind, Xerxes IX and Lou's Sentient Backfat
Tari said:
Additionally, it's reversible. Because SE is retarded.
Click to expand...
In theory, if you get a bunch of people to make a massive collection of their own account-IDs and the hashed-IDs they see, you can reverse-engineer the hashing function such that that only variable you're guessing at is the unhashed account-ID of the other person.

The amount of work that is involved in this kind of thing would be absolutely ridiculous, and it's easily scuppered by throwing a second layer of variable into your function. For example, the first time your client uses the mute feature (or rather, the first time it sees a player message), you could snapshot the clock tick of the machine and use that as an input for a bit-shifting function to mask the hashes on a second layer. That variable would be stored server-side, used whenever the server needs to send you a hash for a player you haven't seen before. Trying to account for this would be a level of absolute insanity to try to unwind, and is far beyond trannies afraid of people finding their ERP alts.

But SE has proven they aren't particularly competent programmers or at security, so who knows. Maybe they used a very simple, very basic hashing function that can be reverse-engineered with large enough dataset analysis.
 
Flopper said:
It's been a while, but don't they have that thing that restores aether unbalancing, or whatever the fuck?
Click to expand...

more than that, Shadowbringers had literally the exact same concept, where people were suffering from an incurable progressive illness due to getting dosed with light aether, which caused them to slowly become aspected towards light and eventually turn into sin eaters. this was a plot thread that got MSQ time over multiple patches. it was the backstory behind the Matoya's Relict dungeon (Matoya helped Alisaie create a mother porxie to mass produce the little dudes to cure everybody). it wasn't a one-off side quest, or a random line of dialogue, or a lore technicality only autists care about. the exact topic of curing aether sickness was a primary part of Shadowbringer's story, ending with Alisaie finally curing the little Au Ra kid they introduced in the expansion story itself. and Dawntrail just forgot about it until a full two patches in. hilarious. they also forgot what they established as the final stage of the sickness; in DT, it's mentioned offhandedly that sufferers eventually just kind of die in bed. insane that they would forget this, one of the most memorable cutscenes in Shadowbringers:

 
  • Like
Reactions: Kane Lives and Lou's Sentient Backfat
Tari said:
Use SSS when you need to go.
Click to expand...
I do, but I basically pop it microseconds before the boss finishes casting.
If I do it as soon as the cast starts its so fucking painful to wait when you finally have a range attack ready, and with the groovy mechanic I will be forced to wait twice as much. *sigh*
 
>Add significantly more clutter to environments
>Don't consider how this might impact individual cutscenes

Lol. lmao even.

7.2 graphics update be like.jpg
7.2 graphics update be like 2.jpg
 
  • Lunacy
  • Winner
Reactions: Weapons Grade Autism and Rich Evans Ayypologist
Rich Evans Ayypologist said:
In theory, if you get a bunch of people to make a massive collection of their own account-IDs and the hashed-IDs they see, you can reverse-engineer the hashing function such that that only variable you're guessing at is the unhashed account-ID of the other person.

The amount of work that is involved in this kind of thing would be absolutely ridiculous, and it's easily scuppered by throwing a second layer of variable into your function. For example, the first time your client uses the mute feature (or rather, the first time it sees a player message), you could snapshot the clock tick of the machine and use that as an input for a bit-shifting function to mask the hashes on a second layer. That variable would be stored server-side, used whenever the server needs to send you a hash for a player you haven't seen before. Trying to account for this would be a level of absolute insanity to try to unwind, and is far beyond trannies afraid of people finding their ERP alts.

But SE has proven they aren't particularly competent programmers or at security, so who knows. Maybe they used a very simple, very basic hashing function that can be reverse-engineered with large enough dataset analysis.
Click to expand...
SuffahWhorse said:
>Add significantly more clutter to environments
>Don't consider how this might impact individual cutscenes

Lol. lmao even.

View attachment 7138845
View attachment 7138853
Click to expand...
XIV at this point is just snowballing into a cycle of "fixing what isn't broken and breaking everything more" at this point, isn't it?
 
  • Agree
Reactions: SuffahWhorse and Kane Lives
Rich Evans Ayypologist said:
But SE has proven they aren't particularly competent programmers or at security, so who knows. Maybe they used a very simple, very basic hashing function that can be reverse-engineered with large enough dataset analysis.
Click to expand...
According to some guy on reddit, here's their trick:

o1 = your own 'hidden/obfuscated' account number
o2 = other person's 'hidden/obfuscated' account id
a1 = your own account id
a2 = other person's account id
a2 = (((o1 ^ o2) >> 31) ^ a1) & 0xFFFFFFFF

All the ids are stored as bit values, so just 0s and 1s. ^ is the XOR operator, which returns 1 only if one of the values is 1 (so 1-1 and 0-0 return zero). >> is a bitwise shift, which moves the bits and changes the value, meaning for example 010 >>1 = 001 (2 -> 1). & is the AND operator, which evaluates to 1 only if both values are 1, and 0xFFFFFFFF is a hex value that is just all 1's.

Which is to say, rather than a proper hash, SE used a cipher. Which is the thing I said to do before you do the hash, but on its own - look, I don't know ciphers offhand, but cryptologists can solve those really easily by just getting large datasets where they know every answer and running them through variations of existing ciphers.
 
Tari said:
Wow, so...
This is happening because they didn't reroll everyone's pre-existing AIDs?
Click to expand...
If the formula works, which the chatter suggests it does, yes.

they didn't salt (or more dramatically just reset and re-issue) the account-IDs, so a group of people could get together, with each knowing their own account-ID key, and could solve for the rest with enough data.

If a user's own account-ID was only known serverside (and I guess ciphered the same way to the user themselves, using it as its own key?), that becomes a lot lot harder to figure out because you have both a2 and a1 to solve for.

I mean, honestly, if you just have a program that tries to solve for the outputs of various ciphers, you could just enter the four variables you already know into one and wait for it to spit the answer out. That could be done by a single person without a dataset if SE just copied one, lol.
 
Last edited:
You must log in or register to reply here.
Back