So it's a book about reconstructing bytecode into human interprettable info, but it doesn't have an intro to them? That seems awfully strange. Are you sure you didn't miss something?
**Ch.2 Ghost in the Machine A good and solid introduction to the JVM and the classfile format. If you're in the market for this book, you probably already know most of this, but a refresher course is always good. For me, it definitely sorted out a lot on internal hand-waving on the subject. Just remember kids, the only thing to fear is fear itself - it's only binary data after all.**
maybe that one has the bytecode covered in short?
btw.. for everyone thinking that obfuscators do a good job.. THEY DON'T! es
Obfuscators DO work. They're certainly not foolproof, but they definitely make it more difficult to crack a program of any size.
I'm not talking about tiny programs; but who even bothers decompiling tiny midlets? Isn't it obvious what they're doing? With tiny programs, if you know enough to be cracking Java programs, you might as well just write the thing out yourself. It's not magic.
But for larger applications, any decent obfuscator can make it very time-consuming to decompile and edit the programs.
'Fraid I don't have both of the books to hand at the moment, but have a look at these reviews/book descriptions if you like: Decompiling Java: Writing for those who want to learn Java by decompilation, Nolan, a specialist in web site optimization, explains how to turn partially compiled Java bytecodes back into source code so that readers can see what the original programmer was thinking. Early chapters unravel the Java classfile format and show how Java code is stored as bytecode and executed by the JVM. Later chapters focus on how to write a Java decompiler, and a final chapter offers case studies. Both Java and.NET use the idea of a "virtual machine," or VM. And while VMs are useful for some purposes, they undermine the security of your source code, because creation can be reversed, or "decompiled." Which makes this one-of-a-kind book extremely useful: you must understand decompilation, to properly protect your intellectual property. For example, how secure is your code after you run an obfuscator? The book will answer questions like this, and provide more thorough information about Java byte codes and the Java Virtual Machine (JVM) than any other book on the market. This book redresses the imbalance by providing insights into the features and limitations of today's decompilers and obfuscators, and offering a detailed look at what JVM's actually do. This is a fantastic in-depth book on decompilers and code obfuscation tools for Java. It covers the structure of Java code files, the opcodes, and the all of the tools required to decompile classes, and to obfuscate existing code. It's an invaluable reference for anyone who has to deploy Java in a non-secure environment, or for those that want to learn how the language really works. There is a lot of code to pour though, and there are no illustrations. I think the text could have used some illustrations, but that's not a big sticking point for me. If you are a serious Java gearhead you should have a look at this book. And if you have a specific interest in either de-compiling some Java or obscuring your deployed Java bytecode then this is a must have. Covert Java: "Covert Java" provides a fascinating and look at behind the scenes Java development tactics that are usually the domain of seasoned veterans. Definitely a read for those who want to master Java. --Floyd Marinescu, Author, EJB Design Patterns; General Manager & founder of TheServerSide Communities. As a Java developer, you may find yourself in a situation where you have to maintain someone else's code or use a third-party's library for your own application without documentation of the original source code. Rather than spend hours feeling like you want to bang your head against the wall, turn to Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering. These techniques will show you how to better understand and work with third-party applications. Each chapter focuses on a technique to solve a specific problem, such as obfuscation in code or scalability vulnerabilities, outlining the issue and demonstrating possible solutions. Summaries at the end of each chapter will help you double check that you understood the crucial points of each lesson. You will also be able to download all code examples and sample applications for future reference from the publisher's website. Let Covert Java help you crack open mysterious codes!
in 1999 i wrote a paper on security in set-top boxes (one of my first papers); yay. but, one approach we had was to build a custom class loader that would actually load encrypted classes.
the details of the paper are:
1999 - Security in Set-Top boxes European Multimedia, Embedded Systems and Electronic Commerce EMMSEC '99, Stockholm, SWEDEN June 21-23, 1999
there was a lot of interest on this topic back in the time:) i had a number of successful prototypes built - but, unless you build the class loader into hardware (ie: cannot access the.class file), its just another hurdle, nothing more.
I believe encryption is probably not worth the effort for most people, it's not much of a hurdle to overcome. Ultimately all custom class loader execution paths will lead to a ClassLoader.defineClass call which can either be intercepted by creating a modified system class loader or by creating a JVMPI agent which listens for JVMPI_EVENT_CLASS_LOAD_HOOK events. If you can prevent these methods from being employed then you're probably operating in a secure environment where encryption would be overkill.
The crux is that at some point in time, you have to deliver the encrypted class to the JVM in an unencrypted format. Intercepting this delivery is incredibly easy (no expert knowledge required, the details for doing so are detailed in the article above), at which time someone can just write the unecrypted class file out to disk (or wherever they wish). Voila! All your IP are belong to us.
> "security" in Java is so trivially easy to circumvent
Are you confusing encryption with obfuscation? If not I agree that class-level encryption has no ROI.
Obfuscation, on the other hand, is an excellent tool for protecting IP. I use Proguard http://proguard.sourceforge.net/ [sourceforge.net] via Ant and am happy with the result, having tried to grok the resulting byte code (using jad...) Good luck trying to work with that!
I'd agree with you that no obfuscator could really make it impossible to recreate a piece of software from the bytecode... but of course the only real aim is to make it hard enough so that it would be easier to simply purchase the software.
Though obfuscation comes with its own array of potential issues, especially in remote applications or those that rely on reflection
Obfuscators pretty much all offer you enough flexibility to exclude classes that will need to be used via reflection or with RMI... or to
I have implemented an encrypted class loader that never delivers the unencrypted bytes to the java class. The author of this article is mostly correct, and I have read this article before. He states the following:
until JVM architecture changes to, say, support class decoding inside native code...
This is already possible and I have implemented it. It involves making direct calls to the jvm libraries from JNI rather than callbacks to java from JNI. There is still a way to get the bytes, but it invo
What ethical problems? Decompiling is perfectly moral and ethical. Whether it is illegal is a seperate and, for me, almost irelevant issue. If I legally own a copyrighted work I am allowed to read it, period and end of story. Corporate licences excepted, software is SOLD, not licensed despite the scary words on the box and the dread click through EULA.
Hell, I learned assembly by writing a disassembler (in BASIC) and reading the Microsoft BASIC roms, then later reading the commented listings that ran in Color Computer Magazine. (TO avoid a copyright fight, and because M$ refused to grant them permission, CCM ran only the comments and memory locations, leaving the reader to run their own dissassembly for the opcodes.)
The only ethical problem would be lifting the code and reusing it without permission and I think we all know that is wrong.
What ethical problems? Decompiling is perfectly moral and ethical.... If I legally own a copyrighted work I am allowed to read it, period and end of story. Corporate licences excepted, software is SOLD, not licensed despite the scary words on the box and the dread click through EULA.
I disagree here. I am a strong believer that people should be able to trade goods/services for prices/conditions they mutually agree upon. If I write software and say I will sell it to you for $x on condition that you do Y
> I think it is morally repugnant of you to break our agreement and decompile.
While you are welcome to your delusions, but out here in the real world we have some things called laws. Specifically the Uniform Commercial Code and the Copyright laws.
You will note that I excepted commercial licenses, since those are actual signed contracts and are legally binding.
According to the Uniform Commercial Code if goods are exchanged in regular trade there can't be strings attached; i.e. if it looks like a sale it IS a sale. If I buy a copy of Microsoft Windows from Newegg.com I did just that, I BOUGHT a copy of Windows. That means I can do anything with that copy, including read it. I can even copy it in whole or in part so long as such activity falls under the backup exception written into the law or by Fair Use. Of course any other reproduction is forbidden by the artifical monopoly rights granted to the author by copyright. While I have a lot of problems with how copyrights are currently operated (eternal instead of "limited times" as prescribed by the Constituition) I don't have a major problem with that limitation.
But think about it, what you are saying is that you can sell me a copyrighted work that I am forbidden to read myself. What a load of fetid dingos kidneys! Ford can't forbid me from taking apart a Caddy and not only making, but SELLING plans; but you think your algorithms are so freaking special that you want the government to put me in jail for the crime of reading them? What are you smoking?
But think about it, what you are saying is that you can sell me a copyrighted work that I am forbidden to read myself
Sure. I was thinking of this as an example when I wrote my last post. I could write a book, and say to you, "Here's my book, it's $5, but if you buy it you can't read chapters 3, 7, or 9." And I'd have no problem with that. If you don't want to pay money for a book whose full contents I say you can't read, then fine - don't buy it. But don't buy it, knowing what terms I've laid out, and
If you don't want to pay money for a book whose full contents I say you can't read, then fine - don't buy it.
You can certainly restrict your customers such terms -- as long as you convince the buyer to read and sign a legally binding contract prior to the sale.
If you don't get a signature, you can't expect any restrictions.
If the EULA is clearly presented and the consumer can understand it, then why not. I just know that I wouldn't buy clothes packaged in a label that said: "NOT TO BE WORN BY ACTUAL PEOPLE. HIGHLY FLAMABLE. IF YOU BURN AND DIE, WE ARE NOT RESPONSIBLE."
Why do you think I am for hiding or "tricking" people? I said in my original post, in very clear terms, that conditions are only valid if the buyer understands and agrees to them.
I just don't understand people with your greedy, assbackwards, mindset.
I don't understand people with your mindset, a mindset that strips individuals of their rights. Listen, if I have created something, and want to sell it to you with conditions, why shouldn't I be able to do that? If you don't want to abide by those conditions: DON'T FREAKING BUY WHAT I'M SELLING. Have a little restraint, Mr. Consumer. Jebus.
I am 100% for free trade between people. You, on the othe
Finally, capitalism works. In a true capitalistic marketplace, having unnecessary, artificial conditions wouldn't be benefitial to the seller, since other sellers could enter the market without such fluff conditions and make the sale.
Wow. Your talking about copyright law, which is an artificial monopoly. Your 100% free trade would work just fine if copyright did not create an artificial monopoly which is why there are laws spelling out what can and can't be done with copyrighted works If people enter in
You can't impose unlawful conditions. Freedom is nothing without laws. The fundamental principle here is that no one can freely contract to contravene the law. Does that help?
Ahem. Last time I checked Ford didn't make Caddys. So I doubt they'd have any qualms about your taking one apart and selling the plans. They might even encourage it!
When you think about it - you can overwrite most laws (non-criminal laws) with a contract - so long as the contract is not illegal (i.e. a contract that between groups to rob a bank is not legal). A good example is contracts that break the "employment at will" clause that many states use.
So if I write some material and I state that part of our agreement is that you cannot read certain sections of it - by purchasing it you are agreeing to my terms and can be held liable in a civil court. Remember - in term
The trade of value occurs at purchase (you gave money for the box and its contents). Since it is not feasible to sit down with a lawyer at a retail store for each purchase - there is a delay from when you purchase the product to when you see the EULA. You can return the product to the store if you are not happy with the EULA. TO say that since the EULA was not presented in visible writing prior to the purchase is not valid BECAUSE you have the option for a full refund. You have the option to read that EU
First you imply that the actual laws are irrelevant to your views on morality:
What ethical problems? Decompiling is perfectly moral and ethical. Whether it is illegal is a seperate and, for me, almost irelevant issue.
Then when someone argues on moral grounds:
If I write software and say I will sell it to you for $x on condition that you do Y (perhaps Y is not decompiling the source), and you agree to these terms, I think it is morally repugnant of you to break our agreement and decompile.
> First you imply that the actual laws are irrelevant to your views on > morality:
When a society is correctly operating, laws codify morals. In our current dystopia of the Law divorced from Truth and Justice that isn't always the case. It is the Right, nay it is the Duty, of every citizen in a free society to violate an unjust law as an act of civil disobiedience.
And yes, I have done so publicly, specifically by confessing to violating the DMCA by viewing DVDs on my laptop in a letter to President
If you don't like the conditions of the offer, don't buy the product.
That is exactly what the Uniform Commercial Code is about, ensuring everyone knows and can agree in a meaningful way to the terms of the transaction. Without a signed contract specifying different terms though, the UCC says that a sale of goods transfers a clear title to those goods, meaning there can't be any conditions attached.
You're talking about specific laws here. The grandparent post was merely saying that violating an a
> The grandparent post was merely saying that violating an agreement is > immoral.
True enough but this whole matter revolves around whether an agreement exists. When people disagree on such matters, that is where the Law comes into the discussion and it is very clear on the point.
The original poster holds that as the creator and owner of a work he has absolute power to dictate the terms and conditions it can be USED under, and that by purchasing his work I MUST agree to those terms. I hold that he
> All well and good, but when you "buy" Windows XP in a store, you aren't > buying Windows XP, you're buying a LICENSE to use Windows XP in binary > form. Huge difference.
Still hung up on that misconception. No, a license is only in effect if I sign a contract changing the sale into a limited license. They can print "By buying this hammer you agree you will ONLY drive our brand of nails and strike no other object with this tool." on the side, stock the shelves of Home Depot with them and get exact
> Software vendors aren't selling you their products...they're selling > you a LICENSE to use their products.
Nope. on the rare occasion I buy software, I BUY it. You do not need a license to use software anymore than you need one to read a book, or even to check one out of a public library.
> Then the GPL, the MPL, and every other open source license, is invalid. > That makes WhiteBox Linux illegal.
Again, you are quite mistaken. You may download as many copies of WhiteBox from whereever you p
> If the GPL can say that distributing a GPL'd work constitutes acceptance of the license, and the license is binding, how can that be? There's no contract.
Er, because if you distribute it, you're distributing someone else's copyrighted works. *DISTRIBUTING*. Not copying/modifying/studying for your own private use, *DISTRIBUTING*. The only way you could do that is with the copyright holder's permission, which happens to be spelled out in the GPL. That's how copyright law works, and that's the whole
> But then you say the GPL provides a license, yet nobody has to sign > anything to use GPL'd software, or copy it, or distribute it, as long > as they meet its conditions. So if I don't have to sign anything, then > the GPL isn't binding.
Exactly correct. If you copy a GNU program and distribute it you do not have to accept the GPL. However when RMS and his squadron of elite attack lawyer ninjas descend upon you for violating their copyright, smiting thee with their rightous fury, only saying "I
He isn't saying that laws and morality are unrelated, only that the relationship ought to be associated with a clear, unidirectional causality, and therefore that moral decisions are not dictated by the law.
If it's a unidirectional causality, then a moral assessment should never depend on any particular laws. The original poster claimed that unapproved decompilation was immoral. Then jmorris42 came around and started citing specific laws to prove that he had the legal right to do so.
> What's worse is he assumed that hypothetical agreement wasn't in writing > and proceeded to draw further conclusions from that assumption
No, read up the thread, in the very first post I excluded the case of corporate site licensing and other such real signed contract sort of software licensing it should be clear I am discussing consumer EULAs.
I assert that since EULAs are wrong on both moral and legal grounds, either of which alone is cause for ignoring them. I claim that I have as much right to r
It's that mutually agreed condition part that is problematic. When I buy hardware or software, I don't normally agree to any conditions on it. If I did, your philosophy would have merit. There are even good examples of things you buy where you must agree to conditions (like cell phones); you read a contract and sign your name. Software and hardware companies want to have it both ways. They want an enforceable contract that users agree to, but they also want to present their wares in a friendly way that makes people think they are buying something normally.
Software and hardware companies want to have it both ways. They want an enforceable contract that users agree to, but they also want to present their wares in a friendly way that makes people think they are buying something normally.
I agree with you fully. Burying what you can and can't do in a EULA, one that you can't read until you take the software home and start installing it, is not what I have in mind. If they wanted to impose such conditions on the software's use, it would behoove them to have on
(I wasn't the author of the grandparent post) What if I buy some software but do not get to see the EULA until after I have purchased it (say, it isn't available online) and, after purchasing it and reading the EULA, I am not permitted to return the product for a refund? Am I still obligated to follow the EULA in that case?
Personally I don't think a EULA that is hidden like that should be binding. I'm not pro-tricking consumers. If a seller wants to place limitations on how his product is used, he needs to make the limitations crystal clear to the potential buyer before any money changes hands. The buyer should then think about whether the goods/conditions are worth the price being asked, and make their decision based on that balance.
What about EULAs that are deliberately written in a style/technical language unreadable to the majority of the buyers ? Or written with intent to discourage complete reading (a EULA of 125 pages for instance, with 75% of its scentences longer than 10 lines and each one containing 15 buzwords that you have to go lookup online. NOBODY should be asked to read and accept all that. It's just plain stupid)
That sounds reasonable to me. Unfortunately, with the exception of EULAs that are available online, I do not know of a single local software store here that would allow you to return software because you did not accept the EULA (but had opened the software). Granted, I live in Edmonton, Alberta, Canada, so it may be different in the U.S., or even in other cities in Canada. But I have tried returning software before when I did not accept the EULA, to CompuSmart and to FutureShop, and neither place would a
Hell, I learned assembly by writing a disassembler (in BASIC) and reading the Microsoft BASIC roms, then later reading the commented listings that ran in Color Computer Magazine. (TO avoid a copyright fight, and because M$ refused to grant them permission, CCM ran only the comments and memory locations, leaving the reader to run their own dissassembly for the opcodes.)
Regardless of the ethics, reading other people's code is, IMHO, the single best way to learn how coding works. And decompiling from objec
It has always been the case with Java (and in general many other interpretted/pcode generating languages) that enable them to be decompiled. I remember, back in old VB days, you could take a VB (pre 3.0) executable and decompile to get the original source. Of course, variable names were changed (since VB compiler changed them when converting to pcode).
As systems get more open/advanced, the sources are more difficult to hide. In case of web apps, there is no need to decompile anything, the javascripts are
I didn't think it was possible to view the source of an ASP. So I did a search and came up with this [tek-tips.com].
I'm not sure why you think of NTFS file streams. That's a complete different issue. How would your trick work if the ASP pages are on a FAT file system? NTFS streams are interesting: I once used them in a pratical joke to consume all of somebody's disk space. They couldn't see in Explorer where it went! Incidentally, it's too bad that Macs can't make use of them for their resource forks when browsing
Java doesn't really have to be that vulnerable. Perhaps code compiled with javac is weak, but it could easily be made much stronger.
Why? Well, Java bytecode is a lot more flexible than the Java language. Take exceptions for example. In the language we handle exceptions with try-catch-finally grammar productions. But in the bytecode we have a table that specifes ranges of bytecode addresses that mapped via an exception to a exception handler. The cute thing is that a "range of bytecodes" has nothing t
As systems get more open/advanced, the sources are more difficult to hide. In case of web apps, there is no need to decompile anything, the javascripts are available for all to see in plain text. Even more advanced applications that use ASP pages...
Web applications are typically implemented server-side. Javascript is client-side code.
Javascript != web applications
Perhaps what you are referring to is the source for ASP and JSP/servlets. There have been bugs in servlet containers (specifically, I bel
Even more advanced applications that use ASP pages that execute on the server, can be seen by changing the URL to list the source rather than execute them
Are you smoking crack?
You can't arbitrarily get at source code on someone's web server. Do you think eBay would want you seeing the passwords to their database servers?
Web apps aren't written in JavaScript. Sure, there might be some to drive calendar selection or something, but pretty much all real apps (shopping carts, etc.) are done server side.
Please get a clue and stop spreading your FUD around.
Additionally, this isn't a "feature" of Java. It's just a side-effect of its machine-independent bytecode. You could argue that it's not all that hard to reverse engineer compiled C - if you step it through a debugger you can see what it does fairly easily.
Systems being more "advanced" (let's wave our hands a little bit more) won't make it any more difficult to hide the source. Many many people run Java on the server side of web apps. It will always be impossible to view the source for such applications (unless the developers put it up for the world to see, of course). As for being "open", what do you mean? If you mean, "open source" then, well, duh...:)
You can't arbitrarily get at source code on someone's web server. Do you think eBay would want you seeing the passwords to their database servers?
I think he's referring to an old bug on IIS that would allow you to view the contents of a file on the server. I believe it was a sample ASP that MS included to demonstrate come capability of ASPs.
I'm sure there are a few servers around that still have that enabled, but I'm sure most had that thing fixed 3-4 years ago.
by Anonymous Coward writes:
on Wednesday November 03, 2004 @04:08PM (#10715004)
No Java developer should be without DJ Decompiler (which sits on top of JAD, the actual decompiler, command line only). Seriously, this book may be useful, but most people are way below needing to know any of this. If you do need to know it or are just curious, fine.
Oh, and obfuscation, blah, any good IDE (like IntelliJ IDEA) is able to help you work around this junk.
...can be handy when trying to figure out the advantage of one coding idiom over another. On the PMD [sf.net] project (a Java static analysis tool) there was a discussion [sourceforge.net] yesterday about code like this:
Anyhow, decompiling the classfile with "javap -c" shows that a couple of instructions get eliminated by dropping the explicit comparison to "true". So the classfile gets smaller, it loads faster, and (unless the JIT compiler is smart enough to do constant propagation on that conditional) it'll run faster, too.
I'm astounded that Sun javac doesn't do the
obvious optimization. I wrote a test program
with and without the "== true" part, and here's
the diffs (the test prog just println's the result). What the hell?
who, as a compiler hacker, would have expected an optimization pass to transform the first form into the second form before generating the bytecode
Almost all of the Java compilers out there do little to no optimizations while generating bytecode. Rather, the focus of the compilers is to generate bytecode that is easily understood and optimized by the virtual machine.
Since the bytecode for Java is a well-defined standard, there are many more bytecode processors for Java compared to say object-code proc
On the other hand, also speaking as a compiler hacker, I should point out that just because an optimisation is possible, doesn't mean it's a good idea. When you add more optimisation, it costs. It's extra code that you have to write, test and maintain over the life of the compiler. If its entire purpose is to make the rare case of badly written code go faster, then you could quite legitimately turn around to the compiler user and say "don't do that".
As an example, a compiler could quite easily optimise
While I hate defending Java in any form, the two should be equivalent on a machine level. To see if a value is true (non-zero), you can do two things- subtract 0 and see if the result is 0, or AND it with 0xFFFF... To see if two things are both the same value, you subtract the two and check if the result is 0. The two are an equal number of instructions (and both test and cmp are quick instructions). On an asm level:
mov eax, isLoggable cmp eax, 0;could also use test eax, 0xFFFFFFFF jnz skip_if;if using test, do a jz skip_if;etc skip_if:;both branches continue here
A check to true only changes the cmp to 1 instead of 0. It won't run any faster.
Anyhow, decompiling the classfile with "javap -c" shows that a couple of instructions get eliminated by dropping the explicit comparison to "true". So the classfile gets smaller, it loads faster, and (unless the JIT compiler is smart enough to do constant propagation on that conditional) it'll run faster, too.
The Java Language spec requires that a conforming compiler (not JIT, but source to bytecode compiler) do constant propagation.
Hm. I knew that the JLS required that in some circumstances - i.e., so that a switch statement can switch on a static final. What's the actual requirement, though? For example:
int x = 2; int y = 4 * x;// can be int y = 4 * 2; int z = f(x, y);
Is a conforming compiler also required to make that transformation?
The Java compiler does some optimization - for example, when given this code:
class Test {
int x = 2 + 2; }
it does algebraic simplification to reduce that assignment to an aload followed by a iconst_4 instruction. And it does some constant propagation so that this:
class Test {
private static final int X = 2;
int y = X + X; }
also gets simplified to the aload/const sequence. I guess it's just some choices the compile designers made on which things wer
>knowing how to decompile code is more about protecting your own source code.
There are many reasons to learn about, implement and use decompilers, but I don't think "to properly protect your intellectual property" should be one of them.
I'm got somewhat interested in this book (never heard about it before), but I think I'm going to pass. Sounds like the decompiling described is too much of a one-trick pony -- which is fine, it's about decompiling java after all -- but I'd really like something like an extension and update of Cifuentes work in book form, with the lessons from the IDA team too.
You know, from the beginning; starting with machine descriptions and disassembly for a generic front-end, efficent IR, and on up through the back end.
I had always assumed that obfuscation was a magic fix that I could apply if necessary.
Let me get this straight: the author recommends that 'honest' developers obfuscate their code?
I've read programs that I thought were obfuscated, but later found out were just poorly written. Other times I've run into programmers who, tin hats firmly affixed, went to great lengths to make sure no one learned their Merlinesque techniques for getting the most out of BASIC.
You've misunderstood. Java obfuscation is an automated process done with a third-party tool that rearranges Java BYTECODE, not source code. The idea being that someone that tries to decompile the BYTECODE will get a bunch of spaghetti. It doesn't take any extra time or energy by the developer, just 5 seconds to run the tool on your.class files.
>you've misunderstood... >byte code, not source code >feature of the language...
My comments were intended to be more general than the Java language. Whether done with a command line switch, on an IDE checkbox at packaging time, or by writing a quickie program to do it yourself (which amortized is on the same order of time), doing anything to seal up your object code is counterproductive.
Work to improve the code by revealing it, not by hiding it.
Unstated and implicit was: what if you lose the sour
Besides that it removes the meta information in classes. Or renames actually. In Java, all class and member names are available (for reflection) after compilation. This makes the design rather obvious, even without decompilation. Renaming them to counters (a, b, c etc.) makes it pretty hard to see the design straight away. As long as you don't use these classes from outside, this does not do anything to functionality of the program.
Normally, you would only do this after debugging your code. Obviously, it m
What's fun about decompiling obfuscated code is when you end up with variables and classes that have reserved names, e.g. a class called "if".
I had to decompile and patch a ridiculously buggy JDBC driver for a commercial database which had been run through an obfuscator, and ran into that issue. Renaming was rather a hassle, I must say.
I came to the conclusion that they had obfuscated their driver out of shame at the embarrasingly bad code, rather than to protect any intellectual property therein.
It's not really a waste of time because the source code remains entirely untouched... it's just one extra step in the build process, and it'd probably even be right there in the buildfile for the project, so it'd happen automatically whenever the source gets changed.
I've read programs that I thought were obfuscated, but later found out were just poorly written. Some user has in their.signature here: "That's not encrypted - that's a perl script I'm working on." from crObar's now defunct matrix parody.
Most techie book these days are quickie grab-bags, and you end up paying for a lot of dead trees that you aren't interested in.
And so I suggest a service like O'Reilly's Safari Bookshelf [oreilly.com]. It includes the full text of over 2,000 technical books, many not published by them. No killing trees, far less money than buying books, plus full text search.
...is pretty much the standard decompiler where I work. Alas, it's no longer free, as I've just found out when I searched for it's home page [tripod.com], but it works really well. I have, on occasion, used it as a pretty-printer for other people's code. It undoes obfuscation with ease.
I have yet to try it on byte-code produced by non-Java languages, but I'd be interested to see the results...
(It sucks that it's no longer free. The version I've got I installed through Debian, for goodness sake, years ago. Does anyone know any free alternatives that work as well?)
It's actually surprisingly bad at handling try/catch blocks. They're fine if the try block starts at the beginning of the method, but it's rare that I decompile a class and can then compile it without fixing up a few catches. The bit which surprises me is that I can fix them on autopilot - if I used jad regularly, I'd write a Perl script to fix them.
(Yes, Slashbots, those are affiliate links... that doesn't make them any less useful though, does it?)
Yes, it does make them less useful. Because now it is impossible to tell whether you are saying things like "a more in-depth look" because you really mean it, or because you stand to make a quick buck by making bogus claims about the book.
Nothing personal, of course; you can probably see yourself why the rest of us simply can't know if you are being honest or running an astroturf con.
Ouch! Also, I think every decompiler has some weaknesses and isn't able to undo all code. I know Jad has some limitations. Unfortunately, I wasn't able to get the source of the code that broke the decompilers;)
I have been decompiling Java regularily. Just get Jode Jode [sourceforge.net] Its very simple and effective.
As long as the writers are not using ubfuscation tools, the code is fully readable in it's original form sans commenting.
By which I mean, there is a java applet running in my web browser. I'd like to decompile it and look over the source code. It's small enough I believe this would be informative. Is there a good way to do this?
The simplest version of cracking a Java program is using JAD to decompile the source, making a few changes in source (like changing the license check to always return "full enterprise version" instead of "time-limited demo"), compiling your altered class, replacing it the JAR, and running the app.
Most obfuscators will make this track impossible, by doing things like using language keywords (while, for, if, and so on) for class/method/variable names, so that when you decompile the thing it cannot be recompiled. They also mix stuff around in the classfile enough so that figuring out what method is doing what becomes non-trivial -- stupid things mostly (like naming methods l1(), ll(), I1(), Il(), etc.), plus a few tricks to stop JAD from fully decompiling the class.
Enough of these little things add up to make the work involved in altering the decompiled class excessive and difficult.
The more sophisticated Java cracker doesn't bother. They decompile enough source to get their bearings, then edit the appropriate bytecode directly, with a classfile editor. Fortunately, most people with this level of experience can just pay for the frickin software they want.
I'm actually not obfuscating my Java code yet, but I'm going to start... it's just too easy to crack Java code without it. yGuard obfuscator [yworks.com] is pretty decent LGPL one, that can run as an Ant task.
no bytecode intro? (Score:4, Interesting)
Re:no bytecode intro? (Score:5, Funny)
Re:no bytecode intro? (Score:2)
A good and solid introduction to the JVM and the classfile format. If you're in the market for this book, you probably already know most of this, but a refresher course is always good. For me, it definitely sorted out a lot on internal hand-waving on the subject. Just remember kids, the only thing to fear is fear itself - it's only binary data after all.**
maybe that one has the bytecode covered in short?
btw.. for everyone thinking that obfuscators do a good job.. THEY DON'T! es
Re:no bytecode intro? (Score:2)
obfuscators don't work? (Score:3, Insightful)
I'm not talking about tiny programs; but who even bothers decompiling tiny midlets? Isn't it obvious what they're doing? With tiny programs, if you know enough to be cracking Java programs, you might as well just write the thing out yourself. It's not magic.
But for larger applications, any decent obfuscator can make it very time-consuming to decompile and edit the programs.
Re:no bytecode intro? (Score:4, Informative)
Better Java Book (Score:4, Informative)
Re:Better Java Book (Score:4, Informative)
Decompiling Java:
Writing for those who want to learn Java by decompilation, Nolan, a specialist in web site optimization, explains how to turn partially compiled Java bytecodes back into source code so that readers can see what the original programmer was thinking. Early chapters unravel the Java classfile format and show how Java code is stored as bytecode and executed by the JVM. Later chapters focus on how to write a Java decompiler, and a final chapter offers case studies.
Both Java and
For example, how secure is your code after you run an obfuscator? The book will answer questions like this, and provide more thorough information about Java byte codes and the Java Virtual Machine (JVM) than any other book on the market. This book redresses the imbalance by providing insights into the features and limitations of today's decompilers and obfuscators, and offering a detailed look at what JVM's actually do.
This is a fantastic in-depth book on decompilers and code obfuscation tools for Java. It covers the structure of Java code files, the opcodes, and the all of the tools required to decompile classes, and to obfuscate existing code. It's an invaluable reference for anyone who has to deploy Java in a non-secure environment, or for those that want to learn how the language really works.
There is a lot of code to pour though, and there are no illustrations. I think the text could have used some illustrations, but that's not a big sticking point for me.
If you are a serious Java gearhead you should have a look at this book. And if you have a specific interest in either de-compiling some Java or obscuring your deployed Java bytecode then this is a must have.
Covert Java:
"Covert Java" provides a fascinating and look at behind the scenes Java development tactics that are usually the domain of seasoned veterans. Definitely a read for those who want to master Java.
--Floyd Marinescu, Author, EJB Design Patterns; General Manager & founder of TheServerSide Communities.
As a Java developer, you may find yourself in a situation where you have to maintain someone else's code or use a third-party's library for your own application without documentation of the original source code. Rather than spend hours feeling like you want to bang your head against the wall, turn to Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering. These techniques will show you how to better understand and work with third-party applications. Each chapter focuses on a technique to solve a specific problem, such as obfuscation in code or scalability vulnerabilities, outlining the issue and demonstrating possible solutions. Summaries at the end of each chapter will help you double check that you understood the crucial points of each lesson. You will also be able to download all code examples and sample applications for future reference from the publisher's website. Let Covert Java help you crack open mysterious codes!
Been decompiling Java for awhile now... (Score:5, Funny)
Better watch it... (Score:2)
another alternative = encrypted class files (Score:5, Interesting)
the details of the paper are:
1999 - Security in Set-Top boxes
European Multimedia, Embedded Systems and Electronic Commerce
EMMSEC '99, Stockholm, SWEDEN
June 21-23, 1999
COPY: (pdf)
http://www.ardiri.com/publications/emmsec9
there was a lot of interest on this topic back in the time
Re:another alternative = encrypted class files (Score:4, Informative)
Doesn't work (Score:5, Informative)
There are a number of papers and articles detailing why this type of approach to "IP security" is so misguided. One such article is here: http://www.javaworld.com/javaworld/javaqa/2003-05
The crux is that at some point in time, you have to deliver the encrypted class to the JVM in an unencrypted format. Intercepting this delivery is incredibly easy (no expert knowledge required, the details for doing so are detailed in the article above), at which time someone can just write the unecrypted class file out to disk (or wherever they wish). Voila! All your IP are belong to us.
Re:Doesn't work (Score:4, Informative)
Are you confusing encryption with obfuscation? If not I agree that class-level encryption has no ROI.
Obfuscation, on the other hand, is an excellent tool for protecting IP. I use Proguard http://proguard.sourceforge.net/ [sourceforge.net] via Ant and am happy with the result, having tried to grok the resulting byte code (using jad...) Good luck trying to work with that!
R7
Obfuscation issues (Score:2)
Though obfuscation comes with its own array of potential issues, especially in remote applications or those that rely on reflection
Obfuscators pretty much all offer you enough flexibility to exclude classes that will need to be used via reflection or with RMI... or to
Re:Doesn't work (Score:2)
until JVM architecture changes to, say, support class decoding inside native code...
This is already possible and I have implemented it. It involves making direct calls to the jvm libraries from JNI rather than callbacks to java from JNI. There is still a way to get the bytes, but it invo
What ethical problems? (Score:5, Insightful)
What ethical problems? Decompiling is perfectly moral and ethical. Whether it is illegal is a seperate and, for me, almost irelevant issue. If I legally own a copyrighted work I am allowed to read it, period and end of story. Corporate licences excepted, software is SOLD, not licensed despite the scary words on the box and the dread click through EULA.
Hell, I learned assembly by writing a disassembler (in BASIC) and reading the Microsoft BASIC roms, then later reading the commented listings that ran in Color Computer Magazine. (TO avoid a copyright fight, and because M$ refused to grant them permission, CCM ran only the comments and memory locations, leaving the reader to run their own dissassembly for the opcodes.)
The only ethical problem would be lifting the code and reusing it without permission and I think we all know that is wrong.
Re:What ethical problems? (Score:3, Insightful)
I disagree here. I am a strong believer that people should be able to trade goods/services for prices/conditions they mutually agree upon. If I write software and say I will sell it to you for $x on condition that you do Y
Re:What ethical problems? (Score:5, Interesting)
While you are welcome to your delusions, but out here in the real world we have some things called laws. Specifically the Uniform Commercial Code and the Copyright laws.
You will note that I excepted commercial licenses, since those are actual signed contracts and are legally binding.
According to the Uniform Commercial Code if goods are exchanged in regular trade there can't be strings attached; i.e. if it looks like a sale it IS a sale. If I buy a copy of Microsoft Windows from Newegg.com I did just that, I BOUGHT a copy of Windows. That means I can do anything with that copy, including read it. I can even copy it in whole or in part so long as such activity falls under the backup exception written into the law or by Fair Use. Of course any other reproduction is forbidden by the artifical monopoly rights granted to the author by copyright. While I have a lot of problems with how copyrights are currently operated (eternal instead of "limited times" as prescribed by the Constituition) I don't have a major problem with that limitation.
But think about it, what you are saying is that you can sell me a copyrighted work that I am forbidden to read myself. What a load of fetid dingos kidneys! Ford can't forbid me from taking apart a Caddy and not only making, but SELLING plans; but you think your algorithms are so freaking special that you want the government to put me in jail for the crime of reading them? What are you smoking?
Re:What ethical problems? (Score:2, Interesting)
Sure. I was thinking of this as an example when I wrote my last post. I could write a book, and say to you, "Here's my book, it's $5, but if you buy it you can't read chapters 3, 7, or 9." And I'd have no problem with that. If you don't want to pay money for a book whose full contents I say you can't read, then fine - don't buy it. But don't buy it, knowing what terms I've laid out, and
Re:What ethical problems? (Score:2)
You can certainly restrict your customers such terms -- as long as you convince the buyer to read and sign a legally binding contract prior to the sale.
If you don't get a signature, you can't expect any restrictions.
Re:What ethical problems? (Score:2)
Why do you think I am for hiding or "tricking" people? I said in my original post, in very clear terms, that conditions are only valid if the buyer understands and agrees to them.
Re:What ethical problems? (Score:3, Insightful)
Very.
I just don't understand people with your greedy, assbackwards, mindset.
I don't understand people with your mindset, a mindset that strips individuals of their rights. Listen, if I have created something, and want to sell it to you with conditions, why shouldn't I be able to do that? If you don't want to abide by those conditions: DON'T FREAKING BUY WHAT I'M SELLING. Have a little restraint, Mr. Consumer. Jebus.
I am 100% for free trade between people. You, on the othe
Re:What ethical problems? (Score:2)
Wow. Your talking about copyright law, which is an artificial monopoly. Your 100% free trade would work just fine if copyright did not create an artificial monopoly which is why there are laws spelling out what can and can't be done with copyrighted works If people enter in
Re:What ethical problems? (Score:3, Interesting)
Re:What ethical problems? (Score:2, Funny)
Re:What ethical problems? (Score:2)
So if I write some material and I state that part of our agreement is that you cannot read certain sections of it - by purchasing it you are agreeing to my terms and can be held liable in a civil court. Remember - in term
Re:What ethical problems? (Score:2)
Re:What ethical problems? (Score:2)
First you imply that the actual laws are irrelevant to your views on morality:
Then when someone argues on moral grounds:
Re:What ethical problems? (Score:2)
> morality:
When a society is correctly operating, laws codify morals. In our current dystopia of the Law divorced from Truth and Justice that isn't always the case. It is the Right, nay it is the Duty, of every citizen in a free society to violate an unjust law as an act of civil disobiedience.
And yes, I have done so publicly, specifically by confessing to violating the DMCA by viewing DVDs on my laptop in a letter to President
Re:What ethical problems? (Score:2)
You're talking about specific laws here. The grandparent post was merely saying that violating an a
Re:What ethical problems? (Score:2)
> immoral.
True enough but this whole matter revolves around whether an agreement exists. When people disagree on such matters, that is where the Law comes into the discussion and it is very clear on the point.
The original poster holds that as the creator and owner of a work he has absolute power to dictate the terms and conditions it can be USED under, and that by purchasing his work I MUST agree to those terms. I hold that he
Re:What ethical problems? (Score:2)
> buying Windows XP, you're buying a LICENSE to use Windows XP in binary
> form. Huge difference.
Still hung up on that misconception. No, a license is only in effect if I sign a contract changing the sale into a limited license. They can print "By buying this hammer you agree you will ONLY drive our brand of nails and strike no other object with this tool." on the side, stock the shelves of Home Depot with them and get exact
Re:What ethical problems? (Score:2)
> you a LICENSE to use their products.
Nope. on the rare occasion I buy software, I BUY it. You do not need a license to use software anymore than you need one to read a book, or even to check one out of a public library.
> Then the GPL, the MPL, and every other open source license, is invalid.
> That makes WhiteBox Linux illegal.
Again, you are quite mistaken. You may download as many copies of WhiteBox from whereever you p
Re:What ethical problems? (Score:2)
Er, because if you distribute it, you're distributing someone else's copyrighted works. *DISTRIBUTING*. Not copying/modifying/studying for your own private use, *DISTRIBUTING*. The only way you could do that is with the copyright holder's permission, which happens to be spelled out in the GPL. That's how copyright law works, and that's the whole
Re:What ethical problems? (Score:3, Insightful)
> anything to use GPL'd software, or copy it, or distribute it, as long
> as they meet its conditions. So if I don't have to sign anything, then
> the GPL isn't binding.
Exactly correct. If you copy a GNU program and distribute it you do not have to accept the GPL. However when RMS and his squadron of elite attack lawyer ninjas descend upon you for violating their copyright, smiting thee with their rightous fury, only saying "I
Re:What ethical problems? (Score:2)
If it's a unidirectional causality, then a moral assessment should never depend on any particular laws. The original poster claimed that unapproved decompilation was immoral. Then jmorris42 came around and started citing specific laws to prove that he had the legal right to do so.
What's wors
Re:What ethical problems? (Score:2)
> and proceeded to draw further conclusions from that assumption
No, read up the thread, in the very first post I excluded the case of corporate site licensing and other such real signed contract sort of software licensing it should be clear I am discussing consumer EULAs.
I assert that since EULAs are wrong on both moral and legal grounds, either of which alone is cause for ignoring them. I claim that I have as much right to r
Re:What ethical problems? (Score:2)
Especially seeing how Cadillac is a GM brand.
Re:What ethical problems? (Score:5, Insightful)
Re:What ethical problems? (Score:2)
I agree with you fully. Burying what you can and can't do in a EULA, one that you can't read until you take the software home and start installing it, is not what I have in mind. If they wanted to impose such conditions on the software's use, it would behoove them to have on
Re:What ethical problems? (Score:2)
Re:What ethical problems? (Score:2)
Re:What ethical problems? (Score:3, Insightful)
Re:What ethical problems? (Score:2)
Re:What ethical problems? (Score:2)
Regardless of the ethics... (Score:2)
Regardless of the ethics, reading other people's code is, IMHO, the single best way to learn how coding works. And decompiling from objec
This is one of the features of Java (Score:2, Insightful)
As systems get more open/advanced, the sources are more difficult to hide. In case of web apps, there is no need to decompile anything, the javascripts are
Re:This is one of the features of Java (Score:2)
I'm not sure why you think of NTFS file streams. That's a complete different issue. How would your trick work if the ASP pages are on a FAT file system? NTFS streams are interesting: I once used them in a pratical joke to consume all of somebody's disk space. They couldn't see in Explorer where it went! Incidentally, it's too bad that Macs can't make use of them for their resource forks when browsing
Re:This is one of the features of Java (Score:2)
Re:This is one of the features of Java (Score:2, Interesting)
Why? Well, Java bytecode is a lot more flexible than the Java language. Take exceptions for example. In the language we handle exceptions with try-catch-finally grammar productions. But in the bytecode we have a table that specifes ranges of bytecode addresses that mapped via an exception to a exception handler. The cute thing is that a "range of bytecodes" has nothing t
Re:This is one of the features of Java (Score:3, Insightful)
Web applications are typically implemented server-side. Javascript is client-side code.
Javascript != web applications
Perhaps what you are referring to is the source for ASP and JSP/servlets. There have been bugs in servlet containers (specifically, I bel
Re:This is one of the features of Java (Score:4, Insightful)
Even more advanced applications that use ASP pages that execute on the server, can be seen by changing the URL to list the source rather than execute them
Are you smoking crack?
You can't arbitrarily get at source code on someone's web server. Do you think eBay would want you seeing the passwords to their database servers?
Web apps aren't written in JavaScript. Sure, there might be some to drive calendar selection or something, but pretty much all real apps (shopping carts, etc.) are done server side.
Please get a clue and stop spreading your FUD around.
Additionally, this isn't a "feature" of Java. It's just a side-effect of its machine-independent bytecode. You could argue that it's not all that hard to reverse engineer compiled C - if you step it through a debugger you can see what it does fairly easily.
Systems being more "advanced" (let's wave our hands a little bit more) won't make it any more difficult to hide the source. Many many people run Java on the server side of web apps. It will always be impossible to view the source for such applications (unless the developers put it up for the world to see, of course). As for being "open", what do you mean? If you mean, "open source" then, well, duh...
Re:This is one of the features of Java (Score:2, Informative)
I think he's referring to an old bug on IIS that would allow you to view the contents of a file on the server. I believe it was a sample ASP that MS included to demonstrate come capability of ASPs.
I'm sure there are a few servers around that still have that enabled, but I'm sure most had that thing fixed 3-4 years ago.
DJ Decompiler and JAD (Score:3, Informative)
Oh, and obfuscation, blah, any good IDE (like IntelliJ IDEA) is able to help you work around this junk.
Being able to decompile code.... (Score:5, Interesting)
Anyhow, decompiling the classfile with "javap -c" shows that a couple of instructions get eliminated by dropping the explicit comparison to "true". So the classfile gets smaller, it loads faster, and (unless the JIT compiler is smart enough to do constant propagation on that conditional) it'll run faster, too.
Which is really surprising to me (Score:4, Insightful)
who, as a compiler hacker, would have expected an optimization pass to transform the first form into the second form before generating the bytecode.
Or more precisely, to understand that both forms are testing for the same thing, and to produce identical simplified bytecode.
Re:Which is really surprising to me (Score:2)
Yeah. Another result - this code results in the "if" statement body being optimized away:
but this doesn't:
But who knows - the JIT compiler may discard those bytecodes at runtime. Hard to say...
Re:Which is really surprising to me (Score:2)
Re:Which is really surprising to me (Score:2)
Almost all of the Java compilers out there do little to no optimizations while generating bytecode. Rather, the focus of the compilers is to generate bytecode that is easily understood and optimized by the virtual machine.
Since the bytecode for Java is a well-defined standard, there are many more bytecode processors for Java compared to say object-code proc
Re:Which is really surprising to me (Score:2)
On the other hand, also speaking as a compiler hacker, I should point out that just because an optimisation is possible, doesn't mean it's a good idea. When you add more optimisation, it costs. It's extra code that you have to write, test and maintain over the life of the compiler. If its entire purpose is to make the rare case of badly written code go faster, then you could quite legitimately turn around to the compiler user and say "don't do that".
As an example, a compiler could quite easily optimise
Re:Being able to decompile code.... (Score:4, Informative)
mov eax, isLoggable
cmp eax, 0
jnz skip_if
skip_if:
A check to true only changes the cmp to 1 instead of 0. It won't run any faster.
Re:Being able to decompile code.... (Score:2)
> machine level.
Yup, for assembler, that makes sense. But for Java bytecode, the explicit comparison is resulting in this:vsSo there's a least one extra instruction in there. Of course, again, what the JIT compiler might do with this is something else entirely.
Re:Being able to decompile code.... (Score:2)
The Java Language spec requires that a conforming compiler (not JIT, but source to bytecode compiler) do constant propagation.
Re:Being able to decompile code.... (Score:2)
Hm. I knew that the JLS required that in some circumstances - i.e., so that a switch statement can switch on a static final. What's the actual requirement, though? For example:Is a conforming compiler also required to make that transformation?
Re:Being able to decompile code.... (Score:2)
Re:Being able to decompile code.... (Score:3, Informative)
The Java compiler does some optimization - for example, when given this code:
it does algebraic simplification to reduce that assignment to an aload followed by a iconst_4 instruction. And it does some constant propagation so that this:
also gets simplified to the aload/const sequence. I guess it's just some choices the compile designers made on which things wer
You didn't sell it. (Score:5, Insightful)
>knowing how to decompile code is more about protecting your own source code.
There are many reasons to learn about, implement and use decompilers, but I don't think "to properly protect your intellectual property" should be one of them.
I'm got somewhat interested in this book (never heard about it before), but I think I'm going to pass. Sounds like the decompiling described is too much of a one-trick pony -- which is fine, it's about decompiling java after all -- but I'd really like something like an extension and update of Cifuentes work in book form, with the lessons from the IDA team too.
You know, from the beginning; starting with machine descriptions and disassembly for a generic front-end, efficent IR, and on up through the back end.
Now that'd be a tome [worth paying for].
In Soviet Russia... (Score:3, Funny)
Er... um...
the compiler decompiles you!
Er...
the java decompiles itself!
Ah, whatever.
- Kevin
You're getting it wrong (Score:2)
Maintainance nightmare (Score:2, Insightful)
Let me get this straight: the author recommends that 'honest' developers obfuscate their code?
I've read programs that I thought were obfuscated, but later found out were just poorly written. Other times I've run into programmers who, tin hats firmly affixed, went to great lengths to make sure no one learned their Merlinesque techniques for getting the most out of BASIC.
In context, the author seems to be talkin
Re:Maintainance nightmare (Score:5, Insightful)
Re:Maintainance nightmare (Score:5, Informative)
Re:Maintainance nightmare (Score:2)
>byte code, not source code
>feature of the language...
My comments were intended to be more general than the Java language. Whether done with a command line switch, on an IDE checkbox at packaging time, or by writing a quickie program to do it yourself (which amortized is on the same order of time), doing anything to seal up your object code is counterproductive.
Work to improve the code by revealing it, not by hiding it.
Unstated and implicit was: what if you lose the sour
Re:Maintainance nightmare (Score:2)
Normally, you would only do this after debugging your code. Obviously, it m
Re:Maintainance nightmare (Score:3, Interesting)
I had to decompile and patch a ridiculously buggy JDBC driver for a commercial database which had been run through an obfuscator, and ran into that issue. Renaming was rather a hassle, I must say.
I came to the conclusion that they had obfuscated their driver out of shame at the embarrasingly bad code, rather than to protect any intellectual property therein.
Re:Maintainance nightmare (Score:2)
Opposite of debugging (Score:4, Funny)
Hat tip to Jebediah Springfield.
Disagree (Score:2)
Re:Maintainance nightmare (Score:2)
Some user has in their
"That's not encrypted - that's a perl script I'm
working on." from crObar's now defunct matrix parody.
Consti-what? (Score:2, Funny)
I might have gone the bathroom, or perhaps had a snack. Maybe a nap.
Books online (Score:4, Informative)
And so I suggest a service like O'Reilly's Safari Bookshelf [oreilly.com]. It includes the full text of over 2,000 technical books, many not published by them. No killing trees, far less money than buying books, plus full text search.
Jad... (Score:5, Informative)
I have yet to try it on byte-code produced by non-Java languages, but I'd be interested to see the results...
(It sucks that it's no longer free. The version I've got I installed through Debian, for goodness sake, years ago. Does anyone know any free alternatives that work as well?)
Re:Jad... (Score:5, Informative)
Re:Jad... (Score:2)
It's the best java decompiler I have found.
Re:Jad... (Score:2, Informative)
Re:Jad... (Score:2)
Sun has this info for free... (Score:4, Informative)
Reverse engineering in Java is as simple as the compile process itself. Besides there are already free tools available so why bother??
Links to books on Amazon (Score:2)
Decompiling Java by Godfrey Nolan [amazon.com] on Amazon.
Another book on the subject is Covert Java : Techniques for Decompiling, Patching, and Reverse Engineering by Alex Kalinovsky [amazon.com]... probably more targetted at those who are already pretty familiar with things and want a more in-depth look.
(Yes, Slashbots, those are affiliate links... that doesn't make them any less useful though, does it?)
Re:Links to books on Amazon (Score:2, Insightful)
Yes, it does make them less useful. Because now it is impossible to tell whether you are saying things like "a more in-depth look" because you really mean it, or because you stand to make a quick buck by making bogus claims about the book.
Nothing personal, of course; you can probably see yourself why the rest of us simply can't know if you are being honest or running an astroturf con.
Nothing beats decompiling hacker code... (Score:3, Informative)
Its starts off with public variable names like:
public int YOU_DECOMPILING_NOOB =-1;
public int NO_SKILLZ_4U=100;
and then the obfusticator kicks in:
where a1 and al(with an L) are switched around.
The variable and method names look similar.
if (a1.b1.x.y == al.b1.xl.y2){
a1.v1.x.y &= al.b1.x1.y2 >> 0x4c;
a1.b1.x( al.b1.x2 );
}
Ouch! Also, I think every decompiler has some weaknesses and isn't able to undo all code. I know Jad has some limitations. Unfortunately, I wasn't able to get the source of the code that broke the decompilers
Why read a book. Just download Jode (Score:3, Informative)
on this topic, does anyone know how to: (Score:2)
By which I mean, there is a java applet running in my web browser. I'd like to decompile it and look over the source code. It's small enough I believe this would be informative. Is there a good way to do this?
Re:on this topic, does anyone know how to: (Score:2)
hmm (Score:2)
Want to keep your code to yourself? Use C++. (Score:3, Funny)
The books about decompiling Java are excellent advertisements for C++.
Or, another way to say it: (Score:2)
Advertisement: Want J. Random Hacker to fiddle with your code? Use Java.
Re:Want to keep your code to yourself? Use C++. (Score:3, Funny)
Enough obfuscation is equivalent to encryption. (Score:2)
The answer to Java decompilation is a write-once, read-whaaa? language.
Good obfuscation WORKS (Score:4, Informative)
Most obfuscators will make this track impossible, by doing things like using language keywords (while, for, if, and so on) for class/method/variable names, so that when you decompile the thing it cannot be recompiled. They also mix stuff around in the classfile enough so that figuring out what method is doing what becomes non-trivial -- stupid things mostly (like naming methods l1(), ll(), I1(), Il(), etc.), plus a few tricks to stop JAD from fully decompiling the class.
Enough of these little things add up to make the work involved in altering the decompiled class excessive and difficult.
The more sophisticated Java cracker doesn't bother. They decompile enough source to get their bearings, then edit the appropriate bytecode directly, with a classfile editor. Fortunately, most people with this level of experience can just pay for the frickin software they want.
I'm actually not obfuscating my Java code yet, but I'm going to start... it's just too easy to crack Java code without it. yGuard obfuscator [yworks.com] is pretty decent LGPL one, that can run as an Ant task.