CODEWITHSUNDEEP
c#.netsecurity
knurd nerd
knurd nerd

Reputation: 324

.NET understanding memory of other process / read variables from other process

I'm currently researching a subject and I honestly lack the knowledge to even be sure whether it's possible at all.

I want to find out if it is possible to understand the process memory of a .NET application when I don't have the source / the PDBs. With understand I mean if I can reconstruct an object graph if I find some starting point, like a known string value.

We want to protect a program configuration that is deserialized from encrypted config files. It is unencrypted in memory. The single values in the configuration graph aren't really secret, but the graph itself is of value.

The questionis if it is possible to reconstruct the graph from the process memory only?

Given the attacker knows how to use something like dnSpy to reconstruct the assemblies (that we protect on disk too) and that we don't want to obfuscate the config assemblies (which would require a lot of changes), can the attacker reconstruct or understand the instances based on the raw memory of our process?

I tried researching this, but I cannot find the right direction / good keywords for what I'm looking for.

I understand that tools like CheatEngine exist or that I could simply dump out the whole memory and try to make sense of that.

But I'm trying to understand if there's a .NET tool that automates the process:

  1. Read the decompiled assemblies with the config classes
  2. Attach to the process and dump the memory
  3. Make sense of the bits and bytes and combine with the decompiled classes to reconstruct the instance hierarchy

My main goal is to decide whether or not additional protection of the in memory config graph is needed. If it's not easy to reconstruct the graph, then I think it's not needed. But if it would be as easy as decompiling the source code of a .NET application, I think some protection would be required.

Upvotes: 0

Views: 229

Answers (1)

Thomas Weller
Thomas Weller

Reputation: 59218

"it is possible to understand the process memory of a .NET application when I don't have the source / the PDBs."

Yes, it is possible. In .NET there is a concept called garbage collection. The garbage collector needs to know how the memory looks like, otherwise it can't do his job. And this needs to work on customer's machines, which don't have PDBs and don't have source code.

There is a DLL called MSCORDACWKS, which is MS for Microsoft (probably), COR for .NET and DAC for "data access control" and WKS for "workstation". The DAC in this name is what you need.

Typically you don't do that yourself, but use a debugger (Micosoft WinDbg) and a .NET extension (SOS) which knows how to deal with the DAC to understand the memory.

For examples and other questions regarding these topics, see and . It is in fact very easy. Try !dumpheap -stat to get a list of all .NET objects.

The questionis if it is possible to reconstruct the graph from the process memory only?

With !gcroot you can start building an object graph, if you like.

For object graphcs, you might better look into existing tools that build such graphs, like memory leak tools such as Jetbrains dotMemory.

The single values in the configuration graph aren't really secret, but the graph itself is of value.

This could be a case to call GC.Collect() in code to force a garbe collection, so that the graph is gone. However, with a debugger it's possible to stop the process before that call.

whether or not additional protection of the in memory config graph is needed.

IMHO, yes. And implemented in a native language like C++.

Upvotes: 2

Related Questions