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 9 years ago.
Improve this question
Let's assume that after a few years of work I would have a 3D game ready, that can be downloaded by millions of people worldwide, it would be a game running on a client-server model.
As far as I understand anyone can look at other people's source code if they possess the .jar (the client one in this case). What are the risks of other people having a client .jar?
The checking part (anti-cheating) will be done on the server side anyway, so I doubt there will be much risk here, but I'm just wanting to have a good view of what can exactly happen, so to be more precise I'm asking the following questions:
What can be done to protect, let's say, client.jar from other people reading the code?
What is the harm that even if people would have full control to the client.jar source code, could be done to the game itself in a singleplayer environment?
What is the same harm that could be done in a client-server multiplayer environment?
What is the harm that could be done to me/my business on a personal and/or legal level?
What could if other people decide to copy the game, okay I know this can also happen if others just build their own game 1:1 mirrorred to my game.
I thought about putting it up on gamedev, but I think it's better suited here as it is directly about a programming language - Java - and an abstract programming problem.
On this one, I should emphasize that all opinions are my own and do NOT necessarily reflect those of my employer.
No, they can't look at your source code if they've got the jar. They can decompile it into equivalent source code, which will be significantly harder to read but can be figured out... just as they could dis-assemble object code (which would, admittedly, be a bit harder to figure out). Code obfuscation will indeed slow them down, but the folks who would do this are used to dealing with that too. Java is more vulnerable than some other languages to being reverse-engineered.
Copy protection generally works only to keep honest people honest. Luckily, most folks are at least moderately honest. The dishonest treat it as a free puzzle included with your product. You can slow them down. But realistically, you can't stop them unless you use specific kinds of hardware-assisted security (basically, running critical parts of the program inside a separate encapsulated machine) -- which tends to drive the cost up and/or annoy people enough that they avoid your product. Most companies have instead moved to a model of requiring that code be registered in order to get upgrades, support, online services, or whatever... and to either pricing it with the assumption that some piracy is going to occur, or pricing low enough that pirating it just isn't worthwhile.
Or, for commercial code, going after the pirated copies in court. For serious code, most companies are very aware that they have much more to lose by allowing a pirated copy onto the premises than they can save by pirating; I've seen employees fired on the spot for making a pirated copy at work.
In fact some companies have made "pirating" part of their business model. "If you got this program from a friend, and you like it, please consider sending us money to support the developers and/or buying an upgrade to the current version." Surprisingly, for good products, many folks are perfectly willing to pay voluntarily. Not everyone, but it helps.
Addressing your questions about alteration of the code:
I AM NOT A LAWYER, AND YOU SHOULD CONSULT ONE FOR THIS QUESTION, but my best understanding is that you have no new liability. If they mess up the code, that's their fault and their problem.
In a singleplayer environment, all they can do is mess with their own copy. If they break it, that's their problem. If they cheat, they're only cheating themselves out of the gaming experience they paid for.
Multiplayer is a much larger problem; if they reverse-engineer the game they can mess with your databases and other player's experience of the game. The only way to solve this, as far as I know, is to design your servers to (a) only allow the client to do things which can't cause much damage, and (b) watch player actions to try to detect abuse and kick abusing players out of the system. It's annoying, but it's the reality. And if you can show that you've made a reasonable effort to do this, it should guard you against any possible liability at this level.... but again, I AM NOT A LAWYER and free legal advice from programmers is like free programming advice from lawyers...
Building their own game mirroring yours: If you can detect that they're accessing your servers, that's legally actionable. If you've got something as simple as Tetris or Minehunter then you're going to get knock-offs and unless you're willing to go after them in court there isn't much you can do about it except by offering upgrades and so on to registered players that the knock-offs won't get. if you've written something complicated, then for the effort of duplicating yours they could create their own so this is less likely to be a problem than pure piracy is.
And as far as industrial-level piracy in the far east etc... Again, there really isn't a good answer.
If you find a solution that actually works, THAT should be your product; the world will beat a path to your door. But in the long run, I really don't think it's possible; all you can do is slow them down and use copyright and license agreements, and build a loyal enough fan base that they'd rather work with you than against you.
What can be done to protect, let's say, client.jar from other people reading the code?
Obfuscate the code, it makes reading the code harder but not impossible.
What is the harm that even if people would have full control to the client.jar source code, could be done to the game itself in a singleplayer environment?
They'll have control over everything (change anything they like), I have no idea how would that effect your game, business wise. but many games offer ways to change the game environment and that makes the game more desirable by players.
What is the same harm that could be done in a client-server multiplayer environment?
It will make it easier to reverse engineer the game protocol and you'll start having [BOTs] instead of real players play the game, besides any constraint imposed by the game UI will be rendered useless.
What is the harm that could be done to me/my business on a personal and/or legal level?
Depends how you monetize and in what country do you operate (local lows). I think you should consult a legal expert on this one.
"anyone can look at other people's source code if they possess the .jar" - this is not true. You can create special jar with the source code, but you are not obliged to do so in order to run a program. The program may contain only "binary jar" - that is, containing compiled java code and/or resources, no source. Corrected: since binary code can be decompiled back to java code (for example, with http://jd.benow.ca/ ), it will be important to obfuscate or encrypt the compiled code ( google for JODE, RetroGuard, etc.)
What can be done to protect, let's say, client.jar from other people reading the code?
you can create "thin client", that does nothing, but downloads the main code from the designated server. Of course, you'll have to protect traffic and use such key authentication that makes it impossible to trick client into using fake server.
What is the harm that even if people would have full control to the client.jar source code
that assume you don't give source-code level control to anyone
What is the same harm that could be done in a client-server multiplayer environment?
bots and DOS-attacks at least
What is the harm that could be done to me/my business on a personal and/or legal level?
it depends on concrete implementation and business model
What could if other people decide to copy the game, okay I know this can also happen if others just build their own game 1:1 mirrorred to my game.
If your client program is reverse-engineered, than hardly you can protect it from copying. Otherwise you should implement such network protocol, that makes copy impossible/useless.
Related
The Security and Design guidelines go to great length outlining various methods to make it more difficult for an attacker to compromise in-app billing implementation.
Especially noted is how easy it is to reverse-engineer a .apk file, even if obfuscated via Proguard. So they even recommend modifying all sample application code, especially "known entry points and exit points".
What I find missing is any reference to the wrapping certain verification methods in a single method, like the static Security.verify() which returns boolean: A good design practice (reducing code duplication, reusable, easier to debug, self-documenting, etc.) but all an attacker needs to do now is identify that method and make it always return true... So regardless how many times I used it, delayed or not delayed, randomly or not, it simply doesn't matter.
On the other hand, Java doesn't have macros like in C/C++, which allows reducing source code duplication, but doesn't have a single exit point for a verify() function.
So my questions:
Is there an inherent contention between the well known software engineering/coding practices and design for so called security? (in the context of Java/Android/secure transactions at least)
What can be done to mitigate the side-effects of "design for security" which seems like "shooting oneself in the foot" in terms of over-complicating software that could have been simpler, more maintainable and easier to debug?
Can you recommend good sources for further studying this subject?
As usual, it's a tradeoff. Making your code harder to reverse-engineer/crack involves making it less readable and harder to maintain. You decide how far to go, based on your intended user base, your own skills in the area, time/cost, etc. This is not specific to Android. Watch this Google I/O presentation for various stages of obfuscating and making your code tamper resistant. Then decide how far you are willing to go for your own apps.
On the other hand, you don't have to obfuscate/harden, etc. all of your code, just the part that deals with licensing, etc. That is usually a very small part of the whole codebase and doesn't really need to change that often, so you could probably live with it being hard to follow/maintain, etc. Just keep some notes on how it works, so you remind yourself 2 years later :).
The counter productivity you are describing is the tip of the iceberg... No software is 100% bug-free on release, so what do you do when users start reporting problems?
How do you troubleshoot or debug field problems after you disabled logging, stack tracing and all kinds of other information that help reverse-engineers but also help the legitimate development team?
However tough the obfuscation methods are, there is always a way to reverse engineer them. I mean, if your software gets more popular among the hakers community, eventually someone will try to reverse-engineer it.
Obfuscation is just a method to make the process of reverse engineering tougher. So is packing. I think many packing methods are available, but so is the process to reverse-engineer them.
You can check the www.tuts4you.com to see how tons of guides are being available.
I am not an expert like many others, but this is my experience in the process of learning reverse-engineering. Also recently I have seen a lot of guides for Android applications reverse-engineering. I have seen even in nullc0n (not sure) CTF, there was an app in Reversing Android. If you want, I can mention the site after searching.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have an application written in Java. In is stored in several files. It uses different classes with different methods. The code is big and complicated. I think it would be easier to understand the code if I have a graphical model of the code (some kind of directed graph). Are there some standard methods for visualization of code. I am thinking about usage of UML (not sure it is a correct choice). Can anybody recommend me something?
ADDED:
I consider two possibilities:
Creating the graph by hands (explicitly).
Creating graph in an automatic way. For example to use some tools that read the available code and generate some graph describing the structure of the code.
ADDED 2:
It would be nice to have something for free.
I tried using a number of UML tools and found that the reverse-engineering capabilities in most UML tools were not helpful for understanding code. They focus on designing needs and reverse-engineering capabilities often just ends up showing huge pictures of lots of useless information. When I was working on the Microsoft Office codebase, I found using a pen-and-paper more helpful that the typical design/modelling tools.
You typically want to think about doing this in a number of ways:
Use your brain: Someone else mentioned it - there is no substitute to actually trying to understand a code base. You might need to take notes down and refer back to it later. Can tools help? Definitely. But don't expect them to do most of the work for you.
Find documentation and talk to co-workers: There is no better way than having some source describe the main concepts in a codebase. If you can find someone to help you, take a pen and paper, go to him and take lots of notes. How much to bug the other person? In the beginning - as much as is practical for your work, but no amount is too little.
Think about tools: If you are new to a part of a project - you are going to be spending a significant amount of time understanding the code, so see how much help you can get automatically. There are good tools and bad tools. Try to figure out which tools have capabilities that might be helpful for you first. As I mentioned above, the average UML tool focuses more on modeling and does not seem to not be the right fit for you.
Time vs Cost: Sure, free is great. But if a free tool is not being used by many people - it might be that the tool does not work. There are many tools that were create just as an exploration of what could be done, but are not really helpful and therefore just made available for free in hopes that someone else will adopt it. Another way to think about it, decide how much your time is worth - it might make sense to spend a day or two to get a tool to work for you.
Once there, keep these in mind when going trying to understand the project:
The Mile High View: A layered architectural diagram can be really helpful to know how the main concepts in a project are related to one another. Tools like Lattix and Architexa can be really helpful here.
The Core: Try to figure out how the code works with regards to the main concepts. Class diagrams are exceptionally useful here. Pen-and-paper works often enough here, but tools can not only speed up the process but also help you save and share such diagrams. I think AgileJ and Architexa are your best bets here, but your average UML tool can often be good enough.
Key Use Cases: I would suggest tracing atleast one key use case for your app. You likely can get the most important use cases from anyone on your team, and stepping through it will be really helpful. Most IDE's are really helpful here. If you try drawing them, then sequence diagrams arethe most appropriate. For tools here I think MaintainJ, JDeveloper and Architexa are your best bets here.
Note: I am the founder of Architexa - we build tools to help you understand and document Java code, but I have tried to be unbiased above. My intention is to suggest tools and options given that this is what I focused on as part of my PhD.
The most important tool you should use is your brain, and it's free.
There's no reason why you have to use any sort of standard method of visualization, and you can use whatever media you like. Paper, whiteboard, photoshop, visio, powerpoint, notepad: all of these can be effective. Draw a diagram of classes, objects, methods, properties, variables - whatever you think is useful to see in order to understand the application. The audience is not only other members of your team, but also yourself. Create diagrams that are useful for you to look at and quickly understand. Post them around your workspace and look at them regularly to remind yourself of the overall system architecture as you build it.
UML and other code documentation standards are good guidelines for the types of diagrams you can do and the information you should consider including. However, it is overkill for most applications and basically exists for people who can't take personal responsibility for documenting without standards. If you follow UML to the letter, you'll end up spending way too much time on your documentation instead of creating your application.
It is stored in several files. It uses different classes with different methods. The code is big and complicated.
All Java code written outside the school is like that, particularly for a new developer starting on a project.
This is an old question, but as this is coming up in Google searches, I am adding my response here so that it could be useful to the future visitors. Let me also disclose that I am the author of MaintainJ.
Don't try to understand the whole application
Let me ask you this - why do you want to understand the code? Most probably you are fixing a bug or enhancing a feature of the application. The first thing you should not try to do is to understand the whole application. Trying to understand the entire architecture while starting afresh on a project will just overwhelm you.
Believe me when I say this - developers with 10+ years of solid coding experience may not understand how certain parts of the application work even after working on the same project for more than a year (assuming they are not the original developers). They may not understand how the authentication works or how the transaction management works in the application. I am talking about typical enterprise applications with 1000 to 2000 classes and using different frameworks.
Two important skills required to maintain large applications
Then how do they survive and are paid big bucks? Experienced developers usually understand what they are doing; meaning, if they are to fix a bug, they will find the location of the bug, then fix it and make sure that it does not break the rest of the app. If they need to enhance a feature or add a new feature, most of the time, they just have to imitate an existing feature that does a similar thing.
There are two important skills that help them to do this.
They are able to analyze the impact of the change(s) they do while fixing a bug. First they locate the problem, change the code and test it to make sure that it works. Then, because they know the Java language well and the frameworks 'well enough', they can tell if it will break any other parts of the app. If not, they are done.
I said that they simply need to imitate to enhance the application. To imitate effectively, one needs to know Java well and understand the frameworks 'well enough'. For example, when they are adding a new Struts Action class and adding to the configuration xml, they will first find a similar feature, try to follow the flow of that feature and understand how it works. They may have to tweak a bit of the configuration (like the 'form' data being in 'request' than in 'session' scope). But if they know the frameworks 'well enough', they can easily do this.
The bottom line is, you don't need to understand what all the 2000 classes are doing to fix a bug or enhance the app. Just understand what's needed.
Focus on delivering immediate value
So am I discouraging you from understanding the architecture? No, not at all. All I am asking you is to deliver. Once you start on a project and once you have set up the development environment on your PC, you should not take more than a week to deliver something, however small it may be. If you are an experienced programmer and don't deliver anything after 2 weeks, how can a manager know if you really working or reading sports news?
So, to make life easier for everyone, deliver something. Don't go with the attitude that you need to understand the whole application to deliver something valuable. It's completely false. Adding a small and localized Javascript validation may be very valuable to the business and when you deliver it, the manager feels relieved that he has got some value for his money. Moreover, it gives you the time to read the sports news.
As time passes by and after you deliver 5 small fixes, you would start to slowly understand the architecture. Do not underestimate the time needed to understand each aspect of the app. Give 3-4 days to understand the authentication. May be 2-3 days to understand the transaction management. It really depends on the application and your prior experience on similar applications, but I am just giving the ballpark estimates. Steal the time in between fixing the defects. Do not ask for that time.
When you understand something, write notes or draw the class/sequence/data model diagram.
Diagrams
Haaa...it took me so long to mention diagrams :). I started with the disclosure that I am the author of MaintainJ, the tool that generates runtime sequence diagrams. Let me tell you how it can help you.
The big part of maintenance is to locate the source of a problem or to understand how a feature works.
MaintainJ generated sequence diagrams show the call flow and data flow for a single use case. So, in a simple sequence diagram, you can see which methods are called for a use case. So, if you are fixing a bug, the bug is most probably in one of those methods. Just fix it, ensure that it does not break anything else and get out.
If you need to enhance a feature, understand the call flow of that feature using the sequence diagram and then enhance it. The enhancement may be like adding an extra field or adding a new validation, etc. Usually, adding new code is less risky.
If you need to add a new feature, find some other feature similar to what you need to develop, understand the call flow of that feature using MaintainJ and then imitate it.
Sounds simple? It is actually simple, but there will be cases where you will be doing larger enhancements like building an entirely new feature or something that affects the fundamental design of the application. By the time you are attempting something like that, you should be familiar with the application and understand the architecture of the app reasonably well.
Two caveats to my argument above
I mentioned that adding code is less risky than changing existing code. Because you want to avoid changing, you may be tempted to simply copy an existing method and add to it rather than changing the existing code. Resist this temptation. All applications have certain structure or 'uniformity'. Do not ruin it by bad practices like code duplication. You should know when you are deviating from the 'uniformity'. Ask a senior developer on the project to review the changes. If you must do something that does not follow the conventions, at least make sure that it's local to a small class (a private method in a 200 line class would not ruin the application's esthetics).
If you follow the approach outlined above, though you can survive for years in the industry, you run the risk of not understanding the application architectures, which is not good in the long run. This can be avoided by working on bigger changes or by just less Facebook time. Spend time to understand the architecture when you are a little free and document it for other developers.
Conclusion
Focus on immediate value and use the tools that deliver that, but don't be lazy. Tools and diagrams help, but you can do without them too. You can follow my advice by just taking some time of a senior developer on the project.
Some plugins I know for Eclipse:
Architexa
http://www.architexa.com/
nWire
http://www.nwiresoftware.com/
If you want to reverse engineer the code, you should try Enterprise Architect
have you tried Google CodePro Analytix ?
it can for example display dependencies and is free (screenshot from cod.google.com):
Here is a non UML Tool which has very nice visualization features.
You can mapping the lines of code per class / method to colors / side lenght of rectangles.
You can also show the dependencies between the classes.
http://www.moosetechnology.org/
The nice thing is, you can use Smalltalk scripting for displaying what you need:
http://www.moosetechnology.org/docs/faq/JavaModelManipulation
Here you can see how such a visualization looks like:
http://www.moosetechnology.org/tools/moosejee/casestudy
JUDE Community UML used to be able to import Java, but it is no longer the case. It is a good, free tool.
If your app is really complex I think that diagrams won't carry you very far. When diagrams become very complex they become hard to read and lose their power. Some well chosen diagrams, even if generated by hand, might be enough.
You don't need every method, parameter, and return value spelled out. Usually it's just the relationships and interactions between objects or packages that you need.
Here is a another tool that could do the trick:
http://xplrarc.massey.ac.nz/
You can use JArchitect tool, a pretty complete tool to visualize your code structure using the dependency graph, and browse you source code like a database using CQlinq.
JArchitect is free for open source contributors
Some great tools I use -
StarUML (allows code to diagram conversion)
MS Visio
XMind (very very useful for overview of the system)
Pen and Paper!
I intend to make some software to be sold over internet. I've only created open-source before, so I have really no idea of how to protect it from being cracked and distributed as warez. Bearing in mind that I know like two programms that aren't either cracked or not really useful I decided that the only more or less reliable way may look like this:
Connect to a server and provide licensing info and some sort of hardware summary info
If everything is fine, the server returns some crucial missing parts of the program bound to that certain pc along with the usage limit of say 2 days
That crucial stuff is not saved to hard drive, so it is downloaded every time the program starts, if the programm runs more than 2 days, data is downloaded again
If the same info is used from different computers, suspend the customer account
What do you think about this? It may seem a bit to restrictive, but I'd better make less sales at first then eventually see my precious killer app downloaded for free. Anyways, first I need some basic theory/tutorials/guides about how to ensure that user only uses a certain Java app if he has paid for it, so please suggest some.
Thanks
I work for a company selling protected Java software.
I won't comment on the scheme for user authentication, but I can comment on the online license check.
Don't make it even "work for two days": that's how I pirate most software... Virtual Machine set "back in time" and externally firewalled so that it doesn't "phone home" anymore (that is: only allowing it to contact the server once, to get the trial key), always reimaged from the point where the software got freshly installed and bingo, the 30-days trial (or two days trial) has become a lifetime trial. Why do I do this? To learn how to better protect our app of course ;) (ok, ok, I do it just for fun too)
What we do in our commercial Java software is to check the license at every startup.
We've got hundreds of customers and nobody ever bitched about it. Not once. We generate a unique class at each run, which is different at every run, which depends both on things unique for that launch on the client side and on things generated once on the server side.
In addition to that having the app contact your server at every launch is a great way to gather analytics: download to trial ratio, nb average launches per trial, etc. And it's not nasty anymore than having an Urchin/Google JavaScript tracker on each webpage is nasty.
Simply make it clear to people that your software performs the online licence check: we'got a huge checkbox either on or off saying: "Online licence verification: OK/Failed". And that's it. People know there's a check. If they don't like it, they go use inferior competitor products and life is good.
People are used to live in a wired world.
How often can you not access GMail because your Internet connection is down? How often can you not access FaceBook or SO because your Internet connection is down?
Point is: make as much computation as possible dependent on the server side:
licence check
save user preferences
backup of the data generated by your app
etc.
Nobody will complain. You'll have 0.1% of your user complain and anyway you don't want these users: they're the one who would complain about other things and post negative feedback about your app online. You better have them not to use your software at all and complain about the fact that it requires an always-on Internet connection (which 99.99% of your target demographic and hence they won't care about the complain) rather than actually have them use the app, and complain about other things related to your app.
Regarding decompiling, .class can usually be decompiled back to .java unless you're using a code flow obfuscator that produces valid bytecode but that it impossible to be generated from .java file (hence it is impossible to get back a valid .java file).
String obfuscator helps make it harder to figure out.
Source code obfuscator helps make it harder to figure out.
Bytecode obfuscator like the free Proguard makes it harder (and produce faster code, especially noticeable in the mobile world) to figure out.
If you're shipping Windows/Linux only then you can use a Java-to-native converter like Excelsior Jet (not free and kinda expensive for startups, but it produces native code from which you simply cannot find the .java files back).
As a funny side note you'll see people trying to mess with your online server... At about 30 beta-testers we had already people (which we know where part of the trial) trying to pirate our online servers.
I am sorry to turn you down, but first you should have an idea of what you want to build; then you should prove that your idea not only works, but is also loved by users to the point where they want to pirate it. Thirdly, you have to make sure that the time you are investing in making it "secure" is actually worth the value of the application.
If you sell it for a dollar, and you only sell ten copies, and you spent 100 hours making it secure, you do the math and tell me if your time was worth that little money.
The take-home message here is: everything can be cracked or copied. At the end there are much brighter people than us doing this (iPhone cracking, digital TV, games, etc) and nobody found the silver bullet. Only thing you can do is make it harder to crack your application (often at the expenses of usability, ease of installation, and by cutting corners for some use scenarios). Asking yourself if it's worth the hassle it's always a good starting point.
Don't bother.
The gaming industry has been battling piracy for decades. Online multiplayer games with a central server typically require a subscription to play. That model is fairly resistant to piracy. Pretty much all other games are heavily pirated, despite innumerable attempts at DRM.
Your app will be cracked and pirated, no matter what language you write it in and what tools you use to prevent it. If your DRM actually works, the people who would have pirated it still won't buy it. Furthermore, legitimate users will prefer other products that don't have intrusive DRM. If there are no competing products and yours has any market to speak of, someone will create one.
Unless your application is specifically web based your users will find it to be a huge hassle to require an internet connection in order that they might access the product. What you are suggesting will work, unless it gets broken, like all DRM systems do. I understand the want to protect your intellectual property, but with many companies as examples, these systems are usually broken or the product does much worse because of them.
I have really no idea of how to
protect it from being cracked and
distributed as warez.
First, you'd be better choosing a language besides Java, if this is a concern. This is why C++ is still alive and well in the commercial apps world. Unless you are going to use an actual Java compiler to native exe, I'd reconsider Java for IP protection reasons.
For that matter, even C++ isn't impervious to cracking, but IP prorection vs. cracking are two separate, important concerns.
That's a really tricky task, especially with something running in a VM.
I would say you might be thinking in the right direction. Obfuscating it to make it reasonably hard to modify might prevent people from circumventing the built in licence checks.
However, ultimately, if your application is self-contained, it will always be crackable. If you can build it so that it uses services you provide, than you can probably command it's use.
To paraphrase a Mr Jeff Atwood, it is better to make it easier for your customer to pay you than it is to crack your app. In other words, I think you are attacking the wrong problem. Make buying your product REALLY easy and then your customers won't feel they need to go to the effort of cracking it.
I would have a look at the backlash from the game Spore before deciding on a licensing scheme. They had it phone home, and only allowed so-many installations, etc. etc. etc. Spore was supposed to be their "Killer App" and it really had a hard time simply because of the licensing. You say you are willing to have fewer sales than see people using it for free, but you may want to be careful what you ask for. I was really looking forward to spore (and so were my children) but I never did buy it because of the DRM scheme.
No matter what you do, it'll be cracked in very short order especially if the program really is worth anything.
If you do go with a licensing scheme, make it simple and usable so you are not punishing those that have actually paid for your software. Also, I would avoid any phone-home style checks, that way your customers will be able to continue to use the software even if you don't want to keep paying for that domain 3 years from now.
I see a specific weakness in your example, besides the comment most people already put in that DRM is hard(impossible) to implement and often simple to circumvent.
In your second point:
If everything is fine, the server
returns some crucial missing parts of
the program bound to that certain pc
along with the usage limit of say 2
days
This 2 (or X) days limit will most likely be extremely simple to circumvent, this would just a few minutes to find and patch (crack).
If you really want to have a DRM model the only reasonable way to go is to put at significant part of the application as a web service and require constant connection from the users.
Before you try any of this, be sure to read Exploiting Software and you will think twice before trying to do DRM.
I think, given the context, the most effective form of protection for now would be the limited demo/license key approach: it would give people time to fall in love with your application so that they are willing to pay for it, yet prevent casual copying.
Once you know that your app hit it big, and that crackers provably siphon off a significant portion of your possible earnings, then you can still add additional checks.
Another thing to consider is where your app is going to be used: if it's something people would put on the their laptops to use on the go, network connectivity is not a given.
That is some of the harshest DRM I've ever heard of, your users would hate it.
Also, keep in mind that there are a lot of good Java decompilers out there due to the nature of the language and someone determined enough could just find areas of the program dealing with your DRM and bypass/disable it then recompile it (according to this a recompilation would be unrealistic)... so you would even have to go out of your way to implement your code as complex as possible to prevent a hacker from being successful. (Which could be done with one of those code obfuscation tools they may have out there.)
As long as it's an Internet application, you could restrict it in that manner. Short of cracking the program, this would work fine except for replay attacks.
For example, if I can capture the traffic that is going to your server, and simply replay it back to my program each time, I'm still good. For example, I could create my own "web server" and ensure the program hits that instead of your server.
You should read "Surreptitious Software" from Collberg and Nagra. This book is really good to help you understand how software protection mechanisms work (such as Code obfuscation, watermarking, birthmarking, etc...).
As lorenzog said, total security doesn't exist and software security is like a constant race between software vendors and pirates.
You should use cheap obfuscating transformations (so the overhead they incur isn't killing the performances) to prevent as many attackers (remember most of them are script kiddies) as possible to "steal" your killer algorithms or any secret data.
If you're willing to push the security further you can birthmark your algorithms and watermark your copies in order to find who leaked your creation. But even if you do, this doesn't mean your software is 100% secured. Plus the time you'll spend adding these mechanisms might not be worth the effort.
These concepts are really well explained in the book I mentioned before which is worth reading.
If I had enough reputation points, I'd vote this question down. Commercial software protection is a waste of time, money, and effort for many reasons. Concentrate on making a piece of software worth buying. If your software is popular enough to maintain wide seeding by pirates, you're probably successful enough at that point that you won't even worry about piracy. Anyway, crackers crack software protection mostly for fun. The stronger your protection, the better the challenge it presents and the more they want to crack it. Your best effort will cost you thousands, take months, and be cracked in only days.
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 4 years ago.
Improve this question
What do you do when your manager wants you to implement something in a quick and dirty way and you just know it's going to backfire?
My manager wants me to develop a web app for a client and to do it as quickly as possible. This is the first web app we're building for this client, and I think it's important that we do it right so that we will be able to build upon it when they inevitably ask us to enhance it or create a new one.
I'd like to spend some time setting up a framework (even if it's just something simple like Stripes), and configuring tomcat to use DBCP. I also think we should be using css templates, and giving at least a minimum amount of thought to the presentation and design of the app as, in my opinion, nothing looks quite as unprofessional as a poorly designed web page (unless it's an email with really bad grammar).
The problem is not so much that we're under pressure to get this done, but more that my manager does not feel he can justify billing extra hours for something he himself does not consider a necessity. His "just get it done ASAP" approach has already backfired a few times - once, for example, he told me not to design the code to handle a certain error situation as it was very unlikely to occur, and then when it did occur it was a big mess (that I had to clean up).
So what do I do? Do I really do it "quick and dirty"? Do I decide that the quickest way is to do it right and deal with the fallout if it takes me longer than he had hoped? Part of the issue here is that while I have done web development in the past, it's always been within an existing framework, so setting up a framework from scratch involves a learning curve for me.
Keep in mind that in his point of view, billing lots of hours makes the sale less appealing to the customer. This could be a good marketing approach (even if it's a horrible design decision) to write it quick and dirty now so the client likes it, and when they want changes he can bill more hours in the future because now he has the client "in his net".
But my advice is: look around you, he's in charge, so do it his way otherwise you're only creating problems for yourself. If you want to do things right, become the boss or find another company that does believe in doing things the right way. But simply going against the grain will only get you fired or in the doghouse with this guy, this is how life works.
Do quick and dirty. That's what they want, that's what they're willing to pay for. Take the money and deliver that.
Later, when the system is unmanageable because it's complete and utter chaos in there, and the client is in a position to want and pay for a robust, well-engineered solution, take the money and deliver that.
See, you get paid twice!
Furthermore, a crap solution will end up with some ongoing manual processes. These can be charged for. You get paid again!
No wonder your manager likes that approach!
In spite of the risks, I'll offer a management perspective on this. :-)
One challenge I've had with some team members is that they sometimes have a hard time seeing the big picture. That's obviously a statement that developers can make about their managers too--certainly managers (especially nontechnical managers) can fail to appreciate how hasty decisions now will lead to problems later. But I'll repeat that it's not just managers who can miss the big picture. Developers can too.
One time my team was supposed to develop a simple demo, and I had two people working on it. This was in all likelihood a throwaway demo. Was there some chance that we might end up keeping it and elaborating it? Sure. The chance was even decent--maybe (just making up a number here) 25% just for argument's sake. After nearly a month there was no deliverable and finally I called BS. It turned out that the developers were "engineering" the thing. Setting it up to be modular, pluggable, testable, etc. I told them to stop and I wrote the demo myself in a single afternoon. The "big picture" was to deliver a proof of concept to the customer quickly, and if for whatever reason we decided that we wanted the demo to evolve into an actual piece of production software--fine--in the worst case we throw away a single afternoon's worth of "hard work". And that was the worst case. It wasn't like I was able to make a few hundred lines of code that complicated.
No doubt sometimes managers make bad calls in the name of expediency, but just because I ask my team to do something quick-and-dirty doesn't mean I'm being short-sighted. Most of the time it means that delivering value quickly is more important in the situation that getting the engineering right. Unfortunately for some developers (a minority, to be sure), the very suggestion is blasphemy.
Start polishing up the resume.
If by 'first web application' you mean prototype then you should probably do it quick and dirty. Your client probably wants to see something before they commit to anything. You CAN do something quick however; without making it dirty. If you were careful about how you designed the web app and wrote it you could probably turn the web app into a work of art in no time after you've released the first version.
Allow your boss to learn from their mistakes.
If you always strive to protect them from themselves then they will never be able learn from their bad decisions, and you will always be trying to mitigate their next bad decision.
It is also important that you don't shield them from the repercussions of a bad decision, for example by quietly putting in a weekend for something that you feel guilty for.
You can and should of course do all this graciously with no hint of spite. Better still, diplomatically talking through the reasons for each approach as early as possible can work wonders.
Of course some people never learn ;-)
I feel that sometimes you have to make choices based on integrity and not fold to the demands of expediency or just because your under pressure from your boss. That doesn't mean I have an answer to your question, only you have to decide for yourself what is appropriate in this situation, with this customer, in your organization. Ask yourself:
How much does your boss really know about what the customer wants?
Do you know better than your boss? Is your relationship with the customer stronger?
Where is the pressure coming from to do it quickly?
Does the customer realize the costs/benefits associated with "quick and dirty"?
What kind of orginization do you work in? Would you consider yourself kind of more of a consultant (very close to the customer) than an employee or vice versa?
How well thought of is your boss (at your company or by the customer? Similarly how well thought of are you?
Is the code truly throw away or if its going to actually be used in the future
If it's just a demo for a client I think a quick-and-dirty solution is sufficient, but ultimately it is you're job as a developer to protest if you think it's going to backfire. Uncle Bob in Clean Code drives home the point well:
"What if you were a doctor and had a
patient who demanded that you stopped
all the silly hand-washing in
preparation for surgery because it was
taking too much time? Clearly the
patient is the boss, and yet the doctor
should absolutely refuse to comply.
Why? Because the doctor knows more
than the patient about the risks of
the disease and infection. It would be
unprofessional (never mind criminal)
for the doctor to comply with the
patient.
So too it is unprofessional for
programmers to bend to the will of
managers who don't understand the
risks of making messes."
This is a case where you need to manage up. Your boss doesn't see the need to implement a good design because he doesn't see that it's going to be easier in the long run. You can either convince him now or make sure that he sees the problem when modifications end up taking longer. At the very least you can steer his thinking over several small tasks so that you train him to go for good design over time.
Just do the quick-and-dirty implementation. Your job is to turn the spec into a working program, not to analyse tradeoffs between immediate costs & future benefits. I've worked with engineers who insisted on adding loads of layers of indirection, wrappers, unused code etc. which no-one was paying for, insisting they knew better than the PM. I've also been that guy (for a couple of years after I graduated) and it does not make you popular. I don't do it anymore.
Hmm, if your boss is only willing to fund quick-and-dirty and you disagree with the assignment, then find another job. Sounds like you don't like doing what you are being paid to do.
I'd go quick & dirty if that's what you've been asked for, as jcollum suggest, Ruby on Rails mught be a solution.
The reason I'd go for quick a dirty, is that if the user and your manager have a time frame and budget, and you can provide a stable solution that meets these and any other requirements, you should do so. Bottom line, if you're working for someone else, it is about meeting their requirements, not necessarily your own ideas about best practice or framework design. That said, if you can convince your manager and the client of the long term benefits of more upfront investment for a better long term outcome, go for it, and fair play to you.
My guess is once you have done a few more implementations, you will be better able to combine fast & good.
On the one hand you're not necessarily privy to all of the factors and pressures on the boss. Perhaps he/she knows this is a "one-off" and you won't be doing any business with this client.
The bottom line is that you're getting paid to implement whatever they tell you to implement. Yes, you have a responsibility to point out the pros and cons but, in the end, it's their decision.
But, to be safe, document EVERYTHING! If people start playing the blame game you can at least have your backside covered. (Might not do any good but always protect yourself.)
My advice would be to say that there is a quick and dirty way to meet the requirements within X days/weeks/months and that if there are major enhancements or features then there will be a cost to move to something larger that can handle what is now required.
Something to consider here is the idea of YAGNI if the client doesn't want anything more than the basics that they wanted in the first implementation. There is also the question of how much of a framework will you be building in this first go round.
If you were in charge, I would imagine you'd do it the "correct" way with a good design, even if it takes longer. The problem though is your manager is in charge. So, this sounds like a conversation you should be having with your manager.
Remind him (subtly) of the times his approach resulted in a mess and suggest that a bit more attention be made to the project. Suggest it may be a good marketing decision to put a little more effort into this project because the relationship with this client may be crucial. Don't get into an argument, just make yourself heard. At least it may get him to stop and think again about his decision - maybe he can have another conversation with the client about how much they're willing to pay.
In the end, respect his decision but make sure he does realize it was his decision and you're simply following orders. That way if a problem does develop in the future, it doesn't end up being your problem.
If he's not the approachable type, I think you're stuck doing it the quick-and-dirty way. I would document the situation though to minimize future ass-biting potential.
Ruby on Rails. If that's an option. I've heard plenty of times that it's the fastest way to get a CRUD site up and running well.
[edit]
Building your own framework is a huge waste of time, you're not going to be able to build a world class framework in any reasonable amount of time. Don't reinvent the wheel. I've heard plenty of programmers say "oh yeah I could build that soooo much better." Sure but could you build it even close to as good in the 5-10 hours of paid time that it will cost your company to just buy it outright? Unlikely.
If this is something that your company does frequently then you should talk your boss into letting you find an off-the-shelf solution to the "quick and dirty but still decent" problem. It might mean extra time now but will save time in the future.
[/edit]
I wouldn't be too judgemental on the boss. Like many people say, he/she has a POV just as you do. You need to adapt to handling this type of demand by learning some kind of rapid prototyping tool. I use the Microsoft platform for business and web applications (Java for scientific tools) so whenever someone wants to see a prototype web site I can hack something together on my local dev platform pretty quickly using ASP.NET. Usually for a prototype, ugly doesn't matter as much as functionality. If the customer knows a thing is possible then they will be apt to buy into the beautification (unless its internal - then who cares what it looks like - ha!).
Think about the fact that you are supposed to be a "professional software developer".
Being a member of a professional group means adherring to some codes and rules. That means that you don't just give up on your principles just because management tells you to.
If you really believe that setting up a framework and using CSS templates is necessary to deliver a product of proper quality, then insist on doing it.
Imagine if a construction engineer was told to do a bridge design in a quick-and-dirty way by his manager. Would he do it even if he knew the design was of poor quality? What would be the consequences if he did, for him personally and for construction engineering as a profession?
I think we as software engineers need to take more pride in our work, and show more professional responsibility.
I'd interpret "Q&D" to "Quick and Feature-Poor". Dirty is seldom Quick, even for a demo or proof of concept. Whatever you do to start, you'll be refactoring it anyway. Just give it the time available, and focus on YAGNI and Minimum Sufficient Solution.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Project Darkstar was the topic of the monthly JavaSIG meeting down at the Google offices in NYC last night. For those that don't know (probably everyone), Project Darkstar is a framework for massively multiplayer online games that attempts to take care of all of the "hard stuff." The basic idea is that you write your game server logic in such a way that all operations are broken up into tiny tasks. You pass these tasks to the Project Darkstar framework which handles distributing them to a specific node in the cluster, any concurrency issues, and finally persisting the data.
Apparently doing this kind of thing is a much different problem for video games than it is for enterprise applications. Jim Waldo, who gave the lecture, claims that MMO games have a DB read/write ratio of 50/50, whereas enterprise apps are more like 90% read, 10% write. He also claims that most existing MMOs keep everything in memory exlcusively, and only dump to a DB every 6 hours of so. This means if a server goes down, you would lose all of the work since the last DB dump.
Now, the project itself sounds really cool, but I don't think the industry will accept it. First, you have to write your server code in Java. The client code can be written in anything (Jim claims ActionScript 3 is the most popular, follow by C++), but the server stuff has to be Java. Sounds good to me, but I really get the impression that everyone in the games industry hates Java.
Second, unlike other industries where developers prefer to use existing frameworks and libraries, the guys in the games industry seem to like to write everything themselves. Not only that, they like to rewrite everything for every new game they produce. Things are starting to change where developers are using Havok for physics, Unreal Engine 3 as their platform, etc., but for the most part it looks like everything is still proprietary.
So, are the guys at Project Darkstar just wasting their time? Can a general framework like this really work for complex games with the performance that is required? Even if it does work, are game companies willing to use it?
Edit: This was written before Oracle bought Sun and started a rampage to kill everything that does not make them a billion $ per day. See the comments for an OSS Fork. I still stand by my opinion that stuff like that (MMO Middleware) is realistic, you just need a company that doesn't suck behind it.
The Market may be dominated by few large games, but that does not mean that there is not a lot of room for more niche games. Lets face it: If you want to reach 100.000+ players, you're ending up building your own technology stack, at least for the critical core. That's what CCP did for EVE Online (StacklessIO), that's what Blizzard did for World of Warcraft (although they do use many third-party libraries), that's what Mythic did for Warhammer Online (although they are based on Gamebryo).
However, if you aim to be a small, niche MMO (like the dozens of Free-to-Play/Itemshop MMOs), then getting the Network stuff right is just insanely hard, data consistency is even harder and scalability is the biggest b*tch.
But game technology is not your only problem - you also need to tackle Billing. Credit Card only? Have fun selling in Germany then, people there want ELV. That's where you need a reliable billing provider, but you still need to wire in the billing application with your accounts to make sure that accounts are blocked/reactivated when the billing fails.
There are some companies already offering "MMO Infratructure Services" (i.e. Arvato's EEIS), but the bottom line is: Stuff like Project Darkstar IS realistic, but assuming that you can build a Multi-Billion-MMO entirely on a Third Party Stack is optimistic, possibly idealistic.
But then again, entirely inventing all of the technology is even more stupid - use the Third Party stuff that you need (i.e. Billing, Font Rendering, Audio Output...), but write the stuff that really makes or breaks your business (i.e. Network stack, User interface etc.) on your own. (Note: Jeff's posting may be a bit flawed, but the overall direction is correct IMHO.)
Addendum: Also, the game industry does license and reuse engines a lot. The most prominent game Engines are the Unreal Engine, Source Engine and id Tech, which fuel dozens, if not hundreds of games. But there are some lesser-known (outside of the industry) engines. There is Gamebryo, the Middleware behind games like Civilization 4 and Fallout 3, there was RenderWare that is now only EA-in-House, but used in games like Battlefield 2 or The Sims 3. There is the open source Ogre3d, which was used in some commercial titles. If you're just looking for Sound, there's stuff like FMOD or if you want to do font-rendering, why not give FreeType a spin?
What I'm saying is: Third-Party Engines/Middleware do exist, and they ARE being successfully used since more than a decade (I know for sure that id's Wolfenstein Engine was licensed to other companies, and that was 1992), even by big companies in multi-million-dollar titles. The important thing is the support, because a good engine with no help in case of an issue is pretty much worthless or at least very expensive if the developer has to spend their game-development-time with unneccessary debugging of the Engine.
If the Darkstar folks manage to get the support side right and 2 or 3 higher profile titles out, I do believe it could succeed in opening the MMO market to a lot more smaller developers and indies.
Sounds like useless tech to me. The MMO world is controlled by a few big game companies that already have their own tech in place. Indie game developers love trying to build MMO's and sometimes they do, but those games rarely gain traction. Larger companies breaking into the MMO world would probably license "proven" technology, or extend their own.
Game companies reuse vast quantities of code from game to game. Most/many game companies have developed their own tech internally, and use it on every game they produce. Occasionally, they will do something like replace their physics code with a 3rd party physics engine. If their internal code base (game engine, design tools, internal pipeline) starts to age too much, or become unwieldy, they might switch to one of the big game engines like Unreal. Even then, major chunks of code will continue to be re-used from game to game.
From what I can tell, video game companies do not reuse most of their code, because if they do it implies that their new game is just a rehash of an old one.
Um... if you're referring to the long tail of video game companies, maybe. Within a company that has had a series of successful games, there is usually some modicum of reuse. Major hardware changes can result in ditching a lot of work, but it really depends on the company.
It sounds like fun to design and code, but I think it ultimately comes down to useless abstractions (to steal from Joel).
It's very common for games to reuse "game engines," even those from third-parties. This sounds like another step in that direction.
I think it's a great thing to do.
Developers not having to worry about all these things that project darkstar takes care of, and it's very easy to use.
But it's not all about just getting it to work and not having to learn everything about internet-communication, It's also about performance. Project darkstar has been under development for over 2 years and it keeps getting better,faster and more robust.
I think it will be hard and probably not worth the time to write these things when aiming at a specific game, when technologies like this can be used instead. And you also get nice information during runtime telling you where in an application there's a cause of slowdown or deadlocks so you can improve that.
I don't work in the games industry, but it sounds to me like this will do the same thing for video games as the Quake and Half-Life engines did. That is they will promote getting young developers interested in the industry and promote development of indie games.
From what I can tell, video game companies do not reuse most of their code, because if they do it implies that their new game is just a rehash of an old one. Everyone wants a cool new physics engine, better graphics, new ways to play the game. Most video game engines and frameworks are made for a specific scenario and thus are not very bendable to other situations.
Maybe Darkstar will get it right though, but I kinda doubt it, since generalizing only works for so much.