I'm trying to analyse compiled Dalvik code, but I found a problem. Here is a specification of .dex format. I can get header of the file, but I couldn't understand what is going on next - when I use dexdump I have classes right next to header:
class_defs_off : 61836 (0x00f18c)
data_size : 368612
data_off : 72312 (0x011a78)
Class #0 header:
class_idx : 62
access_flags : 1536 (0x0600)
But when I look at my bytecode there is something other. I can't understand what going next to header. According to specification it is string_idi's, but I'm not sure. What is the real structure of .dex files?
Baksmali can dump the contexts of an existing dex file, in a format similar to the hex dump of dx. (The advantage is that it can dump an existing dex file)
baksmali classes.dex -D out.dump
The spec you refer to does in fact accurately portray how dex files are structured. (Note: I wrote that document.)
Dexdump doesn't output the full contents of a dex file in order, which explains some of your confusion. The dx tool can output an annotated listing of dex file contents when it generates a dex file. You might find this useful. Sorry, I don't remember the options offhand, but it'll be something like --dex --dump-to=file.txt --dump-bytes.
I hope this helps.
Related
I just compiled a customized Minecraft server (PC-server running in console) into a .zip file, named test.zip, containing classes.dex and classes2.dex, with sdk-dx tool.
I want to run the application with the "dalvikvm" shell command, but it keeps throwing java.lang.NoClassDefFoundError: test.server.Start
The path of the .zip file is /sdcard/Test/test.zip, and the original main class is test.server.Start in classes.dex. (I don't think it's modified since I tried dex2jar and the class names remain the same.)
These are the commands I've tried. Non of them works.
dalvikvm -cp /sdcard/Test/test.zip test.server.Start
dalvikvm -cp /sdcard/Test/test.zip/classes.dex;/sdcard/Test/test.zip/classes2.dex test.server.Start
dalvikvm -cp "/sdcard/Test/test.zip/classes.dex /sdcard/Test/test.zip/classes2.dex" test.server.Start
Does anyone know what's wrong here?
Setting aside bigger questions, the Dalvik classpath is a colon-separated list of filenames (e.g. /sdcard/foo1.jar:/sdcard/foo2.jar). Each jar/apk contains a single classes.dex. For an APK you'd work around this with multidex, but for command-line invocation you just need to put each classes.dex into its own jarfile.
I am using gdb for dumping core file for an android process. I am running gdbserver on the device on tcp port and gdb client on the desktop. When i do gcore on client i get the below error.
Does any one know why i'm getting this error , any help much appreciated.
(gdb) gcore
Command not implemented for this target.
The reason i'm doing this to dump process memory and extract Classes.dex file from the memory using core file. I've tried doing this using /proc/pid/mem and proc/pid/maps and dump memory but that has too many mapped regions , i couldn't find the area where the Classes.dex file is. Any other alternate approach is also welcome. Thanks for your help.
First of all, you can only dump odex from memory (because dex compiled to odex for execute). But its not a big deal to convert odex to dex using baksmali-smali.
To find odex in memory you can use gdb for checking magic number for every begin-address of mapped memory(proc/pid/maps - first column):
gdb --batch --pid "pid_task" -ex x/s "mem_start"
So, when returned value equal to "dey\n036", you can dump this memory region via gdb.
Try to begin checking memory addresses from the end of file "proc/pid/maps", it will be much faster.
PS Sorry for my english, but hope it will help.
#Chris Stratton, the memory mapped classes.dex file will be different from the dex file inside apk on disk, for example in cases of packed dex files, some part of dex will be deobfuscated, question is to dump the memory mapped classes.dex file by getting the process memory.
You can use GameGuardian for this. Need root.
Memory editor tab - menu - memory dump - input 0-0 as range and folder - press ok - wait for toast Dump end.
Go to selected folder - open maps file - search needed odex in regions - remember start address of region - open GameGuardian - menu - memory dump - input remembered address in both field as range - press ok - wait for toast Dump end.
Now you have in your folder .bin file with dumped odex file.
Also you can find address in drop down list in GameGuardian UI. Press drop down icon on right with dump range field.
Here some video examples how to do this:
How to dump odex file from memory on Android -
GameGuardian
I'm trying to decompile some apk using apktools, but on the first step when I'm doing:
apktool if framework-res.apk
I'm getting the following log:
Exception in thread "main" brut.androlib.AndrolibException: Multiple resources:
spec=0x01080293 drawable/ic_ab_back_holo_dark, config=-xhdpi
at brut.androlib.res.data.ResConfig.addResource(ResConfig.java:65)
at brut.androlib.res.data.ResConfig.addResource(ResConfig.java:58)
at brut.androlib.res.decoder.ARSCDecoder.readEntry(ARSCDecoder.java:196)
at brut.androlib.res.decoder.ARSCDecoder.readConfig(ARSCDecoder.java:165
)
at brut.androlib.res.decoder.ARSCDecoder.readType(ARSCDecoder.java:130)
at brut.androlib.res.decoder.ARSCDecoder.readPackage(ARSCDecoder.java:10
5)
at brut.androlib.res.decoder.ARSCDecoder.readTable(ARSCDecoder.java:82)
at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:48)
at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:39)
at brut.androlib.res.AndrolibResources.installFramework(AndrolibResource
s.java:384)
at brut.androlib.Androlib.installFramework(Androlib.java:365)
at brut.apktool.Main.cmdInstallFramework(Main.java:193)
at brut.apktool.Main.main(Main.java:69)
My guess is that this apk contains lib that possess resource with the same name as the main apk's project. The question is whether I can fight and get it to work or leave it.
PS - I still can decompile the .class file using JV-GUI but I need the xmls.
Thanks
Your version of Apktools is too low. you need download apktools 1.52.
I am porting to SDL2 and the Android platform a C++ game that uses SDL 1.2. Everything went well so far except for one thing: when I try to access the fields of SDL_Window, the compiler tells me
error: invalid use of incomplete type 'SDL_Window {aka struct SDL_Window}'
I think my installation of SDL may be faulty. I have compiled SDL 2.0.0 from the source found on libsdl.org using the folloing command:
ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APP_PLATFORM=android-18
Then, I have copied the freshly built libSDL2.so into $ANDROID_TOOLCHAIN/sysroot/usr/lib and the files in the include/ directory in $ANDROID_TOOLCHAIN/sysroot/usr/include/SDL. These files are given to CMake and referenced by the game's code. I managed to convert every SDL calls and now I am stuck with this SDL_Window problem.
I did a quick search in SDL's source code and found that SDL.h includes SDL_video.h which contains a typedef SDL_Window on struct SDL_Window. Then I searched for this struct and did not find anything except in the original source archive, in a file named src/video/SDL_sysvideo.h. Since it is not a file of the API, I doubt I have to include it in my code.
So, how to find a definition of SDL_Window in SDL2, for Android (if this is relevant)?
It appears that the problem is a lack of knowledge of SDL 2's API. Let's remember that one does not access the fields of struct SDL_Window: there are functions to get the size and the flags of the window, such as SDL_GetWindowFlags and SDL_GetWindowSize.
So the problem is absolutely not related to the installation of the SDL or to Android builds. Sorry for the waste of time, people of the Web.
I would expect that you are expected to only deal in pointers to SDL_Window objects, and not actually put a full SDL_Window object on the stack.
I have an important problem while compiling Android Application.
Using Windev Mobile, it generates java code, compile and create apk, however, when the apk creation, an error happens:
command line: "myjavapath\java.exe" -Xmx1024m -Djava.ext.dirs=.\platform-tools\lib -jar .\platform-tools\lib\dx.jar --dex --output "path\classes.dex" "path\classes" "path\libs"
returned error:
Trouble writing output: No expanded opcode for 0004368d R.java:11#0001: invoke-direct v0:NffffLmynamespace/R$attr;, java.lang.Object.<init>:()v
Furthermore, R$attr in R.java contains nothing:
public static final class attr {
}
I assume there is a hard limit of 64k. But:
The R.java file contains only 364 lines, if these lines are
fields/methods references, I'm very far away from 64k hard limit.
This error happened when I add a specific window, in my Windev Mobile project. Window that I'm using in another project without error.
So, what do you think it comes from?
If you need any information, or document, no problem.
Thanks in advance.
PS: Maybe my english isn't perfect, I sorry for that.
There are various limits in the dex file format. It looks like the one you are encountering is that there can't be more than 64k method references. This limit is for all classes in your dex file, not for just a single class.
The fact that the error is occurring on that class has nothing to do with the class itself, that's just that where it happened to hit the limit.
The only solution currently, is to reduce the size of your code, or to split some classes out into a separate dex file that you load dynamically.