1

I need some starter advice here. Never done Java reverse engineering before, but I needed to somehow read the memory of a running desktop java application. The process communicates with an external server on an encrypted channel and fetches some files. The files as far as I know are Java bytecode meant to extend the functionality of the current application. I would like to know what are in those files, so I could later try to reverse bytecode to program code to get a closer look how it is to change the behavior of the application. Can you suggest a suitable debugging tool or tell me a bit about this methodology?

  • 1
    reverseengineering.stackexchange.com – julian Feb 28 '17 at 3:57
  • If you're comfortable with command line you can use jdb, it's available on most linux distros – Mr. E Jul 29 '17 at 15:01
1

I usually use the Krakatau (dis)assember https://github.com/Storyyeller/Krakatau for examining and tweaking Java bytecode files.

The only way to get code into a JVM is to implement a class loader. The bytecode that goes into the JVM is, of course, in plaintext. So, disassemble the local classes first, locate the ClassLoader and hook the ClassLoader to dump the bytecode that would be loaded to a file (and possibly, load replacement code if you want).

Good luck, and don't do this in USA, as it is probably a DMCA violation.

  • @Downvoter care to explain? – DepressedDaniel Feb 28 '17 at 20:22
  • I didn't downvote, but this doesn't really answer the question. The OP is asking how to read the memory of a running process not decompile the Java bytecode. – RoraΖ Mar 8 '17 at 19:44
  • @RoraΖ Debatable because OP said "I would like to know what are in those files [...]" so I think it's a legitimate answer to (admittedly only a part of) the question. – DepressedDaniel Mar 8 '17 at 20:50
  • I see your point, but it seems to me that the problem is getting the files unencrypted first in order to decompile. I think the OP should clarify his/her question a bit. – RoraΖ Mar 8 '17 at 21:08
  • @RoraΖ Well that's the clever part of my solution, it bypasses the encryption because you can't classload encrypted bytecode into the JVM. So at some level the main program that has to run in a standard VM has to have an unencrypted loader that can be hooked to dump the decrypted bytecodes. Then you can hook those bytecodes in case they have another encrypted classloader and so on thus defeating any manner of bytecode encryption nested to any depth. – DepressedDaniel Mar 8 '17 at 21:17
-1

Can you break the encrypted channel with a proxy (if it's HTTPS being use for encryption for example?) and install the proxy's SSL certs into your local cert store so that the process trusts the proxy? Then you can capture the data from the packets (i.e. the byte code) and go from there? This doesn't quite give you the image of what is actually running following a download but it may be enough for your purposes. If you can't do this (because it's not a proxyable protocol for example, or the process doesn't use the local cert store) then it depends on your local setup in terms of OS and level of privilege etc.

  • @Downvoter - again, care to explain? – David Scholefield Mar 2 '17 at 7:39
  • i didn't downvotet but what have this to do with the question? – Serverfrog May 29 '17 at 11:32
  • It answers the question by offering an alternative way of achieving what the OP wants - i.e. to read what's in the files sent over an encrypted channel by the server. It does't directly answer the 'how can they read the memory of a running .. app' but it does offer an alternative way of achieving the same thing if what they want to do is read the files i.e. intercept them in a proxy if possible. Just a thought/suggestion that I thought might help the OP achieve what they needed! if they don't find it useful then fair enough. – David Scholefield May 29 '17 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.