Hello everyone,
This is my first post, but I have been lurking in the shadows. Thank you for everything you guys have done for the Android community.
I am running CM 4.2.1, and after loading some silly SPL from some guide, messed things up, wiped and reflashed. Having done that I installed only a few programs. SAM (SlideMe Application Manager) gives me the following warning.
"WeatherFirst App warning!"
If you have installed WeatherFirst application, there has been a security warning issued. Recommended to remove
The notification remains there all the time. From the limited info available I have concluded it is a botnet, or some variation used for this website: "wunderground.com," which is where I get my weather on my PC and accessed once on Android. The information I found, and the first result on Google is the following:
hxxp://mobilecomputingauthority.com/?p=111 (sorry I cannot post links, so you'll have to copy/paste and change the x's)
I would like to know how to remove it.
Any help is appreciated.
Funkz
WeatherFirst clarification
Hi Funkz. As the author of your referenced blog post at MobileComputingAuthority,I thought I might chime in and help to clarify the post, this app, and ease your fears a bit; at least as far as I understand it.
In the post I said that the WeatherFirst app was a proof-of-concept application demonstrating how users might be tricked into downloading and installing an application that might be malicious. The app uses the GPS receiver to get your current location, then transmits that information to a server. The server then converts the coordinates into a zip code and submits the weather request to wunderground on your behalf. This interaction is itself harmless, but demonstrates that there is an opportunity to do something malicious on the server or to transmit data (GPS coordinates in this example) without your knowledge or consent. I'm unclear about whether the use of the GPS was disclosed or not.
So the gist of this is that the WeatherFirst application is not a malicious application (ie botnet client). The researchers that made it, DID make a malicious version, but that version was never released to the public according to their statements and I don't have any reason to question that.
Hope that helps clarify things and thanks for reading MCA!
Bill
General information on Xposed has been moved to this thread: http://forum.xda-developers.com/xposed/xposed-installer-versions-changelog-t2714053
The FAQ has been moved to this thread: http://forum.xda-developers.com/xposed/-t2735540
Questions, suggestions, bug reports and so on can be posted in the Xposed General forum (for the installer/framework/development only) and in the Xposed Framework modules forum (for anything module-related).
Sounds interesting.I hope that you make a apk that simplifies things for simple user like rom control in AOKP
Keep up the good work my friend
That's great, decompiling/compiling apks is not really my cup of tea lol thanks rovo89
May be useful for my themes, keep working on it
Very interesting... Will try soon.
This looks like a really great idea and could help reduce the need for dev's being pestered by users for mod's every time a new rom is leaked/released, well done sir, hope to see this take off
I will definitely have a swing at this over the next few days. This looks like fun!
**This message will self-destruct**
Thanks for the "thanks" everyone. I decided to create an installer first before looking into the other things. This way, I hope a few people can test whether it works on their device (see first post for the APK).
Some notes about this:
The installer holds the app_process executable and the XposedBridge.jar as assets and can install it to the correct locations (root permissions required!).
It will automatically create a backup of /system/bin/app_process at /system/bin/app_process.orig, which can be restored either via the app or via shell (e.g. adb, works in recovery as well).
I have only tested it on ICS (LPQ Stock). Honestly, I do not have the time to test it with anything below that. If somebody wants to do this, I can help you to get started with the code. app_process was not changed very often, so chances are rather good that it will work with only few changes.
The installer requires SDK15 (4.0.3) for the same reason.
Improvements for any part of the code are welcome! It should be easy to use for both users and developers.
(Un-)Installing the installer app alone does not change anything (at least not now). Please use the buttons inside the app.
The next step should now really be to load modules dynamically, I hope I can use standard installable APKs for that (although the framework will probably request enabling confirmation for technical and security reasons).
siberian tiger said:
I hope that you make a apk that simplifies things for simple user like rom control in AOKP
Click to expand...
Click to collapse
From what I read, Rom Control seems to be something like the Settings app for ROM-specific stuff? I am not so sure yet whether I want to implement generic settings in the framework.
Having a standard interface for setting loading/saving (like or using Android's Shared Preferences) would probably make sense. But the settings themself can be very different from module to module, so I would rather let those bring their own settings menus.
What I did though was to implement an installer. My idea how it should ideally work for end users:
Install the Xposed Installer
Click the "Install/Update" button in the installer
Install one or more modules
Configure the modules (if necessary)
Have fun!
Where "install" would mean that you can download the app from the Play Store or a website and install it with the usual package manager. At least for steps 1 and 2, this is working already. For the others, I have to see.
Dynamic module loading is implemented now as well. Modules are normal apps with a special metadata tag and an asset describing which classes to load. You can look at my modifications for examples how this works. I think it is quite simple to develop and use.
I feel that Xposed is quite stable right now. It should be very easy to install both the framework and the modules without any knowledge about modding.
Also for developers, creating a new module is not too complicated. If anyone wants to give it a try, I'm happy to help you getting started. I'm convinced that Xposed is great alternative to APK modifying, but it will not work without developers creating modules for it.
Speaking of modules, I have published one for the famous CRT off effect: http://forum.xda-developers.com/showthread.php?t=1583963
The source code is also available at Github. See how it has less than 40 lines (and only about 10 LOC)? I think that this is awesome!
I was not able to install it as normal app hence pushed them to system/app using root explorer.
It works perfectly on XXLPS SENSATION ROM ICS V 3.2
Sent from my GT-I9100 using Tapatalk
OK you got me interested
What is currently holding me back is a lack of "documentation" about how to go about doing things...
Is there any reference info (even source code comments) that I should have a read of?
Or perhaps a little worked-through guide as to how you made the screen-off or red-clock one, complete with the "thinking" behind it all, just to learn the thought process.
This seems potentially hugely useful for me, just need to know what it can do!
Diliban said:
I was not able to install it as normal app hence pushed them to system/app using root explorer.
Click to expand...
Click to collapse
Really? Oh. Did you get any error message? I assume you have allowed installation of non-market apps?
@pulser_g2: Feedback taken! Until now, I focused on bringing Xposed to a level where it is actually doing something useful for end-users.
As there are some steps that can not be documented easily in the source code (e.g. how you mark an app as Xposed module), I will recreate a tutorial how you can create the clock example. I will try to give many details not only what to do, but also how you can know that you need to do this.
TUTORIAL - How to create an Xposed module
The tutorial has been moved to https://github.com/rovo89/XposedBridge/wiki/Development-tutorial
this is one of the most amazing projects made lately.
You are unleashed the best way to handle mods and possible some hacks.
very great work, robo89
Great concepts mate. Very powerful.
Wouldnt this also expose a device to malicious coders?
If a device has this implemented then is it possible that a simple theme could contain something nasty.
Not trying to stop progress of this project just throwing this out there for consideration.
----------------------
GTI9100 KK5
aceofclubs said:
Wouldnt this also expose a device to malicious coders?
If a device has this implemented then is it possible that a simple theme could contain something nasty.
Not trying to stop progress of this project just throwing this out there for consideration.
Click to expand...
Click to collapse
This is an absolutely valid thought.
In a way: Yes, it is easier to do something malicious with this. With great power comes great risk. The thing is: How would you prevent that? I couldn't think of any way once a module has been loaded, because a) how do you identify something malicious and b) how can you block it when it could just circumvent the security measure taken?
So what I did was to require that you enable a newly installed module in the installer. This at least avoids that you install any normal app and it contains a hidden Xposed module.
And not trying to play this question down, but you could insert malicous code in a theme also when you post a new framework.jar or SystemUI.apk. You could just change the smali code, compile it and you have similar power. For example, modifiying the constructor of the Activity class would also get you into any app and you could as well do whatever you want. You wouldn't even find these modifications because of the hundreds of classes in the Android framework. In this point, Xposed modules are easier to check, because they will usually contain just one class with very few and short methods.
Or take Superuser. Yes, it is asking you every time whether you want to execute this command. But the command can as well be a script that could replace files as the root user. Same for the kernel. In any case, when you modify anything in your phone, there is a risk that it is malicous.
As I said, I'm not denying that there could be a misuse of this project. But I do not see a chance to prevent it without blocking even simple real-life modifications. If anybody has ideas, please let me know.
rovo89 said:
This is an absolutely valid thought.
In a way: Yes, it is easier to do something malicious with this. With great power comes great risk. The thing is: How would you prevent that? I couldn't think of any way once a module has been loaded, because a) how do you identify something malicious and b) how can you block it when it could just circumvent the security measure taken?
So what I did was to require that you enable a newly installed module in the installer. This at least avoids that you install any normal app and it contains a hidden Xposed module.
And not trying to play this question down, but you could insert malicous code in a theme also when you post a new framework.jar or SystemUI.apk. You could just change the smali code, compile it and you have similar power. For example, modifiying the constructor of the Activity class would also get you into any app and you could as well do whatever you want. You wouldn't even find these modifications because of the hundreds of classes in the Android framework. In this point, Xposed modules are easier to check, because they will usually contain just one class with very few and short methods.
Or take Superuser. Yes, it is asking you every time whether you want to execute this command. But the command can as well be a script that could replace files as the root user. Same for the kernel. In any case, when you modify anything in your phone, there is a risk that it is malicous.
As I said, I'm not denying that there could be a misuse of this project. But I do not see a chance to prevent it without blocking even simple real-life modifications. If anybody has ideas, please let me know.
Click to expand...
Click to collapse
It is so refreshing to see someone take such a mature approach as this.
I greatly appreciate your time on that tutorial, and I will take a proper read through it while working it out myself later... (on vacation right now, this seems like a good thing to try if it rains )
Regarding security, I guess you could add a way to protect WHAT was being edited... Such that your package needed to declare edit access to package X and Y, and if it doesn't have permission, it can't do it... This way, if I want to interfere in Gmail, the user must agree, and he/she will say "well... Why is my no battery sound tweak touching gmail?" But this obviously doesn't help for frameworks and services where they are all in the one file... :/
pulser_g2 said:
Regarding security, I guess you could add a way to protect WHAT was being edited... Such that your package needed to declare edit access to package X and Y, and if it doesn't have permission, it can't do it... This way, if I want to interfere in Gmail, the user must agree, and he/she will say "well... Why is my no battery sound tweak touching gmail?" But this obviously doesn't help for frameworks and services where they are all in the one file... :/
Click to expand...
Click to collapse
Maybe.. I could rather easily implement something in hookMethod that checks the method to be hooked against a whitelist defined in an asset in the module (which could of course contain wildcards). Then when you enable a module, I could display this whitelist, with a warning if it includes some very central classes/packages/methods (but how to create such a list?).
However, this cannot control the following:
What you do inside the handling method. If you change anything in SystemUI (and that might be only the battery icon or the clock color), this method will be executed in the context of the SystemUI, which has a large set of Android standard permissions.
Calling any methods of the framework and modifying any available variables, as this can be done via standard reflection.
Basically anything that is not handled through XposedBridge, but using standard techniques.
Wanted to install the framework, but i am getting:
sh: /data/data/de.robv.android.xposed.installer/cache/install.sh: no such file or directory
What am i doing wrong ?
Hi,
Write file access on Windows Phone 8 is very restricted. In fact 3rd party apps can only write pictures to the public picture folders. Other types, such as music, documents, or video folders cannot be accessed.
Are there hidden API calls available for accessing these folders (I am aware that applications using these APIs will probably fail Marketplace submission)?
Greetings,
Yes, there are but you need special permission from MS to use them.
Do you have more details about these API calls?
No...not really. I know there are APIs for everything we can't do as ordinary devs, but MS only releases these to certain groups (typically recognized development studios).
These include:
Native compiled APIs, to use with C++/C#
Appointment API (other than live calendar)
Bluetooth APIs
and some others.
thanks, this really explain a LOT of things.
Do you have an idea how to get access to these APIs? I already tried it with the MS developer support but they say that they don't know
I don't know exactly. But you can't get them through the usual ways. Maybe if you send them a physical letter asking xD?
There are native APIs accessible to regular users. You can read all Calendars since WP7.5 and starting with WP8 you at least can create a new Appointment in a Calendar but only through a Task so the user has the ability to edit it and he must confirm it. Bluetooth-APIs are also open in WP8 although not everything can be done through them.
There might be additional APIs you can gain access too if you work with Microsoft directly. I would suggest you contact one of the Microsoft Dev Champs near you (there is a "Find my Champ" App in the Marketplace) and get into contact with him.
But unless your App gains special permissions through Microsoft even though you might know about those APIs your App would not be able to use them.
And then they cry that Google won't give them the API for a youtube app....the irony
The problem with YouTube is more that there are APIs but that YouTubes Terms of Service prohibit using those APIs for competitors in the search engine space. So Microsoft is specifically prohibited because they own Bing. I hope you can understand the difference but I have a feeling you won't.
Thanks for all your comments. Please don't abuse this thread with company bashing because the situation is often more difficult than it seems. Thanks :good:.
I think wp8.5 may see some more APIs open up. Wp8 is rushed and many existing APIs on win8 simply does not exist on wp8.
Ms is taking a more cautionary approach for APIs as they don't want junior devs mess up the phones user experience like they did with Android.
Sent from my RM-820_nam_canada_246 using Board Express
let me start off by saying that the xposed framework is absolutely awesome but if you've noticed recently just the amount of modules have just gotten a bit unruly I suggest adding some sort of tag system to help organize all the modules
for example some the tags could be device specific modules, type of module, android version etc.
ie. I would disable any tags with sense or touchwiz because I do not on that device and those modules wouldn't work on my device
This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.
rovo89 said:
This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.
Click to expand...
Click to collapse
For the Xposed modules index thread, I'm using 9 categories to separate modules by their function, and additional tags for modules that are specific to an Android version or vendor.
If you find that that makes sense and if you'd like to use it, I can share a CSV file (which is easily usable with Python, which is why I picked it) that should have the necessary info to easily add it to your server's data "automatically" (by writing a hopefully short script) (fields include, among others: tags and package name for each module).
I realize this needs discussion and will take a good amount of time and effort, but I'm just offering the index right now should you want to take a look at it. Also, if you think I/the community can make your life easier by categorizing modules with additional tags, I'm sure many will step up to help.
That is so kind of you! Thats awesome
I will also say that I wasn't very clear. (What it became is way awesome)
I meant only like an automatic way to get ones that won't work with my device to be hidden
My scenario for this was I have an aosp gpe tablet. And when I'm brousing modules I don't want to scroll past 6 experia mods that don't apply to me.
Hello all,
I hope this is the right medium for this message. I am writing to inform all of you about my use of the Xposed framework in my security research on Android.
I'll start off with the abstract of the published paper and then talk a bit about the internals of the system.
Mobile Malware Exposed
The 11th ACS/IEEE International Conference on Computer Systems and Applications (AICCSA'2014)
In this paper, we propose a new method to detect malicious activities on mobile devices by examining an application’s runtime behavior. To this end, we use the Xposed framework to build a monitoring module that integrates with an intrusion detection system to generate behavior profiles for applications, which our IDS can then analyze and report on. We then use this tool to detect malicious behavior patterns using both a custom-written malware and a real one. We also detect behavior patterns for some popular applications from the Google Play Store to expose their functionality. The results show that standard techniques that are used to evade static analysis techniques are not effective against our monitoring approach. This approach can be generalized to detect unknown malware or expose exact application behavior to the user.
This was written several months ago and so is somewhat dated by now(in the smartphone timeline) but the bureaucracy of the academic world forced me to wait before i can share this. When I was writing this, there was no mention of using Xposed in such work before.
The gist of the research was using an Xposed module to generate a behavioral profile and use behavioral analysis to try and find malware on Android. A lot of behavioral analysis before used to involve modifications to the system or the applications but with Xposed, I was able to make applications "talk" to my monitoring system without any apparent modifications to the underlying source code. The behaviral profile is a direct indication of functionality in the application thus avoiding the pitfalls of static analysis in terms of encrypted, hidden and/or mutating code.
I don't want to make this post too long but I'm happy to answer any questions if anyone is interested. I also wanted to thank rovio and contributors for the work done on Xposed. I've had the pleasure of having to go through the source code of Xposed to better understand its internals and I have to say that I enjoyed reading it.