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?

2
  • 1
    reverseengineering.stackexchange.com
    – julian
    Feb 28, 2017 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, 2017 at 15:01

2 Answers 2

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.

6
  • @Downvoter care to explain? Feb 28, 2017 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, 2017 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. Mar 8, 2017 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, 2017 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. Mar 8, 2017 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.

3
  • @Downvoter - again, care to explain? Mar 2, 2017 at 7:39
  • i didn't downvotet but what have this to do with the question?
    – Serverfrog
    May 29, 2017 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. May 29, 2017 at 15:31

You must log in to answer this question.

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