Is it possible to set the java decompiler to return everything it finds during the process? I have a game I have been working on for a little over a year, I am still pretty new to java and have been beating my head against the keyboard and api documentation to produce this game. I come home from a business trip and find that my house has been broken into and my workstation is gone. I still have my keystore because I keep it on a flashdrive for safety. I also keep my project files on a flashdrive, which I did not remove from my workstation before leaving on my trip. I have tried to use every .apk decompiler I can find to recover my source code. They all return some code but of course because of proguard almost all of it is unusable. I have a copy of my signed .apk on my phone for testing purposes and it is debuggable, is there anyway to recover all of my project files from this? Like setting the java decompiler to very verbose, or a different setting that will produce a 1:1 copy of each file reguardless of if the decompiler thinks it is relavent?
Edit: I have used dj java decompiler, androchef decompiler and the decompiler # www.decompileandroid.com which is just a script that is run on their server to use the standard tools included in eclipse adt package for developing android applications.
I used to deobfuscate Java applications for a hobby and have worked on several decompilers, so if you send it to me, I might be able to help.
That being said, there are some things that are simply impossible to fix. You're never going to get back anything that isn't present in the compiled apk because it's impossible to recover information that isn't there. Among other things, this includes comments, original source code formatting, and compile time annotations. The obfuscation step will also strip out class names, variable names, unused methods, etc.
One other thing to try is to see if there's any possible way that a non obfuscated version of apk survived. Did you ever upload your files anywhere else?
Related
I have recently started learning to develop minecraft plugins and heard a good way to learn is to decompile other plugins and then learn what the code inside them does but i looked it up and could not find a way to do that.
If you would like to decompile plugins, I would recommend using a program called Luyten. You can open up jar files and see whats inside and see the code. Keep in mind, some plugins may be obfuscated and decompiling some plugins may be against the developer's TOS. If you are in the clear, you can open up a jar file in Luyten by dragging the file onto the window and you can have a look at the code there. But if you would like to edit the code in something like eclipse, you can click the 'File' tab up the top right and click 'Save All'. Then extract all the files inside the zip file and then open up the project in eclipse.
Like #exro mentioned before, you should use Luyten to decompile the code first and be aware of the developer's terms of service and the copyright licensing of the code as sometimes attempts to re-create/decompile the code will be considered a violation of their copyright and could get you into legal issues.
#exro has done quite a good job explaining how to do it on Luyten, though I'd personally like to recommend that you check out github.com and have a look at some of these projects.
https://github.com/ElevatedDev/Frequency
Frequency is a Spigot open-sourced Anti-Cheat made by a few developers and the licensing should enable you to re-create the code in Eclipse without any legal difficulties though this should not be considered legal advice (Please also note that Frequency is created in IntelliJ and Maven so I would recommend that you either learn how to use those tools or just be aware of what they are).
https://www.youtube.com/watch?v=wysn_pFhcmE&list=PLdnyVeMcpY79UFZFfqwaXF2GUGc0v3YyG
This is a beginner-friendly Bukkit/Java coding course which will get you over the first few projects you'll do.
I release a new java based Game Maker Studio extension having spent many days putting it together.
Few downloads later someone decides it nice, they get your extension and the code and make their own copy/version and sell it on marketplace for much lower price. As I beleive the java code in the extensions is easily exposed.
So whats stopping people from copying and undercutting you?
I suppose you can obfuscate your code, java etc..
But thats not really hard to still copy and alter.
What else is there. I was thinking of wrapping the class into a jar file (mind you I know nothing about this) and then importing those and just referencing the functions/methods in the extensions .java file. Is this possible if so id like to know how.
I have looked at this answer provided here, and here, and here
The answers provide some useful information but I wanted to know if there are better ways to do it.
I have built my apk and I used pro guard, but when i decompiled the apk, everything was the same as they were before the compression.
The name of the classes and some variables were obfuscated but a Newbie could have looked at the code and would understand how the app works.
In my app I want to hide the core network communication between the app and the server. For example, the address of the server, the JSON format etc.
I came across something as way to protect from decompilation is putting the java.class files into jars and then signing them and then add them as a library to my app.
My question is:
Is it the correct way to do it ie. using the jar signing ?
No. Jar signing is used to make sure the file isn't tampered with. You can still decompile it.
Rather than wasting time worrying about decompilation, you should concentrate on something useful. Obfuscation is used to save space in Android, not to prevent people from looking at your code. Besides, did you really create something so special that you need to protect it? (Be honest now)
At first I have to say, that I've just started learning java a short while ago, so I'm not familiar with the language at all. Due to this, I try to get things done without using an IDE, so I can understand how things work. However, it's not the language that drives me crazy, but the process of making a .jar file.
I have the directories E:\Java\MyLib\mylib.java, E:\Java\Test\PartA\parta.java and E:\Java\Test\PartB\partb.java, which contains my main. mylib.java is a package that gets imported by parta.java, parta.java gets imported by partb.java.
I created a .bat file consulting several tutorials as much as the official specification from oracle about how to use the jar.exe, I've created a valid manifest.txt, I told the programm where it could find the partb.class containing my main, everything gets compiled to its own .class file just fine what tells me that my code is correct, but trying to merge all the files together into one .jar file took me hours without a working result.
According to any instructions I was able to find I'm doing everything right, I tried many different spellings and options, but at the end, either the compiler does not even find the files in the subfolders, or the files are in the .jar, but the javab.class is not able to find them during runtime.
It's sickening. I think I'm missing something, doing something absolutely wrong, but I can't figure out what it is. Any advice would be highly appreciated.
Use an IDE, it makes life so much easier. But, if you insist on doing things the old fashion way, try turning off your antivirus. If that doesn't work, check to make sure your environment variables are set correctly. If all else fails, try reinstalling your JDK.
I use Eclipse to write Java code and use DropBox to sync my code with others' across our multiple computers. Most of the time, everything works as expected: if anyone makes a change on either end, the change is saved and when the other person refreshes the Eclipse workspace, the changes come through and can be viewed and run successfully.
Sometimes, one of several errors arises. Sometimes Eclipse says it cannot find a main class and sometimes it says it could not find the class itself. Sometimes it will not report an error but for some reason will not actually update the .class file and therefore run an old version even though the compiler displays the new source code and that saves. I've then noticed that if I manually copy the code into a new .java file elsewhere in the file system and then compile it, it works fine, but for some reason it refuses to regenerate the .class file and I have to delete it manually and replace it with the one generated in the other project--then it works. But for solving the other problems everything needs to be manually copied, deleted, and re-pasted....
[The actual errors include NoClassDefFoundError, UnsupportedClassVersionError, and some other error related to not having a main class.]
I realize that the description here is somewhat vague, but unfortunately I'm not entirely sure what's going on. I hope I'm just missing some basic fact that would help solve all these problems.
Thanks!
I'm sure you will see issues using Dropbox for sharing your source.
Eclipse does not know what Dropbox is doing whilst it's uploading and downloading updates and their activities will certainly not be synchronised. At arbitrary points in time when Eclipse tries to do builds etc. it will find unexpected activity going on, maybe even partially downloaded source files which might explain the specific errors you are seeing.
You're trying to do something more complex than sharing photos or documents. The advice I would give is to use a source control system like git or subversion for source code sharing and control. You can then make use of plugins for Eclipse that are designed to integrate these systems in an easy to use way. There's a learning curve there, but the skills will serve you well.
You can use online versions of these solutions like github and unfuddle if you want to consume sharing, backup and version control of source as a service like you do with Dropbox. They're free, too.
Subversion, Git and all version control software solve all of these problems for you.
Dropbox is not really an adapted system for sharing code. What you should do is set up a SVN, and commit only the source files. This way, you won't have these kind of errors.
Dropbox does have versioning (you can restore old versions of a file), and doesn't seem to be a horrible solution for the problem. I keep my Eclipse repository on Dropbox so it is available on any computer; but since I only use it myself, I haven't encountered your problems.
There is one case I can absolutely see you running into problems--it's if your class files are stored in the dropbox as well. This would just screw everything up. Make sure you specify a location on your local hard-drive for all build artifacts (classes, jars, ...) and that the only thing on your dropbox is the .java sources.
In fact, I suggest you don't keep your eclipse project in your dropbox, just create your eclipse project and point it to the java files in your dropbox.
If this doesn't work for you, go with what other people here said and set up a SVN repository somewhere, it's easier than you would think.
Oh, another possible problem--dates! You may want to make sure the date on your java files isn't jumping forwards and backwards (as might happen if one of your developers were in another time zone). In this case, Eclipse may prefer not to re-compile your file.
Also, instead of the copy/etc procedure you are currently going through, try forcing a project clean.
Response to request for more info:
When you start Eclipse, select/create a workspace that is NOT on your dropbox. The best place is probably off your home directory. If you have already specified a default workspace, there should be a switch workspace item in the file menu.
Create your project. select "Create project from existing source" and specify the source files in your dropbox. I think you want "create separate folders for source and class files" to keep your class files out of your dropbox. If you see anything saying "Copy files into your workspace, say "no".
This should give you a valid, working project. I hope you don't see those problems any more.
One more thing may help--and this may work on your existing project--without the above procedure...
Whenever you refresh your files (f5) to load in changes from the dropbox, select the Project/clean menu and select the project. This should delete all the class files and rebuild them.
If your classfiles are shared on the dropbox, this could still have strange consequences on other people with eclipse open, so I really do suggest rebuilding your workspace as I said above.
How to avoid no main class
Provide one. That issue has nothing to do with DropBox