We Keep Coding

Reverse Engineering of an APK

For my master thesis I'm studying and improving the security of an application. The code is obfuscated and my goal now is to see how easily I can exploit the application. However, I'm having some problems; I think I may have found a piece of code that, when removed, will allow me to override some fundamental step of the application logic. As such, I want to recompile the single class that contains that piece of code and replace the one on the application with this new version. I used dex2jar to obtain a jar with all the classes and have already obtained the .java file with the class I want to alter. My exact problem is how I can recompile the file. I already downloaded the Android API jars and I'm using javac with the classpath pointing to the jar having the remaining classes of the application and to the Android API, but I still can't compile as javac complains about some Android literals being ambiguous. Can you please help? Thanks!

The type java.util.Map$Entry cannot be resolved

I've a JSP file which needs the class Map, which belongs to javax.script (if I'm not wrong).
I've imported it, but I'm getting the following error:
The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files
After doing a bit of research, I think it's because I need to have a jar file which contains it, but I don't know how can I find it (neither to which jar, nor the place to download it).
Could you explain me how to find it (as it would be useful for future cases) or provide a link?
Thank you so much

(Just for the sake of completeness.)
One reason might be that Tomcat 6 does not run with Java 8 (nor do some versions of Tomcat 7; I stumbled over that problem myself once):
https://stackoverflow.com/a/21322569/694804
So, it is highly suggested to use a recent version of Tomcat 7.0.x (or even 8) when using Java 8.

How to tell the range of java versions a jar is compiled for

How to see which java versions a compiled jar file will work with?
Thanks

generally MANIFEST.MF file has this information as an attribute, if you don't find it, extract the jar and choose a class and do
$javap -verbose SomeClass.class | grep 'major'
major version: 50
and map the javac version from that major version

Here is the structure of a compiled java class file stated from this link :
http://en.wikipedia.org/wiki/Java_class_file
Sections[edit]
There are 10 basic sections to the Java Class File structure:
Magic Number: 0xCAFEBABE
Version of Class File Format: the minor and major versions of the class file
Constant Pool: Pool of constants for the class
Access Flags: for example whether the class is abstract,
static, etc.
This Class: The name of the current class
Super Class:
The name of the super class
Interfaces: Any interfaces in the class
Fields: Any fields in the class
Methods: Any methods in the class
Attributes: Any attributes of the class (for example the name of the
sourcefile, etc.)
As you can see, the second point is the version. Therefore, download an hex editor, open any .classfile located in the jar and you will be able to read the version.
Edit : Altough I never verified, the byte offset for the version is suppose to be between 4 to 7, once again from the same link.
Edit 2 : If you prefer doing it with command, check this thread : how to check the jdk version used to compile a .class file

There is no such information in the Jar file, especially when considering that your term “java versions a compiled jar file will work with” heavily depends on how you define “will work”. An application could start, run for a second and then terminate with an exception. Does that already fulfill your definition of “does work”?
As said by others, there is a version number within the class files. You can find the information about how to map that version number to Java version here.
However, that version number only tells you the minimum JVM version that is needed to load that class file. It does not tell you which API it targets. It’s perfectly legal to compile a class file compatible with a Java 1.1 JVM but using Java 8 APIs.
You could scan all class and member references of all class files within a Jar file and compare to the official API versions, however that only tells you which is effectively used, not what’s intentionally targeted. E.g. the application could still rely on certain bugs being fixed or missing functionality filled into already existing APIs. E.g. whether an application relies on the requirement “the JRE’s AWT can load PNG images with correct transparency support” can not be concluded by looking at the class file version number or at which API it refers to.
Specifying which Java version an application or library requires is beyond the scope of simple Jar files, e.g. you may have a look at OSGi or Java Webstart.

how to avoid "duplicate class" in Java

Suppose I have have a java project myProject and am using an external library jar (someJar.jar), which has a class com.somepackage.Class1.class.
Now I find an updated version of Class1.java which fixes a bug in the original jar.
I include the new Class1.java in my source code under package com.somepackage
When I build the project (e.g., using Netbeans), there is a dist\myProject.jar which contains the classcom.somepackage.Class1.class and a dist\lib\someJar.jar which also contains a class with the same name.
When I run the file (e.g, using java -jar dist\myProject.jar), the new version of Class1.class is used (as I want).
How does Java decide which class file to run in case of such duplicates? Is there any way I can specify precedence ?
Is there any 'right' way to avoid such clashes?
In Proguard, when I try to compress my code, I get a duplicate class error. How do I eliminate this?

Java decides which one to use based on the order of the classpath. List yours first and you'll be fine.
The "right" way would be to fix the orignal source, but sometimes that's not always an option.
I haven't used ProGuard, but I have re-jarred libaries before that had duplicate classes. The solution in my case was to tell Ant to ignore duplicate classes. I would assume ProGuard would have that support too.

Can you not create an updated jar file which contains the bug fix? It's going to make things a lot simpler if you don't have two versions of the same fully-qualified class around.

1) Updated Jar is a better solution.
2) Use a different class name. Is there a reason, why you want to use the same class name and same packing? I don't think there is a reason.
3) create a wrapper/ proxy class, that encapsulate all the calls to the jar and you can decide to call this new class that fixes the bug ( provided it has a different name and packaging)

Modern equivalent of javadeps?

I am looking for a replacement for javadeps, which I used to use to generate sections of a Makefile to specify which classes depended on which source files.
Unfortunately javadeps itself has not been updated in a while, and cannot parse generic types or static imports.
The closest thing I've found so far is Dependency Finder. It almost does what I need but does not match non-public classes to their source files (as the source filename does not match the class name.) My current project has an interface whose only client is an inner class of a package-private class, so this is a significant problem.
Alternatively if you are not aware of a tool that does this, how do you do incremental compilation in large Java projects using command-line tools? Do you compile a whole package at a time instead?
Notes:
javadeps is not to be confused with jdepend, which is for a very different purpose.
This question is a rewrite of "Tool to infer dependencies for a java project" which seemed to be misunderstood by 2 out of 3 responders.

I use the <depend> task in ant, which is ok, but not 100% trustworthy. Supposedly JavaMake can do this dependency analysis, but it seems to be rarely updated and the download page is only sometimes available.