No secrets log being generated (but appears to be attaching)

[trittimo]

So I'm a little puzzled. I have a Java jar file that I want to debug. I am launching it with the following command:

java -javaagent:"extract-tls-secrets-4.0.0.jar=secrets.log" -jar MyApp.jar

I have put the extract-tls-secrets jar file in the same directory as my jar file, and am launching it from that directory as well. I see the jar launching as follows:

OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
Aug 05, 2022 7:56:45 PM name.neykov.secrets.AgentMain main
INFO: Successfully attached agent C:\Users\MyUsername\Documents\Programming\MyAppDir\target\extract-tls-secrets-4.0.0.jar. Logging to C:\Users\MyUsername\Documents\Programming\MyAppDir\target\secrets.log
...
More logs from the jar I'm trying to analyze

However, there is no secrets.log file getting generated in that directory. I've also tried sending the secrets.log file a few other places just to see if it made a difference but have seen none.

I know for a fact this jar is communicating with TLS because I can see the encrypted traffic in Wireshark.

Just to see if there was any additional information getting logged, I also tried launching as follows:

java -D"java.util.logging.config.file=logging.properties" -javaagent:"extract-tls-secrets-4.0.0.jar=secrets.log" -jar MyApp.jar

I added a logging.properties file with this content:

handlers=java.util.logging.FileHandler
java.util.logging.FileHandler.pattern=debug.log
java.util.logging.FileHandler.limit=50000
java.util.logging.FileHandler.count=1
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.FileHandler.level=FINEST

This produces the following debug.log file in the launch directory:

Aug 05, 2022 7:54:49 PM name.neykov.secrets.AgentMain main
INFO: Successfully attached agent C:\Users\MyUsername\Documents\Programming\MyAppDir\target\extract-tls-secrets-4.0.0.jar. Logging to C:\Users\MyUsername\Documents\Programming\MyAppDir\target\secrets.log. 

And that's all that ever gets written to the log file. My jar file is threaded, but I wouldn't at all expect that to be an issue since I've used this before to debug a Tomcat app. Any ideas on where I can go next?

[neykov]

Thank you for the detailed report @trittimo.

Nothing obvious comes to mind, so a few of guiding questions:

• Which Java version are you using?
• Could the jar be using some non-standard encryption library?
• Is that HTTP requests or TCP communication?

[fancywriter]

@neykov same thing is happening for me. This tool says "successfully attached to process XXXX" and exits without creating any file with any keys.

I did some research and found out that this java app uses Apache HTTP client 4.5.2 and JRE-1.8.0_66.

UPDATED: I was wrong, seems it works... but I was confused by wrong path.

[neykov]

@fancywriter could you provide some more details on the relative path - what didn't work and what worked for you?

[fancywriter]

@neykov I have attached logging.properties similarly how @trittimo did, and I see that it creates file when I do it like this

-javaagent:extract-tls-secrets-4.0.0.jar=secrets.txt

However, it doesn't work with absolute path on another Windows drive letter (sorry, I have to use Windows here, because app is not really portable, though is written on Java)

-javaagent:extract-tls-secrets-4.0.0.jar=A:\secrets.txt

It says

java.io.FileNotFoundException: A:\secrets.txt (The system cannot find the path specified)
	at java.io.FileOutputStream.open0(Native Method)
	at java.io.FileOutputStream.open(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileWriter.<init>(Unknown Source)
	at name.neykov.secrets.MasterSecretCallback.write(MasterSecretCallback.java:76)
	at name.neykov.secrets.MasterSecretCallback.onCalculateKeys(MasterSecretCallback.java:42)
	at sun.security.ssl.Handshaker.calculateConnectionKeys(Unknown Source)
	at sun.security.ssl.ClientHandshaker.serverHello(Unknown Source)
	at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
	at sun.security.ssl.Handshaker.processLoop(Unknown Source)
	at sun.security.ssl.Handshaker.process_record(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
	at sun.security.ssl.AppOutputStream.write(Unknown Source)
	at sun.nio.cs.StreamEncoder.writeBytes(Unknown Source)
	at sun.nio.cs.StreamEncoder.implFlushBuffer(Unknown Source)
	at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)
	at sun.nio.cs.StreamEncoder.flush(Unknown Source)
	at java.io.OutputStreamWriter.flush(Unknown Source)

Which doesn't make much sense, it has to create file and the root directory of A: exists.

[fancywriter]

What's weird, that from any java app (if I do one-liner doing nothing, but opening the file) it works fine. For example, either new FileWriter("A:\\secrets.txt", true) or new FileWriter("A:/secrets.txt", true) work just fine. But, for example, new FileWriter("B:\\secrets.txt", true) doesn't (I don't have drive B, I have only A which is network and C which is system). Could you try to reproduce it?

[fancywriter]

Oh... I have found root cause of why it happened. Sorry. It has nothing to do with Java or your lovely app. This is how Windows works. :facepalm:

The network drive A: is accessible for non-admin user, but not accessible for admin user... The app is run by admin. That's why it "doesn't see" drive A.

So looks great. Thanks again for amazing tool!

[neykov]

Thanks for digging into this @fancywriter.