SMSDispatch - how to create modified ddiclasses.dex?-

[andr3jx]

Hello! I modified the code in SMSDispatch.java and want to compile it and get a modified ddiclasses.dex. Can somebody tell me how I can do that? My understanding is that I need to use Eclipse / Android Studio create a apk and extract the classes.dex from the apk. But which configuration exactly do I need and what should I include? ddiclasses.dex (which I converted to a jar to take a look at the classes) includes /android/support/v4 - is it necessary?

Thanks for any help.

[scintill]

Hahaha, fancy seeing you here! I'm probably working on the same thing you are (injecting into the phone process to get access to RIL functions.) I built a makefile:

install: ddiclasses.dex libs/armeabi/librilinject.so
    adb push libs/armeabi/librilinject.so /data/local/tmp/
    adb push $< /data/local/tmp/

ddiclasses.dex: ddiclasses.jar
    /opt/android-sdk-linux/build-tools/19.0.1/dx --dex --no-strict --output=$@ $^

ddiclasses.jar: RilExtender.class IRilExtender.class IRilExtender$$Stub.class IRilExtender$$Stub$$Proxy.class
    jar cf $@ RilExtender.class IRilExtender.class 'IRilExtender$$Stub.class' 'IRilExtender$$Stub$$Proxy.class'

RilExtender.class: RilExtender.java IRilExtender.java
    javac -classpath /opt/android-sdk-linux/platforms/android-15/android.jar $^

libs/armeabi/librilinject.so: jni/rilinject.c
    sh -c "cd jni; /opt/android-sdk-linux/ndk/ndk-build"

Of course the names and paths will differ, but that's the basic idea. Going the build-and-extract way will probably work too, but I wanted to take the opportunity to learn more about the process. As far as I can tell, my dex doesn't contain any "support" or "android" classes.

By the way, as a kind of vague "bug report" for @crmulliner, I tried hooking the phone service's onTransact() for Binder, and it works for awhile until the process crashes -- I wonder if there are some thread safety issues in ddi that get exposed under the heavy volume of calls that are happening? Or maybe the glue code I adapted from the smsdispatch demo has thread issues. I don't see any message about the cause of the crash, just a logcat entry from ActivityManager that the process died, and then it gets restarted. Anyway, I know that isn't much to go on, so I don't expect you to devote a lot of time to it -- your already-awesome work is appreciated! Thanks.

[odexcide]

@scintill I think your issue sounds very similar to the issue reported a few days ago (https://github.com/crmulliner/ddi/issues/8). I assume you are trying to hook system_server since the phone service runs in it. Check out that issue reported and copy your comments under it if you feel that the issue is similar.

[andr3jx]

@scintill Great to see you here ;) Thanks for your makefile, very nice, exactly what I needed. :+1: What I did is modifying SMSDispatcher so that it logs the PDU of each received SMS, which should help to detect Silent SMS.

[scintill]

I am injecting com.android.phone. The system_server issue sounds similar to mine, though. I found there are some logs about the crash after all, see here. I just repeated it about 15 times; it usually triggers quickly. The fault address 6f5ed010 is pretty consistent, but there are some at low addresses with SEGV_MAPERR. The thread name differs; I see Binder_1 (through 4), Compiler, and com.android.phone. I may put in some more logging to see if a function is being re-entered concurrently.

Couple of other things I discovered with more advanced payloads: I found I had to use an intermediate jar, to get around an apparent bug with dx thinking classes were duplicated, when passing in anonymous inner classes in .class files. For simpler cases, you can skip the jar and just pass the .class files to dx.

My injected class depends on (through inheritance) several other classes in the dex. It seems I have to explicitly dexstuff_defineclass() those other classes, before mine, or defining it will fail.