Hacker News Reader

Comment by pton_xd | Hacker News Reader

I've always heard that "security through obscurity" is discouraged because, well, there's no stopping someone from digging in and figuring it out. However in this case it seems somewhat successful in that the author was not able to decrypt the packets directly.

The article says that "while it might seem feasible to reimplement these functions in Python without running the client, several factors make this approach impractical" and then lists some reasons like the lookup tables changing, chunk layouts getting shuffled, etc.

Is that all it takes to thwart decrypting the packets? Even though, presumably, you have access to all those lookup tables and chunk layouts somewhere in the client? Is it just too much effort to piece together how it works? I'd be curious to hear more specifics on how exactly Riot was able to make reverse engineering this so impractical.

Great article!

View on HN

>I've always heard that "security through obscurity" is discouraged because, well, there's no stopping someone from digging in and figuring it out.

This should tell you enough about the person.

Obscurity very often increases security. The question is - by how much?

It is fine to add obscurity AS ANOTHER layer.

It is the same story as the "open source software is safer"

No. If you are open source & you have significant community then it is, otherwise closed source is harder to attack.

There's hundreds/thousands of generated one way decryption schemas for fields. However, it's not impossible to generate the decryption in another language with some effort.

Example:

A packet could be decrypted like this (the actual decryption takes more steps than this)

field1 = LOOKUPTABLE(XOR(ADD_CONST(... field2 = ADD_CONST(XOR(LOOKUPTABLE(... field3 = ADD_CONST(XOR(SUB_CONST(LOOKUPTABLE(... ...

We observe that each each operation is composed of ADD_CONST, XOR, SUB_CONST, LOOKUPTABLE and the lookup tables in the client which is ~256 bytes long.

We could extract these operations and generate a really long script in python.

Why didn't I approach it this way?

1) It's really fragile. League is an actively updated game and the decryption mechanism may change in the future. If the decryption adds another operation like MUL_CONST or DIV_CONST, I would need to account for that on my end. This is unlike the reverse engineering efforts for dead games/servers where the packets do not change.

2) I don't need to know how the decryption mechanism works. Building a game server would require decryption of packet necessary. I only need to observe game state.

As for understanding how it works, I have not put enough time/effort to give an answer. :)

> League is an actively updated game and the decryption mechanism may change in the future

Wouldn’t this render all previous replay files unusable? Is that likely to happen?

They could just also support the past methods

You can't watch a replay from the league client that doesn't match the same version.

what a blast to run into this subject on hn ..

apologies, english is not my native ..

dug into LOL more than a decade ago with a few mates to back an api/bot/site, parsing the keyframe and chunk formats within a week of spectator launch to automate timer callouts for jungle camps through fog of war due to the observer delay being less than the respawn time and so-called « auto-shoutcasting » for matches implementation when we were maybe 11 years :)

there are a number of difficulties these days (ive not played in years but work in the industry and do not touch these due to legal risk particularly REing competitor code)

from kernel anticheat being a requirement and packman before that - this article was written during covid so predates vanguard but contains packman -

legality - RE is « forbidden » - bannable so in which you do not want to lose your account in which you have spent tens of thousands of hours or more, breaking authentication and DRM flows is [DRM, auth handshake, protecteions] illegal in USA -

entire obfuscation format and flow changes with every patch; you have to repeat the work every hotfix + patch (and it isn't just a new xor key) - the re implementations would probably need to be realised every week or two - annoying - this is likely one of most tedious bits

> legality - RE is « forbidden » - bannable so in which you do not want to lose your account in which you have spent tens of thousands of hours or more, breaking authentication and DRM flows is [DRM, auth handshake, protecteions] illegal in USA

You are confused. Reverse engineering is perfectly legal in USA, but that of course is irrelevant when it comes to losing your account (which isn't yours to begin with).

I would have assumed that the changes make it too impractical to maintain.

Semi-related but the game Vindictus/Mabinogi Heroes (a Source engine MMO) changed the game archive format multiple times (and probably continues to change it every so often) because people would eventually reverse-engineer the format, dump the files, then use them in Garry's Mod or the like.

Reply on news.ycombinator.com