I have a game, and I want to know its api request endpoints. But since it is encrypted, I need to get its key log file to decrypt it in wireshark. I tried to run my application with the command --ssl-key-log-file and it doesn't dump any SSL key logs. But if I run my browser chrome or firefox it works, it’s printing on my logs.

"C:\Games\my_game.exe" --ssl-key-log-file=%USERPROFILE%\documents\ssl\ssl-keys.log
  • 4
    Providing a SSL key log file is an explicit features of browsers, i.e. it is not a generic feature of everything which uses TLS. Specifically games usually try to make reverse engineering harder, so it is unlikely that such functionality is provided by the application in the first place. Nov 5, 2021 at 1:28

2 Answers 2


To expand on @MechMK1 point "depends on your skill level"

What this means is it is possible, while non-trivial the means is quite simple to explain in a SO answer and not easy to do in reality.

While TLS is designed to have all data readable by endpoints including any 'endpoint' you add into a communication channel, it is important to realise that TLS endpoints are designed to prevent packet modification.

To put it another way, TLS connections being sent to a server you do not control, from a client you do not control, must maintain integrity of the packet. The data the receiver (server) processes must be cryptographicly verifiable to be complete unmodified from the packets the sender (game) actually sent.

Now we have described TLS is designed for integrity, as mentioned above TLS is not designed for confidentiality. I.e. if you add a network device (like security devices) into a communication channel, it is possible by-design to read the contents of all TLS traffic (with a few caveats).

The hardest one is TLS1.3; This uses ephemeral keys negotiated by both the server and teh client, i.e. before every communication a server generates a public key using a private key it has that never leaves its endpoint (so you never see it on a client side), then the client generates a public key using it's own private key that never gets sent to the server and uses the server public key to encrypt the client public key and send it to the server. The server (and only the server) now can decrypt the client public key using it's own server private key. This means the client public key is used to encrypt the data for this communication in such a way that the client using it's own client private key can decrypt the server sent data.

As an 'endpoint' for TLS1.3 you must have some way to access a server private key and a client private key, this is how security devices must operate, and are able to do eavesdropping for security purposes.

The next communication will have to do this exchange again, ergo ephemeral key exchange. And this is the only option for TLS1.3

A simplified description of TLS1.3 key logging, i.e. not only done on a client.

Now the next one is TLS1.2; This will depend on the cipher negotiated. If a cipher that uses ephemeral keys is used the TLS1.3 is also an appropriate summary.

Other ciphers will allow you to symmetric cryptography which means a shared session key is used, for browser they're typically stored to:

  • Windows: C:\Users<user>\Desktop\sslkeylog.txt
  • Mac: /Users//sslkeyfile
  • Linux: /home//sslkeyfile

Some ciphers used for TLS1.2 and earlier TLS versions even allow what are called null ciphers, again not trivial but these essentially permit eavesdropping with far less complexity.

The most interesting caveat is some servers will allow you to force the use of certain ciphers, even allow you to negotiate from the client a lower TLS protocol.

The last caveat is some servers are misconfigured, or as I like to point out, configured for optimisations of insecurity. I.e. even with TLS1.3 is it ubiquitous (not just common, more common than common) to see symmetric session keys in use, because it is faster but makes eavesdropping possible in TLS1.3 when the entire reason for TLS1.3 to exist was to avoid shared secrets entirely.

I don't like to shut down people who ask questions and tell you that you're lacking fundamental knowledge, because this is Stack Overflow and answering those types of questions is entirely the point of this community. I encourage you to take the above topics and do your own investigations and please ask more questions on Stack Overflow as you progress on your learning journey, don't be discouraged by the previous answer that is not what this community is about.

  • Good answer and I'm glad that you addressed that other, high and mighty, answer. Nov 13, 2021 at 15:49

You cannot just provide random command-line arguments and expect applications to do what you want them to do. That's not how programs work.

Browsers explicitly include features to dump key material in order to aid in debugging. Someone wrote code that parses this specific command-line argument and implemented logic in the browser to write key material to a file.

If an application isn't written to be debugged by the end-user, then you can pass random command-line arguments until the end of days and you still won't get the program to dump key material for you.

But what can I do then?

That depends on your skill level - in other words, there is no easy answer. Given that you fundamentally misunderstand how programs work, it's safe to assume that debugging possibly obfuscated assembler code is out of the question. You could try setting up a transparent reverse proxy and hope that the server certificate isn't hardcoded into the application. If it is, you'd likely have to use virtual patching to exchange it without the changes being permanent - but hooking into the process could trip up their anti-cheat.

In simple terms: How do you dump the SSL keys? You don't.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .