Memory Address Obfuscation in .NET Framework

Hello:
    The C Family of programming languages in the unmanaged world , are famous because of the fine grandularity of control they put under the programmer's finger tips. The lowlevel of control over memory operations made these languages attractive to many even today.
   
    But one problem is that this level of control, intoduces memory errors, that also introduce security flaws into software written using such languages. Attack vectors that exploit memory errors such as the bufferoverrun attacks, and the likes, continue to emerge everyday, and because of this , many techniques have been developed to treat the symptoms of the problem rather than the problem itself (ref StackGuard, formatguard..etc).

    The real solution that would solve these memory problems, is to obfuscate the memory address of each running program. So that each time a program is started the shape of the memory address is different. If encryption is added to this obfuscation, then all bufferoverrun problems will simply vanish. Malicious crackers, would not be able to takeover the system of their victims , and the targeted program would simply crash.

    MS, has introduced a similar system into Vista, that changes the memory address of the OS each time its started. This is really cool. But why not extend this ability into the .NET framework itself, so that all programs written in managed code (C# or VB.NET /C++) would immediately take advantage of this. It would be harder to fish for data in the memory spaces of applications.

    You might be aware that people were able to read encryption keys of software, right from memory, and this would just break security systems right there(ref AACS HDDVDs). So why not add the ability to obfuscate memory and even encrypt data contained in memory so that we end up with more secure system by design?

    I want to see support for the obfuscation in .NET framework, and for encryption of in-memory data, so that things would just become guess work for the malicious crackers out there...

What do you think about this? Would this not be a cool thing?

Thanks

Well.. ASLR could be something cool to add to the .NET Framework (if it's techincally possible). If you want to store variables safely in memory you can at least do that for string variables by using the SafeString class.

B.t.w, does anyone know how/if the .NET framework works with DEP that is now pretty much a standard CPU feature?

What's the point? The memory layout is subject to the mood of the GC and JIT, for objects and compiled code respectively.

Indeed, doesn't the GC compact objects up anyway, so they're frequently being moved around while programs are running?

Anyway, I thought .NET had eliminated buffer overrun attacks? Although you still need to encrypt data in memory to keep it from prying eyes.

You need a way to prevent people from fishing for variables in the memory space of your application, so that any vulnerability that you might have missed, would not be used effectively to hurt your customer's machines. Hence its better to obfuscate the memory space per program running.

GC could be upgraded to compensate for memory obfuscation and encryption. So things would be guess work for malicious crackers, and each time they guess wrong the application would crash and would send an error report. That is the worse they can do. And if the application crashes frequently that might indicate a cracking attempt, and can be mitigated in other ways.

Nothing, NOTHING will stop people looking at your software and your data and working out how it works if they really want to. Get it into your head and stop wasting people's time with this increadibly redundant topic over and over again.

Massif wrote:

Indeed, doesn't the GC compact objects up anyway, so they're frequently being moved around while programs are running?

Anyway, I thought .NET had eliminated buffer overrun attacks? Although you still need to encrypt data in memory to keep it from prying eyes.

This is an interesting read

rhm wrote:

Nothing, NOTHING will stop people looking at your software and your data and working out how it works if they really want to. Get it into your head and stop wasting people's time with this increadibly redundant topic over and over again.

That is a rather bold statement. If you want to surrender, by all means do. I will not. Obfuscation will make it harder, and will raise the bar.

hmm.  All interesting, but I can't help think none of this would help.  The program itself, with its' rich api, becomes the weak link.  Once you get an object ref, you can get properties, fields, and call methods.  So the objects return the data and the clr does all that background work with little gain.

SecretSoftware wrote:



rhm wrote:Nothing, NOTHING will stop people looking at your software and your data and working out how it works if they really want to. Get it into your head and stop wasting people's time with this increadibly redundant topic over and over again.

That is a rather bold statement. If you want to surrender, by all means do. I will not. Obfuscation will make it harder, and will raise the bar.

Ever heard of SoftIce?

SecretSoftware wrote:



rhm wrote:Nothing, NOTHING will stop people looking at your software and your data and working out how it works if they really want to. Get it into your head and stop wasting people's time with this increadibly redundant topic over and over again.

That is a rather bold statement. If you want to surrender, by all means do. I will not. Obfuscation will make it harder, and will raise the bar.

That's the sort of attitude the **AA are taking. They seem unable to admit their war on piracy is inherently unwinnable, there are alternative paths they could take, but that would just be seen as defeatist.

The same applies to the War on Drugs, it's just a cash blackhole with virtually nothing to show for it (perhaps even the opposite, by accidentally glamorising drugs).

The DVD-Jon guys are well under way to cracking Blu-Ray, HD-DVD is almost sorted too. So long as the memory chips themselves aren't encrypted, there is nothing you can do to prevent the debugging and research of your program. I consider it a fallacy to try to fight it. The better options are non-technical: Analyze their motives, see what's going on.

For instance, people disassembling your app to bypass the 30-day demo limitation? Use conditional compilation to remove features instead.

People wanting to find out how your program works:
a) for personal interest: leave them to it, it's just helping them understand how things work. This should never be stifled, imo.
b) for profit/gain: offer licensing options

People wanting to distribute a warez'd version: pre-empt them, build a special version of your app that's got a logic bomb in it and distribute that to the warez networks, by the time somone finds out it's got a logic bomb it's too late and it's impossible to break the high noise ratio on the warez sites to distribute the cracked version.

Have you read about Execute Disable Bit in Intel Processors? Intel says:

Execute Disable Bit: This feature, combined with a
supported operating system, allows memory to be marked
as executable or non-executable. If code attempts to run in
non-executable memory the processor raises an error to the
operating system.

Also there is Data Execution Prevention (DEP) in Windows already which work well on Intel processors.

I have tried it myself on a Pentium D processor with DEP turned ON. When any attempt to execute data in memory is made, the program crashes.

Shreyas Zare

AMD has this too (maybe even before Intel), although their implementation is called NX Bit (No Execute Bit). It works with Windows DEP.

shreyasonline wrote:

Have you read about Execute Disable Bit in Intel Processors? Intel says:

Execute Disable Bit: This feature, combined with a
supported operating system, allows memory to be marked
as executable or non-executable. If code attempts to run in
non-executable memory the processor raises an error to the
operating system.

Also there is Data Execution Prevention (DEP) in Windows already which work well on Intel processors.

I have tried it myself on a Pentium D processor with DEP turned ON. When any attempt to execute data in memory is made, the program crashes.

Shreyas Zare

If you have an old machine you might not have DEB, although you can activate it in software.

But its still has its own problems.

Charles wrote:



Read this.

C

Thanks for the link. Now Vista has something similar to this outlined in that paper. The memory address randomization happens each time you restart Vista. But its time to bring this feature in the .NET framework, so that managed programs, would be safe from memory corruption attacks or fishing attacks, independent of the plantform OS your target them for. Because .NET framework would work to obfuscate memory address and encrypt critical variables.

This is something that will effectively stop malicious crackers, because it would be guess work and not science trial and error. And the cost of guessing wrongly is that the application or the OS would just crash or restart. This blows the cover on any attack attempt and the software designers would know because of the error report that gets sent.

SecretSoftware wrote:



Charles wrote:  Read this. C

Thanks for the link. Now Vista has something similar to this outlined in that paper. The memory address randomization happens each time you restart Vista. But its time to bring this feature in the .NET framework, so that managed programs, would be safe from memory corruption attacks or fishing attacks, independent of the plantform OS your target them for. Because .NET framework would work to obfuscate memory address and encrypt critical variables.

This is something that will effectively stop malicious crackers, because it would be guess work and not science trial and error. And the cost of guessing wrongly is that the application or the OS would just crash or restart. This blows the cover on any attack attempt and the software designers would know because of the error report that gets sent.

I guess it depends on what problem your trying to solve.  Even with all that "stuff", I can still load your exe, disable CAS if needed, and call all your code like my own library and party on.  So I don't even need to start poking at memory, your app and the CLR does it for me.   Here is a very interesting watch: