Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Out of fear that someone will downvote this question because piracy is not preventable, I want to make it clear that the system I have put in place is only to deter pirates, and I am asking this question to ensure that it causes as little annoyance possible.
Currently, my system uses a combination of the MAC address, CPU Type and the HDD serial to create a hardware fingerprint (not the problem). Using Windows all my life, I have been pretty naive towards the simplicity of installing (and 'uninstalling') applications on OS X. At the moment I am storing this hardware fingerprint in a location in ~/Library/Application Support (so that Administrator passwords aren't required) as I had the intention of removing the application with an uninstaller. I know that some Mac applications use uninstallers, but personally I don't want to intervene with the simple drag 'n' drop process that is the convention.
I am going to implement functionality that will check the online database the see if the fingerprint of the machine running the software corresponds with the fingerprint that was bonded with the serial key upon licensing the software (If the user has an internet connection). Though, that would still require a way to store the serial key that was used and I want my users to be able to run the software without an internet connection.
Does anyone have any experience in this field or have any suggestions as to how I could still allow my software to be installed and removed using drag 'n' drop while still implementing my licensing system?
Thanks in advance.
Instead of storing the hardware fingerprint, just calculate it when you need it.
I do not know if the Preferences API would work for you in this situation, otherwise it could be used.
I don't suppose this is actually a proper, nor does it have a common answer. I also think I've probably jumped the gun and asked the wrong questions because in my more recent question that I asked I got the information I was looking for. So, the answer I really wanted/needed:
(It turns out) It's okay to leave files behind in Application Support (and Preferences). Some would even consider it desirable. So I'm going to store the licence file and a configuration file in a subdirectory of ~/Application Support and let my users decide where to put their 'database directory'. That way everyone wins (well, pretty much)!
Just an FYI, The problem wasn't with what I had, it was with where it went (file wise).
Related
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 last month.
Improve this question
Account is new but I've been reading on this website for years and I now need some advice.
Still pretty new at Java and I am developing a desktop application that deals with personal information relating to the user but also their social circles.
What would be the best option to keep these info safe? I am not considering external DB (like MySql which I am using so far for my beta) as it means potential users would have to install and configure some other softwares, also not considering serialization as I don't really like the idea of an external txt file (please correct me if I am wrong about any of these two points).
Is there a way to directly store info in the application? Could someone please give me some perspective on the matter and recommend leads?
(And sorry if a previous thread covers my concerns, I did not find it!)
Thanks a lot in advance!
Good night, evening, day or morning!
Modern OS design and security principles strongly dictate that an app should not have write access to itself. There are real hacky ways (complex, hard to write, most libraries don't work well with it, and fragile, in that it'll easily break on some systems) to write into your own jar, but it's a bad design in any case, let alone when you take into account that complex and fragile.
You can't reasonably encrypt anything (because the password will have to be inside the app) unless the user has to enter the decryption password as they start your app / open your 'storage file' if it's a multi-document kind of deal, in which case, by all means, do that.
h2 is an all-java database engine, no need for the user to install separate anything, it produces a single file with the data. It's that or handroll your own serialization to a separate file in the user's home or ~/Documents or whatnot. You'll have to hardcode for each major OS the right location if you don't just want to 'write to .myapp.bin in the home dir of the user' which you can easily do via System.getProperty("user.home").
So, yes, you are wrong on both points:
DB/SQL is fine - there is no need to force the user to install a separate library. sqlite can do it (but this does involve DLLs and the like; sqlite JDBC driver takes care of this), but I'd recommend h2database.com for this purpose.
It will be a file. It won't be a txt file. This is good.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I am working on a mac os x computer. I was asked by a Java automatic update.
I have answered to remind me later this update.
And Safari opened this url: prefmgr-cookie.truste-svc.net
Do you think it is a malware or do you have ever see that when updating Java for mac os x ?
Thanks
prefmgr-cookie.truste-svc.net is a service from TrustArc (formerly TRUSTe, hence the domain name) which provides services for websites so that they can manage privacy management processes. Basically, they host the cookie compliance stuff, for example. Various research shows that they suck at their job, so a TRUSTe logo on a site is mostly a sign said company is throwing money at the problem and not actually willing to adhere to standards and laws, but that's beyond the technical nature of Stack Overflow.
It is not malware.
Note that 'java automatic update' isn't a thing. java is shipped by some party, and there are many offerings: AdoptOpenJDK ships them. So does oracle (but they don't want to, and you should probably not have oracle's offering). So does azul, amazon, even microsoft.
The updater, if there is such a thing, is installed and controlled by the party that shipped it to you, but you did not specify which java you installed, so going much further than this answer is difficult without knowing what you have.
You also don't need java installed unless either [A] you are a developer or [B] you are trying to run software built by some entity that is woefully out of date. Java apps should be shipped self-contained (not requiring you to separately install 'java') and this isn't hard to do either.
Googling this URL points to the company TrustArc (https://trustarc.com/), which provides an integration for websites, where the website visitors can manage their cookie preferences (e.g. only allow cookies which are necessary and disable additional tracking cookies on a specific website). So the URL itself is from a major company in that area, and can IMO be trusted.
For the reason, why this would be opened when delaying the Java update i can only speculate, possibly because the fact, that you delayed the update is stored locally in a cookie and thus the updates has to forward you to that page so that you can manage the settings.
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
I have a small doubt, I trying to make my application secure as much as possible so is it possible we can make a setup file that will run only once and after that it should not run on any pc. It sounds STUPID but is it possible. I don't have any code to show, I just want to know can we make it in JAVA
The setup wizard doesn't actually control when, or if, it runs. Nor does it control how many times one wants it to run. So the direct answer to your question is "no"; however, it is quite possible (and even desirable) to have the setup wizard check for "artifacts" of being ran a previous time.
If you have a setup wizard detect a file or setting which the wizard would be the only likely creator and then shutdown if it is detected, then effectively you can guard against the critical section of the wizard being run twice.
You could have the application connect to a website to check if it has been installed however it would require internet connection at the time of installation.
Then during the installation you would send notice of its installation.
I use a system like this. At time of download it generates a serial number and inserts it into a file that is later read by the installation system and used to "register" the product during installation.
No. You can put some reasonable steps in place to make it more difficult, but anyone truely interested in breaking your security mechanism will likely be able to.
Anything you create can be copied and executed any number of times, even if the running copy deletes itself afterwards.
This leads to the requirement of external authentication against some server each time the setup program is run. This however is also not guaranteed to work, just look at how easy/quick video game DRM is to crack as an example.
You could read from a file that contains either true or false. Wrap the start-up of the wizard in an if statement to only execute if this variable is false, then at the end of the wizard change the file to say true. If you want to make it more secure you could encrypt the file and then decrypt to see what it says.
"Is it possible" is always a tricky question, for many reasons.
I think it is unlikely that you will be able to create this to work the way you want, simply because you're talking about a security question, and if anyone is seriously interested in violating your security measures, then there will be someone better at breaking than you are at locking.
Whether your software will inspire that sort of interest, I have no way of knowing. The important question in security is "can I make this secure enough for my purposes?", and we don't know enough about your requirements, expected threat models, and so forth.
All in all, the best answer I can give you is: if you want security done right, don't do it yourself. Go to a professional and have them secure it. You want to know enough about security to evaluate the professional, so you have some hope of getting what you pay for, but you don't want to try to write that code. You might be good at writing spreadsheets or mail clients or whatever you're writing, but you're clearly not good at writing security, and it's not something you learn in a day.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Recently I released an app into Android Market using the licensing system with the ServerManagedPolicy model.
Some days ago someone cracked the apk making it always response "Using cached license response" and allow access.
How can I avoid that in future apps? Thanks!
I agree with #Tom van der Woerdt Implement your own licensing library
I'd also refer you to check out this from Google I/O 2011:
Evading Pirates and Stopping Vampires
http://www.youtube.com/watch?v=TnSNCXR9fbY
EDIT:
The Presentation Notes from Evading Pirates and Stopping Vampires
Some basic keypoints
Modify the LVL
Implement LVL Tamper Resistance
Use obfuscation
Add reflection
There's no perfect solution. Even Apple's iOS has issues like this, but on a far smaller scale. If your app is very popular or good, it will be cracked. I'd say consider it a compliment.
Of course, using standard libraries for licensing is always a bad idea, because crackers can simply re-use their cracking tools for every application that was built using the same library. Implement your own licensing library, which will make cracking your app a lot harder.
Interesting fact: Apple's OS X App Store also has a licensing system built-in, but developers have to write their own libraries to use it. This way crackers can't crack multiple applications simultaneously, because every application has a different implementation of the licensing system.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We are developing a Java EE application backed by any database of customer choice.
We will sell to customers based on per user license price. How do I make sure, the application is getting used as per our conditions, i.e., not easily hackable? Are there any tutorials available?
Bill Karwin's answer was the most useful of the answers from the question mentioned in the comments. Assuming that you will go ahead with a "protection" scheme, try to do the bare minimum. Anything else tends to frustrate users immensely and leads to lower repeat business and/or an increased desire to hack around your frustrating system.
From your question, it's tough to tell if each user will install the application. If so, you probably just need to require a license code that they must contact you in some way to get. If it's a client-server thing, then your options are a lot more limited; in fact, I can't think of a single solution I've ever designed in my head or come across in practice that isn't massively frustrating. You could probably do a license code solution here, too, except the license code would somehow carry a payload that indicated the number of users they paid for and then disallow the creation/use of users in excess of that number. At that point, though, you're really walking that frustration line I mentioned.
If you can obfuscate - this is the way to go for a start. But it could be painful if you use inversion of control frameworks (e.g. spring). I heard that it's possible to obfuscate spring context as well, never tried it though. Also (just guessing) there could be some surprises with reflections, dynamic proxies and such. As to the licensing, I can suggest using TrueLicense. It has very flexible means of handling various aspects of protection as well as free trial periods out of the box. Works very well and has great documentation.
Do clients pay for support of this application? If so, there is a chance that support is a bigger pay-off than the licensing of the application itself. If so, you may consider not locking down the application, but rather, choosing to only provide support for authentic copies of the software (unmodified copies proved via checksums and the such). Many businesses licensing this software would be more inclined to avoid any modifications (even though the chance of them wanting to actually do this is probably tiny) in order to not jeopardize their support.
FYI: This is how Oracle tends to operate with their e-Business Suite. You can modify pretty much any component you want. Good luck on getting support, though!
Look at how Atlassian sells their products. I believe this is an approach that works very well, and probably would for you too. Note: There should be added value in subscribing to updates!