Im currently working with the xposed framework on Android 8.0. How is it possible to find all the method names of an app to hook? For example, i want to hook the method that is called if i add a new contact. Would it be possible to reverse engineer the apk to insert an logcat output into all methods, that shows which method was called?
There a various methods for identifying the relevant methods.
The first and most important one is knowledge of the official Android API. All Java/Kotlin based apps at some point use the classes and methods defined i the API. And the most important fact is that because the Android API belongs to Android and not to the app it can not be obfuscated.
Second you can reverse engineer the app itself using tools like Jadx, apktool, Ghidra, JEB... Just make sure that the tool you use does not rename the class names (e.g. to avoid name collisions or make obfuscated class and method names better readable) or at least allows you always show you the original class and method name. Because trying to hook a method by it's name will fail if you use a name generated by the APK reversing tool.
Also a very helpful tool that allows to identify a lot o the internal on a running program is frida-trace. As long the the executed app has no anti-debugging or anti-frida measures in place you can attach frida-trace at any time to an app on a rooted device and create execution traces you can later use to hook the methods using xposed or directly using frida.
Related
I would like to determine which third-party SDKs (like Mixpanel, Google Analytics, Facebook SDKs) are being used in an app, if any. Is there a way to find this out?
Assume for the purposes of this question that I am not the developer of the app, and therefore I don't have access to the source code.
You can use a service like Appbrain to find that out. It's free for the first few lookups.
It's not possible to reliably enumerate the libraries used by an application, for a few reasons.
The main reason is obfuscation: If a user turns on Proguard or R8, they will rename the library's classes, potentially in such a way as to make them unrecognizable.
Another reason is that there's simply not a comprehensive list of every Android library in existence, or a mapping of class names to libraries.
However, if you did want to try to do this, you'd want to retrieve the application's class files and then hunt through them for the start of package names from libraries you care about (as obfuscators are less likely to rename the entirety package names, though they still might). For example, if you wanted to see if an application uses okhttp3, you'd look to see if there are is an okhttp/okhttp3 folder (for the package okhttp.okhttp3).
You could maybe even automate this by finding a list of popular Maven/Gradle packages, downloading them, extracting the class names, and using that as your dataset.
I want to do a static analysis of an Android app with Androguard. Particularly, I am interested to identify whether a particular library method is called. However, as the method call could be in a part of the code that is never reached, would the static analysis with Androguard account for that? If not, is there a different tool that I can use? (On a side note, as I need to do a large-scale analysis of many apps, the tool should be automatable, which I understand is the case for Androguard.)
You can use JArchitect and create your custom CQLinq queries to query the codebase and check if a method is callable or not, many other possibilities are provided by CQLinq to create advanced queries.
Unit testing android application is often more difficult than expected because there are classes that do not have a public constructor (like NotificationManager) and classes that have methods that is not possible to override like Context.getText.
For NotificationManager I used a delegator. I would do the same for the context but that means that in all the classes that use the context (many) I need to use my own context that can't even be derived from Context. Then whenever I need to pass the context to an Android API I need to get the real context from within my wrapper.
Is this correct? Is there another way to do it? What is the rationale of having those methods declared as final?
Is there someone that has really written unit tests for big applications for Android?
EDIT
I found the reason why the getText method is defined as final: it's a template method. So it is enough to override the called non final methods
I also found this that works but it is a bit weird
Question is a little bit vague so I am going to write a long answer.
there are classes that do not have a public constructor (like NotificationManager)
Because there are some system-wide resources/components (for instance NotificationManager) which Android doesn't like application to construct/instantiate on demand, instead, these resources are centralized and managed by system and application should always use system provided API to acquire them.
and classes that have methods that is not possible to override like Context.getText
Generally in Java, method marked as final means they are protected by API and API developer doesn't want the default behaviour to be overridden by application developer. In particular for this method Context.getText(), it actually use Template method pattern, check out herschel's comment below and the source code for more details.
Then the question is how do we properly test our code written by using these android context based resources/components?
The answer given by Android SDK is Test Project (via InstrumentationTestRunner). Generally, when using InstrumentationTestRunner, behind the sense, system will install both test.apk (build from Test Project) and app.apk (build from Application Project), and use test.apk manipulate app.apk for testing. This is happened Regardless of whether you use AndroidTestCase API (referred as JUnit in diagram below) or InstrumentationTestCase API (referred as Instrumentation in diagram below) The corresponding testable android context based resoures/components (i.e. Activity, NotificationManager or TextView) are all acquired from the real running app.apk instance. In case you create/use your own MockContext in Test Project, you can see from the diagram that mock object is injected into the running application by InstrumentationTestRunner.
The drawback of using instrumentation test is about efficiency, it goes into the complete running life cycle (start emulator -> install and start both test.apk and app.apk and fire InstrumentationTestRunner) even though you just need test a single method from a single class (as you mentioned in comment). I agree with Ollie, it is a hostile design.
This is where Robolectric come in and play, quouting from their website: Robolectric is a unit test framework that de-fangs the Android SDK jar so you can test-drive the development of your Android app. Tests run inside the JVM on your workstation in seconds.
From my own experience, I have an application consists of around 10 activities and several Service with some other custom views/widgets doing mainly http communication with remote server, and use both instrumentation test (via Test Project) and Robolectic testing Android Context based code. I can pretty much test almost every single class/public method of my application as long as time is allowed.
Android is pretty hostile to testing in many respects.
You might want to take a look at Roboelectric
http://pivotal.github.com/robolectric/
I assume you've read these:
http://developer.android.com/guide/topics/testing/index.html
http://developer.android.com/resources/tutorials/testing/helloandroid_test.html
The *TestCase classes that Android provides for you should be able to solve the testing issues you are encountering. In most of these instances it will spawn a context for you that you can override if you wish. I would suggest starting there, or asking more specific questions about how you would test one thing or another.
Ultimately I wish to produce a compressive Contact Manager with some specific features.
I thought it would be good to experiment by extending Contact.
So using git I checked out froyo-release and tried to build it.
That didn't work so well as it contains things like
import
com.android.internal.telephony.CallerInfo;
and friends.
I'm considering the following two approaches:
Suppress the internal stuff under
the assumption that I really don't
need it.
Start with a toy Contact Manager
and implement (reinvent) everything.
My guess is that I am going about this incorrectly.
"I want that third alternative" --kirk.
Just for completeness, the new special behavior is to provide
an action list for a contact based on the types of that entities data.
A lot of the applications that ship with the platform unfortunately make use of non-public api's, which means they require a lot of hacking to build as sdk apps.
You can build them as part of a full platform build, or you can modify them to connect to the private api's via reflection or by including stubs for the private api functions that will get automatically stripped out later (as their names conflict with the real ones) - but if you want the result of your work to be something you can portably and reliably distribute other than as part of a rom upgrade, you probably need to rework things to use only public APIs.
If I needed to build an android SDK that other developers can integrate into their android apps, is jarring my SDK the only way to go about it? As far as I have learnt, jarring has the following considerations:
If your app uses a layout, then you have to create it programmatically. Since jar files cant carry any resources.
The jar will needs to be placed in the lib/assets folder and added to the build path (in Eclipse) -- Learnt here: Android - Invoke activity from within jar
The main app will have to create an Intent object and specify the package and class name in the jar to start the activity.
Any one have other ideas of going about any of the above steps?
Thanks
George
Creating a JAR is, in my opinion, a very bad decision. Android has specific features just for the kind of thing you're looking for. If your JAR:
provides some sort of (structured) data to be used in other applications, use a ContentProvider;
does some backround processing and makes that processing's results available to other applications, use a Service;
provides an Activity that gets some input from the user (or shows some information about something), eventually processes it and returns it to the calling Activity, just create that Activity and any application will be able to start your Activity as long as it's installed on the phone.
If you use one of the three solutions above, third party apps will be able to probe for whether your application is installed and, if not, prompt the user to install it. Only if your application does not fall into one of the three bullet points mentioned above should you use a JAR. Otherwise, using a ContentProvider, Service or Activity provides:
More standardized interaction between components
Better maintainability -- if you update your SDK you won't have to call everyone who uses it and tell them to upgrade.
No duplication -- if you were to provide a JAR and multiple applications that use it would be installed on a device, multiple copies of the JAR would be present on that device, thus using more memory than it has to. If you provide one of the three components mentioned above, one copy will satisfy all applications that need to use it.
Again, these components are specifically designed and provided by the Android OS for creating such SDKs. Please, only use a JAR if you really, really have to. Otherwise, provide a standardized ContentProvider, Service or Activity and document the way it's supposed to be used (i.e. how to use/query/integrate it).