As I know there are some applications that decompile DLLs to get source codes from application files.
Not only I don't want others to have the sources but also I don't want others to use them, I mean the DLL files. so how should i lock the DLLs and how safe they are ?
Before I get into anything else, I will state that it is impossible to protect your application entirely.
That being said, you can still make things more difficult. There are many obfuscators out there that will help you make it more difficult for someone to decompile your application and understand it.
http://en.wikipedia.org/wiki/List_of_obfuscators_for_.NET
.NET obfuscation tools/strategy
That's truly the best you can hope for.
Personally, I really wouldn't bother going too deep, if at all. You'll find that you are either spending too much money or time (or both) trying to protect your application from no-gooders. These are the same people who, no matter what barriers you throw up at them, will continue to try and given the nature of managed languages, they will most likely succeed. In fact, most obfuscators can be deobfuscated with simple tools... In the meantime, you've let other important features and bug fixes slip by because you spent more time and effort on security measures.
Obfuscation is one way to protect your code. Again, the solution is relative as per your needs. If you have a super secretive program, then you would want to explore more expensive and in-dept strategies.
However, if you are developing a business application or such thing which would not be worth a lot of any hacker's time to reverse engineer, minimal to normal obfuscation strategies are good enough. As the main answer suggests, look at those links.
Recently, I came upon ConfuseEx, a free open-source obfuscator that does the job for WPF apps and more. It seems to be very powerful, effective and customizable.
ConfuseEx on Github
For DLLs there is almost nothing we can do , confusing the files is the best way , but public member will remain in the way they were before , but if you pack them in your exe file , and confuse them , no one can use them easily .
I used ConfuserEX and it was very easy to use and effective .
Related
I'm thinking about creating a simplistic video game. I'm not talking about anything fancy, but about a game like this:
Since I want to learn, I would prefer not to use libraries but roll as much as I can on my own. I'd need to know how to render the car and the track, deal with collision with other cars, etc. I'm targeting Linux, Mac OS X and iOS. I fear that using a library like OpenGL makes things "too simple".
Are there any good resources out there that discuss this? Most of the tutorials / papers I have found are based around popular libraries & engines.
" I fear that using a library like OpenGL makes things "too simple" "
Don't worry, you still have plenty of work left.
In the REAL world, programmers use as many libraries as they can, that is the only way to produce a applications that focus on how things should work and not spend years on every little feature.
Start out programming above libraries, then, if you want to divide down into details, implement your own library and replace the one you used with it.
Dividing your application into self contained parts is a good practice, makes changing it without breaking everything possible.
Also, I would recommend you learn C++ first. Being able to model your problem domain with Object Oriented methodologies will help you break down the problems into solvable units.
Sounds like you're interested in learning from the level of Simple DirectMedia Layer.
If so, this might be a good place to start: http://gamedevgeek.com/tutorials/moving-sprites-with-sdl/
Probably followed by: http://www.gpwiki.org/index.php/SDL#Creating_a_Complete_2D_Engine
Also, for that particular rendering style, see:
http://en.wikipedia.org/wiki/Parallax_scrolling#The_raster_method
http://en.wikipedia.org/wiki/Mode_7
Edit:
This information about the original Doom engine may be useful:
http://fabiensanglard.net/doomIphone/doomClassicRenderer.php
Also, Chocolate Doom is a port of the original Doom source into SDL, so you'll probably learn some useful patterns studying the source for it:
http://www.chocolate-doom.org
It will be more or less impossible to develop a game without using any library. I guess you would have to go back to good old C64 days to do that. If you are interested in learning, I would look for a more low level library, which provides access to graphics, sound, ... But it should leave the logic to you.
I would propose to have a look at http://www.pygame.org/. It makes working with graphics, sprites, ... easy, is still relativly low level and Python is a great language to get started with.
Primary goal is to learn from a popular web server codebase (implemented in C) with priority given to structure/design instead of neat tricks throughout the code.
I didn't include Apache since its code base is an order of magnitude larger than the two mentioned.
Ngxinx might just be the best straight-c code-base I have encountered. I have read large chunks of Apache, and I always came out feeling unclean, it is a monolithic mess.
You will not just learn about web-servers by exploring Nginx, but pretty much the best practises for writing networked software under Unix and straight-c, from code architecture to meta-programming techniques.
I have heard nothing but good things about Lighttpd, however it is limited in scope compared to Nginx. therefore I would invest time in nginx if I was you. Although lighttpd's limited scope might be beneficial to you, as a first target to study.
Neat tricks always happen in any codebase worth its salt, to be honest. Nevertheless, the answer you probably don't want to hear is that it would probably be good to study both so you can kind of learn through the intersection. The alternative might really leave you stuck in a box of the "lighthttpd" way or the "nginx" way, etc.
I didn't include Apache since its code base is an order of magnitude larger than the two mentioned.
Actually Apache code is quite readable. It has large code base because it does lots of things. But it is well structured and quite easy to understand. You can also check APR library (Apache Portable Runtime) which has plethora of small things to learn from.
IMO if you want to learn programming, you should start with lower profile projects - and not HTTPd, but something simpler.
Both nginx and LightHTTPd (just like Apache) are production quality software, meaning very steep learning curve. And the learning unfortunately often means digging archives to see why it is that way - that comes with age to any mature project.
If you are simply into C and learning design, you might want to check the FreeBSD or its derivatives. In my experience it is a better place for starting: there are lots of tools and libraries of all calibers there. And their TODO lists are never empty, what serves well as a guide to where to start.
We've pretty much licked the whole distributed thing for version control at this point. I'm not saying everything's perfect, but, from hereon out, it's mostly just a matter of continuing what has already been started.
Distributed bug tracking, though, is in its infancy stage, IMHO. It's rather inconvenient, not being able to work with an issue tracker on the road, especially since I have a tendency to forget what my changes over the past two hours were for. Yes, I know, I could just keep a log on the road and update a traditional tracker as soon as I get on the net again, but still... Keeping my options open and all that. :P
Currently, I only know of Bugs Everywhere and Ditz-- those, and the one that comes with Fossil. Of these, I think Fossil is the farthest along, which is not suprising, considering how tightly it's integrated with the version control side of the equation. I've had to jump through quite a few hoops to get my co-devs to even look at something other than SVN, but, if Fossil really is all that, I wouldn't mind doing it again.
Before I do, however, I want to ask older and wiser heads than mine: Do you have experience with these three? What do you think of them? Do you know of others? Please link to them, and let me know how they fared.
Fossil works as an 'easy to setup' Distributed Bug tracker , and has a nice autosync facility that lets developers share their bugs without intervention.
to get started,
Download the fossil binary of your choice
fossil new bugs.fossil
fossil ui bugs.fossil (runs the server)
your developers do the same
Download the fossil binary of your choice
fossil clone
fossil ui bugs.fossil
set up a cron job to 'fossil sync ...' so the bugs propagate to all users as the fossil self-hosting repositories demonstrate
There is not much more to it than that.
Edit - take a look at Customizing The Ticket System too.
Because I wanted (well, needed, really) a solution that could probably (maybe, hopefully) work right now, we went with the following setup:
Bazaar-NG as the VCS
Bugs Everywhere as the bug tracker
Zim as wiki
It may not be the perfect setup, nor even a particularly acceptable one to some, but it meets the criteria of working right now. I still would like to learn more from others; maybe I'm missing a not-so obvious trait of other solutions that would cause me to become fanatic enough that I'd bug my co-devs to switch.
Anyway, if anyone uses this, or a similar, set of tools, please let me know how it's worked out so far for you, what your circumstances are, etc. Right now, this solution of ours is all of three days old, so I really don't have much data to share as of yet.
Eric Sink has some sensible thoughts on the subject here - he's clearly given it more thought than me but he does make one key point which is that you have a different paradigm when dealing with features and bugs to when dealing with development, particularly with respect to bugs.
Additional information for people like me who're interested in the subject, but can't pull up enough relevant info through Google (either they're not there, or my Google-fu is severely lacking):
Just branched Bugs Everywhere again. bzr log --limit 1 shows the last commit to be from early October 09. The development is slow, but it's there. I haven't yet dived in to see just what exactly be offers. Documentation is severely lacking. There isn't even a quick-start guide on the site.
Ditz, using a clone of its mainline git repo just utterly fails for me. Google indicates the 1.9 releases of Ruby breaks it. Supposedly, there are git clones that fix it, but I'd really rather not mess with git.
Fossil has at least one relevant question here on SO: What do people think of the fossil DVCS? (it even has an answer from the author!). Much respect for D. Richard Hipp (author of SQLite and Fossil, as well other insanely cool things I can only use and read about on Wikipedia), but I'd like feedback from other mortals, as well.
Still not enough for me, though. There has to be at least a couple of people who've used either be or ditz for a non-trivial project-- at least, enough to be able to give an informed opinion.
I don't care about the technical side-- either the project documents it on its Web site, or I could just look at the source. What I'm looking for is real-world experience: What were the hurdles to its adoption? What is a particular project lacking? What would you add, that you really need, given maybe two years of paid time to work on it? Stuff like that.
This is a problem we all have to consider at some point.
After many years and many approaches I tend to agree in general with the staterment:
"For any protected software used by more than a few hundred people, you can find a cracked version. So far, every protection scheme can be tampered with."
Does your employer enforce the use of anti-piracy software?
Further, every time I post about this subject, some one will remind me;
"First of all, no matter what kind of protection you'll employ,a truly dedicated cracker will, eventually, get through all of the protective barriers."
What's the best value for money c# code protection for a single developer
So not withstanding these two broadly true disclaimers, lets talk about "protection"!
I still feel that for smaller apps that are unlikely to warrent the time and attention of a skilled cracker, protection IS a worthwhile exercise.
It seems obvious that no matter what you do, if the cracker can switch the outcome of an IF statement (jmp) by patching the application, then all the passwords and dongles in the world anre not going to help.
So My approach has been to obfuscate the code with virtualization using products like:
http://www.oreans.com/codevirtualizer.php
I have been very happy with this product. To my knowledge it has neve been defeated.
I can even compress the executable with PEcompact
Does anyone else have experience with it?
Had nothing but problems with EXEcryptor
http://www.strongbit.com/news.asp
Even the site is a headache to use.
The compiled apps would crash when doing any WMI calls.
This approach allows you to surround smaller sections of code with the obfuscation and thus protect the security checking etc.
I Use the online authorization approach, as the application needs data from the server regularly so it makes no sense for the user to use it off line for extended periods. By definition, the app is worthless at that point, even if it is cracked.
So a simple encrypted handshake is plenty good. I just check it occasionally within the obfuscation protection. If the user installs the app on a different machine, a New ID is uploaded upon launch and the server disables the old ID and returns a new authorization.
I also use a hash of the compiled app and check it at launch to see if a single bit has changed, then open the app as a file (with a read LOCK) from within the app to prevent anyone changing it once launched.
Since all static strings are clearly visible in the .exe file, I try to be generic with error messages and so forth. You will not find the string "Authorization failed" anywhere.
To protect against memory dumps, I use a simple text obfuscation technique (like XOR every character) This makes plain text data in memory harder to distinguish from variables and so forth.
Then of course there is AES for any data that is really sensitive. I like counter mode for text as this results in no repeating sequences revealing underlying data like a sequence of white spaces.
But with all these techniques, if the Key or Initialization vector can be dumped from memory, or the IF statement bypassed, everything is wasted.
I tend to use a switch statement rather than a conditional statement. Then I create a second function that is basically a dead end instead of the function that actually performs the desired task.
Another idea is to code pointers with a variable added. The variable is the result of the authorization (usually zero). This will inevitable lead to a GPF at some point.
I only use this as a last resort after a few lower level authorizations have failed otherwise real users may encounter it. Then the reputation of your software is lowered.
What techniques do you use?
(this is NOT a thread debating the merits of implementing something. It is designed for those that have decided to do SOMETHING)
I disagree xsl.
We protect our code, not because we want to protect our revenue - we accept that those who would use if without a license probably would never pay for it anyway.
Instead, we do it to protect the investment our customers have made in our software. We believe that the use of our software makes them more competative in their market place and that if other companies have access to it without paying they have an unfair advantage - ie, they become as competative without having the overhead of the licensing cost.
We are very careful to ensure that the protection - which is home grown - is as unobtrusive as possible to the valid users, and to this end we would never consider 'buying in' an off the shelf solution that may impact this.
You don't need a few hundred users to get your software cracked. I got annoyed at having my shareware cracked so many times, so as an experiment I created a program called Magic Textbox (which was just a form with a textbox on it) and released it to shareware sites (it had its own PAD file and everything). A day later a cracked version of Magic Textbox was available.
This experience made me pretty much give up trying to protect my software with anything more than rudimentary copy protection.
I personally use the code techniques discussed here. These tricks have the benefit of inconveniencing pirates without making life more difficult for your legitimate end-users
But the more interesting question isn't "what", but "why". Before a software vendor embarks on this type of exercise, it's really important to build a threat model. For example, the threats for a low-priced B2C game are entirely different to those for a high-value B2B app.
Patrick Mackenzie has a good essay where he discusses some of the threats, including an analysis of 4 types of potential customer. I recommend doing this threat analysis for your own app before making choices about protecting your business model.
I've implemented hardware keying (dongles) before myself, so I'm not totally unfamiliar with the issues. In fact, I've given it a great deal of thought. I don't agree with anyone violating copyright law, as your crackers are doing. Anyone who doesn't want to legally aquire a copy of your software should do without. I don't ever violate software copyright myself. That being said...
I really, really dislike the word "protect" used here. The only thing you are trying to protect is your control. You are not protecting the software. The software is just fine either way, as are your users.
The reason that keeping people from copying and sharing your software is such an unholy PITA is that preventing such activites is unnatural. The whole concept of a computer revolves around copying data, and it is simple human nature to want to share useful things. You can fight these facts if you really insist, but it will be a lifelong fight. God isn't making humans any differently, and I'm not buying a computer that can't copy things. Perhaps it would be better to find some way to work with computers and people, rather than fighting against them all the time?
I, along with the majority of professional software developers, am employed full time by a company that needs software developed so that it can do its business, not so it can have a "software product" with artificial scarcity to "sell" to users. If I write something generally useful (that isn't considered a "competive advantage" here), we can release it as Free Software. No "protection" is needed.
From some of the links:
The concept I tried to explain is what I call the “crack spread”. It doesn’t matter that a crack (or keygen, or pirated serial, or whatever) exists for your application. What matters is how many people have access to the crack.
Where/when to check the serial number: I check once on startup. A lot of people say “Check in all sorts of places”, to make it harder for someone to crack by stripping out the check. If you want to be particularly nasty to the cracker, check in all sorts of places using inlined code (i.e. DON’T externalize it all into SerialNumberVerifier.class) and if at all possible make it multi-threaded and hard to recognize when it fails, too. But this just makes it harder to make the crack, not impossible, and remember your goal is generally not to defeat the cracker. Defeating the cracker does not make you an appreciable amount of money. You just need to defeat the casual user in most instances, and the casual user does not have access to a debugger nor know how to use one.
If you’re going to phone home, you should be phoning home with their user information and accepting the serial number as the output of your server’s script, not phoning home with the serial number and accepting a boolean, etc, as the output. i.e. you should be doing key injection, not key verification. Key verification has to ultimately happen within the application, which is why public key crypto is the best way to do it. The reason is that the Internet connection is also in the hands of the adversary :) You’re a hosts file change away from a break-once, break-everywhere exploit if your software is just expecting to read a boolean off the Internet.
Do not make an “interesting” or “challenging” protection. Many crackers crack for the intellectual challenge alone. Make your protection hard to crack but as boring as possible.
There are some cracks which search for byte patterns in search for the place to patch. They usually aren’t defeated by a recompile, but if your .EXE is packed (by ASProtect, Armadillo, etc) these kind of cracks must first unpack the .EXE.. and if you use a good packer such as ASProtect, the cracker will be able to unpack the EXE manually using an assembly level debugger such as SoftICE, but won’t be able to create a tool which unpacks the .EXE automatically (to apply the byte patches afterwards).
I have used .NET Reactor in the past with good results - http://www.eziriz.com/
What I liked about this product is that it did not require you to obfuscate the code in order to have pretty good protection.
xsl, that is a very narrow point of view with MANY built in assumtions.
It seems obvious to me that any app that relies on delivering something from a server under your control should be able to do a fairly good job of figuring our who has a valid account!
I am also of the belief that regular updates (meaning a newly compiled app with code in different locations) will make cracked vesrions obsolete quickly. If your app communicates with a server, launching a secondary process to replace the main executable every week is a piece of cake.
So yes, nothing is uncrackable, but with some clever intrinsic design, it becomes a moot point. The only factor that is significant is how much time are the crackers willing to spend on it, and how much effort are your potential customers willing to exert in trying to find the product of their efforts on a weekly or even daily basis!
I suspect that if your app provides a usefull valuable function then they will be willing to pay a fair price for it. If not, Competitive products will enter the market and your problme just solved itself.
As much as we would all like to say it is a benefit to programmers to be language agnostic, is it really feasible to support multiple enterprise Web applications of the same type all written in different languages? Think about how complicated a CMS or e-commerce system can be -- now imagine supporting three different CMS platforms all written in different languages. I would hate to be known as a .NET or Java or PHP shop, but I also don't want to be the vendor who says they can support a solution they have never worked with, upsetting a client who wonders why we can't get something done right on time. Can anyone speak from experience on this? Does your company usually just suck it up, and try and to learn a new platform on the fly? Do you bill up-to-speed, or eat those costs?
I think it all depends on who your clients are and what they expect. I think knowing about different technologies is good, but really when you're hired by someone, they expect you to know what you are doing. Personally, I would much rather be known that I do a really good job with a certain type of technology and when hired, I get the job done well.
If you try and go after every contract without regard to what your core competencies are, you aren't going to succeed. You'll anger the people who do hire you and make mistakes, and you'll potentially miss opportunities where you can really shine. Sometimes you have to make compromises to pay the bills, but if you aren't careful, it can bite you in the end.
The large consulting firms I've worked with throw resources at it and hope they don't anger too many people. They mainly do this because they know that the people who work with the consultants and get angry when they don't get the job done aren't the ones making the decisions to keep them hired. To them (not all of them I know, but some definately), don't care if they screw up because they ultimately know they can convince the VPs and SVPs to keep them around.
To be honest, I think you tend to see this kind of thing happen over time, no matter how disciplined the organization is. It's natural for new methodologies to come bundled in the form of new libraries, frameworks, or even languages. Keep in mind that a .NET shop may well have been a ASP/VB shop at one time. They'll probably still maintain older systems for clients, because there's little benefit to rewriting everything from scratch.
I'm not sure anyone has the luxury to keep everything "the same," because language issues are minor compared to library or framework issues -- especially the ones you build yourself.