Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am curious enough to considering not evening writing certain code in Java because of how easy it is to decompile. Is there a way that I can write in Java and not have to worry about decompilers? I understand anything can be reversed engineered given enough time, so what I am asking is: are Java class obfuscators effective enough to deterrent decompliation?
are Java class obfuscators effective enough to deterrent decompliation?
I would say "no". When I decompile source code with the intent of trying to figure out how someone did something, I already know what I'm looking for. So I don't have to understand the entire program -- just the one piece that's of interest to me at the time. With enough puzzling over methods and backtracking a bit up the call chain, it's usually possible to determine what's under the hood without an excessive amount of effort.
If your question is Can I ensure that no one can hack my code , the answer would be NO..
Whether it is in JAVA or Visual C++ .
As long as your software which is made up of byes or bits is directly accessible by the hacker.
The REASON is simple.
However you encoded , that can be decoded.
The best strategy could be to make a web service and deploy your secret logic there.
Let others use your service without having access to how you wrote.
Obfuscation, in Java and other languages, is just a deterrent. It simply raises the bar for the attacker. That doesn't mean obfuscation has no value, it just isn't a guarantee.
What are you trying to protect and what type of market are you targeting ?
Obfuscation to protect a license algorithm in a market that it full of pirating isn't going to mean that much. However, for SMB, it may be a enough to cut out most of the casual pirates.
If you are trying to protect IP from competition, I see two answers. The idea, will be hard to protect. A capable engineer looking at the code will figure out the gems of the logic and be able to reimplement. Obfuscation will make it a lot harder for people to just pick up the code and include it in their own product. The maintenance costs will continue to grow as they attempt to make changes (I'd say that is also true for cleanly decompiled code).
The java products I develop for my company are obfuscated. Have they protected us from theft...I doubt it. But, in the context of our development costs, the obfuscation wasn't that expensive. A small bit of protection for a small price isn't a bad trade-off.
From personal experience decompiling Java, I will say that obfuscation can make someone's attempts to decompile very very irritating and difficult. The most irritating to me is when the final builds class files are all named "a.class, b.class, c.class" and so on, and a large amount of dummies are thrown in. In terms of in code obfuscation, try/catches do a fine job of messing stuff up for the decompiler.
In general, anything you decompile will not be compilable, but will give you hints as to the general workings of the program.
"Effective enough" depends entirely on how effective you need it to be. And that depends on what you are protecting, and from whom. None of the conventional methods (obfuscation, encrypting the bytecodes, compiling to an "exe") will stop a skilled and determined attacker with enough time and incentive. But that pretty much applies to all forms of programming. (You can disassemble or decompile C/C++ apps as well ...)
The only way you can protect against a serious reverse engineering effort is to use a secure execution platform; e.g. using something based on TPM. Even then, if the bad guys can attach a logic analyser to a system running your code, they can (in theory) capture the native code being executed and then start on the reverse engineering path.
EDIT : Someone has reportedly succeeded in breaking a popular TPM chip, using an electron microscope; see this Register article. And interestingly, his original motivation was to hack Xbox 360 consoles!
Frankly speaking No. No matter how ridiculously you obfuscate the code, if someone knows he can make a million dollar out of your code, he will decompile your class files and get the code.
There are alternatives though:
Convert your java program to exe beofre distributing. You must know that there are catches here.
Encrypt you class files with a key. Make a custom classloader that can decode the class files using the private key before loading it into memory. There are two problems here, a) load time increases, b) how will you hide the private key.
if you read my post https://stackoverflow.com/a/26717791/2132826 you will see that I couldn't find one good java de-obfuscator that actually works as expected.
so the current answer is: NO.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
First of all, I love Python, and I currently use it for most stuff. However, as a PhD student, I mostly implement prototypes for testing and evaluating ideas. This also includes that I'm usually the only one coding, and that -- while I certainly try to write half-way efficient code -- performance is not a primary issue. And for quick prototyping, Python is for me just neat.
Now I consider to go with some of my stuff more "serious", i.e., to bring it into a productive environment, make it better maintainable, and maybe more efficient. So I wonder if it's worthy to rewrite my code to, say, Java (with which I'm also reasonably familiar). I know that Python is not slow, but things like Java's static typing including seems to make it less prone to errors on a larger scale, particularly when different people work on the same project.
It's only worth it if it solves a real problem, note, that problem could be
I want to learn something better
I need it to go faster to reduce power requirements in my colo.
I need to hire more people and the talent pool for [insert language here]
is too small.
Insert innumerable real problems here.
Python and Java are both suitable for production. Write it in whatever makes it easiest to solve the problems you and or your team are facing and if you want to preempt some problems make sure you've done your homework. Plenty of projects have died because they chose C/C++ believing performance was going to be a major factor without thinking about the extra effort involved in using these language well.
You mentioned maintainability. You're likely to require more code to rewrite it in Java and there's a direct correlation between Bugs and LOC. It's up for debate which one is easier to maintain. I'm sure both camps believe theirs is.
Of the two which one do you enjoy coding with the most?
The crucial question is this one: "Java's static typing including seems to make it less prone to errors on a larger scale". The crucial word here is "seems." Sure, Java will help you catch this one particular type of error. But how important is that, and what do you have to pay for it? The overhead imposed by Java's type system means that you have to write more lines of code, which means reduced productivity. I've used both and I have no doubt that I'm more productive in Python. I have found that type-related bugs in Python are generally easy to find and fix. Keep in mind that in a professional environment you're not going to ship code without testing it pretty carefully. The bottom line for a programming environment is productivity - usable functionality per unit of effort, not the number of bugs you found and fixed during development.
My advice: if you have a working project written in Python, don't rewrite it unless you're certain there's a benefit.
Java is inherently object oriented. Alternatively python is procedural.
As far as the ability of the language to handle large projects you can make do with either.
As far as producing more usable products I would recommend java script as opposed to java because of its viability in the browser. By embedding your js in a publicly hosted website you allow people with no coding knowledge to run your project seamlessly in the browser.
Further more all the GUI design features of HTML are available at your disposal.
That said any language has it's ups and downs and anything I've said here is simply my perception.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
So is a decompiler really a thing that gives gives the source of a compiled/interpreted piece of code? Because to me that sounds impossible. How would you get the names of the functions, variables, classes, etc if it is compiled. Or am I misinterpreting the definition? How does it work? And what is the general principal behind making one?
You're right about your definition of a decompiler: it takes a compiled application and produces source code to match. However, it does not in most cases know the name and structure of variables/functions/classes--it just guesses. It analyzes the flow of the program and tries to find a way to represent that flow through a certain programming language, typically C. However, because the programming language of choice (C, in this example) is often at a higher level than the state of the underlying program (a binary executable), some parts of the program might be impossible to represent accurately; in this case, the decompiler would fail and you would need to use a disassembler. This is why many people like to obfuscate their code: it makes it much harder for decompilers to open it.
Building a decompiler is not a simple task. Basically, you have to take the application that you are decompiling (be it an executable or some other form of compiled application) and parse it into some kind of tree you can work with in memory. You would then analyze the flow of the program and try to find patters that might suggest that an if statement/variable/function/etc was used in a certain location in the code. It's all really just a guessing game: you'd have to know the patterns that the compiler makes in compiled code, then search for those patterns and replace them with equivalent human-readable source code.
This is all much simpler for higher-level programs like Java or .NET, where you don't have to deal with assembly instructions, and things like variables are mostly taken care of for you. There, you don't have to guess as much as just directly translate. You might not have exact variable/method names, but you can at least deduce the program structure fairly easily.
Disclaimer: I have never written a decompiler and thus don't know every detail of what I'm talking about. If you are really interested in writing a decompiler, you should get a book on the topic.
A decompiler basically takes the machine code and reverts it back to the language it was formatted in. If I'm not mistaken, I think the decompiler needs to know what language it was compiled in, otherwise it won't work.
The basic purpose of the decompiler is to get back to your source code; for example, one time my Java file got corrupted and the only thing I could so to bring it back was by using a decompiler (since the class file wasn't corrupted).
It works by deducing a "reasonable" (based on some heuristics) representation of what's in the object code. The degree of resemblance between what it produces and what was originally there tends to depend heavily upon how much information is contained in binary it starts from. If you start with basically a "pure" binary, it's generally stuck with just making up "reasonable" names for the variables, such as using things like i, j and k for loop indexes, and longer names for most others.
On the other hand, a language that supports introspection needs to embed a great deal more information about variable names, types, etc., into the executable. In a case like this, decompiling can produce something much closer to the original, such as typically retaining the original names for functions, variables, etc. In such a case, the decompiler can often produce something quite similar to the original -- possibly losing little more than formatting and comments.
That depends on what language you are decompiling. If you are decompiling something like C or C++, then the only information provided to you is function names and arguments (In DLLs). If you are dealing with java, then the compiler usually inserts line numbers, variable names, field and method names, and so on. If there are no variable names, then you would get names like localInt1, localInt2, localException1. Or whatever the compiler is. And it can tell the spacing between lines, because of the line numbers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
in private and in companies it is over and over again a problem that I or we developers comment in fact our code but generally nobody knows exactly how the code of the whole project works together. When I write my own code and the project is getting bigger I sometimes have this problem too. Although I write tons of comments, after 3 months you don't know what the whole thing exactly does, that means how the different methods and classes work together.
How do you solve this in your company or in private (if there is just marginal project development and no requirements specification). Or do you have always such a good project development with contract document and requirements specification that you don't have to worry about that?
Code complete can explain the solution to your problem better than I ever could.
I find the best way to solve this is to write a functional test using a unit test framework.
In a functional test you write a test which loads up several if not all the core components laid bare. This shows that all the components work correctly together but also you get a documents which shows you in one place how everything connects.
Depending on how complex you interactions are, you may not be enough and you need to document it. Personally I would prefer to make the code simple so that documenting it is not really needed or is relatively easy to explain.
If documenting it sounds too hard, its time to refactor your code so that its not.
Take your time a create some short and simple design documents, add some UML diagrams to just show the basic ideas behind the whole application. This would give new team players a quick overview. Publish this documentation on an internal wiki and encourage the team to enhance, if necessary.
Then, as Peter suggested, some well documented test cases really help: Read the test code and learn how to use the API. (and, as a secondary effect, test the code ;-) )
I would not put too much effort on comments, especially on line comments. The tend to become out dated, because no unit test verifies that line comments are still valid and, even worth, no one ever deletes unnecessary comments.
Good question. Part of what you are asking relates to code maintainability. In my view the two main things you can do to improve this are:-
Write some design documentation
Develop maintainable and clearly written code
From past experience the first item is very often neglected on software projects due to time constraints, but I think that if you can produce at least a class diagram of your system, then this is worth a lot in terms of understanding how objects interract when you revisit the code in a few months. Depending on the complexity, then sequence diagrams can also be useful. Producing this documentation will also be of benefit to new members of the team, in quickly having an overview of how the software is structured.
I can't stress enough the importance of writing clear and maintainable code. My eyes were recently opened when I read Clean Code by Robert Martin. You owe it to yourself and your fellow developers to read at least the first couple of chapters in this book. That alone will immediately improve the readability and maintainability of your code.
The idea is that the code should read almost like a narrative, where methods follow in a logical order, are short, appropriately named, and take few parameters. Doing this almost eliminates the need for code comments, and improves the code structure.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am constantly reading about how much Cobol code is still in production. And the main reason that it hasn't been updated into am more modern language is that it would take too long/cost too much.
My question is: If there was a tool that converted Cobol to, say, Java, would any organizations find it useful? Or would they rather continue maintaining what they know already works?
Currently, a large volume of the COBOL code (I'd estimate well over 90%) is untestable.
No one knows what it really does.
They know that -- minimally -- it does the expected job most of the time. And when it doesn't, the bugs are known.
Worse, some percentage of COBOL is just workarounds for bugs in other parts of the COBOL.
Therefore, if you subject it to any scrutiny, you'll find that you don't know what's really going on. You can't create test cases.
Indeed, you'll find that most organizations can't even agree on what's "right". But they're willing to compromise on what's available.
The cost and risk of examining the core business processing is unthinkable.
Any conversion tool would have risks associated with it, and the resulting code would have to undergo a lot of testing.
Given that a lot of these systems are in use daily to run a business, a lot rides on the continuing operation. So it is not just "how long" or "how expensive", but can we trust it to work 100% the same.
One will always find tools to convert one language to another - they usually go by the term "compilers".
There is always a shortcoming with compilers that have to perform the task of converting code in language X to language Y, especially when the said code was written by a person. That shortcoming happens to be the fact that readbility is often lost in the process of translation. There is no guarantee that the code compiled from COBOL to Java will be understood by any programmer, so in effect the cost of translation has actually increased. In fact, it is difficult to define readability in such a context.
Lack of readability and understandability translates into lack of knowledge of runtime behavior of the translated code. Besides there is no guarantee that people understand the original code completely; surely they do understand bits and pieces of it.
Probably a little of both. There are companies that provide tools and services for conversion using both automated and manual techniques.
Many companies, however, follow the "ain't broke" philosophy, which is likely as wise as anything. Especially since many conversions result in attempts to "improve" the existing system or try to introduce modern software design/construction philosophies and result in a mess.
Many systems written in Cobol have many transactions going though them. They work well on the mainframe platforms that they run on. It would be risky to change them just for the sake of change.
I think some organizations could find it useful, particularly organizations where interfacing with/designing around legacy code has become more costly and problematic than converting the code to Java (or another language)
while ( (CostToPortToJava > CostOfNotPortingOverTime++) && DoesLegacyCodeStillWork() )
{
StayWithLegacyCode();
}
PortCodeToJava();
There are a few factors here:
Cobol program files are super long and just about always on ultra-secure mainframes. Usually the Java developers don't have access to them.
Colleges & Universities haven't taugh Cobol for more than 20 years. As a result, all of the really top-notch Cobol developers have moved up in their companies to be replaced with a bunch of tech school grads. These people didn't love programming enough to be hackers (or they'd do C, Python, C++, whatever and wouldn't have taken a course) or enough to go school (and be Java, .Net, Python, whatever).
Java developers generally lose their minds when they look at Cobol programs in their 50,000 line glory, so they aren't any help.
There really aren't any documents, and the logic is so tight in these programs that you should really just read them and convert them.
Most of these companies are financial companies where the best way to blowup and not be in the industry anymore is to screw something up. Good way to screw something up is to tack something like converting a critical task from Cobol to Java.
It's going to take a long time - every so often, part of one of the programs stops working or can't do something, and it gets replaced. I don't see a lot of senior managers having the stomach for the all of the FUD in one of these projects, and the timeframes are pretty long in terms of return on money spent.
COBOL is, in effect, a superb DSL (domain specific language).
It's domain is business rules as embedded in (mainly) backend applications.
Find another language that....
is feature rich in that specific domain
has some years of actual, applied, experience behind it so all the gotchas are cured or out in the open
has a TCO (total cost of ownership) lower than the existing COBOL legacy mountain
is cost-effective to convert to
....and you will have the killer application for backend business applications.
Something to realize about old COBOL applications, besides the language dissimilarity, is that at a lot of data structures built in these applications don't conform to any later RDBMS structure, so really you would be talking about rethinking a lot of the underlying architecture and design, not just changing the language syntax, and replacing that would have a lot of performance risk once it hit real world loads, even if it could be QA'd sufficiently.
The bottom line is that it is more economical to bolt on new features in a modern language than rewrite it. As long as that continues to be the case, COBOL will continue to live on.
Cobol has the advantage of being fast for moving data around, which is what that kind of applications tend to do a LOT. Also the machines are designed for I/O, not processing speeds. Hence, any translation to another language will most likely be slower than the Cobol counterpart on identical or similar hardware, leaving no reason to do so.
Let me ask a counter question: WHY convert it, if you have something in place that works?
(Similar to tearing down a bridge ever 10 years just for rebuilding it again right afterwards - it is usually always cheaper just to maintain what you have).
There are translators around which can be modified at little cost to make it run on a specific machine or operating system and some are available from England and can be run there or on site. Standard versions exist for the major models (anyone can contact me about them). Cobol to another language source code or script is relatively easy to do automatically and would produce a text file for import into a source file on the target machine with 95 percent or more code compatibility. Simple manual amendments are all that are necessary before running the compiler or JIT software to achieve a new program - do not forget to amend the job command language or macro for mainframe jobs when testing or going live. New cobol compilers exist for ICT/ICL mainframes and one or two others and these compile faster than the old software and sometimes the new compiled program can run several times faster.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm working on getting an Introduction to Groovy presentation ready for my local Java User's Group and I've pretty much got it together. What I'd like to see is what you all think I just have to cover.
Remember, this is an introductory presentation. Most of the people are experienced Java developers, but I'm pretty sure they have little to no Groovy knowledge. I won't poison the well by mentioning what I've already got down to cover as I want to see what the community has to offer.
What are the best things I can cover (in a 1 hour time frame) that will help me effectively communicate to these Java developers how useful Groovy could be to them?
p.s. I'll share my presentation here later for anyone interested.
as promised now that my presentation has been presented here it is
I don't know anything about groovy so in a sense I've qualified to answer this...
I would want you to:
Tell me why I would want to use Scripting (in general) as opposed to Java-- what does it let me do quicker (as in development time), what does it make more readable. Give tantalising examples of ways I can use chunks of scripting in my mostly Java app. You want to make this relevant to Java devs moreso than tech-junkies.
With that out of the way, why Groovy? Why not Ruby, Python or whatever (which are all runnable on the JVM).
Don't show me syntax that Java can already do (if statements, loops etc) or if you do make it quick. It's as boring as hell to watch someone walk through language syntax 101 for 20min.
For syntax that has a comparible feature in Java maybe show them side by side quickly.
For syntax that is not in Java (closures etc) you can talk to them in a bit more detail.
Remember those examples from the first point. Show me one, fully working (or at least looking like it is).
At the end have question time. That is crazy important, and with that comes a burden on you to be a psuedo-guru :P.
I'm not sure about how the Java6 scripting support works but I'm fairly sure it can be made secure. I remember something about defining the API the script can use before it's run.
If this is the case then an example you could show would be some thick-client application (e.g. a music player) where users can write their own scripts with an API you provide them in Groovy which allows them to script their app in interesting and secure ways (e.g. creating custom columns in the playlist)
I'd go for:
Closures
Duck typing
Builders (XML builder and slurper)
GStrings
Grails
I'd mention the following things in addition to what has already been stated:
GDK - extensions/additions to existing JDK classes
Interaction between Groovy and Java code (basically a non-issue)
Compiling Groovy code to Java .class files
XML parsing and mechanisms for accessing document content
One thing I like doing with Groovy is implementing an interface defined in Java as a map from method names to closures. It's a cool thing you can do with Groovy, but probably well beyond an introductory presentation though.
Include an example of how making Java code more groovy takes away soooo much code. Wait for them to pick their jaws up off of the floor before continuing. Scott Davis has a simple example at the beginning of Groovy Recipes that takes 35 lines of Java or 3 lines of Groovy.
You should definitely show them how to create a quick Grails application. Two domain classes that are related. Build a basic CRUD app. Explain that tables are being created behind the scenes using GORM(Hibernate). Then explain that you can create a war file and deploy it as you would any other Java war file. You can also add Grails/Groovy to an existing Java/JSP project so it doesn't require a huge commitment or paradigm change.
Groovy/Grails is simply Ruby/Rails for Java people. I'd cover the plugins for Netbeans/Eclipse too. Groovy/Grails are just now getting full support in the major IDE's.
Finally, if you can find a good diagram that shows how Grails is built on top of Spring, Hibernate, Quartz, Sitemesh and Groovy, I think people will understand that there is a treasure chest waiting to be unlocked.