Related
I learnt swing basics and event handling basics from head first java...
Then i read a few tutorials on swing app development using netbeans...
and i loved it as i don't have to care about layouts and stuff...
But i read in one of the forums, that i should learn swings properly rather than using netbeans directly...
This confused me a bit....
Please suggest the best way to master development of swing apps....
thanks in advance
Well, I see I'm going to run counter to the majority here ;-)
Hand coding GUIs is a pain in the ass. Anything that makes that task easier is a good thing in my book. When you're just starting, having a generated GUI lets you get up and running faster.
GUI builders handle the really repetitive work and prevent you from doing the most common dumb things. The downside is that same approach will also prevent you from doing the really clever things. Eventually, you will encounter something that you cannot do through the GUI builder and you will need to poke into the code. So, you can't treat code generators like black boxes where you don't need to know what magic happens inside. At minimum, you need white boxes. Let the GUI builder do its magic, but understand that magic and its limitations.
Practice by generating a very simple GUI. Walk through the code and understand what it does. Make a change through the builder and see how the generated code changes. Try changing the code yourself to confirm you understanding is correct. *
If you don't understand something, hit the JavaDocs, the Swing Trail, or browse through the Java2S Swing Tutorials.
If you're still stuck try the kind folks at Java Ranch, or here on StackOverflow.
* Netbeans puts the generated code in guarded blocks and will not let you edit them directly. However, you can open the file in another editor to test a change. Also, you can do quite a lot to influence the code generation using the code tab in the properties window.
It depends on what you see as your goal.
There is no "perfect" approach to get comfortable using Java and swing, it always depends on what you want the outcome to be like.
Most enterprises depend on stability and speed, programmers need to write code fast and stable. If you write complex interfaces by hand it gets ugly when it comes to speed and precision at the same time. You can never write better code in terms of "it is working" then the netbeans gui builder can. Also, no one will probably have a look at your code once the application is up and running.
If you want to get to know swing only for the purpose of knowing it with no deeper intention what so ever, I'd recommend learning it by heart without netbeans as you'll probably familiarize yourself with most of it's functionality quicker then the other way around.
On one hand, if I want to learn something, I want to learn it from scratch, so I would probably go with writing swing-code myself and in the end using netbeans to generate it when I am fully able to comprehend what is generated.
On the other hand, if I need to write applications quick and am not paid to go into any details, I'd simply use netbeans.
I think you have answered yourself... you want to master development of swing apps...
everything that you do by autogenerating without knowing why or how is not mastering in my opinion ;)
If you want to be master, then you should at least know how to do it with your bare hands. Moreover, it will also help you if you will use other gui toolkits (main principles of gui toolkits are more or less the same, imho).
I wish to create shareware software that contains a registration algorithm. I am looking for a programming language, that cannot be easily decompiled into readable code. For example, C# can be decompiled into readable code.
What are my options?
Edit: I'm looking for something that can be only decompiled into assembly. Delphi, for example, cannot be decompiled like C# or Java, but from what I've heard, Delphi is dying.
Delphi is not dying, it is alive and well.
As is the community, at delphifeeds.
You can also see more delphi projects, Freeware, shareware and commercial at the Delphi Wikia.
Thus I'd say Delphi is a very good choice for Software Development. Freeware, Shareware or Commercial.
Update:
On September 1st 2011 Embarcadero released Rad Studio XE2. This released adds 64 Bit Compilation, Livebindings, Native Mac OSX compiling, IOS (via XCode) and a whole lot more to the already powerful delphi Dev environment.
If your CPU is able to see the code and run it, by definition, a sufficiently talented person can do it too.
You can, however, make it harder by running your code through an obfuscator.
I'd suggest the language of business and economics can protect your program.
If you are targeting consumers, and price it at say $10, almost all people would find it easier to pay you the $10 vs going into your program and reverse engineering it.
If you are targeting corporations, and say pricing it at $10,000, it just has to be easier to get the purchasing department to approve the payment than to reverse engineer your code. For real companies who would purchase your product, it's not worth the audit risk to have unlicensed code running.
Lastly, what are the costs/benefits of protecting your code? If you write your program in assembly instead of C#, you might have far higher production costs, while reducing the chance of reverse engineering. However, does this cost outweigh the potential lost sales? Could this time be better spent adding value for people who will buy the product? Generally, trying to sell your product to people who are never pay for software is not a economic strategy.
You could write it in Perl.
(I kid, I kid! Put down the pitchforks!)
As the others said, Delphi is NOT dying.
As the others said, there is no bulletproof method.
As the others said, there are tools to make the life of a cracker much harder.
But what the others didn't say is:
Java, .NET (etc.) obfuscation is rather a toy compared with obfuscation toys for eg. Delphi and other native solutions. (of course YMMV)
A very good technology to relatively protect your executable can be found here.
Repeat after me: "Obscurity is not security."
You would be better off using a hard encryption algorithm (where "hard" doesn't mean "difficult", but "not bi-directional; not easily reversible".
Isn't this logically impossible?
If you can run the code, you can get the instructions being executed by your CPU. At that point, your algorithm is readable, for some definitions of readable.
No language is capable of that AFAIK.. since it's impossible as it can always be reverse engineered.. though a good number of developers would cry if you coded it in brainfvck though.
"I'm looking for something that can be only decompiled into assembly."
Try writing your program in assembly. That is the best possible solution.
if you really concern about people disassemble your software, make your software as a service (SaaS) http://en.wikipedia.org/wiki/Software_as_a_service
Try finding an obfuscator. As the name suggests it obfuscates the code enough that reverse-engineering it will not be trivial.
Or use C/C++. Those can be disassembled, but that's it.
Of course, this is just enough to keep the not-sufficiently-competents from understanding and reverse-engineering the code.
As Dominic said, if you can run it, it can be decompiled.
That said, I believe there are tools that obfuscate the compiled code and make it more difficult for someone to disassemble and reverse or take apart a registration process.
For example, I believe that major companies like Adobe and Microsoft use products like this, in order to make it much more difficult for folks to disassemble and crack their programs.
It's like security or cryptography or even the locks on your car/house - someone with enough time and resources can probably break through anything.
You just need to tilt the curve enough to make it sufficiently unattractive for anyone to really try, so that they'd be more likely to move onto easier targets.
I am going to make the assumption that because you're writing shareware and you mention a registration algorithm you are wanting to protect your software from a keygen or patch that bypasses the restrictions on your trial versions.
Really the most you can do is deter. Like others have mentioned there are obfuscation techniques available, but they are not preventative. There are commercial software packers available which compress the file and make it initially unreadable. But the program has to be decompressed at some point so the machine can run it, so it's still reversible.
And that is pretty much the crutch against any of the anti-reversing techniques you'll see. It has to be interpreted by the machine at some point. More modern packers use anti-debugging techniques to deter the more novice reversers. But these techniques end up being documented rather quickly on popular reversing sites. Many of the techniques are bypassed with nothing more than a simple debugger plugin.
The only way I can think of to protect your executable from being arbitrarily reversed is to run the whole thing on a server you control and just pipe the output to users. But that's not always feasible.
As far as your language options go, take a loot at this. I can't really speak to how complete it is but I'm sure some others can add languages they think of.
If you're lookig "for something that can be only decompiled into assembly", that essentially means that you want to use a language that gets compiled (or assembled) directly into a native code executable.
The usual prime suspects then are C, C++, Delphi, VB6. Of course, also assembly meets your criteria, although I doubt you'd want to write any project of decent size in it.
Very simple:
No Programminglanguage,No Programm can Protect your Software.
The Software Cracker will reversengine your App till it is just asembler and will crackt it.
All code can be read back in assembly. Someone can reverse engineer your application and see what the machine is doing.
This is not so much a matter of choosing the right language as it is finding a tool that will do code obfuscation for you. Nothing is bulletproof, but there are efforts to accomplish this sort of thing.
Eg. see this research project about Java code obfuscation.
You can't be 100% sure nobody will able to read your code, but you can make it very hard. You can encrypt your code and modify it during run time.
For example I have not heard of any successful attempts to reverse engineering Skype.
You could always write it in APL. You could deliver the source and still no one would be able to understand it.
Any code running on client-side can be reverse engineered with enough trial and error. In my opinion, make the client-side code contain only the GUI code, while running the actual security requiring authentications etc. on serverside.
On the other hand, if your app's a service which runs on the client-side, such as a game, CAD, POS or anything that needs to have high quality code on the client-side, I'd recommend storing process outputs on your server-side with an encrypted upload tool, then authenticate the client's key/account data every-time before sending their data back? It is an overkill for most projects though.
So I've spent the last few days looking for a way to create a simple image drawing app with wxPython, and I think the key to doing just that is understanding how to use Device Contexts. The problem is that the wxPython demo program doesn't demonstrate DCs, and the docs for both wxPython and wxWidgets don't explain as much as I'd like to know so I've decided to try and 'reverse engineer' an existing app to see how its done.
The first problem I have is that I don't know of any drawing apps written in wxPython (or any written in Python for that matter o.o), and the second is I don't know how I'd go about doing it. Am I right in saying that I'm going to need a copy of an application's Python source and something like Winpdb? What do professional programmers do when they find themselves in a situation like mine, needing answers that the docs don't provide?
If you need to understand the concepts, but the docs don't cut it, it's worth it to look at docs for similar APIs. In the case of drawing contexts, there are a lot of similar APIs in other languages. Java has Swing for instance.
Reverse engineering is easier in tools that aren't big event-driven GUI things. The converse is that event-driven GUI things tend to copy each other, so you only need to figure them out once or twice before they all make sense.
In .NET world, I have Reflector as indispensable tool.
In my company, we use to program SharePoint websites. There are many "gotchas" we just figure out by reverse engineering that product assemblies, exactly because documentation is plain wrong, just missing or simply doesn't exists.
I think I'm in somewhat of a unique situation: I have a decent amount of coding experience in C/C++ in a Linux environment. However, I don't really have "project experience." For example, I'm familiar with the concept of version control, but I've never used any. Or, i've never worked on a project with more than a half dozen source files.
So, where I am now is that I'm working on this project with a large amount of code already existing. I have to write all my code in a windows environment using Visual Studio 2008 (Visual C++ to be specific) So I have a few questions:
How do integrate the already existing code into VC++? I'm using tortoise SVN and I have all the code on my machine...
Does anyone have any general advice on moving from small projects to larger projects?
Any help/advice would be greatly appreciated
Some of the keys to coming to grips with a large codebase:
Learn the ins and outs of source control. For now, start with just learning how all the SVN commands work. SVNBook is a good resource for this. Use VisualSVN or a similar plugin to interact with your repository within your IDE (Tortoise is still useful when you want to interact from elsewhere). Down the road, you'll want to become intimately familiar with branching and merging (and the tools for doing so quickly and correctly), and perhaps learn a DVCS (distributed version control system) like Git or Mercurial. This will at the very least expand your mind a bit, and likely teach you some lessons that will be useful even in projects where you use more traditional (centralized) version control.
Learn how to quickly look for things, find the declarations of unfamiliar classes and variables, and trace the execution of the larger application. There are lots of approaches for this, and you'll likely use most of them at one point or another, but some of them are your IDE's built-in features (most of them are quite robust in this regard, you should be able to right-click on a class name and find its declaration easily), grep and the like (ack is a variant that is very suitable for code spelunking), and CTAGS if you swing that (C/C++) way.
Learn the basics of unit testing, maybe even try out a framework like NUnit. Personally I'm not big into unit tests, but I recognize their utility and many swear by them, so don't knock it 'til you've tried it, at least.
Even if you're a flawless programmer with a robust battery of unit tests, large codebases demand a higher level of debugging skill, due to the inherent complexity of the problems that crop up. Whether it's learning how to write concise, descriptive debug printf()-like statements, becoming more familiar with your debugger, or even learning the ins and outs of your language (e.g. the corner cases of the type system/object model) can be helpful in unwinding these complex issues.
Unfortunately, I haven't used Visual Studio, but I think getting to know your IDE's project import/migration flow will be instructive too. Maybe somebody else will chime in with more concrete advice on that front. The process can be onerous, especially if you had a non-standard custom build system before and you want everything to be done The One True Visual Studio Way henceforth, but the tools for automatic dependence extraction from code are getting better and better.
The ideas already given are very good. But you also might want to read Mike Gunderloy's Coder to Developer. From your description of your current experience, I think you'll find it useful. Also read The Pragmatic Programmer; I keep it in my office by my desk, and often find myself loaning it to younger developers.
Just dive in. Hopefully whoever has been working on this project so far organized the code into logical groups (namespaces, class hierarchies, folders).
I'll also second Matt J on learning how to use the IDE: I'm not familiar with Visual Studio specifically, but there should be contextual menu items when you click on a class or method to take you to the place where it was declared, and from there to the classes it was derived from.
Get version control set up first though: you'll feel more comfortable poking around once you learn how to "revert" ;)
I have been using VisualSVN for quite a while without problems. It integrates perfectly with vs2008. As for moving on to large projects, a great way to see how things are done is to download the source of a decent size existing project and see how it was put together. After you've got a good idea of how things are structured, the best thing you can do for yourself is to write code. Brainstorm a project and go at it. Depending on how you feel about your outcome after completion, you could use it as part of your portfolio as well.
Unit tests. Use them or you'll regret it.
Get to know Visual Studio well, if you live in it, you really have to know it well.
AnkSVN is a free plug-in for Visual Studio 2008, and it works very well.
Also, Refactor for C++ is another free plug-in and one of the only ways to get refactoring support in Visual C++.
Also, you will soon learn that on large projects, 80% of your time is going to be spent doing code maintenance, so do yourself a favour and make your code a place in which you want to live, not a place of terror that you shrink back from. Clean code, the occasional comment, and unit tests will go a long way to making you want to get up and go to work in the morning, rather than dreading that you have to work on that monstrosity where anytime you touch anything it breaks.
I mean, I always was wondered about how the hell somebody can develop algorithms to break/cheat the constraints of legal use in many shareware programs out there.
Just for curiosity.
Apart from being illegal, it's a very complex task.
Speaking just at a teoretical level the common way is to disassemble the program to crack and try to find where the key or the serialcode is checked.
Easier said than done since any serious protection scheme will check values in multiple places and also will derive critical information from the serial key for later use so that when you think you guessed it, the program will crash.
To create a crack you have to identify all the points where a check is done and modify the assembly code appropriately (often inverting a conditional jump or storing costants into memory locations).
To create a keygen you have to understand the algorithm and write a program to re-do the exact same calculation (I remember an old version of MS Office whose serial had a very simple rule, the sum of the digit should have been a multiple of 7, so writing the keygen was rather trivial).
Both activities requires you to follow the execution of the application into a debugger and try to figure out what's happening. And you need to know the low level API of your Operating System.
Some heavily protected application have the code encrypted so that the file can't be disassembled. It is decrypted when loaded into memory but then they refuse to start if they detect that an in-memory debugger has started,
In essence it's something that requires a very deep knowledge, ingenuity and a lot of time! Oh, did I mention that is illegal in most countries?
If you want to know more, Google for the +ORC Cracking Tutorials they are very old and probably useless nowdays but will give you a good idea of what it means.
Anyway, a very good reason to know all this is if you want to write your own protection scheme.
The bad guys search for the key-check code using a disassembler. This is relative easy if you know how to do this.
Afterwards you translate the key-checking code to C or another language (this step is optional). Reversing the process of key-checking gives you a key-generator.
If you know assembler it takes roughly a weekend to learn how to do this. I've done it just some years ago (never released anything though. It was just research for my game-development job. To write a hard to crack key you have to understand how people approach cracking).
Nils's post deals with key generators. For cracks, usually you find a branch point and invert (or remove the condition) the logic. For example, you'll test to see if the software is registered, and the test may return zero if so, and then jump accordingly. You can change the "jump if equals zero (je)" to "jump if not-equals zero (jne)" by modifying a single byte. Or you can write no-operations over various portions of the code that do things that you don't want to do.
Compiled programs can be disassembled and with enough time, determined people can develop binary patches. A crack is simply a binary patch to get the program to behave differently.
First, most copy-protection schemes aren't terribly well advanced, which is why you don't see a lot of people rolling their own these days.
There are a few methods used to do this. You can step through the code in a debugger, which does generally require a decent knowledge of assembly. Using that you can get an idea of where in the program copy protection/keygen methods are called. With that, you can use a disassembler like IDA Pro to analyze the code more closely and try to understand what is going on, and how you can bypass it. I've cracked time-limited Betas before by inserting NOOP instructions over the date-check.
It really just comes down to a good understanding of software and a basic understanding of assembly. Hak5 did a two-part series on the first two episodes this season on kind of the basics of reverse engineering and cracking. It's really basic, but it's probably exactly what you're looking for.
A would-be cracker disassembles the program and looks for the "copy protection" bits, specifically for the algorithm that determines if a serial number is valid. From that code, you can often see what pattern of bits is required to unlock the functionality, and then write a generator to create numbers with those patterns.
Another alternative is to look for functions that return "true" if the serial number is valid and "false" if it's not, then develop a binary patch so that the function always returns "true".
Everything else is largely a variant on those two ideas. Copy protection is always breakable by definition - at some point you have to end up with executable code or the processor couldn't run it.
The serial number you can just extract the algorithm and start throwing "Guesses" at it and look for a positive response. Computers are powerful, usually only takes a little while before it starts spitting out hits.
As for hacking, I used to be able to step through programs at a high level and look for a point where it stopped working. Then you go back to the last "Call" that succeeded and step into it, then repeat. Back then, the copy protection was usually writing to the disk and seeing if a subsequent read succeeded (If so, the copy protection failed because they used to burn part of the floppy with a laser so it couldn't be written to).
Then it was just a matter of finding the right call and hardcoding the correct return value from that call.
I'm sure it's still similar, but they go through a lot of effort to hide the location of the call. Last one I tried I gave up because it kept loading code over the code I was single-stepping through, and I'm sure it's gotten lots more complicated since then.
I wonder why they don't just distribute personalized binaries, where the name of the owner is stored somewhere (encrypted and obfuscated) in the binary or better distributed over the whole binary.. AFAIK Apple is doing this with the Music files from the iTunes store, however there it's far too easy, to remove the name from the files.
I assume each crack is different, but I would guess in most cases somebody spends
a lot of time in the debugger tracing the application in question.
The serial generator takes that one step further by analyzing the algorithm that
checks the serial number for validity and reverse engineers it.