I decompiled dex and when browsing one of the classes I noticed that it contains imports from custom namespace like 'ua.blah.blah.ClassName'. When I started searching for it - seems like it is not in the dex file. I tried several tools for dex dumping and none of them helped.
So I'm wondering how is it possible for this apk\dex to work? Where this missing piece can be? It is cleanly not a standard class (like java.blah.blah).
Also I tried to search for DexClassLoader, so that may be it downloads this part from somewhere - no entries found..
The package name can be either to one of your ofuscated classes or a library class already ofuscated.
If its not on your source structure then its a jar/aar/gradle dependency.
Check into the build.gradle the packages.
Also, I don't know if it was a jar where it will be after compiled+descompiled.
Related
I have received the task, at work, to find a way to use some methods from an existent jar file in a Python project. I have very limited experience in Python, but I have worked with that specific jar file before (it is part of a project we are working on). I am not allowed to modify much of both projects, and they are required to be as independent as possible.
I have researched multiple ways to include the jar methods in Python. So far, I have tried Jython (which I cannot use because the Python project uses PyQt among other libraries, which force the use of CPython, if my understanding is correct), Pyjnius and JPype. JPype seems the most promising, but I cannot get it working either. I have pasted the my code below, slightly censored because I don't know how much I am allowed to share.
from jpype import *
import jpype.imports
try:
jpype.addClassPath("jars/sdk.jar") #the relative path to the jar file
jpype.startJVM(convertStrings=False)
java.lang.System.out.println(jpype.getClassPath()) #printing the classpath to check, the path is correctly pointing to the sdk.jar file
java.lang.System.out.println("Hello world") #just to check if jpype is installed correctly, works
jpype.imports.registerDomain("a")
from a.b.c.d.e.f.g.h import SomeClass #fails here
except OSError as err:
print(err) # ToDo: Remove print when done
pass
The error I am getting is that the module a.b.c.d.e.f.g.h.SomeClass could not be found. I have tried different ways to give the path (absolute path, relative path, place the jar in different places in the project and outside of it), but that doesn't seem to be the problem, as the path printed is the correct absolute path to the jar file.
Also, the jar is used in other (Java) projects and it works. It is created using maven package (using IntelliJ, if it is relevant, and the same Java version as the one used by the JPype JVM). In the Java projects, the import would be:
import a.b.c.d.e.f.g.h.SomeClass;
I have copied this and just transformed the syntax into Python.
I have also tried to create the class with JObject (which I probably didn't do right anyway) and also tried the older syntax (to my understanding) with JPackage. For the JPackage way, I am getting the exception that the package a.b.c.d.e.f.g.h.SomeClass.someMethod is not Callable, which to my understanding is an equivalent exception to the one I'm getting using jpype imports. I have already gone through all the questions I could find here with similar problems, but none of those solutions have helped me.
Can anyone suggest some possible solution? Or can anyone see what I'm doing wrong? Suggestions of other possibilities to replace JPype are also welcomed. If there is any clarification needed, I will edit the question.
The only thing that seems likely if the jar is on the classpath and failed to import would be for there to be some missing dependency. You have two other ways to try loading the class which may provide additional diagnostics.
jpype.JClass("a.b.c.d.e.f.g.h.SomeClass")
and
jpype.JClass("java.lang.Class").forName("a.b.c.d.e.f.g.h.SomeClass")
The first is manually loading a class by full class specification. It is mechanically what is happening under the import. The second is calling for Java to load the class (bypassing all of JPype). It returns a java.lang.Class which can be passed to JClass to make a wrapper.
Common failures include missing a jar or native library, attempting to start JPype from within a module and having the wrong relative path, error in initialization of the class due to missing resource. JPype is just calling JNI calls, so if everything is fine on Java end it should work. Given that you checked the java.class.path System variable, it has to be something to do with class resources.
The JPype user manual has an alternatives section if you would like to try to find another package. Most of the alternatives with the exception of PyJnius appear to be unmaintained.
Say an Android app uses a jar library and everything is working fine when the library is specified as a dependency:
dependencies {
...
...
compile 'org.example:example:1.1.1'
...
}
BUT : one of the classes in the org.example code needs to be tweaked.
One approach is to obtain the source code and put all of that in the java folder, and remove the module. When the tweak is made, that, and the entire library will be compiled.
Another approach is to make the tweak, compile, and replace the .class file within the .jar file.
Both of those methods have their drawbacks.
My question is: Is there an easier way to tweak code in a library?
When I tried just creating the package, placing the class that needed changing into the java folder, I got an error:
Error converting bytecode to dex:
Cause: com.android.dex.DexException: Multiple dex files define Lorg/example/ClassNeedingChange;
I just wondered if there was a trick to getting code in the Java folder to override whats in a library jar file.
Additional Info:
Although not stated specifically above, the class that needs tweaking is buried in the library and is referenced by the library's code; I don't call it directly. For the simple case where the class that needed tweaking is one that my code (and only my code) called directly, then it would be a simple matter of extending the class using the Java construct. But for this simple case, I would not need to post this question.
Extend the class that needs tweaked in your code, and override the appropriate method.
Class A extends TweakMe {
#Override
public void someTweakedMethod() {
//Do stuff
}
}
Currently I'm trying to implement the code given in the answer to this question:
CTSheetView view = sheet.getCTWorksheet().getSheetViews().getSheetViewArray(0);
view.setView(STSheetViewType.PAGE_LAYOUT);
but the poi-ooxml-schemas (version 3.14) JAR file does not contain the class STSheetViewType. I delved into the poi-ooxml-schemas JAR file (using 7ZIP) and found that the class file STSheetViewType$Enum.class existed within the path:
org.openxmlformats.schemas.spreadsheetml.x2006.main.STSheetViewType$Enum.class
But (If I'm not mistaken) The '$' signifies an inner/nested class, meaning the STSheetViewType Enum is encapsulated within another class. I checked the documentation on the STSheetViewType class in an older version of poi-ooxml-schemas (version 1.1) here and found that the class STSheetViewType contained an inner Enum STSheetViewType.Enum.
This also seems to be confirmed by the errors I'm receiving from within Eclipse. I get these errors when using the code shown above:
"STSheetViewType cannot be resolved to a variable"
"The type org.openxmlformats.schemas.spreadsheetml.x2006.main.STSheetViewType cannot be resolved. It is indirectly referenced from required .class files"
Which further makes me believe that the STSheetViewType.Enum is missing its parent STSheetViewType class file. But why? I checked the documentation on the new version of poi-ooxml-schemas-3.14 and found no mention of STSheetViewType in the changelogs. I've downloaded the binary zip file for POI several times to ensure that my download wasn't faulty, I even downloaded the source and tried building the JARs but the class file is missing each time.
I found that a class STSheetViewType with seemingly the same functionality is held in another Jar file here but I can't seem to import the class correctly. Is such a thing even possible? Or must the class file come with the poi-ooxml-schemas-3.14 JAR file?
Ultimately I'd like to find out how to make the above code compatible with the current version of poi-ooxml-schemas-3.14 JAR. Any information or insight shed on that would be greatly appreciated.
As pointed out by #AxelRichter and the FAQ, Apache POI 3.14 and above uses a subset of classes from the ooxml-schemas-1.3.jar. You need to get that jar file and include in your classpath instead of poi-ooxml-schemas-3.14.jar. POI only provides the ooxml schemas classes it requires. When you begin to directly call ooxml schema classes in your own code, you most likely have to get the full jar that has all ooxml schemas classes to avoid this kind of issue you have. You can get the jar from maven central:
http://central.maven.org/maven2/org/apache/poi/ooxml-schemas/1.3/
See also the FAQ entry at http://poi.apache.org/faq.html#faq-N10025
I am working with ForgeGradle (Minecraft Forge modding platform).
I'd like to obfuscate my mod before publishing but the nature of Forge platform won't allow me to do it by simply running program like ProGuard after compilation (with defined libraries).
Why?
The structure goes like this:
Mod -> Forge -> Minecraft
Since Minecraft uses its own obfuscated classes and ForgeGradle compilator is not DIRECTLY obfuscating Mod's code to fit with Minecraft's one, it is not possible to use MC.jar as library while using ProGuard. Compiled Forge Mod is actually decoded by Forge in runtime using SRG names. The logic behind this is not easily explainable so I'll just note: I cannot obfuscate .jar in a way to fit with libraries.
So I though - I could just take my mod's code (.java files) and rename all fields/methods/classes that are MINE before Forge compilation.
Is there a software that would allow me to pick number of .java files and "obfuscate" them in a way to not reaname references that don't belong to them?
EDIT (more explanation):
Mod's code has 3 states: Development, Compiled, Running.
I will try to give an example:
Let's say there is a decompiled method ItemSword.onHit() inside Minecraft.jar
And its compiled (obfuscated) version look like this: bca.aa(), also all packages are lost (flattened).
In mod's development state of code (.java) to make reference to it we simply make: ItemSword.onHit()
When we compile mod the call will look like this (.class): ItemSword.func_ab4234() - this is the SRG I was talking about.
Now when the mod will be loaded to game, forge will translate "ItemSword" to "bca" and "func_ab4234()" to "aa()"
Because of this I can't even add proper library - there IS NONE. I will always get (in ProGuard) NoClassDefFound Warning and I can't ignore it (it will crash compilation).
So after this edit - Is it still possible to make obfuscation with ProGuard (considering I cannot have "good" library assigned)?
Did you try the proguard options?
http://proguard.sourceforge.net/manual/usage.html
e.g. for Serializable classes and other stuff put this to your proguard configuration (you also can preserve complete classes if you like):
<!-- With this code serializable classes will be backward compatible -->
<keepnames implements="java.io.Serializable"/>
<!-- or for native access:-->
<keepclasseswithmembernames>
<method access="native"/>
</keepclasseswithmembernames>
<!--Preserve all public classes, and their public and protected fields and methods.-->
<keep access="public">
<field access="public protected"/>
<method access="public protected"/>
</keep>
If I got your question, you want to obfuscate your own code, not anything beyond that. That's what ProGuard is actually quite good at. Let's assume you created your classes in the packages com.foo and com.bar. You can use this simple ProGuard command to only obfuscate your own classes:
-keep class !com.foo.**,!com.bar.** { *; }
It tells ProGuard to not obfuscate any members of classes which do not belong to either com.foo or com.bar.
If you are getting NoClassDef errors, you added the wrong library. I guess you are using some kind of IDE (perhaps eclipse). Have a look at the libraries your project references to find the correct library classpath (e.g. a jar file). You basically need to find the classpath used for compiling your code, ProGuard will take that as well and everything should work.
I am trying to emulate some java.lang and java.io classes, e.g. OutputStream within GWT.
I have created a "super" package in my module and referenced it using super-source.
My package structure looks like
com/example/gwt/client
com/example/gwt/server
com/example/gwt/shared
com/example/gwt/super
com/example/gwt/super/java/io/OutputStream.java
com/example/gwt/mymodule.get.xml
and mymodule.xml contains an entry
<super-source path="super" />
Within Eclipse all of the files within the super folder are in error - to be expected because the package structure is wrong. .class files are being generated in the WEB-INF/classes folder, again with the "wrong" package structure so should be ignored.
When I run my application in development mode I get lots of
unable to resolve class java/lang/Object
errors. What am I doing wrong?
Rename ....get.xml to ....gwt.xml?
You can exclude "super" from the eclipse build path.
Try right-clicking or the build path menu exclusion options..
There was nothing wrong with the approach - just the execution.
I had compile errors in the emulated classes which were being masked by the fact that Eclipse was showing errors because of the "incorrect" package structure. Running the compiler from within Eclipse flushed these out.
It also seems that deleting the gwt-unitCache might have helped. As I was moving code around it seems that there were stale entries in here that were still being referenced.