Hi folks,
I'm trying to extract execution path information using Xposed. All I need is to record the invocation of methods in logCat. I found this Xposed-Method-Finder module (github.com/MohammadAG/Xposed-Method-Finder) on repository that can inspect all the methods in a package. However, it needs the name of classes in the package as an input (private static final String[] CLASSES_TO_HOOK). Is there any way to automatically generate the list of classes inside a package instead of provide it manually? Or, is there any other way to inspect and hook all the methods in a package without providing the exact names?
I appreciate your helps
How to get access to resources in own res/strings.xml file (witch contain my xposed project)?
My xposed project does not have any activity. If I try to get string from res/strings.xml
Code:
hookedctivity.getString(R.string.my_id)
I got value from hooked module not mine.
How I can get value from res/string.xml in my project?
Use Context.createPackageContext
I need to learn how to compile and run a simple C source file on this platform. I have downloaded different NDKs and I have a copy of the build environment for this platform. What I do not know is as follows:
- Is there a specific folder I need to use in the build environment to put my file in? ( My knowledge of the AOSP and Samsung source build environment is limited, and I do not have a good understanding of what gets compiled at which stage and where does it end up on the final image )
- Is there a validated procedure for building a simple C file, and what is it? All the way from editing the file to where to place it on the phone. I have compiled a simple file, and put it in the /sdcard but I can not run it. Even after I go su, and change the permissions of the file to 775.
I am facing issues in compiling systemui.apk and systemUI.odex files. I was porting Pixel Navigation bar for AOSP ROM of @Santhosh M. There is any to combine both the files?
If i remember right i made the Pixel navbar for Santhosh M ROM. Doesn't it work anymore? If you don't like the home button just decompile the apk and go to drawable-xxhdpi-v4 and change the ic_sysbar_home icon.
Anyway in order to combine them
1. Download baksmali. Make new folder and put the baksmali.jar and SystemUI.odex there.
2. Open command prompt in the folder where baksmali is located. Type in command prompt "adb pull /system/framework/arm" to extract the required files from the phone.
3. Type "java -jar baksmali.jar deodex SystemUI.odex -l" in the command prompt and if it successful there should be an output folder called "out". Copy it and paste it to the decompiled SystemUI.apk then rename it "smali"
4. Get the required odex files from Pixel's SystemUI(tho' i would recommend you to get them from the already modified systemUI as it usually generates the same number IDs so you wont have to deal with odex file changes).
5. Paste them to smali/com/google/android/systemui(if i remember right you had to create google/android/systemui folders so no worries if they are missing)
6.Recompile
I'd advise you to use this tutorial as it is way more detailed.
Sashko98 said:
If i remember right i made the Pixel navbar for Santhosh M ROM. Doesn't it work anymore? If you don't like the home button just decompile the apk and go to drawable-xxhdpi-v4 and change the ic_sysbar_home icon.
Anyway in order to combine them
1. Download baksmali. Make new folder and put the baksmali.jar and SystemUI.odex there.
2. Open command prompt in the folder where baksmali is located. Type in command prompt "adb pull /system/framework/arm" to extract the required files from the phone.
3. Type "java -jar baksmali.jar deodex SystemUI.odex -l" in the command prompt and if it successful there should be an output folder called "out". Copy it and paste it to the decompiled SystemUI.apk then rename it "smali"
4. Get the required odex files from Pixel's SystemUI(tho' i would recommend you to get them from the already modified systemUI as it usually generates the same number IDs so you wont have to deal with odex file changes).
5. Paste them to smali/com/google/android/systemui(if i remember right you had to create google/android/systemui folders so no worries if they are missing)
6.Recompile
I'd advise you to use this tutorial as it is way more detailed.
Click to expand...
Click to collapse
Thanks! I will be trying this out today. You developed Pixel Nav bars and the thing is you made it for January build. This is April so I have seen that it doesn't works. We need to decompile the systemui.apk again and again Change the ID and other things.
I have ported pixel Navbars for LineageOS. It was easy and today, I stuck in this steps.
I just followed your tutorial and I got this error
C:\Users\Xaif\Desktop\Baksmali\framework>java -jar baksmali.jar deodex SystemUI.
odex -x
usage: java -jar baksmali.jar [options] <dex-file>
disassembles and/or dumps a dex file
-?,--help prints the help message then exits.
Specify twice for debug options
-a,--api-level <API_LEVEL> The numeric api-level of the file
being disassembled. If not
specified, it defaults to 15 (ICS).
-b,--no-debug-info don't write out debug info (.local,
.param, .line, etc.)
-c,--bootclasspath <BOOTCLASSPATH> A colon-separated list of
bootclasspath jar/oat files to use
for analysis. Add an initial colon
to specify that the jars/oats should
be appended to the default
bootclasspath instead of replacing
it
-d,--bootclasspath-dir <DIR> the base folder to look for the
bootclasspath files in. Defaults to
the current directory
-e,--dex-file <DEX_FILE> looks for dex file named DEX_FILE,
defaults to classes.dex
-f,--code-offsets add comments to the disassembly
containing the code offset for each
address
-i,--resource-id-files <FILES> the resource ID files to use, for
analysis. A colon-separated list of
prefix=file pairs. For example
R=res/values/public.xml:android.R=$A
NDROID_HOME/platforms/android-19/dat
a/res/values/public.xml
-j,--jobs <NUM_THREADS> The number of threads to use.
Defaults to the number of cores
available, up to a maximum of 6
-k,--check-package-private-access When deodexing, use the
package-private access check when
calculating vtable indexes. It
should only be needed for 4.2.0
odexes. The functionality was
reverted for 4.2.1.
-l,--use-locals output the .locals directive with
the number of non-parameter
registers, rather than the .register
directive with the total number of
register
-m,--no-accessor-comments don't output helper comments for
synthetic accessors
-n,--normalize-virtual-methods Normalize virtual method references
to the reference the base method.
-o,--output <DIR> the directory where the disassembled
files will be placed. The default is
out
-p,--no-parameter-registers use the v<n> syntax instead of the
p<n> syntax for registers mapped to
method parameters
-r,--register-info <REGISTER_INFO_TYPES> print the specificed type(s) of
register information for each
instruction. "ARGS,DEST" is the
default if no types are specified.
Valid values are:
ALL: all pre- and post-instruction
registers.
ALLPRE: all pre-instruction
registers
ALLPOST: all post-instruction
registers
ARGS: any pre-instruction registers
used as arguments to the instruction
DEST: the post-instruction
destination register, if any
MERGE: Any pre-instruction register
has been merged from more than 1
different post-instruction register
from its predecessors
FULLMERGE: For each register that
would be printed by MERGE, also show
the incoming register types that
were merged
-s,--sequential-labels create label names using a
sequential numbering scheme per
label type, rather than using the
bytecode addressQA
-t,--implicit-references Use implicit (type-less) method and
field references
-v,--version prints the version then exits
-X,--experimental enable experimental opcodes to be
disassembled, even if they aren't
necessarily supported in the Android
runtime yet
-x,--deodex deodex the given odex file. This
option is ignored if the input file
is not an odex file
Click to expand...
Click to collapse
I also tried doing like the above given command so I followed this steps:
C:\Users\Xaif\Desktop\Baksmali\framework>java -jar baksmali.jar --deodex SystemU
I.odex -l
Error occurred while loading boot class path files. Aborting.
org.jf.util.ExceptionWithContext: Cannot locate boot class path file /system/fra
mework/core.jar
at org.jf.dexlib2.analysis.ClassPath.loadClassPathEntry(ClassPath.java:2
96)
at org.jf.dexlib2.analysis.ClassPath.fromClassPath(ClassPath.java:207)
at org.jf.baksmali.baksmali.disassembleDexFile(baksmali.java:67)
at org.jf.baksmali.main.main(main.java:305)
C:\Users\Xaif\Desktop\Baksmali\framework>
Click to expand...
Click to collapse
I have used ApkTool for Android to deodex that file and it did it successfully. Now, I am porting again
After joaomgcd placed the code on github. I was not able to compile a working version however after some very basic pbw file hacking. I was able to make a version that works with the PTR. I had to open the file with 7zip and make new directories aplite and chalk. chalk might have been all that was needed and placed the contents of basalt in each directory. I also replaced the appinfo.json file with one made after trying to compile the autpoebble code from github.