Slashdot Mirror
Morphing Code to Prevent Reverse Engineering?
ptolemu writes "Cringely's latest article discusses a new obfuscation technique currently being researched called PSCP (Program State Code Protection). An informative read that concludes with some interesting insight on the software giants that heavily depend on this kind of technology."
I've done mostly server-side work where:
- the jar files were secure because they were on the server and
- bytecode optimization and jar size was the least of our problems
Obfuscation seems to be useful only for client-side Java applications that contains super-secret valuable algorithms. I mean, who cares if somebody decompiles your code to see how you did sortable JTables or whatever?
The Army reading list
This technique might be interesting for stopping people from stealing your closed source code, but as far as security goes it's pretty much worthless. 99% of the vulnerabilities in MS's code were found before their code was leaked, and if you believe them, even the major exploit found after it was leaked had more to do with bad code than someone finding the existing problem by reading the code.
Don't blame me; I'm never given mod points.
Form of, illegible code.
Shape of, encrypted executables.
Not sure where the monkey fits into all of this.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Just name all of your variables in Hungarian notation like Microsoft. No one will have any idea what the fuck is going on even if your entire source code leaks.
So you code in Perl too, eh?
The medical profession deals with viruses by identifying our weaknesses, and exposing them to the viruses (the ultimate "reverse engineering"?). If there were a biological DMCA, developing vaccines would certainly violate it on the illegality of "hacking into the body".
With software, though, people still insist on trying hide and pretend as if there were no viruses out there and that we would be impervious to them.
Can we finally just open all of our code so we can vaccinate it against all these exploits?
This looks vaguely like self-modifying code, like back in the old days of copy protection.
.net runtime engine (or maybe it's loaded and spews bytecode to the runtime), then it can be removed...or the output intercepted. .
The thing I don't understand about the article (and how it describes the PSCP process) is this: how will this make reverse engineering more difficult?
When you're starting to crack something, you work backwards from system calls, library calls, and known behaviors. "Known behaviors" are, well, patterns of code that people (or compilers) use to do things. Anyone good at low-level stuff can probably identify the compiler used to build the code. Likewise, if you think about something enough, you can probably figure out three or four ways to do something, and look for that pattern in the code.
PSCP prevents this...how? By making this process happens as the program runs? How else do you reverse engineer something?
Anyway, it sounds like this thing sits right before the
What am I not getting here?
Just like all the hubbub over proprietary signal encryption to "protect" digital audio streams, all you need here would be the CPU-equivalent of the old Analog Out jack.
Break it down to the Universal Turing Machine and tape analogy. The program code is the tape, and the state of the machine is in the tape-executing device. If the tape were to somehow morph itself dynamically, and yet execute properly by morphing to a well-designed program at the moment it is read for execution, all you have to do is to watch the read/write head of the UTM itself.
If they find ways to monkey around with bytecodes so that they're shifted around between disk and executor, just run it with a special version of the executor. Shouldn't be hard... the standard for what the unencrypted bytecodes are capable of accomplishing are standardized. Execute the code once, and take "notes" of what is being accomplished. Run through a code coverage test suite, even a crude black-box analysis, and you should get an unscrambled bytecode equivalent.
It just doesn't make sense. If obfuscation, i.e. obscurity, is your only security, it is no security at all.
[
Cringely has really outdone himself that time. I can't even follow this poorly thought out mess. He seems to totally misunderstand every single concept he touches on.
Compilation to bytecode and an "interpreted language" are NOT THE SAME THING. Both the CLR and a compiled java class are effectively machine code for a machine that doesn't exist. These abstract machines have machine code that reveal *MORE* information to a disassembler/reverse engineer than, say, x86 or PPC assembly, but it is still far, far from being code. This is reaction one that I have. The rest of the article is so confused I don't even know how to respond to it.
how come for every new technology that comes out that is suppose to "secure" us i can think of a way it can be used "malicously"
.NET is so "young" can't you see this used for creating a perpetual virus that can't be removed? you wouldn't even be able to ID the bug that caused this to virus to run itself.
ex. I write YourDoom.A and i write it using this new code morphing obfuscator. how exactly are Anti-virus programs 1. suppose to remove this? 2. identify this?
Given the numberous amount of VB/Outlook bugs and considering that
When a computer program runs, the computer can follow millions of paths to get the job done. We leverage those millions of paths and transform them into billions of paths instead
Millions of paths implies some sort of jump instruction, whether or not that translates to millions of function calls, i don't know. assume it does. then instead of making millions of function calls, your making billions of function calls. Going from millions to billions is a large step, bigger than just swapping an "m" for a "b" in marketingspeak. So are they planning on passing this performance hit to the legitimate consumer? No thanks, I'll take my Free source code and like it.
Would code that was changing itself while running (polymorphic) be nailed by a heuristically-scanning anti-virus program? I would hate to de3velop something, and then all of a sudden get seriously bad press for releasing what seems to act like a virus. Just food for thought.
So legitimate software is going to take on the functionality that virus software has been using for years? And companies are patenting these techniques as if they are somehow new? Virus writers are the true innovators here. They pioneered the infamous Mutation Engine. I would consider off the shelf software that used those techniques innovative, in fact I find it creepy. Honestly, if the time wasted trying to protect so-called intellectual property was used instead to invent things to simplify our lives, we (as in humanity) would be better off.
Ok, I tried that. It really works.
In fact, it obfuscated my Python code so badly even the interpreter couldn't figure out what the hell it meant.
Maybe I need to improve my Hungarian.
KFG
Yet, I have no doubt that if someone came up to them and warned them about the dangers of IP theft and showed them this solution, they would bite.
If they really wanted to do maximum damage to their competition they should have just released the source code and hoped their competitors tried to used that as guidance.
There are probably some rare instances when a specialized software technique is developed and you want to keep its implementation specifics secret. I have yet to run into a single instance of this after many years in the industry.
Sure, you can reverse engineer it. But is it worth the effort?
Most of the time it's not even worth reverse engineering unencrypted code, because it's really hard. There are open source projects that go undone because people don't want to expend the effort.
The trick is not to make it impossible, but to make it hard enough that it isn't done. That level is different for different projects, but it's always finite.
There is nothing new under the sun. These Java and .NET obfuscators are just the same old anti-SoftICE sections, which were just the same old Amiga/Atari copylocks, which were just the same Spectrum/C64 turboloaders, and so on.
Every single one of these is broken. Almost all good programmers are capable of deciphering the standardised, retail-boxed algorithm used for the obfuscation, and can easily un-obfuscate it. Are all the Java variables named "a"? Diddums! You don't have a Java decompiler with the option to ignore that simple tweak.
All that matters is:
1) How important is the code behind the obfuscation?
2) How much time and effort is the reverse engineer willing to spend?
If you use a company's retail-box obfuscator, anyone with the "'Brand X obfuscator' deobfuscator v1.0" can get straight at your code. It's a technological arms race, nothing more.
Does my bum look big in this?
I don't love microsoft, but I think this article makes several claims without backing them up or offering any explanation as to their merits. Such as:
And "You can write a program in C# or Visual Basic.NET." while factually accurate, ignores Delphi.NET, C++ managed code using the CRL, and other implementations of the CRL (COBOL, etc).
I think the basic premise of the article, where if someone is using your objects it is obviously a bad thing/security breach, is flawed. If you need to secure your objects, SECURE them! Seal them, see who is calling you, etc.
Lastly, As shown by previous posts, Obfuscation is not the end-all panacea to security. In my opinion, it's barely a detour. Otherwise, Open Source literally could not be secure.
If you blog it...
You're a asuming that there is a Microsoft way to look at code and that every MS developer is a robot brain washed to think that way. MS hire very capable and brilliant people, you couldn't tell the difference between a bunch of NT kernel hackers and a bunch of Linux kernel hackers, both groups are extremely knowledgeable and manufacture high quallity code.
MS has the biggest industrial infrastructure in the world of quallity assurance. Every developer should go trhough an internship in Redmond to see this.
Large software *is* complex, period. Given a finite amount of talent and time, bugs are depedent of the size of the project, it really don't make a difference whether you're code is open source or not.
How many people do you think actually look at open source code to look for bugs?
Moral: if MS releases buggy, exploitalbe and potentially unsafe code is *not* because they are sloppy or because propietary code is inherently worse than open source, is because large software is complex and takes a lot of time to do it right.
If it changes how it executes every time, it sounds like it would be a fantastic way to introduce unreproducable bugs.
I'm sure this would make QA testing a nightmare.
"He's lost in a 'floyd hole"
I remember a primitive attempt at this in the copy protection routine for dBase III way back when the DMCA was but an industry wet dream. This was the ProLok Disk, the one with the laser burn.
There was a section of code hidden by about forty layers of byte-by-byte XORing against bytes looked up in a table. At each level, it would intercept the Debug and Single Step interrupts, XOR the next layer, and jump into it. In those floppy-only days, it had to be reverse engineered a layer at a time, each step producing a disk with one less layer. Approximately the 40th disk had the actual copy-test code...which turned out to be pirated code!
This was also before BIOS shadowing in RAM, and the BIOS executed straight from ROM. The test for the laser burn required hooking into it, which of course they couldn't do in ROM. Instead of working out their own shadowing routine they copied some 700 bytes of the IBM Fixed Disk BIOS, inserted their hooks, and then made a weaselly attempt to cover their tracks by interchanging logical-shift with arithmetic-shift instructions wherever it was guaranteed that nothing would go through the carry bit.
And all that meshugass was there only to hide the publisher's own piracy...the copycrack consisted of a two-byte change elsewhere on the disk.
rj
Well, that seems a bit simplistic. However, when I take a look at running code, there are several things that don't jive with the article:
.NET framework itself in a sandbox. You watch as the OS is fed an EXE, it identifies the type and starts to run it. The CLR (potentially) starts up and checks permissions, loads all the JIT stuff, etc. Then, bytecode is churned. You are stepping one instruction at a time, interrupting at each of the CLR's instructions. One notices the buffer used for the JIT and the "feed" going into it. Tools are written that do this watching and drop items (portions of files, by instruction) into logical "components" and each pass becomes a little clearer. By running the application and matching behavior to component, you begin to learn how the application is designed.
.NET can be both "open" and yet "secure". Unless the bytecode SPEC is proprietary and unable to be reverse engineered (it is neither, hence the "open" nature of it), one can form a CLR that processes valid-yet-obsfucated code and rebuild a logical image of how the program is designed. I can take the MONO bytecode runtime have it start to partition the code into blocks and examine, for the calls each block makes to layer beneath it, what it is allegedly doing.
One forms logical boxes around things. For instance, a good cracker knows to identify the boundary between the JIT and the bytecode, know where the security check call is made, and what threads are monitoring the heap and garbage collector.
When cracking, you initially "freeze" the code, the machine, the stack, and the registers. You're working at such a low level, it begins with a step-by-step of understanding how everything fits together.
For example: Imagine the
Also, you look at the program file itself. THIS is what the article seems to be saying: the bytecode is obsfucated...without context clues you're not going to discern how it works. But you can snap up context many times with a cracking tool. In this article, they seem to imply that each snapshot will be different by scrambling the variable names, or program locations. By seeing how all the names have been crammed, a pattern develops.
Also, I take issue that
Lastly, what makes these tools immune from reverse-engineering themselves? If I know the patterns this DASH-stuff uses, I can begin to reverse them. Unless there's one-way hashing or hardward/networked keys flying around, everything to solve the puzzle is right there, for me and my friends to examine at our leisure. This is done today by virus writers to try to avoid detection by checkers; they know how they work.
If this tool becomes actually as valuable as he claims, then I expect it's own design (stolen or RE'd) to appear in the cracker circles like any other.
But perhaps I'm missing something?
>>delete all the white space, and comment in Hungarian
Ha, you laugh. At my first job, the documentation for our product (a medical management system) was written by the original software developer - who was Hungarian. Screen after screen, there were pages filled with explanations like this:
LOBExpCode. This is the LOBExpCode for the system. Enter your LOBExpCode here.
NGFTSMapC. This is the NGFTSMapC for the system. Enter your NGFTSMapC here.
And so on. And no, no data dictionary. Occasionally there would be half-pages of attempted explanation in extremely broken English. Even our own developers couldn't tell what half the stuff did. So that's one form of code obfuscation...
Okay: for argument's sake we'll say that PSCP works like a charm to prevent nasty evil crackers from debugging my program effectively.
.NET program's IL instructions are JITted into machine code at runtime, thereby making it pointless to modify the IL -- unless these people are invalidating the JITted code every time the IL code changes (is that even allowed?) or providing a translator between IL and machine code that inserts code-morphing instructions into the OUTPUT machine code (which I seriously doubt).
.NET assembly which is bursting with code, how does PSCP prevent him from taking the assembly apart and dissecting? Answer: PSCP *doesn't* provide any such protection.
.NET assembly. I may need to hunt back and forth for a little while to find the specific place I'm interested in, but I can't imagine that PSCP is able to change offsets or locations of instructions by very much.
We'll ignore the obvious problem presented by the fact that your
We'll ignore the fact that instructions which modify other code are generally very easy to spot -- because they must refer to regions of a program's address space where code resides -- and it should be easy to find these code morphing instructions and turn them into no-ops.
We'll set both of those tricky issues aside and focus on the crux of the matter. How does this PSCP protect the program *before* it starts running? When the cracker gets his hands on my juicy
So, the school of crackers that likes to use a debugger to deduce program behavior may find themselves having trouble. But in the worst case, all I need to do is run the morphing code in a debugger, record the location of the program counter at the point in the program's execution in which I'm interested, and then consult the corresponding section of the program code that resides in the original
Think about it: if PSCP wanted to change the location of a jump target, for example, it would need to track down every other instruction in the program that jumped to that instruction, and modify the jump to point to the new location of the jump target.
Examples of Stupid Obfuscator Tricks include:
- Scrambling exception ranges so they don't nest.
- Inserting non-structured GOTOs
- Inserting never-executed exits from synchronized blocks
There are others, these are just the ones that I recall. A compiler (static or JIT, it does not matter) must deal with all of these.There are two outs that I know of. One is to only use interpreted code and morph it on the fly (still seems vulnerable to an observant interpreter, but perhaps the amount of necessary observations can be made extravagantly large), the other is to require use of a "trusted" compiler (which, in turn, requires use of a "trusted" OS to prevent substitution of an untrusted compiler, which in turn requires "trusted" hardware to prevent substitution of an untrusted OS).
You mean you don't know the scope of Tmp, i, and j?! What's wrong with you? Tmp is obviously a global string, i is a class level float, and j is a local pointer to a linked list. Jeez, programmers these days.
Black and grey are both shades of white.
Like Ultra-Wide-Band networking and enterprise XML integration, this column fits a Cringely mold of writing an entire article about the business plan of one small company most people haven't heard of, and passing it off as an important insight about the IT industry as a whole. It works for the most part because there are a lot of neat-sounding business plans out there. Every start-up company in the world has a story about how their vision, fully realized, would shake up the entire industry. It makes for great column-fodder, but provides poor analyses.
If you read the whole column here twice, you immediately become aware of the fact that Cringely's entire "argument" turns on the idea that security rests on keeping source code secret. Because "interpeted" code "always" discloses code secrets, "interpreted" platforms like .NET will require the intellectual property wrapped up in schemes like PSCP. Therefore, the "inventors" or PSCP hold an important position on the chess-board of the entire IT industry. Microsoft and Sun will launch bidding wars to ensure they control the PSCP IP.
Of course this is just crazy-talk. Just for a moment, leave aside the argument that something like PSCP can really prevent reverse engineering. In the post-PSCP world, all security rests in a distributed repository of millions of lines of source code "locked up" in an organization that spans 45 buildings and untold tens of thousands of people in Redmond. You can't keep source code secret. Closed source is a speed-bump to dedicated attackers, who will break into networks, find corrupt insiders, or even get janitor temp positions in order to get the code.
Nobody working in security seriously believes that the source code for Windows 2000 wasn't floating around the computer underground years before the most recent disclosure. 'Twas ever thus: most of the SunOS and Solaris exploits that powered attackers in the mid-90's were derived from stolen Sun source code. Stolen source trees have always been the most stable currency in the computer underground for exactly that reason. What you do with the compiled product of that code makes no difference if the blueprints are already in enemy hands.
I'm not sure it's even worth confronting Cringely's argument (that PSCP is a strategic technology that is crucial to .NET security) head-on, but I think I can make a decent response simply by evoking video game copy protection. Companies went through all sorts of contortion to devise copy-protection schemes. Kids with the Microsoft Macro Assembler bible thwarted them, because, just like in the DRM/Media battle, when you control the entire player architecture, it is impossible to completely secure the content. Regardless of whether PSCP makes it harder to grep out the cookie cutter exploit from the .NET IR, the payoff in the "battle" between code-obfuscation and exploit generation is much higher than the payoff to defeat copy protection, and nobody has ever won the copy protection battle.
Cringley is right every once in awhile (business plans occasionally do pan out!), like with Eolas and Burst. I normally wouldn't care enough to comment, but this time he's inadvertantly promoting a damaging and popular misconception in his article.
tmp is less clear, but it certainly would have local scope, and only exists because of shortcomings in the implementation language (like not having a primitive operation for swapping the values of two variables without introducing a temporary variable), but no real significance in the problem domain.
These variable names are perfectly acceptable and clear - unless you abuse them, of course, but you can abuse all nameing schemes. Nothing stops you from calling a global integer m_pszHelloKitty.
Hungarian notation on the other hand is problematic because a) it is just a non-functional workaround for the weak typing in C and C++ (and their habit to make type errors crash your program in random unrelated places, or just corrupt your data) and b) there aren't actually enough rules, and if there were, nobody could remember them all. "iSomeInteger" and "sSomeString" are pretty common, but if you happen to use more interesting types, or even a whole C++ class hierarchy, it just doesn't work anymore. The only use of Hungarian Notation is to make clueless middle managers happy, similar to a long-winded format for mandatory comments preceding any trivial function or multi-page e-mail disclaimers. Source code is readable when you can actually read it out loud and people would understand whats going on, not if you encrypt redundant information in variable names.
Programming can be fun again. Film at 11.
Of course, if you don't know what the type of a variable is you can also just look at the type declaration.
Unless you're using something like BASIC where variables just suddenly appear out of the ether I really can't see how Hungarian notation is necessary. Especially in an age where we have advanced editors with split windows, and powerful search tools like glimpse, cscope, and ctags.
Besides, why should I trust some agglutinated letters on a variable name when I can do the same thing the compiler will do and look at the type declaration and be totally _sure_ of the type of the variable? What if some doofus changed the type of the variable in the declaration but was too lazy to update all the instances of Hungarian notation? Hungarian notation can only lead to a code maintainence nightmare!
--
"I'm too old to use Emacs." -- Rod MacDonald
Boy, if only there were some way to unambiguously declare the type of your variable. You could put it right next to where you declare the variable, or where it gets passed into the function. And then, if you needed to change the variable's type, you could do it from that one location. If only this were the case, we could get rid of the ugly maintenance nightmare that is Hungarian Notation.
The problem with Hungarian, of course, is that it lies.
It's like the comments. They tell you what the programmer *meant* to do, not what he or she did.
Similarly, Hungarian notation tells you the *intended* scope, type, etc, but the compiler may have a very different view of things.
Eloi, Eloi, lema sabachtani?
www.fogbound.net