dump ecfs dump file format from ram with volatility

[gogo2464]

Is your feature request related to a problem? Please describe. I am currently trying to run back in a securely protected vm a rensomware ram caught by volatility in order to find back the encryption key. Sadly the windows .dmp files do not permit to restart the process yet.

Describe the solution you'd like As mentionned in this other repository: https://github.com/elfmaster/ecfs/blob/master/README#L47 there is already a file format for this need that does it for Linux (my ransomware is on windows). I suggest to write it for this Linux format first. Then I will do something similar for windows. Volatility should be able to extract each ecfs files from ftk imager or any imager.

Describe alternatives you've considered -rerun a .dmp file (useless because it does not contain the informations about the variables in the state of the program).

Additional information I have already oppened a similar feature request at this address: https://github.com/volatilityfoundation/volatility3/issues/871 During this period I did not really knew how to do it. I have a better idea now.

Here is a similar issue that describe the problem: https://superuser.com/questions/904441/possible-to-save-process-as-dump-file-to-disk-and-then-reload-the-process-later

[ikelos]

I'm afraid I still don't understand why the process needs to be able to run again? It is possible to acquire memory whilst a process is running, and have it continue running after the acquisition has happened. It sounds as though what you're trying to do is find where in the process the encryption key is stored? You could do that from a complete memory dump and then write a program that could find that within the memory of a running process at any time. This is a far simpler task than trying to restart a terminated process.

The ECFS file format sounds interesting, but as the authors in the dmtcp bug you mentioned state, the tool doesn't work on windows, so it sounds as though you're asking us to write something that reads from a memory image, extracts all the necessary information about a process and stores it in an ECFS container? I feel that is a significant task and has a very specific use-case, so is unlikely to be a priority for the volatility team.

I would recommend you re-examine what you're trying to achieve and whether it really requires restarting a process, or simply not stopping the process in the first place? I have marked this as an enhancement and as low priority, we're happy to accept code contributions but are unlikely to pursue this specific goal without a more significant drive to include the support.

[gogo2464]

I'm afraid I still don't understand why the process needs to be able to run again?

I want to be able to debug an existing process catched by volatility. As you told it could be use-full to extract malware encryption/ransomware key. You mentioned we could already read hardcoded values or disassemble process. It sounds a lot of more convenient and faster to resume the process in his state because we could debug it, put a breakpoint and then run a decompiler. This way is particulary effective for #C malwares. Thank you very much for trying to understand what I want to do. It is much more friendly than just letting me writting the ecfs dumper :).

I feel that is a significant task and has a very specific use-case, so is unlikely to be a priority for the volatility team. I have marked this as an enhancement and as low priority, we're happy to accept code contributions but are unlikely to pursue this specific goal without a more significant drive to include the support.

It sounds perfect to me. I just wanted to ensure that the main contribution could be merged in case I successfully make an encouraging PR. I will start with easier and tinier contribution. Of course if it could help the community, it sounds a great plus! Any opinion is welcome about this point.

[ikelos]

I want to be able to debug an existing process

Debuggers can already do this

I want to be able to debug an existing process catched by volatility

Why does it have to be caught by volatility? Is it not visible with normal windows APIs? Volatility can probably be used to extract the encryption ransomware key from a memory sample where it is running, and you can take memory samples without having to stop processes, but it will require a lot of analysis to find the location and properly read the key.

You mentioned we could already read hardcoded values or disassemble process

We can read hardcoded values if you know where to look but finding the value you want to read requires a lot of work (which is what you'll need a debugger for if you want to do dynamic analysis rather than static analysis).

It sounds a lot of more convenient and faster to resume the process in his state because we could debug it

If you can see the process you want to debug, you should be able to apply the debugger to it, but there will likely be anti-debugging techniques applied to make that task difficult.

It is much more friendly than just letting me writting the ecfs dumper

Please don't misunderstand myself or the ecfs developers. What you're asking for (starting of processes) is a huge task that hasn't been accomplished yet for good reason. The developer was telling you that they think it's a big task and asking an open source developer to expend their energy on a specific goal you have isn't really how open source works. If you have the drive to do something, then you'll need to be the one that does it, but you can get help and support from the authors, particularly once you demonstrate that you're willing to put in effort/contribute code to achieve the goal. They will not just write what you ask them to, they have different priorities, it's up to you. The volatility team is the same (note in my previous reply: I feel that is a significant task and has a very specific use-case, so is unlikely to be a priority for the volatility team). Please don't feel poorly about the ECFS developer, or expect a significant degree of code written by the volatility team to help with your individual requirements.

I strongly advise you to stop including the need to restart a stopped process in your request because both myself and the ECFS developers have told you that it's a huge undertaking if it's even possible at all. Including it is what's likely to get your requests ignored or closed as being unrealistic. There are many complexities that both myself and the ECFS developer have tried to communicate to you. Instead, I would focus on determining which process you need to attach to with a debugger, and statically looking at the malware to figure out where you'd want to set the breakpoint. These are far easier goals and achievable with the currently available tools. Malware analysis is not easy, malware authors include anti-debugging techniques specifically to stop dynamic analysis (as well as tricks to make static analysis more difficult). There is no simple solution or easy tool to help you with that.

We'll be happy to review any pull requests you may have, and we'll help review them to get their quality to the level that would be needed for us to pull them into the project and maintain them. Please note that there is no guarantee that the project will accept your changes, but I can at least assure you that we'll review them. If you apply them as a branch to a fork of this repository then at least the work will be available to others even if it doesn't get included in the main project. That way if it's useful to someone else they can continue developing on it.