Hope this helps!
[0] https://github.com/volatilityfoundation/volatility
[1] https://www.andreafortuna.org/2017/07/10/volatility-my-own-c...
Hope this helps!
[0] https://github.com/volatilityfoundation/volatility
[1] https://www.andreafortuna.org/2017/07/10/volatility-my-own-c...
That said, there are plenty of legitimate (albeit low-probability) reasons for the dumping tool to screw up the service. Slightly affecting memory timing and triggering some rare race condition, using up more RAM than usual (or increasing the HDD utilization) and again triggering some conditions that wouldn't happen normally. You name it.
If it was me, I would try to run the binary on another machine and do a "clean room" recreation of the config file. That said, service without sources and missing configs without backups indicate severe organizational problems, so I would probably not want to work in such a place for a long time, unless I was hired by the CEO specifically to rectify things.
One is technical, and to do with the service and how to deal with it.
One is political, and to do with who gets the blame when the service inevitably fails.
OP needs to work out if they're being tasked with the job as the answer to the technical problem or the political problem. Because management could be very aware that this is a ticking bomb with no technical solution, and have appointed OP as a scapegoat to take the blame when it blows up.
You need to know how machine instructions work, details of the operating system, and a bunch of other things... but any number of copy-protection systems have been bypassed this way. Any number of devices have had their firmware dumped, their memory scanned, and the resulting data analyzed to make patches or build compatible systems.
Reminds me of The Phoenix Project.