Related
Hi all, I have a major concern about privacy and all the 3rd party data collectors...
A lot of apps are uploading user info and stats to companies like Flurry, pinch media etc.
I'm about to make the move from iphone OS to android, and i'm looking for a opt out to keep my privacy intact.
Saurik creaded PrivaCy for the jailbreak community that enabled on\off toggles for the 4 major companies.
My issue on iphone was that Pinch Media alone gathered the following information without my knowledge :
* iPhone’s unique ID (imei)
* iPhone model
* OS version
* Application version (in this case, camera zoom 1.x)
* If the application is cracked/pirated
* If the iPhone is jailbroken
* Time & date I start the application
* Time & date I close the application
* My current latitude & longitude
* My gender (if Facebook enabled)
* My birth month (if Facebook enabled)
* My birth year (if Facebook enabled)
I want the option to chose weither or not this kind of info gets collected and distributed.
I've looked into this issue on the android platform, and it seems like there's no option other than not to install the app.
Take for instance Locale. To my knowledge it uploads my imei nr (+lot of other info) to Flurry, whilst i do see the developers need to gather info, and I do not see why my imei number should be uploaded at all.
When I get my android phone I can only chose NOT to install locale, but I just want to prevent it from uploading such info..
Can anybody create a toggle, preferably one that doesn't aquire root, or some guide as to hosts file editing, or a firewall app that will give me this control over my device?
regards
-e
just add a line in hosts file like the following for each website you want to block:
127.0.0.1 some.company.com
Fantastic, thanks mate.
Unfortunately I will have to have root permissions to edit the hosts file.
(it might take time before the htc desire gets root)
(edit: unless theres another way to get write permissions for that file..?)
If I do mess with the hosts file I'd be keen on adding a fair few entries to block ads too..
Since the hosts file gets loaded in ram at bootup, will there be any noticably difference in speed due to the size increase?
regards
-e
could you please post the host-file or the addresses/ip's of the companies your gonna block?
they should be of interest for everybody here
1. You will need root access.
2. The change shouldn't impact the performance in the least. Any local host lookup is always faster than DNS lookup. Meaning that it should increase performance in cases where it finds the match in hosts file, although I doubt if you will notice it.
3. I wouldn't worry about RAM. The host file, even if you add a hundred entries, given that each line consumes 100 bytes, should still be under 10kb.
Great to hear. Thanks for the replies.
@fabsn: I'll post my hosts file as soon as I get this working.. (gimme a few weeks to get my phone, move to android and root
Although: I'd be keen on using the adblock app in androidstore (the one that modifies the hosts file), but my manual changes will break every time I update the app.
I'll try to get hold of the dev to se if he/she might add these info collectors (like Flurry) in another version so that people can get "the best of both worlds"
By the way: I wish all devs that utilizes info collection in their apps could just provide users with an opt out, then my problem would be solved...
-e
http://textbin.com/x6430
Here is a complete "phone home" list for the iPhone. A lot of this will directly apply to android as well, so perhaps a nice soul here at the forum could compile the most useful adresses for me (I'm writing on my phone and it's a b**** to do this on)
the list is taken from: i-phone-home.blogspot(dot)com/
so credit goes to that community.
I really want to combine this with the hosts file that jamesisbored/droid has for adblock..
I will test this once desire hits my mailbox and someone finds root.
-e
This sounds like a great idea. Once a comprehensive list is compiled it should be passed on to "bigtincan". I know myself and a lot of other people use their "ad free" app to block ads using the same method mentioned by Ady above. Although they may be blocking them already and I don't know. I've never looked closely at the host file.
http://bigtincan.com/downloads/android.html
Any progress made on this end?
ady said:
1. You will need root access.
2. The change shouldn't impact the performance in the least. Any local host lookup is always faster than DNS lookup. Meaning that it should increase performance in cases where it finds the match in hosts file, although I doubt if you will notice it.
3. I wouldn't worry about RAM. The host file, even if you add a hundred entries, given that each line consumes 100 bytes, should still be under 10kb.
Click to expand...
Click to collapse
I am new to modding my phone, would you be so kind as to go into more detail how to do this. Specifically, what is this "Hosts file" you speak of? I do have root access and searched my entire phone for a file like that with no joy.
Also, the links provided to possible host data do not work, can somebody update that?
Thanks!!!:laugh:
You may be interested in the MOAB (mother of all adblockers) thread here on xda. Best ad blocker out there, imo, if you haven't already. Sorry, I can't link it now.
Sent from my SCH-I545 using Tapatalk
Hello
I want to create an Android App. In the last days i read a lot of Android API Documentations, Tutorials and "how do do's". Now I'm really confused, because on one hand, it's nice to have so many possibility, but on the other it confuses me, whats the best way to do it. So I played a little with Activity life-cycle.
Now I'm going to start to build my first 'real' App.
This App should download initial data from a Webservice, process these data with a database, download more data related to results from a database, save these data again to database, and make it accessible in the Acitvity.
So please correct me if I'm wrong from this point on:
I assumend that a Android Service is the best way, to process these Data in a background-worker-thread.
So far so good. So I read about the Android Handler which seems to be a pipeline, so Threads can work on the Handler message queue. I can Access the Service from within my MainActivity over the ServiceConnection.onServiceConnetcted where I recieve a simple Binder which gives me access to my Service. From there i can put Messages in the Message queue from the HandlerThread. But how I can tell my Acitivity from within the Service, that it has finished Processing and send the Data to it?
I read that I don't have to use AIDL since the Service is running in the same Process. But How can I do it then? I tried to call onBind() in the Service, hoping OnServiceConnected will be triggered in the Acitvity which initially Binds these Services, but it doesn't seem to work. I also tried to "hack" the Funktionality, by spending my Service a singleton member "MyMainActivity" with corresponing static setMainActivity(MyMainActivity activity), calling it in the ServiceConnector onServiceConnected, with the same result: Runtime Error
I even don't think I understand the functionality behind these HandlerThread.
will it loop infinitly waiting for HandlerMessages while draining the Battery, or is it on a wait() status since it recieves a message?
I read the Android API about Services but for me, it seems that they only describe to Access the Service from the Activity, and not the other way round.
If I call a method of my Service within my Activity over the ServiceBinder, which has a return value, but was started in another Thread in my Service, how will my Activity know that it processes finish? 'busy waiting' on a boolean member of my Service doesn't seem to be the way to go. If I do that, like I saw in a tutorial, I don't see a reason not to do the work in the Activity Thread itself.
I read also about an AsyncTask, but this doesn't seem to be practicable for me, because I have to do different work related to JSON Objects I get.
Please you expirienced Android guys: show me the way.
You probably don't need a full-fledged service if you just need a background thread. Services can run independent of an activity and reconnect, etc. If you don't intend for the thread to be stand-alone, then just use a class that implements Runnable. Since you seem to have a handle (no pun intended) on handlers, this won't be too hard. Just post a message to your handler from your thread to let the activity know what's going on.
We have all seen this CIQ information in SFR thread and repeated all over the internet on various forums and blog sites.
Code:
What Is Carrier IQ? Why Should We Care?
3/31/2011: Hello, Slashdotters!
Put simply - and bluntly - Carrier IQ is a software package buried deep within Android by Samsung at the behest of Sprint. It has been in active use since the time of the Moment, if not before. The company that develops it, also known as Carrier IQ, bills it as "Mobile Service Intelligence". In their own words,
[T]he combination of the MSIP and IQ Insight lets you move seamlessly from broad trend data across many users, through comparative groups down to diagnostic data from individual devices. Now, not only can you identify trends, you have the power to drill down to specific instances, giving you the insight your specialists need to make a difference.
On its own, that description can vary from harmless, to worrying, depending on how you look at it. It's not until one drills deep down into the system and ferrets out every piece of the software that one truly knows what it contains. As some of you might remember, ACS took the first steps toward disabling the Carrier IQ software with the release of SyndicateROM and Xtreme Kernel 1.0. That, however, didn't even scratch the surface.
Carrier IQ's native libraries are plainly visible - libiq_client.so and libiq_service.so in /system/lib. During every boot, this service is launched - you can see it in Settings > Applications > Running Services as "IQAgent Service". These native libraries are called by non-native (Android application) libraries located in ext.jar (the client) and framework.jar (the service). Removal of these (rather obviously-named) libraries alone, be it the .so files or the libraries in framework or ext, will, obviously, break boot. So I - k0nane - had to dig deeper. To make a long story short, reference to the IQ Service and IQ Client were littered across the deepest portions of the framework, and some of the most basic functions of the Android system as we know it.
Carrier IQ as a platform is designed to collect "metrics" at any scale. What I found it to hook into is far beyond the scope of anything a carrier needs - or should want - to be collecting. Carrier IQ sits in the middle of, and "checks" the data of, SMS and MMS messages. It listens for and receives every battery change notifications. It hooks into every web page you view, and every XML file your device reads. It receives every press of the touch screen. It 'sees' what you type on the physical keyboard. It reads every number you press in the dialer. It can track which applications you use, what 'type' they are, how often, and for how long. It hooks into data sent and received.
.................
What I am asking in this thread is for any specific information about CIQ that Dev's who have worked with it are willing to provide from their personal experience with investigating and removing it. I am also asking Dev's and Forum Members who have come across other articles, threads in other forums, etc, to please provide information with links.
Code:
Provided by chris41g
to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
Provided by mkasick
Here's all the files that reference "CIQ", "carrieriq", or "libiq" with instances unrelated to Carrier IQ removed:
/ (initramfs):
- init: /dev/ttyCIQ0 UART, presumably to communicate with radio.
- init.rc: Start iqmsd service if property:service.iq.active=1.
- lib/modules/dpram.ko: Implements ttyCIQ UARTs.
/system:
- app/DialerTabActivity.odex
- app/FactoryTest.odex
- bin/iqmsd
- framework/ext.odex
- framework/framework.odex
- framework/sec_feature.odex
- framework/services.odex
- lib/libiq_client.so
- lib/libiq_service.so
Of these, bin/iqmsd is a purpose-unknown daemon, and libiq_client.so & libiq_service.so the client & service native code. The client & service managed code is implemented in framework/ext.odex & framework/framework.odex respectively.
In addition, the following framework classes reference Carrier IQ in some fashion:
framework/ext.odex:
- org.apache.http.impl.client.DefaultRequestDirector
framework.framework.odex:
- android.inputmethodservice.InputMethodService
- android.net.http.Request
- android.webkit.{BrowserFrame,CallbackProxy,LoadLis tener,WebViewCore}
- com.android.internal.telephony.SMSDispatcher
framework.services.odex:
- com.android.server.BatteryService
- com.android.server.WindowManagerService
- com.android.server.am.UsageStatsService
Finally, libiq_service.so is used exclusively by framework/framework.odex (com.carrieriq.iqagent.client.NativeClient), and libiq_client.so is used by:
- bin/iqmsd
- framework/ext.odex (com.carrieriq.iqagent.service.IQService)
- lib/libopencore_player.so
I am seeking facts, file names, files, information on CIQ in the framework, specifically what files CIQ hooks into, etc. Thank you for taking the time to read this.
I received a response yesterday (June 15, 2011) from a group that has disassembled IQAgent & CarrierIQ.
in response to questions about CIQ's capabilities.
We have actually disassembled IQAgent/carrierIQ and captured its behavior to find exactly what it is sending back to sprint on the samsung optimus phone. The information we found it to collect was basic, such as cell towers, signal strengths, device battery. Nothing alarming on that phone, but Sprint could send a remote update to enable the surveillance features without the owner being aware.
Click to expand...
Click to collapse
Now while the above statement is about the Optimus, I was able to confirm through another source that IQAgent & CarrierIQ collection and transmission capabilities are set the same across all Sprint Android offerings.
During a telephone call with Sprint and in a follow up email Sprint responded to requests for information on Carrier IQ, who was responsible for the installation on Sprint's hardware and asked to directly address concerns over its potentially invasive nature.
the software that is in the Android phones is supplied by Google themselves as well as the manufacturer. We
(Sprint) has no control over the actual operating system supplied to us such as the Carrier IQ as it is indigenous to the Android platform.
Click to expand...
Click to collapse
Off the record, Google has denied this referencing that the Nexus S did not have CIQ installed on it because they would not let carriers install such software on their native Android devices.
In the same conversation and follow up email Sprint stated;
removing the Carrier IQ software from your Samsung Epic device can void your manufacturer warranty.
Click to expand...
Click to collapse
The representative was questioned on Sprint's use of the word "can" but could not elaborate on under what circumstances removal of CIQ would not void the warranty.
Update July 5, 2011
Sprint still refuses to address the concerns over Carrier IQ's potentially invasive nature. When directly questioned on if CIQ as it is installed on Sprint hardware is capable of the level of invasive data collection as previously reported by Steve Toplez, Sprint responds with complete silence.
I have since requested contact and an official response from both Sprint's compliance department and General Counsel. Once again, the silence is deafening.
Good thinking
Sweet ... but this might just start another debate ..
Lets hope it doesn't. I would really like to see this community come together and allow this information to be provided with little or no flaming, thread hijacking or warring.
Description of CarrierIQs Service
Mobile Service Intelligence
Mobile Service Intelligence is the process of analyzing data from phones to give you a uniquely powerful insight into mobile service quality and user behavior. Carrier IQ's Mobile Service Intelligence Platform (MSIP) is the smart database at the heart of our solution. It receives raw data (known as Metrics) from phones and converts them into reliable, repeatable Measures which feed into analytic applications. The MSIP delivers true enterprise grade performance, with its proven ability to process data submitted by millions of phones with outstanding integrity and security.
Get the Insight
We know you don't just want data, you want to solve business problems and identify new business opportunities. The IQ Insight application suite uses data from the MSIP to deliver true Actionable Intelligence, tailored to specific business areas. From the performance information to support the launch of a new phone or service to historical information to understand in detail customer behavior and usage patterns, the IQ Insight suite cuts through the complexity to allow you to focus on critical business issues, create and track Key Performance Indicators (KPIs) and all in the knowledge that the data is measured at the point the customer experienced it – in the phone.
What's more, the combination of the MSIP and IQ Insight lets you move seamlessly from broad trend data across many users, through comparative groups down to diagnostic data from individual devices. Now, not only can you identify trends, you have the power to drill down to specific instances, giving you the insight your specialists need to make a difference. That is the power of Mobile Service Intelligence.
Click to expand...
Click to collapse
http://www.freshnews.com/news/383257/carrier-iq-powers-android-platform-mobile-service-intelligence
twolostminds said:
Lets hope it doesn't. I would really like to see this community come together and allow this information to be provided with little or no flaming, thread hijacking or warring.
Click to expand...
Click to collapse
as info is provided, you should compile it (in an easy to read format) in the first post so others don't have to read through (potentially) pages and pages of stuff.. (you can use 'code' HTML tags to 'condense' longer text into smaller boxes I think)
Just my .02
and hopefully the community can come together and compile good/relevant info without all the drama.
http://www.carrieriq.com/overview/IQInsightServiceAnalyzer/ServiceAnalyzer.datasheet.pdf
by the way, as far as framework.. to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
http://www.carrieriq.com/overview/IQInsightDeviceAnalyzer/DeviceAnalyzer.datasheet.pdf
this datasheet, makes it sound like its installed for testing the phone, then turned off and can be turned on if needed for support..
daddymikey1975 said:
as info is provided, you should compile it (in an easy to read format) in the first post so others don't have to read through (potentially) pages and pages of stuff.. (you can use 'code' HTML tags to 'condense' longer text into smaller boxes I think)
Just my .02
and hopefully the community can come together and compile good/relevant info without all the drama.
Click to expand...
Click to collapse
I will be updating the OP on a regular basis and once enough verifiable information is gathered I will be creating a Wiki-like posting.
i would think that if we are rooting and also using custom roms or taking features Sprint has built into the phone (Carrieriq) then would we not be violating the terms and conditions of service. And lets not forget that google can tell if we are rooted as we can not get movie rentals from the market. Also google and sprint are able to see what apps we have installed and if they see super user app then its a safebet we are rooted. If google wants to get rid of rooted apps they can by simply removing them from the market upon carrier request like vzw and att did for wifi tether.
chris41g said:
...
then in the kernels initramfs, you have to disable the service in the init.rc
Click to expand...
Click to collapse
sorry noob here, I'm running stock EC05, how do I remove it from init.rc?
chris41g said:
http://www.carrieriq.com/overview/IQInsightDeviceAnalyzer/DeviceAnalyzer.datasheet.pdf
this datasheet, makes it sound like its installed for testing the phone, then turned off and can be turned on if needed for support..
Click to expand...
Click to collapse
I don't know much about it but I do know it runs in the background at boot. To me, that's not "turned off."
dchawk81 said:
I don't know much about it but I do know it runs in the background at boot. To me, that's not "turned off."
Click to expand...
Click to collapse
The service is running, with logging and reporting turned off, and can (presumably) be remotely activated..
Sent from my SPH-D700 using XDA App
chris41g said:
The service is running, with logging and reporting turned off, and can (presumably) be remotely activated..
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Right. So it's not truly off. Standby isn't off.
Since it's not off, I prefer it gone.
From what I've been able to gather from it it doesn't do much of anything. It has the potential to track stuff, but i'd bet stuff for marketing purposes and possibly troubleshooting remotely.
Everyone is all up in arms over removing it, but there or not it doesn't have any effect on your phone, or battery life.
As far as security purposes, you may as well stop using your phone all together, because thats similar to the kind of stuff google can collect from your phone at any point. Its not a big deal, its not important, and the performance gain for removing any of it is nil.
Well if it doesn't do anything at all, it doesn't need to be there.
chris41g said:
http://www.carrieriq.com/overview/IQInsightServiceAnalyzer/ServiceAnalyzer.datasheet.pdf
by the way, as far as framework.. to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
Click to expand...
Click to collapse
Does anyone have a list of every file that references CIQ?
twolostminds said:
Does anyone have a list of every file that references CIQ?
Click to expand...
Click to collapse
That would be an almost impossible task, without going through the source... and even then there are likely to be closed source files too....
The list I gave you is what is edited in a nociq rom though..
Sent from my SPH-D700 using XDA App
chris41g said:
That would be an almost impossible task, without going through the source... and even then there are likely to be closed source files too....
The list I gave you is what is edited in a nociq rom though..
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
You are probably right, it would be impossible without access to both open and closed source. My goal is to put together the most complete and comprehensive information source on CIQ's implementation and capabilities as installed in Android. So any other references that have been found would be greatly appreciated.
The Vulnerability
In recent updates to some of its devices, HTC introduces a suite of logging tools that collected information. Lots of information. LOTS. Whatever the reason was, whether for better understanding problems on users' devices, easier remote analysis, corporate evilness - it doesn't matter. If you, as a company, plant these information collectors on a device, you better be DAMN sure the information they collect is secured and only available to privileged services or the user, after opting in.
That is not the case. What Trevor found is only the tip of the iceberg - we are all still digging deeper - but currently any app on affected devices that requests a single android.permission.INTERNET (which is normal for any app that connects to the web or shows ads) can get its hands on:
the list of user accounts, including email addresses and sync status for each
last known network and GPS locations and a limited previous history of locations
phone numbers from the phone log
SMS data, including phone numbers and encoded text (not sure yet if it's possible to decode it, but very likely)
system logs (both kernel/dmesg and app/logcat), which includes everything your running apps do and is likely to include email addresses, phone numbers, and other private info
Normally, applications get access to only what is allowed by the permissions they request, so when you install a simple, innocent-looking new game from the Market that only asks for the INTERNET permission (to submit scores online, for example), you don't expect it to read your phone log or list of emails.
But that's not all. After looking at the huge amount of data (the log file was 3.5MB on my EVO 3D) that is vulnerable to apps exploiting this vulnerability all day, I found the following is also exposed (granted, some of which may be already available to any app via the Android APIs):
active notifications in the notification bar, including notification text
build number, bootloader version, radio version, kernel version
network info, including IP addresses
full memory info
CPU info
file system info and free space on each partition
running processes
current snapshot/stacktrace of not only every running process but every running thread
list of installed apps, including permissions used, user ids, versions, and more
system properties/variables
currently active broadcast listeners and history of past broadcasts received
currently active content providers
battery info and status, including charging/wake lock history
and more
Let me put it another way. By using only the INTERNET permission, any app can also gain at least the following:
ACCESS_COARSE_LOCATION Allows an application to access coarse (e.g., Cell-ID, WiFi) location
ACCESS_FINE_LOCATION Allows an application to access fine (e.g., GPS) location
ACCESS_LOCATION_EXTRA_COMMANDS Allows an application to access extra location provider commands
ACCESS_WIFI_STATE Allows applications to access information about Wi-Fi networks
BATTERY_STATS Allows an application to collect battery statistics
DUMP Allows an application to retrieve state dump information from system services.
GET_ACCOUNTS Allows access to the list of accounts in the Accounts Service
GET_PACKAGE_SIZE Allows an application to find out the space used by any package.
GET_TASKS Allows an application to get information about the currently or recently running tasks: a thumbnail representation of the tasks, what activities are running in it, etc.
READ_LOGS Allows an application to read the low-level system log files.
READ_SYNC_SETTINGS Allows applications to read the sync settings
READ_SYNC_STATS Allows applications to read the sync stats
Theoretically, it may be possible to clone a device using only a small subset of the information leaked here.
I'd like to reiterate that the only reason the data is leaking left and right is because HTC set their snooping environment up this way. It's like leaving your keys under the mat and expecting nobody who finds them to unlock the door. For a more technical explanation, see the section below.
Additionally, and the implications of this could end up being insignificant, yet still very suspicious, HTC also decided to add an app called androidvncserver.apk to their Android OS installations. If you're not familiar with the definition of VNC, it is basically a remote access server. On the EVO 3D, it was present from the start and updated in the latest OTA. The app doesn't get started by default, but who knows what and who can trigger it and potentially get access to your phone remotely? I'm sure we'll know soon enough - HTC, care to tell us what it's doing here?
Technical Details
In addition to Carrier IQ (CIQ) that was planted by HTC/Sprint and prompted all kinds of questions a while ago, HTC also included another app called HtcLoggers.apk. This app is capable of collecting all kinds of data, as I mentioned above, and then... provide it to anyone who asks for it by opening a local port. Yup, not just HTC, but anyone who connects to it, which happens to be any app with the INTERNET permission. Ironically, because a given app has the INTERNET permission, it can also send all the data off to a remote server, killing 2 birds with one stone permission.
In fact, HtcLogger has a whole interface which accepts a variety of commands (such as the handy :help: that shows all available commands). Oh yeah - and no login/password are required to access said interface.
Furthermore, it's worth noting that HtcLogger tries to use root to dump even more data, such as WiMax state, and may attempt to run something called htcserviced - at least this code is present in the source:
/system/xbin/su 0 /data/data/com.htc.loggers/bin/htcserviced
HtcLoggers is only one of the services that is collecting data, and we haven't even gotten to the bottom of what else it can do, let alone what the other services are capable of doing. But hey - I think you'll agree that this is already more than enough.
Patching The Vulnerability
... is not possible without either root or an update from HTC. If you do root, we recommend immediate removal of Htcloggers (you can find it at /system/app/HtcLoggers.apk).
Stay safe and don't download suspicious apps. Of course, even quality-looking apps can silently capture and send off this data, but the chance of that is lower.
Affected Phones
Note: Only stock Sense firmware is affected - if you're running an AOSP-based ROM like CyanogenMod, you are safe.
EVO 4G
EVO 3D
Thunderbolt
EVO Shift 4G? (thanks, pm)
MyTouch 4G Slide? (thanks, Michael)
the upcoming Vigor? (thanks, bjn714)
some Sensations? (thanks, Nick)
View 4G? (thanks, Pat)
the upcoming Kingdom? (thanks, Pat)
most likely others - we haven't verified them yet, but you can help us by downloading the proof of concept above and running the APK
HTC's Response
After finding the vulnerability, Trevor contacted HTC on September 24th and received no real response for five business days, after which he released this information to the public (as per RF full disclosure Policy). In my experience, lighting fire under someone's ass in public makes things move a whole lot faster, which is why responsible disclosure is a norm in the security industry. (This is where we come in.)
As far as we know, HTC is now looking into the issue, but no statement has been issued yet.
HTC, you got yourself into this mess, and it's now up to you to climb out of the hole as fast as possible, in your own interest.
The ball is in your court.
Credit
ANDROID POLICE
Huge thank you to Trevor Eckhart who found the vulnerability and Justin Case for working with us today digging deeper.
Hi there, I need help, someone is consistently hacking into my phone, htc evo 4g, they are penetration testers and pc savvy, currently I cant login to the phn for trying to do a factory reset. They kept intercepting me and now my password does not work. Who knows maybe they changed it on their side. I wrote down everything I saw. I was seeing all these process running for the same app. in my applications. My phone was getting hot, freezes but its people that live in my apt complex and at work. can you help?
zzm5 said:
Hi there, I need help, someone is consistently hacking into my phone, htc evo 4g, they are penetration testers and pc savvy, currently I cant login to the phn for trying to do a factory reset. They kept intercepting me and now my password does not work. Who knows maybe they changed it on their side. I wrote down everything I saw. I was seeing all these process running for the same app. in my applications. My phone was getting hot, freezes but its people that live in my apt complex and at work. can you help?
Click to expand...
Click to collapse
Is your device rooted?
I used root explorer and removed the HtcLoggers.apk and other than the forced close loop that removing it caused (requiring me to remove the battery), after rebooting all seems to be working fine.
EDIT: Actually I didn't just delete HtcLoggers.apk but moved it to a safe location on the SD Card in case there was a problem and it needed to be restored. I highly suggest you do this instead of just deleting it, or better yet, a nandroid backup.
there are a few good ROMS out there that have the ICQ loggers removed already.
Do we really need three threads on the front page about the same thing?
Hello. I'm working on a custom device that is not on the market yet, and I am having issues getting it to work with Google Play. I have root access, so I was able to sideload GooglePlay.apk and GoogleServicesFramework.apk. However, I am forced to use Market Helper in order to download apps. I would like to bake in compatibility to the ROM itself, but am having issues.
I've tried modifying the build.prop to have dummy values for ro.product.{model,device,manufacturer}, as well as ro.hardware and ro.com.google.clientidbase. I feel like I'm close, but the device still fails to be accepted by Play without marker helper.
Any hints or advice are tremendously appreciated!
Sorry, can't help you with the problem.
But I am really interested in your custom device. Could you please tell us more about it?
Cool.
For those who encounter a similar problem, I will post the answer. Credit to (xkcd: Wisdom of the Ancients) for the idea.
edit: the policy of not posting outside links is really annoying. All links have the base: http: slash slash developer dot android dotcom , just add the relevant url and glue it together.
Anyway, here goes. Turns out the build.prop was not the limiting factor.
Explanation of the overall process:
- Developers create an app, and list certain features it depends on in the manifest.xml file located in the root of the apk. ( /guide/topics/manifest/uses-feature-element.html)
- When the Play Store is opened, a call is made to getSystemAvailableFeatures()
- This call is handled by an internal app called PackageManager - (/reference/android/content/pm/PackageManager.html)
-This app looks in /system/etc/permissions and parses the xml files to determine what hardware and software features the phone has. it then sends this list back to the play store. - see( /guide/practices/compatibility.html) and ( /google/play/filters.html )
- The play store then filters the apps, as per the links above.
How to modify this:
- What I’ve done is taken the files from /system/etc/permissions on a galaxy S2 Skyrocket (my personal device), and copied in all of them, without overwriting the already existing files. Now, google play works and allows the download of the same subset of apps as on the Skyrocket.
For those wondering how to include these files at compile time, here is the answer:
http://forum.xda-developers.com/showthread.php?t=2356046