Gabriel Torok - Protecting .NET applications through obfuscation

Jason Zander invited Charles Torre and cameraman Robert Scoble to meet the .NET Common Language Runtime team.
In this first of three segments (it's a big team!) you'll meet a variety of developers from across the team and see what they are working on.
Don't know what this team does? Well, the .NET CLR is at the center of all .NET applications. So, if you're writing .NET apps, you are using this team's work.
You'll meet more of the CLR team over the next week.
leighsword wrote:Slow........
should fire all members of the CLR team ,
and replace with the MASM team.
the garbage always makes a garbage!!!
dugsnake wrote:
I don't know about you, but I don't mind waiting a week for the garbage men to come by. It's better than having to drive down to the landfill everytime I want to throw out garbage.
dugsnake wrote:
I don't know about you, but I don't mind waiting a week for the garbage men to come by. It's better than having to drive down to the landfill everytime I want to throw out garbage. Who knows, sometimes I might get lost and it may end up under my neighbors porch.
Don't fire the garbage men! Civil servants have their place in society!
leighsword wrote:the JAVA, i have fotgot to metion it.
the MS will lose many C++ programmers,because we(most of c++ programmers) are prepare turn to JAVA ,and learning it NOW.
dugsnake wrote:
leighsword wrote:the JAVA, i have fotgot to metion it.
the MS will lose many C++ programmers,because we(most of c++ programmers) are prepare turn to JAVA ,and learning it NOW.
I guess you haven't tried running JAVA apps on top of Windows lately. When I open up my Oracle utilities, I go for a cup of coffee.
leighsword wrote:
dugsnake wrote:
leighsword wrote:the JAVA, i have fotgot to metion it.
the MS will lose many C++ programmers,because we(most of c++ programmers) are prepare turn to JAVA ,and learning it NOW.
I guess you haven't tried running JAVA apps on top of Windows lately. When I open up my Oracle utilities, I go for a cup of coffee.
To choice JAVA, absolutly wanna give up the win32 platform,meaning have no choice on win32 platform.
dugsnake wrote:I see there is a cultural difference here. I can see your point.
On one side, yes, managed code running on top of CLR is slower and more restrictive than unmanaged code. What benefit do I get from using it? I don't have to worry about memory management. I know my memory is safe without any leaks. How do I solve the speed problem? I go out and buy a faster processor and more memory (obviously a very western philosophy).
On the other hand, running unmanaged code is faster and more flexible than managed code. What are the problems with unmanaged code? As a programmer, now I have to spend resources on memory management rather than concentrating on the programs purpose. As a user, I have to trust the programmer's ability to manage memory. How do you solve this problem? Pray that all programmers are good at memory management. Yes, you tweak out every ounce of performance from your hardware (a very eastern philosophy), but when Dell is selling P4 2.x GHz, 512 MB systems for less than $400.00, why bother?
Do you drive a manual transmission or an automatic? (Please don't say you ride a bike!)
leighsword wrote:
the memory management is a programmer 's job
leighsword wrote:
it also can shows the ablity of programmer
leighsword wrote:
Will you spend your money to buy a car that is slower than a bike?
if answer is yes, then i will buy that bike.
Sven Groot wrote:Also, I, like most programmers I know, am lazy.
Ovidiu.Platon wrote:Actually, you talk about automatic memory management and JIT compilation, but the CLR is about much more than that. It has a full-blown security engine (if you RTFM you can write apps that run as administrator and yet have no rights over the system), the loader and the related components are a piece of jewelry because they're one of the most advanced attempts to solve common issues such as versioning vs. ease of deployment vs. serviceability.
Then the CLR makes it possible for you to write code once and run it anywhere (x86, Itanium, AMD64, mobile devices), just in a different sense than Java. Then you can get native code-like performance with tools such as NGEN (except for the GC overhead, which is not that big actually). And there's much more to it. Great piece of software.
dugsnake wrote:Still sounds a little like a JRE though.
Comparing Java and .NET
K John Gough Stacking them up: A Comparison of Virtual Machines
, Presented to the Australian Computer Systems and Architecture Conference, ACSAC-2001 Gold Coast, Australia, February 2001 (Draft Version)
and
http://www.cl.cam.ac.uk/~jds31/research/jvmclr.pdf
Beer28 wrote:EDIT: actually, I'm sorry I asked, there's probably no way .NET gives the app access to it's managed memory. I'd think anyway, much less access control. Basically, the CLR treats it like the MSJVM and VBVM as far as access I suppose. I was originally thinking you could pin the pointer down then VirtualProtect it to rwx. I guess that would make for a bad VM though if that was possible.
Beer28 wrote:
OK, so wait a second, you are now saying the heap pages in the CLR for your app are +x ?
Beer28 wrote:
So what's stopping you from pinning down a pointer and writing a function out as opcodes to that pointed address, assuming it's also +w ?
Then you could just call the function from C++ /CLR and have the the function exec from inside the CLR with the CLR's privilages right?
Beer28 wrote:
Is there hardware page protection inside the CLR assuming you could get native code to execute in there?
Beer28 wrote:
I thought calling kernel functions on your managed pointers or memory would not work because of some type of protection. Granted I never actually tried it, but I didn't think the managed pages were +x or accessable from outside API.
Beer28 wrote:ok, so in the CLR the virtual code segment is a heap (dynamically growing) instead of a fixed paged section with RVA's as call addresses?
Beer28 wrote:
So there isn't a CS code segment offset in JIT'd code, the runtime has the CS address and runs the code in a heap like the JRE right?
Beer28 wrote:
I was under the impression that after it was JIT'd the code was loaded and run with it's own LDT and segment offsets for cs, ss, and so forth. I'm getting the impression that it's still in it's code fragments and strung together by the VM at execution time.
Beer28 wrote:
Actually, I don't wanna be any more of a pain in the butt, I'll just read the rest of inside the CLR instead, thanks
Sven Groot wrote:So if you open a file and forget to Close it, it'll be closed only when the GC decides to finalize your FileStream object, and in the mean time it's locked.
Sven Groot wrote:Even if that were to happen in the case of the file it's not so bad, because open file handles are also reclaimed by the OS when the process quits.