Related
Hi all,
I'm working on reserve engineering libcamera for Tattoo, based on libcamera2 by NCommander. Thanks to nopy for many help.
HTC have changed a lot in their kernel, and left LOTS of useless or temporary codes not to be cleaned up. Right now, camera codes in the kernel are very clean and tidy and mainly ported from AOSP-donut kernel. Interfaces of /dev/msm_camera/control0, config0, and frame0 are successfully generated. As you know, HTC kernel implemented the /dev/msm_camera/msm_camera0 interface to communicate with requests from user space. I'm not sure why HTC did such a hack. The reason why I ported camera codes from AOSP-donut relies on the fact that most of camera working ROMs for other headsets like Dream or Sapphire did this, even if these ROMs are powered by 2.6.32 or even 2.6.34 kernels.
I've sticked to HTC camera driver in the kernel. Please check out my github.
Here is the explanation of the relationship between libcamera, libqcamera and the kernel, written by NCommander.
This is my first step to reserver engineering work on libcamera. Camera does NOT work yet.
The current logcat and klogtail have been attached here, Donut version as well. Thanks to MrGland, salva.tejero, and kicmi.
If anyone is interested in hacking for Tattoo, just let know. I'll invite you to cooperate with us.
Regards,
do you want try my kernel?
it have a problem with wifi...but the camera and media driver are correctly loaded...
if u want i can send it via pm
i have fix the GL problem on my rom...i haven't a tatto...but if u want i can see again the problem with your rom.
i'm just thinkg to restart my rom from zero. I have already downloaded the froyo source and i'm starting to compile the source and add my personal kernel...
said me if u want collaborate to made a new 2.2 rom
W/dalvikvm( 613): threadid=10: thread exiting with uncaught exception (group=0x400207d8)
I am by no means a c++ expert, but I started learning it last week. A uncaught exception needs catching so that the whole thread does not terminate, you can deal with them using catch(), unless it is a hardware exception
I think you two have the best chance of making a working froyo rom if you work together based on using your roms. I use fyodors 1.6 rom daily
I believe this too.
I prefer fyodor's rom though cause with his roms I never had problems on booting. Ikxdf' s roms from the other side don't boot on my device(except abusu 2.01 and capcake 1.01)
you two (ikxdf,cn.fyodor) are supermans make a team mix up your files and your skills, make a great panfyodorcake ROM and we, tattoo users will be so happy Good Luck
E: omg sry kiljacken and HCDR.Jacob ale supermans too
cn.fyodor said:
I've dived into the source files, and found there was a __NULL__ "config_defaults" array of structure in egl.cpp file. This array was used in eglChooseConfig function, which is heavily related with my issue. I'm not sure what the codes did since not familiar with C++ programming. I've googled a lot, but no luck.
I need C++ experts to read the opengl codes in Froyo system and find the reason why 'No configs match configSpec' error comes up. Thanks in advance.
Regards,
Click to expand...
Click to collapse
If you send me that file or gives me the path to it in the Android source code I'll gladly take a look at it...
If you send me that file or gives me the path to it in the Android source code I'll gladly take a look at it...
Click to expand...
Click to collapse
Same here...
ikxdf said:
do you want try my kernel?
it have a problem with wifi...but the camera and media driver are correctly loaded...
if u want i can send it via pm
i have fix the GL problem on my rom...i haven't a tatto...but if u want i can see again the problem with your rom.
i'm just thinkg to restart my rom from zero. I have already downloaded the froyo source and i'm starting to compile the source and add my personal kernel...
said me if u want collaborate to made a new 2.2 rom
Click to expand...
Click to collapse
Hi, ikxdf
Glad to see you in this dev thread. My kernel can drive the camera correctly, but I haven't verified it yet. Feel free to send yours to me, I'll test it to check whether it works or not.
speedyracer5 said:
W/dalvikvm( 613): threadid=10: thread exiting with uncaught exception (group=0x400207d8)
I am by no means a c++ expert, but I started learning it last week. A uncaught exception needs catching so that the whole thread does not terminate, you can deal with them using catch(), unless it is a hardware exception
Click to expand...
Click to collapse
Thanks for the info. If it's a hardware exception, there must be some bugs in my customized kernel. However, to be honest, I really don't know how to debug the C++ codes.
kiljacken said:
If you send me that file or gives me the path to it in the Android source code I'll gladly take a look at it...
Click to expand...
Click to collapse
Thanks. The top path is frameworks/base/opengl. This exception error was thrown by the ./java/android/opengl/GLSurfaceView.java and the eglChooseConfig function is defined in ./libagl/egl.cpp. Hope you find something useful to debug it.
My greetings,
are the best in the tattoo improving.
Thanks to all the people who try to improve the tattoo...
let´s go friends
cn.fyodor said:
Hi, ikxdf
Glad to see you in this dev thread. My kernel can drive the camera correctly, but I haven't verified it yet. Feel free to send yours to me, I'll test it to check whether it works or not.
Thanks for the info. If it's a hardware exception, there must be some bugs in my customized kernel. However, to be honest, I really don't know how to debug the C++ codes.
Thanks. The top path is frameworks/base/opengl. This exception error was thrown by the ./java/android/opengl/GLSurfaceView.java and the eglChooseConfig function is defined in ./libagl/egl.cpp. Hope you find something useful to debug it.
Click to expand...
Click to collapse
I've looked much at the files and i have fund that the error you get is caused when an app gives some info about a configuration and EGL can't find a config that matches that information...
Does this error happen in the camera app??
cn.fyodor said:
Hi, ikxdf
Glad to see you in this dev thread. My kernel can drive the camera correctly, but I haven't verified it yet. Feel free to send yours to me, I'll test it to check whether it works or not.
Thanks for the info. If it's a hardware exception, there must be some bugs in my customized kernel. However, to be honest, I really don't know how to debug the C++ codes.
Thanks. The top path is frameworks/base/opengl. This exception error was thrown by the ./java/android/opengl/GLSurfaceView.java and the eglChooseConfig function is defined in ./libagl/egl.cpp. Hope you find something useful to debug it.
Click to expand...
Click to collapse
The Exception has been thrown from JAVA because num_config[0] has not been populated by eglChooseConfig. This output parameter it's populated at the last line of eglChooseConfig.
I don't know the architecture of android and egl stuff, what i can reccomend to you is to use the LOGE macro to write in console the list of attibute (attrib_list parameter) and try to see in which point the function returns (using LOGE macro opportunely).
From what i can understand, this function tries to match the list of attributes passed as parameter(attrib_list) with global array of configurations (gConfigs), which contains 8 configurations (every configuration is an array of attributes).
Java makes 2 calls to eglChooseConfig, the first is to retrieve the number of configurations that matches the attribute list, if this number is >0 create an empty array and re-call eglChooseConfig to get the array itself populated, otherwise throws the exception you have showed in your log.
ivendor said:
The Exception has been thrown from JAVA because num_config[0] has not been populated by eglChooseConfig. This output parameter it's populated at the last line of eglChooseConfig.
I don't know the architecture of android and egl stuff, what i can reccomend to you is to use the LOGE macro to write in console the list of attibute (attrib_list parameter) and try to see in which point the function returns (using LOGE macro opportunely).
From what i can understand, this function tries to match the list of attributes passed as parameter(attrib_list) with global array of configurations (gConfigs), which contains 8 configurations (every configuration is an array of attributes).
Java makes 2 calls to eglChooseConfig, the first is to retrieve the number of configurations that matches the attribute list, if this number is >0 create an empty array and re-call eglChooseConfig to get the array itself populated, otherwise throws the exception you have showed in your log.
Click to expand...
Click to collapse
I think you're right...
I think it would be important for all of us, to have a rom 100 % funcional 2.1 or 2.2 without the camera, and before fix the camera...i think
If you make a team i havent doubt could be able to make it real
thanks for all
capito djjkd said:
I think it would be important for all of us, to have a rom 100 % funcional 2.1 or 2.2 without the camera, and before fix the camera...i think
If you make a team i havent doubt could be able to make it real
thanks for all
Click to expand...
Click to collapse
why?
because the devs maybe could stop developing, because they are satisfied of the working camera?
i don't think so. if they could get the camera working, there isn't a long way anymore to a 100% functional 2.1/2.2 ROM.
I hope this comes true, good luck to the devs!!!!!!
ivendor said:
The Exception has been thrown from JAVA because num_config[0] has not been populated by eglChooseConfig. This output parameter it's populated at the last line of eglChooseConfig.
I don't know the architecture of android and egl stuff, what i can reccomend to you is to use the LOGE macro to write in console the list of attibute (attrib_list parameter) and try to see in which point the function returns (using LOGE macro opportunely).
From what i can understand, this function tries to match the list of attributes passed as parameter(attrib_list) with global array of configurations (gConfigs), which contains 8 configurations (every configuration is an array of attributes).
Java makes 2 calls to eglChooseConfig, the first is to retrieve the number of configurations that matches the attribute list, if this number is >0 create an empty array and re-call eglChooseConfig to get the array itself populated, otherwise throws the exception you have showed in your log.
Click to expand...
Click to collapse
I commented out the setEGLConfigChooser() stmt. in Camera/src/*/ui/GLRootView.java source file to use the GLES default config for camera. Although the 'no config match...' exception didn't come up, camera didn't snapshot any images as if the sensor didn't open. Check out the attachment below.
If the setEGLConfigChooser stmt. was added, in eglChooseConfig function, both possibleMatch and num_config will be 0. I'm trying to find the low-level reason.
The setEGLConfigChooser() in Camera/src/*/ui/GLRootView.java source file is defined:
public void
setEGLConfigChooser (int redSize,
int greenSize, int blueSize, int alphaSize, int depthSize, int stencilSize).
All we want (i think) is the correct values for the parameters. Ok at page
http://brandnewreality.com/blog/android-egl-querying-your-gl-driver
there is a java program to query from a donut tattoo the configs....
Now we can correct the parameters at setEGLConfigChooser function.
I hope that this helps us...
seg
segway_ said:
The setEGLConfigChooser() in Camera/src/*/ui/GLRootView.java source file is defined:
public void
setEGLConfigChooser (int redSize,
int greenSize, int blueSize, int alphaSize, int depthSize, int stencilSize).
All we want (i think) is the correct values for the parameters. Ok at page
http://brandnewreality.com/blog/android-egl-querying-your-gl-driver
there is a java program to query from a donut tattoo the configs....
Now we can correct the parameters at setEGLConfigChooser function.
I hope that this helps us...
seg
Click to expand...
Click to collapse
Wont this method you are proposing hard coding the values?Shouldnt these be set by the user?There must be another class with the default values and which saves the user defined values.
Look at the code:
http://android.git.kernel.org/?p=pl...0f823229da7569a51367f20c0c9d048d1cba;hb=froyo
175 private void initialize() {
176 mFlags |= FLAG_INITIALIZED;
177 setEGLConfigChooser(8, 8, 8, 8, 0, 4);
178 getHolder().setFormat(PixelFormat.TRANSLUCENT);
179 setZOrderOnTop(true);
Click to expand...
Click to collapse
Is it hard coded?
seg
Well the values are hard coded.. but at the look of it I guess the hardware need these hard coded values to initialise. Good point seg.
Hi fellas,
i must admit that i'm really impressed by the energy that has been put into the BOINC project, to hunt for the Motorola private certs to crack the RSA key inside OMAP3430.
From the M-shield white paper:
Code:
...
For example, secure on-chip keys (E-Fuse) are OEM-specific, one-time-programmable
keys accessible only from inside the secure environment for authentication and encryption.
...
More specific information here:
https://www.droid-developers.org/wiki/EFuse
What would happen, if we slip into the role of the OEM's?
To be more precisely what happens, if...
a) we disable VFUSE power domain (VPP rated @ 2.4V/50mA, connected to APE_VPP and DBB_VPP)?
b) we use eFuse programming algorithm in mbmloader to blow additional eFuse and enter engineering mode?
(what is the hash for engineering mode?)
c) we use read routines within mbmloader to read eFuse values?
d) we blow all remaining efuse for the 160-bit hash in the user programmable area (factory default on milestone = 1d3fb662 794d8c70 fb57b4cb 492e27f6 6f152e4f)?
(result would be a OEM value of 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)
Perhaps we'll never know...
Here's what i think:
a) Barely no effect, apart from preventing mbmloader to blow another e-fuse.
b) Maybe the whole mbmloader code could only be accessed from within security domain, not sure if a debugger would work here.
c) Same as above. There had to be a proof of concept that mbmloader routines could be executed.
d) See b) and c). We need the correct offset, of course.
Any comments welcome.
IMHO there might be a better chance to crack the security on Milestone, if the interest would be focussed on mbmloader disassembly and further investigation on JTAG access for debugging the platform more intensely.
If you're a technical geek, you might have a look over here:
http://forum.xda-developers.com/showthread.php?t=849632
Experts are very welcome!!!!
P.S.: If nothing will ever work out, there's something slightly off-topic we might think about ...
Someone should contact Mototola to follow a new marketing strategy... called: ICS (Individual Customer Support).
Customers could upload their custom kernels to Motorola and get them signed by beautiful private key!
We could also push our kernel source to Motorola and as a side effect they would fix bugs and finish firmware updates much earlier .
TBC...
EDIT: Corrected some parts...
Cheers,
scholbert
Always nice to read your posts But there is one error I think:
scholbert said:
...to crack the 128-bit RSA key inside OMAP3430...
Click to expand...
Click to collapse
I think it is a 1024Bit key or am I wrong?
TheSSJ said:
Always nice to read your posts
Click to expand...
Click to collapse
Thanks for your reply!
TheSSJ said:
But there is one error I think:
I think it is a 1024Bit key or am I wrong?
Click to expand...
Click to collapse
Not 100% sure about all this.
In fact i must admit that i'm not a cryptographic expert, but after reading all these hardware manuals and references, this is what i understand:
The hash key stored in the eFuse farm seems to be 160 Bit SHA-1 and uses 1024Bit certification.
Seems that this basically is used to verify mbmloader security.
Maybe this is bull****, so who ever got some more details please join discussion!
I really like to know at which offset the key is stored
Regards,
scholbert
So if I get this right, you want to disassemble a Milestone and mess with the circuit?
djefkbefke said:
So if I get this right, you want to disassemble a Milestone and mess with the circuit?
Click to expand...
Click to collapse
Yeah correct, first this would be hardware stuff to get JTAG to work.
It's not strictly me reaching this, in fact this addresses to a community!
See my JTAG post, there's anything you need to trace the signals
So if you got a broken device go for it!
Afterwards some cracks might use a JTAG debugger (e.g. OpenOCD) to fiddle with the bootcode: Set breakpoints, trace conditional branches, even tweak some lines of code.
The hope is that something will open another door to get access to certain memory areas, especially eFuse location would be interesting
Regards,
scholbert
There was someone on here a month or so ago that had a device without a working radio. There are probably others like him. If we manged to get someone willing to donate their non-working device, would you be willing to try your jtag on it. I don't have a jtag at this time, and although i wouldn't mind getting 'hold of one, it probably wont happen for a while.
http://forum.xda-developers.com/showthread.php?t=849632
Hey,
just stumbled over these lines in one of the Ti documents:
...
The device type is readable from an eFuse by the CONTROL.CONTROL_STATUS[10:8] DEVICETYPE
field. During booting, the ROM code checks the DEVICETYPE field to determine in which mode to
operate.
· The HS device is a production device with all security features enabled. The ROM code requires the
authentication of the Initial SW before execution. A failed authentication causes a watch-dog reset.
Authentication of code in external flash memory or code that is downloaded is handled by routines in
the secure ROM (a part of the ROM code).
· The GP device is a production device in which security is disabled. Authentication is not performed
before initial SW execution.
...
Click to expand...
Click to collapse
Just wanted to add it here for completeness
There's also some progress to understand the bootloader implementations of security functions, pushed by xvilka!
For the geeks, see here:
https://www.droid-developers.org/wiki/Security
Regards,
scholbert
additional info....
Hi,
i gathered some more information about how things work out:
- SHA1 sum of the first (root) key in the CertPK is stored in eFuse array inside SoC, accessible through PKEY 0..4 registers
- the value for the SHA1 sum has a length of 160 bits
- theoretically eFuse bits that are now zero could be blown by using Secure Service, to modify hash value
- Milestone: 1d3fb662 794d8c70 fb57b4cb 492e27f6 6f152e4f
Droid: 75ed7020 641333dd 7bc3aecb 9857683c 2422efe1
- BootRom loads root key in SecureRAM and uses Secure Service, from secure part of BootROM to verify integrity/signature
This secure part of BootRom is not accessible from non secure world.
- All main keys are stored in CertPK/SecureRAM
- In theory we could break the chain of trust with:
a) find rsa keypair where the public key's sha1sum matches the existing SHA1 sum in PKEY 0..4 registers (hash_collision)
b) modify the efuse setup with Secure Service function and alter PKEY 0..4 registers to match a given key pair (this might be a very complicated issue)
Please correct me if i'm wrong
PS: Just realized that this is my 666th post, so this is dedicated to the devil
Regards,
scholbert
The devil thanks you.
It's quite a simple one I hope. Also, apologies for adding noise to the forum, but I couldn't find any detailed documentation or many tutorials.
I'm making use of findAndHookMethod for a little test project of mine. The problem is, the method which I am hooking has custom classes in its parameters.
Obviously I don't have access to these classes in terms of having the source code imported, so my first thought was just to list the paramaters as Object.class, but this didn't work.
What (if any) are the solutions? Thanks!
P.S.
In case I worded it badly. Say I have method to be hooked...
public void methodThatDoesSomething(ThisCustomClass nameOfParameter)
How do I use findAndHookMethod when listing parameters, as ThisCustomClass.class is not within the scope of my project
Use a string with the class' full name, e.g. "com.hooked.package.ThisCustomClass".
Okay guys.
I have seen a lot of posts where people need to trigger an action inside their own app from the xposed class they hooked. Sometimes (quite often) there is no context object to obtain where we could usually send a broadcast or start a service or even maybe an activity from our own apps we wrote.
This guide will allow me to show you how this is possible without the use of a context object. I have used this myself in multiple modules and it works quite wonderfully. I am going to provide as much code as possible without being too specific, that is where you will need your own intuition to figure out some simple things.
Now for the guide
First, obviously, we need to create a new xposed module. That's another thread found here. For the duration of this guide, I am going to assume you have read that. If you have not, stop reading this, and click that link and go read that please Its fun!
Alright, our module has been created, all manifest declarations established all jars imported. Sweet.
Now we are looking at an empty class file that implements the IXPosedHookLoadPackage.
Next, we need to create a class that extends Service. You can either create a nested class inside the Xposed class, or, my personal choice, create an entirely new class inside your package. ***(Don't forget to add this service to your manifest!!!)
Next, we need to create a boot receiver that will start our newly created service when our device gets booted so its already up and running. (Google that if you don't know how to do that.) here is a great read on how to do this.
Now, go back to your service class (either nested or its own file) and create the "onCreate" method. (If not done already)
Inside the onCreate method of your service, we will need to create a file inside the apps files directory. You can do this in the constructor as well if you please. I have the code below showing how to create your new file.
Code:
@Override
public void onCreate() {
super.onCreate();
File myCommands = new File(this.getFilesDir(), "commands");
}
Yes its that
Now that we have our file object created, we need to actually create the file as follows:
Code:
if(!myCommands.exists()) { //Make sure the file doesn't already exist first.
try {
myCommands.createNewFile();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
However, there are some things we need to do to allow the xposed hooked method permissions to read them, which are simple and as follows.
Code:
myCommands.setReadable(true, false);
myCommands.setWritable(true, false);
We need to use the method "setReadable" and "setWriteable" to set the files permission. The first boolean argument sets the file writeable or readable, the second boolean argument restricts it to the owner only, which since we used false, means that everyone can read and write to this file.
So, now lets take a look at our entire onCreate method thus far:
Code:
@Override
public void onCreate() {
super.onCreate();
File myCommands = new File(this.getFilesDir(), "commands");
if(!myCommands.exists()) {
try {
myCommands.createNewFile();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
myCommands.setReadable(true, false);
myCommands.setWritable(true, false);
}
Pretty simple. Now, we need to actually do something with this file. This is where the magic begins to happen
After our file is created, we need to create what is called a FileObserver. The following code explains how to do that.
Code:
FileObserver myActionsObserver = new FileObserver(myCommands.getAbsolutePath()) {
@Override
public void onEvent(int event, String path) {
// This is where things are done. Every time you open, write to, close etc a file. This method is executed.
}
};
Now our file observer is created. However, it is doing nothing. As of now, it does not even listen for file changes. I want to further define what to do on a file change first before I start receiving the changes.
The "onEvent(int event, String path)" method is what we will be defining.
The "event" argument determines what type of event was acted upon the file. For a full explanation, click here. The "CONSTANTS" table shows the different types of events acted upon a file. For this guide, I will be using the constant "CLOSE_WRITE".
So inside the onEvent method we should have this:
Code:
@Override
public void onEvent(int event, String path) {
// This is where things are done. Every time you open, write to, close etc a file. This method is executed.
if(event == FileObserver.CLOSE_WRITE) {
//This is where we are notified that something has happened.
//This is where we can communicate from the xposed hooked method to our own app where we can do whatever we need to do :)
}
}
Now we are notified of the "CLOSE_WRITE" action onto our file. The next step would be to read the text file for our actual command. For instance, we need to start up an activity. So, for the instance of this guide, I will use the command "startActivity".
Once our "onEvent" method is executed and we see that its action was CLOSE_WRITE, we are going to read the file for the action. This is simple, I really don't feel like I should/have to go into this, but I will to make the guide full.
Here we are going to read the file, I am using a BufferedReader for this.
Code:
try {
BufferedReader br = new BufferedReader(new FileReader(myCommands));
String action = br.readLine();
br.close();
} catch(Exception e) {
e.printStackTrace();
}
Now we got a string object of the contents of the file to determine the necessary actions to take. Don't forget to change the myCommands file to final
Now that we have all that setup, we can finally start receiving actions for the file. We simply do this by calling the "startWatching" method of FileObserver as follows.
Code:
myActionsObserver.startWatching();
Now, whenever that file is written to, we will get notified of it in our service
So now that our service is setup, we need to setup our xposed hooked method to write to the file.
I am going to make something up that prolly doesn't exist in android source, but its just an example method that I am going to hook
The only thing to note when creating the file is that we need to hard code the file's path.
Code:
@Override
protected void afterHookedMethod(MethodHookParam param) {
boolean status = (Boolean)XposedHelpers.getObjectField(param.thisObject, "status");
if(status) {
File myCommand = new File(Environment.getDataDirectory() + <your package name here>, "commands");
FileWriter fw = new FileWriter(myCommands);
fw.write("startActivity");
fw.close();
}
Now we have written to our file and our service will receive the action.
That about sums it up You can also do the reverse, you can create a FileObserver inside your xposed hooked method, and use your own activity or service to write to it and then have the xposed hooked method do some actions regarding the command being written to the file.
Please hit thanks and donate if I helped you out! Don't hesitate to ask questions either!
Thanks!
need help
Hi I`m using your code and it`s work I seccessed to comunicate between the module and the FileObserver.
But my problem is that I want to activate some class or send a intent to activate some function from the FileObserver and I don`t find a way to do it.
Do you have any solution for me??
Thanks
doronmazor said:
Hi I`m using your code and it`s work I seccessed to comunicate between the module and the FileObserver.
But my problem is that I want to activate some class or send a intent to activate some function from the FileObserver and I don`t find a way to do it.
Do you have any solution for me??
Thanks
Click to expand...
Click to collapse
This method is beyond hackey. TBH, I'd be embarrassed to use it in my code.
If you want to communicate from Xposed to your main app, add a broadcast reciever and talk to it via intent and putextra. Provided you're not passing sensitive data, this works wonderfully.
digitalhigh said:
This method is beyond hackey. TBH, I'd be embarrassed to use it in my code.
If you want to communicate from Xposed to your main app, add a broadcast reciever and talk to it via intent and putextra. Provided you're not passing sensitive data, this works wonderfully.
Click to expand...
Click to collapse
lol
Why would you be embarrassed? This works perfectly when we have no context object in the class/method being hooked. If coded properly, it functions the exact same way as a broadcast receiver. Where is your solution to communicating without a context object? Not exactly sure why you think this method doesn't work...
elesbb said:
lol
Why would you be embarrassed? This works perfectly when we have no context object in the class/method being hooked. If coded properly, it functions the exact same way as a broadcast receiver. Where is your solution to communicating without a context object? Not exactly sure why you think this method doesn't work...
Click to expand...
Click to collapse
Look, not trying to be mean...it's just a very hacky solution. There are other ways to resolve the context of the class/method being hooked, and better ways to communicate between xposed and the apk code besides writing a file to the /data partition and then watching it. Sure, it works, but IMHO, it's...well...hacky.
digitalhigh said:
Look, not trying to be mean...it's just a very hacky solution. There are other ways to resolve the context of the class/method being hooked, and better ways to communicate between xposed and the apk code besides writing a file to the /data partition and then watching it. Sure, it works, but IMHO, it's...well...hacky.
Click to expand...
Click to collapse
I am not taking you as being mean. Not one bit. Just trying to expand my knowledge and better my code. You said there are other ways to resolve the context of the class/method being hooked, what are they? You said there are better ways to communicate between xposed and the apk code other than writing and listening to a file, well what are they? lol. I am asking so I can use them.
I have done ample research when I wrote this guide, and there were no other ways to communicate when you couldn't get a context object. I do know you can call other methods and such using xposed to get objects, but that in itself is also hacky. I really would like to know what other ways there are so I can use them instead of the current method. A lot of "helper" class files have issues where there is no context because its not needed. Say you have a class file labeled "MathHelper" and you want to hook the method "getFirstZero" and in that method the user wrote something simple like this:
Code:
private int firstZero(String address) {
int returnValue = address.indexOf("0");
return returnValue;
}
THIS IS JUST A POOR EXAMPLE.
You have no context object. And the class is huge. You want your app to, i don't know, show a notification and perform some task when the address is equal to some explicit value. There is no way of telling your app what the address is.
So what would you personally do to resolve this aside from simply creating a method inside the xposed class with the proper actions. I'm honestly curious.
I've been trying to hook a method for hours and I'm kind of desperate.
The scenario:
I have a browser app which allows to create shortcuts on your homescreen. The only problem is: They are not renamable. So I thought I write a little xposed module to make this possible.
Steps taken:
Create module base and make it loadable into xposed - check.
Make sure method hook is only called from inside the application - check.
Create a simple dialog with edit stuff - check.
Finding and hooking the correct method in correct class - fail.
The method I am trying to hook is "sendBroadcast(Intent)". The original method is abstract and not hookable.
My first try was to hook the method in "android.content.Context" -> abstract.
I read somewhere that you can hook a subclass so I tried "android.content.ContextWrapper". Turns out this just inherits the method from android.content.Context and is still abstract.
Same goes to "android.app.Activity". So I searched for the Implementation of the sendBroadcast function. I found it in "android.app.ContextImpl" but this also turned out to be just the abstract method call from "android.content.Context".
It can't be that hard to find the right class to hook, right?
I didn't want to use the "hookAllMethods" because it seemed a little overkill for such a small change.
This is my last hook try:
Code:
findAndHookMethod(XposedHelpers.findClass("android.app.ContextImpl", lpparam.classLoader), "sendBroadcast", Intent.class, new XC_MethodHook(){
//... stuff here which I think is correct
}
the browser calls sendBroadcast with only one argument, right?
do you get a NoSuchMethodException, or just can't find the broadcast you want in this method?
Sorry for the late answer.
The error I get is: "IllegalArgumentException: abstract methods cannot be hooked"
odd because it's not an abstract. are there more findAndHookMethod calls before this one? are you sure they work?
because the sendBroadcast hook might not have been called at all if an exception was thrown beforehand
you can test it by XposedBridge.log() right before it