5 ms·

From the article: > I had found a way to obtain a privileged access token within the environment (a story for another day, but a certain game's executable had

From the article: > I had found a way to obtain a privileged access token within the environment (a story for another day, but a certain game's executable had hardcoded credentials!), but I wasn't sure what I could do with it. Can someone speak to this a bit more? I'm under the impression an executable binary shouldn't be easily read to find such credentials, and I don't know what else a game dev is supposed to do if their executable needs to authenticate itself with a remote server.

hobs 2y ago
The strings command is pretty old can do it if you're naive enough to embed a username and password into the game client. The main thing is that its privileged - having a token shouldn't let you do anything besides say, report your game stats to a central server or enumerate the server lists, things like that.
- NikkiA 2y ago
  TBF strings might not trivially show up the password if you took the most basic of provisions (a non-ascii password, not stored right next to the username separated by a \0), but most programmers likely wouldn't even bother with that.
  - nijave 2y ago
    Even then you can MITM if you have elevated access to the platform and can tinker with the certificate store. Games like Pokemon Go use a highly obfuscated algorithm to sign requests which makes it much harder to actually use the key if you can retrieve it
NikkiA 2y ago
> I'm under the impression an executable binary shouldn't be easily read to find such credentials Why would you assume that? binaries are perfectly easily readable on non-locked-down platforms. You'd have to have a system where the executable is encrypted and a secure part of the CPU die handle decryption against a private key, and even then it'd probably be only a matter of time before someone delidded the chip to get the key.
- jfactorial 2y ago
  > Why would you assume that? I thought too highly of modern compiler string literal obfuscation.
  - nijave 2y ago
    Consider the string needs reversible obfuscation or it won't be usable. The only secure way is encryption but you'd need to properly secure the key (probably using some hardware facility that's physically locked down)
  - johnny22 2y ago
    If they used any open or even popular compiler, then that wouldn't solve anything. Folks would have already figured out how it works, since such encoding would have to be deterministic.
  - CyberDildonics 2y ago
    What obfuscation? Do you think that is happening automatically? If you compile literals into your program they are sitting in the data section of your binary verbatim so they can be read directly once the binary itself is memory mapped.
  - mmsc 2y ago
    > modern compiler string literal obfuscation the what now?
    - mschuster91 2y ago
      There's at least one plugin for LLVM to obfuscate strings from binaries [1], and for Android there is DexGuard [2]. The general idea is to make life as difficult as possible for reverse engineers, crackers and whomever else - hardcoded stuff just showing up in "cat .binfile | strings" is about the first thing I do when investigating some random stuff, and there's tools like binwalk that can automatically do stuff like extracting PEM certificates and other easily identifiable content. Of course they can all be reverse engineered by hand, if you figure out the scheme used you can write yourself an IDA or Ghidra plugin/script to automate the process - which assumes that the method doesn't (subtly) change between different builds of the target. Or you can attempt to intercept memory accesses of the application. But that's tedious, annoying and complex busywork that no one really wants to do. [1] https://github.com/tsarpaul/llvm-string-obfuscator https://github.com/tsarpaul/llvm-string-obfuscator [2] https://www.guardsquare.com/dexguard https://www.guardsquare.com/dexguard
rubendev 2y ago
If the program has access to the credential, and the program is running on your computer, you also have access to the credential no matter how they try to obfuscate it. What the game dev is supposed to do is have an account system on their backend, and ask the player to enter their credentials in the game. The game can then identify itself as this player to the backend servers. That way any actions on the backend can be attributed to a particular player and you have a good basis to make security decisions on.
- deleted 2y ago
  [deleted]
nijave 2y ago
The credentials are stored as a string so you can search the binary for a pattern matching what the credential looks like and it will be in there somewhere. In client server architecture, the client is always untrusted. An executable shouldn't need to authenticate itself to the server. The executable should authenticate as a user or account using details provided by the person. In cases like telemetry these endpoints usually accept unauthenticated or lightly authenticated data and perform layers of validation to prevent abuse (and are usually write/append only)
gruez 2y ago
>I'm under the impression an executable binary shouldn't be easily read to find such credentials It's hard but not impossible. It's more annoying than trying to extract strings out of a minified js file, but far from impossible. There are tools for it (eg. IDA), so you're not searching for credentials amongst anything that vaguely looks like a string. >and I don't know what else a game dev is supposed to do if their executable needs to authenticate itself with a remote server. The problem isn't that that the binary has hardcoded credentials, it's that the credentials are privileged.
feoren 2y ago
> I'm under the impression an executable binary shouldn't be easily read to find such credentials If the computer can read it, and you have full control of the computer, then you can read it. Physical access is game over. Even if they encrypt it and put the encryption key in an HSM (probably not possible on an arbitrary client's machine anyway), at some point the game is going to decrypt that string and put it in memory. Memory that you can read.

hobs 2y ago

The strings command is pretty old can do it if you're naive enough to embed a username and password into the game client. The main thing is that its privileged - having a token shouldn't let you do anything besides say, report your game stats to a central server or enumerate the server lists, things like that.

NikkiA 2y ago
TBF strings might not trivially show up the password if you took the most basic of provisions (a non-ascii password, not stored right next to the username separated by a \0), but most programmers likely wouldn't even bother with that.
- nijave 2y ago
  Even then you can MITM if you have elevated access to the platform and can tinker with the certificate store. Games like Pokemon Go use a highly obfuscated algorithm to sign requests which makes it much harder to actually use the key if you can retrieve it

NikkiA 2y ago

> I'm under the impression an executable binary shouldn't be easily read to find such credentials Why would you assume that? binaries are perfectly easily readable on non-locked-down platforms. You'd have to have a system where the executable is encrypted and a secure part of the CPU die handle decryption against a private key, and even then it'd probably be only a matter of time before someone delidded the chip to get the key.

jfactorial 2y ago
> Why would you assume that? I thought too highly of modern compiler string literal obfuscation.
- nijave 2y ago
  Consider the string needs reversible obfuscation or it won't be usable. The only secure way is encryption but you'd need to properly secure the key (probably using some hardware facility that's physically locked down)
- johnny22 2y ago
  If they used any open or even popular compiler, then that wouldn't solve anything. Folks would have already figured out how it works, since such encoding would have to be deterministic.
- CyberDildonics 2y ago
  What obfuscation? Do you think that is happening automatically? If you compile literals into your program they are sitting in the data section of your binary verbatim so they can be read directly once the binary itself is memory mapped.
- mmsc 2y ago
  > modern compiler string literal obfuscation the what now?
  - mschuster91 2y ago
    There's at least one plugin for LLVM to obfuscate strings from binaries [1], and for Android there is DexGuard [2]. The general idea is to make life as difficult as possible for reverse engineers, crackers and whomever else - hardcoded stuff just showing up in "cat .binfile | strings" is about the first thing I do when investigating some random stuff, and there's tools like binwalk that can automatically do stuff like extracting PEM certificates and other easily identifiable content. Of course they can all be reverse engineered by hand, if you figure out the scheme used you can write yourself an IDA or Ghidra plugin/script to automate the process - which assumes that the method doesn't (subtly) change between different builds of the target. Or you can attempt to intercept memory accesses of the application. But that's tedious, annoying and complex busywork that no one really wants to do. [1] https://github.com/tsarpaul/llvm-string-obfuscator https://github.com/tsarpaul/llvm-string-obfuscator [2] https://www.guardsquare.com/dexguard https://www.guardsquare.com/dexguard

rubendev 2y ago

If the program has access to the credential, and the program is running on your computer, you also have access to the credential no matter how they try to obfuscate it. What the game dev is supposed to do is have an account system on their backend, and ask the player to enter their credentials in the game. The game can then identify itself as this player to the backend servers. That way any actions on the backend can be attributed to a particular player and you have a good basis to make security decisions on.

deleted 2y ago
[deleted]

nijave 2y ago

The credentials are stored as a string so you can search the binary for a pattern matching what the credential looks like and it will be in there somewhere. In client server architecture, the client is always untrusted. An executable shouldn't need to authenticate itself to the server. The executable should authenticate as a user or account using details provided by the person. In cases like telemetry these endpoints usually accept unauthenticated or lightly authenticated data and perform layers of validation to prevent abuse (and are usually write/append only)

gruez 2y ago

>I'm under the impression an executable binary shouldn't be easily read to find such credentials It's hard but not impossible. It's more annoying than trying to extract strings out of a minified js file, but far from impossible. There are tools for it (eg. IDA), so you're not searching for credentials amongst anything that vaguely looks like a string. >and I don't know what else a game dev is supposed to do if their executable needs to authenticate itself with a remote server. The problem isn't that that the binary has hardcoded credentials, it's that the credentials are privileged.

feoren 2y ago

> I'm under the impression an executable binary shouldn't be easily read to find such credentials If the computer can read it, and you have full control of the computer, then you can read it. Physical access is game over. Even if they encrypt it and put the encryption key in an HSM (probably not possible on an arbitrary client's machine anyway), at some point the game is going to decrypt that string and put it in memory. Memory that you can read.