I would like to make my plugin require a license to run similar to the maven clover plugin. Is there some utility out there that I can generate licenses with that will also allow me to integrate that into the plugin?
I need to do the following steps.
Modify the existing plugin to validate the license file
Generate the license file online and store the information for retrieval later.
Thanks,
Walter
If you use something too weak, it will always be possible to decompile the invoking class, remove the verification, compile the new class and add it back to the jar. So, unless you have some method of inline code in a lot of methods to do a complex validation of a string from the license data, use a tool that does something more.
You could try for example:
Easy Licenser from Agilis Software (uses Java so integration is straightforward)
[...] Java is our native language so integration is straightforward, and we are familiar with the issues you need to consider when protecting Java applications. Our license management solutions include protections such as digital library signatures (to make sure the libraries haven't been 'spoofed' or tampered with), guidelines on how to use exception-based flow of control to conceal the license check call itself, as well as protection against clock roll-back on time-limited licenses.
LM-X License Manager from X-Formation (uses JNI so make your application platform dependent)
But mostly the entry point to the license manager is vulnerable. With decompilers you can remove those calls from the software. Obfuscators make it a lot harder, but not impossible.
The mentioned solutions don't seem too be very expensive. However, if you decide to build your own solution, this open-source library might help: TrueLicense Library Collection.
In all cases, I don't think these tools offer the "web integration" you're looking for (something a la Atlassian if I understood well your requirement). It looks like you'll have to implement a custom solution for that.
Related
Are there ways to automaticlly apply changes of an API or library that have been made while in parallel there was ongoing development of the consuming part in another branch for example, just as if one would use a rename or signature refactoring operation in common IDEs, which are usually applied automatically to all consuming parts.
What are the usual strategies to handle these cases as automated as possible when no fully automated tool is used to deal with this.
I'm mainly working with the IntelliJ platform (Pycharm, IDEA), so any possibility directly inside it would be preferred.
So, as I understand git checkout changes some signatures in the API, and you want IDE to automatically detect the signature change and refactor all its clients in the project? If it is so, it is not possible in the current version.
The best way to handle this, I believe, is to change clients along with the API. This can be achieved by having all the clients in the same project or monitoring API usages via some service.
I got the Java classes from an APK after using some tools like dex2jar and JD-GUI. As everybody knows Java byte code can be converted to Java classes back so mostly it is optimized and obfuscated through some tools (like ProGuard is used in the case of Android) to make it secure from others. So what I got is obfuscated code and I want to make it error-free, readable, understandable so that I can further modify it for my own purpose (for my personal use only, I don't mean to violate any copyrights). So any help i.e advices, tools, helping material to make this obfuscated code much closer to what was written by a developer or to make it error-free and understandable will help me a lot. Currently my focus is about to reversing obfuscating techniques used by ProGuard like when I tried reverse engineering on my own projects and found that:
int resource values can be altered with ids by matching through the R file which is generated with reverse engineering.
The if/else conditions mostly converted to while(true) and some continues and breaks.
Inner classes mostly broke up to separate files
So, any other techniques and helping material for the above mentioned ways which can describe how to properly reverse them will be very helpful.
There isn't a magical tool that will refactor obfuscated code into a buildable project. Most likely, you won't be able to decompile and de-obfuscate an APK to be clean and maintainable code. This is a good thing.
There are tools which are better than dex2jar and jd-gui. One of them is apk-deguard, which claims to reverse the process of obfuscation. From their about page:
DeGuard
DeGuard (http://www.apk-deguard.com) is a novel system for statistical
deobfuscation of Android APKs, developed at the Software Reliability
Lab, ETH Zurich, the same group which developed the widely used JSNice
system. Similarly to JSNice, DeGuard is based on powerful
probabilistic graphical models learned from thousands of open source
programs. Using these models, DeGuard recovers important information
in Android APKs, including method and class names as well as
third-party libraries. DeGuard can reveal string decoders and classes
that handle sensitive data in Android malware.
You should use Enjarify, which is owned by Google, instead of dex2jar. Also, apktool is good for decompiling an APK's resources, which is not handled by dex2jar and enjarify.
Other tools include jadx, procyon, fernflower, show-java, smali/baksmali.
You will need a good IDE for refactoring. JEB looks like a good tool for refactoring. This is a paid tool mostly used by Android security researchers.
This should help:
DeObfuscator
Reverse engineering is a difficult task (i would say subtle art), mostly hit and miss, especially with obfuscated code, what you can do is to focus in some special function, that seems pretty obvious and start from there, renaming and refactoring classes, also a good IDE may help you a lot (my personal recommendation: NetBeans).
I am currently working on a project that utilizes the jfreechart library. I am currently using the jar file for this library by adding it in my build path. However I do not need the entire functionality of the library. I would like to carve out only those sections of the library I have used my code and obviously the dependent code.
My ultimate aim is to reduce the size of the project. I have to meet some size targets and using the entire 7 mb jar library is not an option.
I wanted to know if there is a way to do this apart from manually checking for dependencies?
I would ideally like to apply any suggested method to the jar file of the library but if there is a convenient way to detect unused code in the source code I am willing to import the source code into my project.
I apologize if my request is a repeat or a stupid question.
Thanks,
Sudipto
Unfortunately, you can't do this without (arguably) violating the JFreeChart license.
JFreeChart is licensed under the Lesser GNU Public License, and one of the tenets of that license is that the end-user should be free to modify or replace the licensed software embedded in your software. If you cherry-pick classes from JFreeChart and incorporate them into your JAR, you make it difficult for your users to exercise their right to replace the embedded JFreeChart classes. This is certainly against the spirit of the LGPL.
For more details, refer to the GNU LGPL and Java page.
If you want to do this kind of thing with JFreeChart, you will need to get permission from the copyright holder. If your supervisor is really keen to keep the download size down, a large cash donation to the JFreeChart project might help them come around to his way of thinking. (Disclaimer - I have no connection whatsoever to the project.)
This can indeed be hard to determine because execution paths of an application can differ per run. However there is the Instrumentation interface which can show you all the classes currently loaded by the JVM. That should give you an idea which classes to keep. As long as you have run all the possible outcomes of the application.
Generally speaking, this is of course a bad idea, but since you've asked...
I'm working on a web app that will need to process DITA documents from persistent storage (likely a JCR). The DITA Open Toolkit is the only DITA implementation I'm aware of, but it requires all of your documents to exist on the filesystem. Ideally, I'd like something that works like the DITA OT, but allows you to provide a resolver (much like an XSLT URIResolver) to pull referenced content from other sources.
If people have other ideas, such as using a virtual filesystem to trick the DITA OT into working, I'd love to hear those too. Thanks!
Edit: I forgot to mention in the original post that I'm looking for an open-source solution, as this is for a project released under the Educational Community License.
After some evaluation, the newest version of the XMLMind Dita Converter (ditac) is really up to the job. Performance is at least double that of the Open Toolkit for building identical projects: http://www.xmlmind.com/ditac/
One thing to note about XMLMind Dita Converter (ditac) is that it's released under the Mozilla Public License, which according to http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses is not compatible with GPL.
Look at Arbortext (specifically Arbortext Content Manager). Arbortext supports xinclude, catalog files, and it also has a production-ready PDF and digital media publishing tool that you don't get with the OTK. The OTK isn't really meant to be for production.
Yes, I'm a vendor (now), but I started as an implementer more than a decade ago. I answer a lot of community questions and sponsor two dozen resources for getting people's questions answered. The best of which is the SF Bay PTC Arbortext User Group (Virtual).
Are you looking to do something like what Juniper is doing? (I can only post one link, so it's going to be mine..) go to juniper dot net, choose support, technical documentation, ex-series platforms, any of the ex series docs. They're showing topics on the web directly (it's also inside the source code on the router and in the pdf books). It would help if I understood what you're trying to do.
Feel free to reach out to me offline.
This new set of DITA XProc pipelines on the EMC Developer Network might be worth looking into. It can be downloaded free for development (and there's an XProc engine there as well).
This package appeared at the end of October 2010.
Quote: "The aim of the project is to provide an alternative to the DITA Open Toolkit (DITA-OT) that does not rely on file system-based processing, has no direct dependency on Java and Ant, and makes use of the XML processing capabilities of XProc to offer greater flexibility, extensibility, portability, and ultimately also better performance. The pipelines use standard XProc features as much as possible, so with little or no effort, users should be able to use them with any compliant XProc implementation. The pipelines have been tested with EMC Documentum XProc Engine (Calumet) version 1.0.12."
My coworker just talk to me about DITA Compiler. Apparently it's part of xml mind.
According to him, the implementation isn't quite complete.
Maybe DITA2Go can help:
http://www.dita2go.com/
DITA2Go allows your files to be anyplace you please, as you requested. It also has numerous extensions beyond what the OT provides, such as scoped keydefs and ditavals, which are under consideration for DITA 1.3. It was created with intense collaboration of two TC members working on major live projects, and is used by hundreds of people currently.
It is also about ten times as fast as the OT, thanks to C++, and requires no programming skills at all to use.
It is free, but it is not Open Source. It is fully supported and the developers fix bugs immediately and often add new features in a day or two on request. It shares a large part of its code with a commercial product, Mif2Go, which is the tool used by about 25% of FrameMaker users who are moving to DITA, according to a recent survey.
I don't see a requirement for the tools used to create a freely-licensed document to be Open Source themselves. There are absolutely no restrictions on use of the output, which obviously belongs to the user, not to Omni Systems.
HTH!
I have made a java project and want to deliver it to a client but I don't want to deliver it as a jar file as the client can see the source code easily by unpacking the jar file.
How can I pack my java project so client cannot look at the source code or cannot change the source code?
One more thing, Can I integrate a key functionality so that client can only access that software by first registering it with the key provided by me?
Second, can I integrate another functionality through which the software can run only on a single machine through that key?
Remember, the software should still have the cross-platform functionality and if it is not possible then how can I made it for Debian Linux as I have made it on Windows.
To your first point. Why not only jar up the class files? These are in byte code so the client will not be able to view the source.
As to providing a key. This can be done and there are libraries that allow this, but be careful as , to my knowledge at least, there has yet to be developed a DRM system that hasn't been cracked. and most users do not like software restricting what they can do. The same point applies to your third question.
Obfuscators
There are some simple things you can do to make it a bit difficult for a client to get hold of your source code and to enforce per-host (etcetera) licensing. For example, obfuscators make it harder to reverse engineer bytecode files, and license managers support a range of restrictions based on the "keys" that you generate and supply.
The problem is that none of these protect you against someone who is determined to subvert the restrictions are trying to impose. For example, no obfuscator can prevent someone figuring out where your code calls a license manager, and once they know that they can modify the code to subvert any license checking.
Short of locking down the entire execution platform (e.g. turning of the client's ability to run debuggers, read physical devices and so on), there is nothing you can do about this.
A more viable strategy is to include appropriate protections in the software license that you require the client to sign. And accept that there is a risk that you may need to take clients to court if they willfully violate the license agreement.