Develop Bugs

Android Permissions info list explained - Galaxy Y GT-S5360 General

We all knows about the permissions that we see when we looking/downloading an
app in Google PlayStore,but never read it or think about why its needet and its dangerous or not.So here is my Guide,its not fake the Permissions are 100% from Store and the Details are collected and from myself.I have spend many/long time and hard work for it,so please give credit when share it using for own blog.Thanx
The main reason for this list is to guide the easynes for take a virus/trojan
to your phone and to make users to thinking about it!!!!
-----------------------------------------------------------------------
Make phone calls
Services that cost you money
URI: android.permission.CALL_PHONE
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to initiate a phone call without going through the Dialer user interface for the user to confirm the call being placed.
Details
This permission is of high importance. This could let an application call a 1-900 number and charge you money. However, this is not as common a way to cheat people in today's world as it used to be. Legitimate applications that use this include: Google Voice and Google Maps.
Another important point to note here is that any app can launch the phone screen and pre-fill a number for you. However, in order to make the call, you would need to press [Send] or [Call] yourself. The difference with this permission is that an app could make the entire process automatic and hidden.
---------------------------------------------------------------------
Send SMS or MMS
Services that cost you money
URI: android.permission.SEND_SMS
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to send SMS messages.
Details
This permission is of high importance. This could let an application send an SMS on your behalf, and much like the phone call permission, it could cost you money by sending SMS to for-pay numbers. Certain SMS numbers work much like 1-900 numbers and automatically charge your phone company money when you send them an SMS.
----------------------------------------------------------------------
Modify/delete SD card contents
Your personal information
URI: android.permission.WRITE_EXTERNAL_STORAGE
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows an application to write to external storage
Details
This permission is of high importance. This will allow applications to read, write, and delete anything stored on your phone's SD card. This includes pictures, videos, mp3s, documents and even data written to your SD card by other applications. However, there are many legitimate uses for this permission. Many people want their applications to store data on the SD card, and any application that stores information on the SD card will need this permission. You will have to use your own judgment and be cautious with this permission knowing it is very powerful but very, very commonly used by legitimate applications. Applications that typically need this permission include (but are not limited to) camera applications, audio/video applications, document applications
WARNING:Any app targeting Android 1.5 or below (possibly 1.6 as well) will be granted this permission BY DEFAULT and you may not ever be warned about it. It is important to pay attention to what version of Android an app is targeting to know if this permission is being granted. You can see this on the Market website in the right hand column.
------------------------------------------------------------------------
Read Contacts
Development tools / Your personal info
URI: android.permission.READ_CONTACTS
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to read the user's contacts data.
Details
This permission is of high importance. Unless an app explicitly states a specific feature that it would use your contact list for, there isn't much of a reason to give an application this permission. Legitimate exceptions include typing or note taking applications, quick-dial type applications and possibly social networking apps. Some might require your contact information to help make suggestions to you as you type. Typical applications that require this permission include: social networking apps, typing/note taking apps, SMS replacement apps, contact management apps.
------------------------------------------------------------------------
Write contact data
Development tools / Your personal info
URI: android.permission.WRITE_CONTACTS
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to write (but not read) the user's contacts data.
Details
This permission is of high importance. Unless an app explicitly states a specific feature that it would use your contact list for, there isn't much of a reason to give an application this permission. Legitimate exceptions include typing or note taking applications, quick-dial type applications and possibly social networking apps. Some might require your contact information to help make suggestions to you as you type. Typical applications that require this permission include: social networking apps, typing/note taking apps, SMS replacement apps, contact management apps.
-------------------------------------------------------------------------
Read calendar data
Development tools / Your personal info
URI: android.permission.READ_CALENDAR
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows an application to read the user's calendar data.
Details
This permission is of moderate to high importance. While most people would consider their calendar information slightly less important than their list of contacts and friends, this permission should still be treated with care when allowing applications access. Additionally, it's good to keep in mind that calendar events can, and often do contain contact information.
-----------------------------------------------------------------------
Write calendar data
Development tools / Your personal info
URI: android.permission.WRITE_CALENDAR
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows an application to write (but not read) the user's calendar data.
Details
This permission is of moderate to high importance. While most people would consider their calendar information slightly less important than their list of contacts and friends, this permission should still be treated with care when allowing applications access. Additionally, it's good to keep in mind that calendar events can, and often do contain contact information.
----------------------------------------------------------------------
Read browser history & bookmarks
Development tools / Your personal info
URI: com.android.browser.permission.READ_HISTORY_BOOKMA RKS
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to read (but not write) the user's browsing history and bookmarks.
Details
This permission is of medium-high importance. Browsing habits are often tracked through regular computers, but with this permission you'd be giving access to more than just browsing habits. There are also legitimate uses for this permission such as apps that sync or backup your data, and possibly certain social apps.
-------------------------------------------------------------------------
Write browser history & bookmarks
Development tools / Your personal info
URI: com.android.browser.permission.WRITE_HISTORY_BOOKM ARKS
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to write (but not read) the user's browsing history and bookmarks.
Details
This permission is of medium-high importance. Browsing habits are often tracked through regular computers, but with this permission you'd be giving access to more than just browsing habits. There are also legitimate uses for this permission such as apps that sync or backup your data, and possibly certain social apps.
----------------------------------------------------------------------
Read sensitive logs
Development tools / Your personal info
URI: android.permission.READ_LOGS
Risk: VERY-HIGH
Protection level: DEVELOPMENT
Official Description
Allows an application to read the low-level system log files.
Details
This permission is of high importance. This allows the application to read what any other applications have logged.
--------------------------------------------------------------------------
Modify global system settings
Hardware controls
URI: android.permission.WRITE_SETTINGS
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows an application to read or write the system settings
Details
This permission is pretty important but only has the possibility of moderate impact. Global settings are pretty much anything you would find under Android's main 'settings' window. However, a lot of these settings may be perfectly reasonable for an application to change. Typical applications that use this include: volume control widgets, notification widgets, settings widgets, Wi-Fi utilities, or GPS utilities. Most apps needing this permission will fall under the "widget" or "utility" categories/types.
--------------------------------------------------------------------------
Read sync settings
Hardware controls
URI: android.permission.READ_SYNC_SETTINGS
Risk: LOW-MODERATE
Protection level: UNKNOWN
Official Description
Allows applications to read the sync settings
Details
This permission is of low to medium importance. It mostly allows the application to know if you have background data sync (such as for Facebook or Gmail) turned on or off.
--------------------------------------------------------------------
Automatically start at boot
Hardware controls
URI: android.permission.RECEIVE_BOOT_COMPLETED
Risk: MODERATE-HIGH
Protection level: UNKNOWN
Official Description
Allows an application to receive the ACTION_BOOT_COMPLETED that is broadcast after the system finishes booting.
Details
This permission is of low to moderate impact. It will allow an application to tell Android to run the application every time you start your phone. While not a danger in and of itself, it can point to an applications intent
---------------------------------------------------------------------------
Restart other applications
Hardware controls
URI: android.permission.RESTART_PACKAGES
Risk: HIGH
Protection level: UNKNOWN
Official Description
This constant is deprecated. The restartPackage(String) API is no longer supported.
Details
This permission is of low to moderate impact. It will allow an application to tell Android to 'kill' the process of another application. However, any app that is killed will likely get restarted by the Android OS itself.
---------------------------------------------------------------------------
Retrieve running applications
Hardware controls
URI: android.permission.GET_TASKS
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
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.
Details
This permission is of moderate importance. It will allow an application to find out what other applications are running on your phone. While not a danger in and of itself, it would be a useful tool for someone trying to steal your data. Typical legitimate applications that require this permission include: task killers and battery history widgets. Other than that however, most apps should not need this permission.
-----------------------------------------------------------------------
Display system-level alerts
Hardware controls
URI: android.permission.SYSTEM_ALERT_WINDOW
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to open windows using the type TYPE_SYSTEM_ALERT, shown on top of all other applications.
Details
This permission is of high importance. This permission allows an app to show a "popup" window above all other apps, even if the app is not in the foreground. A malicious developer/advertiser could use it to show very obnoxious advertising. Almost no apps should require this permission unless they are part of the Android operating system. An example of a system alert would be the alert you are shown when your phone or tablet is out of battery and is about to shut down.
-------------------------------------------------------------------------
Control vibrator
Development tools
URI: android.permission.VIBRATE
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows access to the vibrator
Details
This permission is of low importance. As it states, it lets an app control the vibrate function on your phone. This includes for incoming calls and other events.
--------------------------------------------------------------------------
Take pictures and videos
Development tools
URI: android.permission.CAMERA
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Official Description
Required to be able to access the camera device.
Details
This permission is of moderate importance. As it states, it lets an app control the camera function on your phone. In theory this could be used maliciously to snap unsuspecting photos, but it would be unlikely and difficult to get a worthwhile picture or video. However, it is not impossible to make malicious use of cameras.
--------------------------------------------------------------------------
Access location extra commands
Network Communication
URI: android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
Risk: MEDIUM-HIGH
Protection level: UNKNOWN
Official Description
Allows an application to access extra location provider commands
Details
The specifics of the extra commands here are a bit unclear. However, the usage of this permission indicates that an app wants to know detailed information about your location, and respond accordingly. This is often used with advertising and location-based and social-network services like Four Square, Twitter, Facebook or Google Places/Google+. It is recommended that you treat this permission with the same caution as the GPS location permission and assume the same implications to privacy apply.
-------------------------------------------------------------------------
Access mock location
Network Communication
URI: android.permission.ACCESS_MOCK_LOCATION
Risk: MODERATE
Protection level: DANGEROUS
Official Description
Allows an application to create mock location providers for testing
Details
This is a permission used for development of apps that make use of location based services. By creating "mock" (fake) locations, apps can test if their code works correctly depending on your location.This permission has no known sercurity considerations; Nor much use in a app released to the public.
-----------------------------------------------------------------------
Battery stats
Hardware controls
URI: android.permission.BATTERY_STATS
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows an application to collect battery statistics
Details
This permission is of little to no importance.
--------------------------------------------------------------------------
Bluetooth Admin
Your accounts
URI: android.permission.BLUETOOTH_ADMIN
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows applications to discover and pair bluetooth devices
Details
Bluetooth (Wikipedia: http://en.wikipedia.org/wiki/Bluetooth) is a technology that lets your phone communicate wirelessly over short distances. It is similar to Wi-Fi in many ways. It itself is not a danger to your phone, but it does enable a way for an application to send and receive data from other devices. Typical applications that would need bluetooth access include: sharing applications, file transfer apps, apps that connect to headset or wireless speakers.
-----------------------------------------------------------------------
Broadcast Sticky (Intents)
Hardware controls
URI: android.permission.BROADCAST_STICKY
Risk: LOW-MEDIUM
Protection level: UNKNOWN
Official Description
Allows an application to broadcast sticky intents. These are broadcasts whose data is held by the system after being finished, so that clients can quickly retrieve that data without having to wait for the next broadcast.
Details
The permission has to do with how applications "talk" to each other using a communication method called "Intents". While this permission is highly technical it is a relatively low importance. There are no know obvious malicious uses for this permission.
--------------------------------------------------------------------------
Change Configuration
Hardware controls
URI: android.permission.CHANGE_CONFIGURATION
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to modify the current configuration, such as locale.
Details
This is a permission that generally should not be granted to regular apps. Other than changing the locale (i.e. language), it is unclear what configuration changes this permission allows. As such, it should be treated with considerable caution.
-------------------------------------------------------------------------
Clear app cache
Hardware controls
URI: android.permission.CLEAR_APP_CACHE
Risk: LOW
Protection level: DANGEROUS
Official Description
Allows an application to clear the caches of all installed applications on the device.
Details
This permission is of low importance. It allows an app to clear the cache of apps on the phone or tablet. The cache is a place that an app stores recently used data for faster access. Clearing the cache can sometimes (very rarely) fix bugs related to those files. Clearing these files generally presents no risk other than to slow the performance of the phone or tablet (as apps will need to re-create the caches when used).
---------------------------------------------------------------------------
Disable Keyguard (lock screen)
(unknown category)
URI: android.permission.DISABLE_KEYGUARD
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows applications to disable the keyguard
Details
This permission is of medium-high importance. It allows an app to disable the "lock screen" that most phones go into after going to sleep and been turned on again. This lockscreen can sometimes be a password screen, or a PIN screen, or just a "slide to unlock" screen.
------------------------------------------------------------------------
MORE IN POST TWO,BECAUSE IM LIMITED 3000 WORDS!!!!!SORRY

THE REST FROM FIRST POST!!!!!
-----------------------------------------------------------------------------
Expand status bar
Hardware controls
URI: android.permission.EXPAND_STATUS_BAR
Risk: MEDIUM-HIGH
Protection level: UNKNOWN
Official Description
Allows an application to expand or collapse the status bar.
Details
This appears to be a system permission -- not for use by regular applications. If you come across this permission I would beware of any app requesting it that is not an Android system app.
-------------------------------------------------------------------------
Flashlight
Development tools
URI: android.permission.FLASHLIGHT
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows access to the flashlight
Details
This allows apps to turn on or off the LED "flash" light used by the camera. This is a handy tool but usually of no risk itself.
---------------------------------------------------------------------------
Get package size
Hardware controls
URI: android.permission.GET_PACKAGE_SIZE
Risk: LOW-MODERATE
Protection level: UNKNOWN
Official Description
Allows an application to find out the space used by any package.
Details
This permission does not seem to have any risk associated with it.
--------------------------------------------------------------------------
Kill background processes
Hardware controls
URI: android.permission.KILL_BACKGROUND_PROCESSES
Risk: HIGH
Protection level: UNKNOWN
Official Description
Allows an application to call killBackgroundProcesses(String).
Details
This permission is a bit of a tricky one. Often this is used by what are called "task killers". These apps supposedly free system resources by closing apps running in the background. However the usefulness of such apps is minimal at best. They can help close an app that is misbehaving, however a user can already do that themselves through the Android settings under "Apps" or "Manage Applications". Conversely this permission has some potential to maliciously close anti-virus or other security related apps. As with anything I would treat this with caution. Few users should ever need an app with this permission. Rather, it could be an indicator of malicious intent (especially if not requested by a task killer or system performance tuning app).
---------------------------------------------------------------------------
Modify audio settings
Hardware controls
URI: android.permission.MODIFY_AUDIO_SETTINGS
Risk: LOW
Protection level: DANGEROUS
Official Description
Allows an application to modify global audio settings
Details
This permission is of low importance. Audio settings pose little to no risk to the device.
-----------------------------------------------------------------------------
Format file systems
Your personal information
URI: android.permission.MOUNT_FORMAT_FILESYSTEMS
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows formatting file systems for removable storage.
Details
The primary danger with this permission is that it could be used to erase data from an SD card or other similar storage in your phone. This is also not a permission any normal app should need.
---------------------------------------------------------------------------
Mount / Unmount file systems
Your personal information
URI: android.permission.MOUNT_UNMOUNT_FILESYSTEMS
Risk: MODERATE
Protection level: DANGEROUS
Official Description
Allows mounting and unmounting file systems for removable storage.
Details
This permission just allows for connecting to SD cards for reading and writing. While not a risk itself, this is also not a permission any normal app should need.
--------------------------------------------------------------------------
NFC (Near Field Communication)
Your accounts
URI: android.permission.NFC
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows applications to perform I/O operations over NFC
Details
NFC stands for Near Field Communication. This is a technology like Bluetooth that enables short range communication between two devices or the reading of NFC "tags". The distance which NFC is able to work is only a few centimeters so that devices (or a device and a tag) must effectively be touching each other to communicate. Due to the distance, this technology is not particularly dangerous. However it does present a small risk and it is something that should used with caution.
For more info: http://en.wikipedia.org/wiki/Near_field_communication
----------------------------------------------------------------------------
Process outgoing calls
Your location
URI: android.permission.PROCESS_OUTGOING_CALLS
Risk: VERY-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to monitor, modify, or abort outgoing calls.
Details
This permission is of high importance. This would allow an app to see what numbers are called and other personal info. Generally this permission should only be seen on apps for VOIP (Voice Over Internet Protocol) like Google Voice or dialer replacement type apps.
-----------------------------------------------------------------------
Read sync stats
Hardware controls
URI: android.permission.READ_SYNC_STATS
Risk: MODERATE
Protection level: UNKNOWN
Official Description
Allows applications to read the sync stats
Details
This permission is related to "Read sync settings" but not particularly dangerous itself. There is a minor risk that some personal information could be gleaned from the sync stats, but the information is unlikely to be valuble. Sync in this case relates to syncing of contacts and other types of media on the phone.
-------------------------------------------------------------------------
Record audio
Development tools
URI: android.permission.RECORD_AUDIO
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to record audio
Details
While this permission is not typically dangerous, it is a potential tool for eavesdropping. However recording audio has legitimate uses such as note taking apps or voice search apps. As a side note recording audio is typically a significant drain on the battery.
-----------------------------------------------------------------------
Set alarm
Hardware controls
URI: android.permission.SET_ALARM
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows an application to broadcast an Intent to set an alarm for the user.
Details
This permission seems to be of low risk because it doesnt allow the setting of the alarm directly. Rather it allows the opening of the alarm app on the phone.
--------------------------------------------------------------------------
Set time zone
Hardware controls
URI: android.permission.SET_TIME_ZONE
Risk: LOW
Protection level: DANGEROUS
Official Description
Allows applications to set the system time zone
Details
This permission poses little, if any, risk
---------------------------------------------------------------------------
Set wallpaper
Hardware controls
URI: android.permission.SET_WALLPAPER
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows applications to set the wallpaper
Details
This permission poses little, if any, risk
--------------------------------------------------------------------------
Subscribed feeds read
Development tools / Your personal info
URI: android.permission.SUBSCRIBED_FEEDS_READ
Risk: MEDIUM
Protection level: UNKNOWN
Official Description
Allows an application to allow access the subscribed feeds ContentProvider.
Details
This would give an app access to RSS feed that you have subscribed to. If you dont subscribe to any RSS feeds this permission is of little risk. If you do, this permission is akin to letting an app have access to your broser history. It could glean interests and preferences and other semi-personal information.
---------------------------------------------------------------------------
Subscribed feeds write
Development tools / Your personal info
URI: android.permission.SUBSCRIBED_FEEDS_WRITE
Risk: LOW-MEDIUM
Protection level: DANGEROUS
Official Description
(No developer documentation is available for this permission)
Details
This would give an app access to RSS feed that you have subscribed to. If you dont subscribe to any RSS feeds, this permission is of little risk. If you do, this permission is akin to letting an app have access to your broser history. It could glean interests and preferences and other semi-personal information.
--------------------------------------------------------------------------
Use SIP
Your accounts
URI: android.permission.USE_SIP
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to use SIP service
Details
SIP stands for Session Initiation Protocol. It is a technology mostly used for making video and voice calls over the Internet. While not a major security risk it should be treated with almost as much caution as the standard "make phone calls" permission.
---------------------------------------------------------------------------
Write secure settings
Hardware controls
URI: android.permission.WRITE_SECURE_SETTINGS
Risk: VERY-HIGH
Protection level: DEVELOPMENT
Official Description
Allows an application to read or write the secure system settings.
Details
This permission should only be seen on Android system apps (and possibly wireless carriers or hardware manufacturer pre-installed apps).
------------------------------------------------------------------------
Write SMS
Services that cost you money
URI: android.permission.WRITE_SMS
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to write SMS messages.
Details
This permission appears to be an offshoot from the "send SMS" permission. This should allow an app to write, but not send an SMS message. Users should still be cautious of this permission however. Many kinds of malware lure users into sending SMS to special for-pay numbers costing them money.
---------------------------------------------------------------------------
Write sync settings
Your messages
URI: android.permission.WRITE_SYNC_SETTINGS
Risk: MEDIUM
Protection level: DANGEROUS
Official Description
Allows applications to write the sync settings
Details
This permission relates to backup and sync of certain types of information like contacts. This allows an app to write settings for how that account and the data are sync and backed up. This is a common permission for social services or contact managers or any other type of app with an account associated with it. Alone, this permission doesn't allow an app access to contacts or other sensitive data. Rather, it just relates to how that data is backed up. Nevertheless, care should be taken as always.
---------------------------------------------------------------------------
Read profile
Development tools / Your personal info
URI: android.permission.READ_PROFILE
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Official Description
Allows an application to read the user's personal profile data.
Details
This a new permission that relates to a special new "Me" contact you can create in your phone or tablet as your own profile.
--------------------------------------------------------------------------
Install Shortcut (Android Launcher)
Hardware controls
URI: com.android.launcher.permission.INSTALL_SHORTCUT
Risk: MODERATE-HIGH
Protection level: UNKNOWN
Details
This is a custom permission for the default Android Laucher (the home screen). This permission would allow an app to put an icon or shortcut there. While not dangerous, this can sometimes be a sign of a potentially malicious or adware app. For more on adware, see the guides section of PocketPermissions.
--------------------------------------------------------------------------
Read external storage
Your personal information
URI: android.permission.READ_EXTERNAL_STORAGE
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows an application to read from external storage.
Details
This permission is granted to all apps by default.
--------------------------------------------------------------------------
Read SMS
System tools
URI: android.permission.READ_SMS
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Details
This permission is mostly a privacy concern. Any app that can read your SMS messages could gather a lot of information about you. However there are quite a few legitimate reasons an app may request this. Some apps are simply "SMS replacment" apps (such as Handcent) and would naturally need this permission to function. Other apps sometimes use this as a way of sending a special code to you device. This can be used by a paid app by sending a code to unlock the full version of an app. Or, this can be used by security apps to listen for a special shutdown codes in case your phone is stolen.
---------------------------------------------------------------------------
Write call log
Your location
URI: android.permission.WRITE_CALL_LOG
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Details
This permission is not much of a danger by itself, but rather could be used to hide other malicious behavoir. However it has a legitimate purpose for dialer replacements or voice over IP apps (like Google Voice).
-------------------------------------------------------------------------
Write profile
Development tools / Your personal info
URI: android.permission.WRITE_PROFILE
Risk: MODERATE-HIGH
Protection level: DANGEROUS
Details
This a new permission that relates to a special new "Me" contact you can create in your phone or tablet as your own profile.
--------------------------------------------------------------------------
Read social stream
Development tools / Your personal info
URI: android.permission.READ_SOCIAL_STREAM
Risk: HIGH
Protection level: DANGEROUS
Details
This permission is very important. It is a new permission introduced with Android 4.0 (Ice Cream Sandwhich). This permission would allow an app to read updates from social networking apps like Google+, Twitter, and Facebook. By granting this permission you are giving an app the ability to read not only your information, but any updates posted by people in your social circles.
----------------------------------------------------------------------------
Add voicemail
System tools
URI: com.android.voicemail.permission.ADD_VOICEMAIL
Risk: MEDIUM-HIGH
Protection level: DANGEROUS
Details
This seems to be a new permission related to Android's new centralized voicemail system. It would be an unusual means for an app to use this permission maliciously. However few apps should need it and, as always, it should be treated with caution.
--------------------------------------------------------------------------
Authenticate Accounts
Your messages
URI: android.permission.AUTHENTICATE_ACCOUNTS
Risk: VERY-HIGH
Protection level: DANGEROUS
Details
This permission is of high importance. It allows an app to authenticate credentials (such as passwords). Typical uses of this would be if an app had it's own type of account on your phone such as Google, Facebook, or Twitter.This permission is closely related to the Account Manager permission. Both are typically requested together.While this doesn't directly give an app access to your personal information or passwords, it does present a security risk for phishing (tricking the user into revealing their password). For more on phishing, see the Guides section of PocketPermissions)
--------------------------------------------------------------------------
Read email attachments
Development tools / Your personal info
URI: com.android.email.permission.READ_ATTACHMENT
Risk: HIGH
Protection level: DANGEROUS
Details
This is a custom permission for the default Android email app (i.e. not Gmail). This permission should be treated with great caution. Many email attachments contain highly sensitive and personal or financial information.
-------------------------------------------------------------------------
Read user dictionary
Development tools / Your personal info
URI: android.permission.READ_USER_DICTIONARY
Risk: LOW
Protection level: DANGEROUS
Official Description
Allows an application to read the user dictionary.
Details
This would allow an app to read words added to your custom dictionary. Oftentimes this is abbreviations like "brb" that you might add for typing text messages. Unless you save personal information in your dictionary, this permission is of almost no risk.
---------------------------------------------------------------------------
Write user dictionary
Hardware controls
URI: android.permission.WRITE_USER_DICTIONARY
Risk: LOW
Protection level: UNKNOWN
Official Description
Allows an application to write to the user dictionary.
Details
This alows an app to add custom words to your user dictionary. For example, the common acronym "brb" for "be right back".
---------------------------------------------------------------------------
Receive SMS
System tools
URI: android.permission.RECEIVE_SMS
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to monitor incoming SMS messages, to record or perform processing on them.
Details
This permission is mostly a privacy concern. Any app that can read your SMS messages could gather a lot of information about you. However there are quite a few legitimate reasons an app may request this. Some apps are simply "SMS replacement" apps (such as Handcent) and would naturally need this permission to function. Other apps sometimes use this as a way of sending a special code to you device. This can be used by a paid app by sending a code to unlock the full version of an app. Or, this can be used by security apps to listen for a special shutdown codes in case your phone is stolen.
--------------------------------------------------------------------------
Receive MMS
System tools
URI: android.permission.RECEIVE_MMS
Risk: HIGH
Protection level: DANGEROUS
Official Description
Allows an application to monitor incoming MMS messages, to record or perform processing on them.
Details
This permission is mostly a privacy concern. Any app that can read your MMS messages could gather a lot of information about you. However there are quite a few legitimate reasons an app may request this. Some apps are simply "SMS/MMS replacement" apps (such as Handcent) and would naturally need this permission to function.
---------------------------------------------------------------------------
Install DRM
Hardware controls
URI: android.permission.INSTALL_DRM
Risk: MODERATE-HIGH
Protection level: UNKNOWN
Details
DRM stands for Digital rights management. Typically this permission is not particularly dangerous itself. However, it is a permission related to controlling access to medi such as books, audio video, and more. Due to its purpose to control access, I would be especially careful installing any app requesting it.More info: http://en.wikipedia.org/wiki/Digital_rights_management
---------------------------------------------------------------------------
Add system service
Hardware controls
URI: android.permission.ADD_SYSTEM_SERVICE
Risk: CRITICAL
Protection level: UNKNOWN
Details
This permission should only be given to Android System apps (and possibly to wireless carrier or hardware manufacturer pre-installed apps)
---------------------------------------------------------------------------
Access WiMax State
Your accounts
URI: android.permission.ACCESS_WIMAX_STATE
Risk: LOW-MODERATE
Protection level: UNKNOWN
Details
WiMax is a technology developed for "4G" data and internet speeds on mobile devices. This permission allows an app to see if it is currently connected to a wireless network that uses WiMax. There is no significant risk associated with this permission.
--------------------------------------------------------------------------
Change WiMax state
Your accounts
URI: android.permission.CHANGE_WIMAX_STATE
Risk: MODERATE
Protection level: DANGEROUS
Details
This permission allows an app to turn on or off the WiMax radio. WiMax is a type of "4G" wireless connection like LTE. This permission essensially allows an app to turn on or off 4G.
---------------------------------------------------------------------------
Read instant messages (IM)
Development tools / Your personal info
URI: com.android.providers.im.permission.READ_ONLY
Risk: HIGH
Protection level: UNKNOWN
Details
This is apermission realated to reading instant messages, such as those on GooleTalk.
---------------------------------------------------------------------------RECEIVE
(unknown group)
URI: com.google.android.c2dm.permission.RECEIVE
Risk: LOW
Protection level: UNKNOWN
Details
C2D stands for Cloud to Device Messaging. This is a push notification technology that is being phased out for a similar technology called GCM. (Google Cloud Messaging). This permission is of little to no risk.
-----------------------------------------------------------------------------
In-app billing
Services that cost you money
URI: com.android.vending.BILLING
Risk: CRITICAL
Protection level: UNKNOWN
Details
This permission is of very high importance. This allows an application to directly bill you for services through Google Play. Users will be required to confirm any purchase made however this is potentially costly. Users should beware of games and other free apps with in-app billing.
------------------------------------------------------------------------
I hope anyone read it for its own safety/knowledge and to understand some things.Many Greeeeetz
-------------------------------------------------------------------------
MAYBE ITS HELPFULL TO MAKE THIS POST STICKY!!!!!!

Nice thread dude too much usefull :thumbup:
I also think this should be stiky thread but not here but in every android forums
Sent from my GT-S5360

I think this wud b more helpful in the apps forum !
nice compilation though
Sent from my GT-S5360 using xda app-developers app

Related

OK, time to give this subject its own thread. You can read about previous efforts here: http://forum.xda-developers.com/showthread.php?t=1113066. In particular, http://forum.xda-developers.com/showthread.php?t=1113066&page=11 is where I started.
Background: the policy database is essentially the Access Control List (ACL) store for WP7. ACLs are typically attached to objects (files/folders, registry keys/values, drivers/services, possibly even APIs). When a process tries to do something, the OS uses the process's security identifier (called a "Token", it identifies the account running the process and therefore the permissions that process has) and looks up the ACL specific to that operation. If the ACL authorizes that account to perform the operation, the kernel permits it. If not, it blocks the operation and indicates an error (most famously on WP7, 1260 or 0x4EC, meaning blocked by policy). For some OSes, like NT, that attachment is in the metadata which describes the object (for example, NTFS stores ACLs for each file and folder). Apparently, WP7 uses a centralized database of ACLs, stored as "policies", instead.
Why I'm doing this: the policy database is the key to fully unlocking the phone. I mean that literally; "full unlock" ROMs achieve that state by basically turning off policy enforcement. I don't necessarily want to do that - at least not phone-wide and constantly - but I want to be able to set my own policies, and possibly modify existing ones.
What can be done with it: well, one example is the subject of the thread I linked above: homebrew native EXEs require first being able to add policies for them. There are some other cool possibilities, like turning off ID_CAP_INTEROPSERVICES enforcement or allowing apps to write to the MaxUnsignedApp registry value directly. That gets around the risk of phones being re-locked and unable to interop-unlock again. Basically, it allows an app to do anything short of modify the ROM.
Purpose of this thread:
* Provide a central location of information about the policy system, policy database, and creation of custom policies.
* Collaborate on the project of understanding and modifying the policy database and policy system overall.
* Share interesting policies we've found in the database, or post custom policies that can be added to enable a cool hack.
* Discuss and share ways to preserve, going forward, our control over the policy system.
There has been concern raised that this work should not be mde public, because Microsoft will look at what we are doing and use that knowledge against us. There is some validity to that argument; if the work is done in secret, and any files posted that use the fruits of that work are heavily obfuscated, it would probably take Microsoft a little longer to block it if they decided to do so. Not terribly *much* longer though, I suspect - they have many tools at their disposal, full source code and documentation, and full understanding of the system in their engineer's minds. Any hack we find, they can reverse engineer or simply block access to whether or not they can read a thread about it here on XDA-Devs.
There's also the risk of malware. Malicious homebrew apps could abuse this knowledge to do serious damage to your phone, to steal info, and possibly even for direct financial effect (send premium SMS, for example). However, I see no real way around that problem; it's an inherent risk of unlocking a device. The simplest and best step to combat it is to not install untrasted apps, and the best way to be sure an app is trusted is to be able to analyze it. (This is one of the reasons I include the source for my apps, and encourage others to do the same.) Besides, it's already possible to do plenty of damage with existing homebrew hacks, yet somehow that problem hasn't materialized.
So, instead of secrecy, I propose openness. The best option we have to offset Microsoft's tools, knowledge, and source code is to collaborate, pooling the knowledge and effort of many hackers. If people want to keep certain things secret, by all means use email or PMs. In general, though, I think the failure to spread knowledge does more harm than good.
OK, that turned into a long enough intro that I'm going to post my first actual findings in a reply.

Policy-related files
There are actually two databases: one is for policies, and one is for accounts. They are located in \Windows\Security\ and are called policydb.vol and accountdb.vol. These files are locked (opened without sharing permitted) while the OS is running. There are two additional files in this folder: PolicyMeta.xml and PolicyCommit.xml. These files can be accessed using provxml, TouchXplorer, WP7 Root Tools, or HtcRoot Webserver.
The PolicyMeta XML file contains macros describing accounts, and metadata about the policies in the database. In particular, it contains a large number of bit masks that indicate different permissions. By itself, this file doesn't tell us much of use, but it will be a big help for understanding binary data in the the database. It's small and not commented, but easy to read.
The PolicyCommit.xml file contains the merged result of combining all the policy files on the phone. I don't know if anything actually reads this fine, but it's a nice human-readable (and searchable) view of the data that goes into the policy database. It contains a number of comments, but most are just where the various policies were merged from. It is the largest file.
The policy database file ("Volume" to use the term of the CEDB APIs) itself is large-ish (mine approaches a megabyte) and contains three CEDB databases. The first is a small single-record "database" (in SQL you'd call it a table) that appears to be used for transaction locking. The second is a single large record (several KB) that appears to be a bloom filter (Wikipedia has a pretty good article, the short version is that it is a quick and compact data structure for checking whether a given item is in a collection). The third database (named "PatternDBmultimap") is the real deal, containing thousands of policy records.
I haven't looked at the Accounts database much yet. It's smaller than the Policy database volume, but still a few hundred KB. A substantial portion of that is probably custom accounts created for each app that is installed (since each app has different permissions - specifically, each app has read and write access to a different set of folders - there must be a unique account for each).
The policies appear to come from a few sources. One of them is the many *.policy.xml files (the first part is usually a GUID) in the Windows folder. These files are locked in ROM, and define the core system policies (system accounts, permissions for system objects, etc.). The \Windows\Security\PolicyCommit.xml file (which is not in ROM, or even marked read-only) appears to be simply the result of merging all these files.
Another source of policies must be the application installer. Application-specific polices are not present in the PolicyCommit.xml merged file, but are in the database itself. It is reasonable to expect that they are created and removed by the package manager. This is a good sign for being able to modify policies ourselves.
The initial creation of the policy files appears to be up to a program, \Windows\PolicyLoader.exe. This program takes policy.xml files, merges them, and produces the merged result file and the policy database(s?). It's even possible to run it, given sufficient permissions. Unfortunately, it seems unable to modify the policies on a running device, and is believed to only run at first boot (or after a hard reset) or when an update CAB installs new policy XML files.
EDIT: Attaching the \Windows\Security\*.xml files from my phone, along with the decompiled source for PolicyLoader that was posted on the other thread.

The LG MFG app has a section for editing certain security policies. I can post the info from there, if it'd be of any help. By the way, it specifically says "Edit security policy through registry" so it might not be the same policies that you're talking about, I don't know.
EDIT: Actually, looks like those policies are a subset of the ones listed here: http://msdn.microsoft.com/en-us/library/bb416355.aspx

Analysis of the policy database
I wrote a function to dump the policy database to a text file (with inevitably some embedded binary). Each record in the database has four fields. I'll do my best to describe them below.
1) The first is a DATETIME struct (two 32-bit integers). This is the only 64-bit numerical type available except for a DOUBLE, so it might be selected just as a convenient way to store that many bits rather than because it's actually a date and time. In particular, when I converted them to actual dates and times, the years ranged from the 1970s well into future centuries... this seems an unlikely candidate for an actual set of dates.
What I think it actually is, is some kind of hash of the second field. It might be the index bits for the bloom filter, for example. The reason I think so is that, when there are multiple records with the same value in the second field, they also have the same value in this field, but even a slight difference in the value of the second field results in a very different first field.
This field is not unique, but it does appear to be the default sort order for the database. I don't know if that's ust because it's the first field, but it would make sense to have it be indexed using this field for fast lookup (binary search) after the bloom filter finds that the item is (probably) present.
2) This field is a binary BLOB struct (a size and a pointer). This field contains Unicode strings, sometimes with a bit of binary data (small, typically less than 20 bytes) tacked on the end. Strings plural; each one is NULL-character terminated.
This field appears to be the paths that indicate the object (or objects, since it can contain wildcards) that the policy applies to. If there is a policy in the XML for ResourceIri="/REGISTRY/HKLM/SOFTWARE/MICROSOFT/CAMERA/READWRITESETTINGS" then there will be a record in the database with the second field that would be written like this in C source code: L"REGISTRY\0HKLM\0SOFTWARE\0MICROSOFT\0CAMERA\0READWRITESETTINGS\0". I'm not sure what the occasional binary afterwards means, although there appears to be a specific value for a wildcard (represented in the source XML as ResourceIri=/PATH/WILDCARD/BASE/(*)", but the last part doesn't translate to Unicade the way you'd expect).
As mentioned above, I'm pretty sure that the first field is related to this one. Since the value of a bloom filter on this database would be to quickly establish "Is there a policy for this object?" it makes sense that the path (second field) is the data that gets hashed to produce the bits of the key. It's not really required to then store the key bits, but they make a reasoanble value to sort on.
3) The third field is also a binary BLOB, but the value of it is much more opaque. Typically in the range of 50-300 bytes in length, there are certain patterns that I've noticed within it (0x01 00 01/02 00 65 is a common prefix, and they typically end with 0x00 3X) but I have not yet determined what they actually represent.
Some logical possibilities are an account identifier (though that seems needlessly long for such a purpose) or possibly the permissions data directly. When the second field has a path to related objects (for example, the isolated storage of an application), the third field is often similar as well.
4) The fourth field is another DATETIME struct, but in this case is obviously not an actual date value. The high four bytes are (almost?) always 0xFFFFFFFC, and the low four bytes are typically 0x0000XXXX where the Xs can be anything. This value is not unique - there are numerous instances of 0xFFFFFFFC00000001, for example - but I'm not yet sure what it is.
The same guesses I offered for field 3 apply as well, with the caveat that it's probably not just a different representation of field 3 because two records can have the same value on field 4, and their field three values may not only differ, but be different sizes. I need to look at the XML files and see if there's a pattern between policies with the same field 4 and an equivalent data item in the XML.
I'm attaching the dump file I created of the policy database. It's best opened in a hex editor (Visual Studio does well enough) although you can also use Wordpad (Notepad won't respect the line endings). Wordpad can't show you the binary, of course, but it's a readable layout of the data.
The format is as follows:
ASCII string: "Index "
ASCII representation of an Integer for the index.
ASCII string: ": Prop0 (FILETIME): 0x"
ASCII representation of the DateTime, with a space between the high and low DWORDs.
ASCII string: " | Prop1 (BLOB, "
ASCII representation of the blob's integer size.
ASCII string: " bytes): "
Direct dump of the second field's BLOB buffer (multiple UNICODE strings).
ASCII string: " | Prop2 (BLOB, "
... and so on. I intentionally used ASCII to make the direct memory dumps, which are in UNICODE for the second field at least, stand out.

@Arktronic: Interesting. Those policies (in the registry) are a legacy holdover from WinMo, and at least some of them have been superceded by the new policy system, but the fact that LG gave them specific mention in their app suggests that they still have some relevance.
However, you're correct that those aren't the policies I was speaking of elsewhere in the thread. It may be a good idea to explore them both in parallel, though. Which ones does the LG app list?

Arktronic said:
The LG MFG app has a section for editing certain security policies. I can post the info from there, if it'd be of any help. By the way, it specifically says "Edit security policy through registry" so it might not be the same policies that you're talking about, I don't know.
EDIT: Actually, looks like those policies are a subset of the ones listed here: http://msdn.microsoft.com/en-us/library/bb416355.aspx
Click to expand...
Click to collapse
We already did some testing with those policy settings, but the ones granting more access were not available and the others could not get the app itself into an "unsafe" mode. But then again, I'm far from a professional when it comes down to these things, I just crossreferenced them all against the MSDN DB and looked for the ones that would make fileops possible, no luck.
I'm not sure if they added policies to the LG MFG app in the meanwhile (unlikely) but it might be worth it to investigate how the MFG app modifies those select policies.

GoodDayToDie said:
@Arktronic: Interesting. Those policies (in the registry) are a legacy holdover from WinMo, and at least some of them have been superceded by the new policy system, but the fact that LG gave them specific mention in their app suggests that they still have some relevance.
However, you're correct that those aren't the policies I was speaking of elsewhere in the thread. It may be a good idea to explore them both in parallel, though. Which ones does the LG app list?
Click to expand...
Click to collapse
The latest ROM's MFG app has the following policy IDs: 4104, 4105, 4108, 4109, 4110, 4111, 4113, 4119, 4120, 4121, 4124, 4131, 4132, 4141, 4142, 4143, and 4149.
The last one isn't in the MSDN doc; it calls itself "FIPS Self Test Policy" or SECPOLICY_FIPS_SELF_TESTS.
There are potentially useful things like SECPOLICY_OTAPROVISIONING (4111), which has the value of 3732 - no idea which flag(s) that represents - but if there's a way to send provisioning messages to WP7, that might open up quite a few possibilities.

I believe there's at least a chance for OTA provisioning. Sending custom SMS appears to be possible (click around from the link):
http://msdn.microsoft.com/en-us/library/ee498239.aspx
That said, it's almsot certainly either secured or disabled by default.

Hmm... does anybody want to take a shot at getting a decent decompile of lvmod.dll? I don't have the tools, though I probably should. Reading the disassembly is slow and painful.
I've found a few new things:
It's possible for two records to differ *only* on the third field, and even then the binary was more alike than not. Look at indexes 12 and 13 in the dump - they're really similar. They are built from the following policy rules (no promises on order):
Code:
<Rule PriorityCategoryId="PRIORITY_HIGH" ResourceIri="/REGISTRY/(*)" SpeakerAccountId="S-1-5-112-0-0-1" Description="TCB can do anything to all registry keys">
<Authorize>
<Match AccountId="S-1-5-112-0-0X02" AuthorizationIds="KEY_ALL_ACCESS, KEY_READ, KEY_WRITE, KEY_EXECUTE, GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE, GENERIC_ALL, DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER, SYNCHRONIZE, STANDARD_RIGHTS_REQUIRED, SPECIFIC_RIGHTS_ALL, ALL_ACCESS" />
</Authorize>
</Rule>
Code:
<Rule PriorityCategoryId="PRIORITY_LOW" ResourceIri="/REGISTRY/(*)" SpeakerAccountId="S-1-5-112-0-0-1" Description="Catch all rule to allow Normal and above apps to read/write to all unnamed keys">
<Authorize>
<Match AccountId="S-1-5-112-0-0X23" AuthorizationIds="KEY_ALL_ACCESS, KEY_READ, KEY_WRITE, KEY_EXECUTE" />
</Authorize>
</Rule>
I would have thought that either the different permissions being granted, or the different accounts they were granted to, would result in a different fourth field... but no such luck. Time to look into this further.
The accountdb.vol file has two databases in it, GroupMemberships (1105 records on my phone) and Accounts (291 records). The latter is actually much bigger in terms of data size, though - 70KB vs 31KB for GroupMemberships. The records in GM must be very small, probably just pair mappings.

Hey GoodDayToDie,
Awesome job on sharing all this low level findings from underneat the hood of my favourite mobile OS. While i'm not capable of researching this myself due to lack of knowledge I love to read about how you (and other well known WP7 hackers as well of course!!) tackle the security and are willing to share this with the community to combine power. I think threads such as these are really necessary to get to the finish. Keep up the good work, i've got a strong feeling we will get there eventually .
THANKS

Looks to me like this is the policy database.
Here is an example set of policies that enable/disable tethering on the Arrive.
Is shows the values needed to create/add a policy to the policy database. HTClv.dll shoudl be able do set/modify these values using "LVModProvisionSecurityForApplication"
You may already know this, but figured I would share.
Also, HTC has regedit.exe and HTC uses it to provision/make registry changes.
I will attach the regedit4 file HTC uses to configure the radios.
This also defines where the key UserProcGroup defines the TCB chamber a driver runs under. see... "UserProcGroup"=dword:5 ; TCB chamber
Seems with using the registry editor, we could elevate any driver to the Kernel chamber.
See attached....

Thanks for the info Paul!
I've heard of the "LVModProvisionSecurityForApplication" API before, yes, and it might be possible to use it here (*really* depends on how it works; if it just reads the app's manifest file like the normal XAP installer does, that's not very useful). LVModAuthenticateFile, LVModRouting, and LVModAuthorize may be extremely useful, though. It also might be helpful to try reverse-engineering how it interacts with the policy database.
The weird thing is, I don't have any htclv.dll or htcpl.dll on my phone, at least not in the \Windows folder. Perhaps they were removed in an older firmware update? It certainly sounds like they would provide the APIs I need - only for HTC phones, true, but they would provide.
The policy.xml file is the standard format read by PolicyLoader.exe, but that doesn't really help unless I can convince PolicyLoader to modify the ploicy database on a running phone.
Elevating an (already installed) driver to TCB might be useful (although I'm not certain that LVMod route-to-chamber rules wouldn't interfere) but all the useful HTC drivers are already in TCB, and installing any more drivers... well, I haven't been able to make that work yet, even old versions of official drivers with the necessary changes to the DllName in the registry.
It's really too bad you can't join in on hacking this stuff though, you've got the right ideas. Do you by any chance have a NoDo restore point you could downgrade to in order to try out some stuff on the old firmware?

Dumped the account database
Turns out the account info is quite straightforward. There are four fields per record.
0) String - the SID ("S-1-5-112-0-0X10-0X00000024").
1) Int32 - 0 for accounts, 1 for groups.
2) Int32 - always 0 on my phone.
3) String - account or group name ("TCB" or "ID_CAP_FILEVIEWER:Capability for hybrid file view app such as PDF reader etc." or "Settings3.exe Chamber" or "9BFACECD-C655-4E5B-B024-1E6C2A7456AC").
Not sure why the third field is there if it's always 0, but OK. The first and last were obvious, and the second was easy to infer. The last record has no fields, and the three immediately before it are without a fourth field; not sure why. All three are groups, and their SIDs are:
S-1-5-112-700-4160
S-1-5-112-700-5132A485-ADEE-5842-9490-856FFFFF2D6D
S-1-5-112-700-A22CF327-25C3-DB2A-A8DF-7BE586F11FBD
This database contained no binary blobs, so the dump file is plain ASCII text (the strings were originally Unicode but converted to ASCII gracefully). In the interest of making it easier to analyze, I ran a quick pass over the dump with sed and produced a CSV, which is attached.
Then, there's the GroupMemberships database. I think this one is probably less important for our concerns, but I wanted to take a look anyhow. It's the simplest so far, though that's not necessarily good. Each record has two fields, and both are just 32-bit ints.
0) Ranges from 0x30000006 to 0x3F0004A6, though the the third through fifth hex digits are always 0. Includes duplicates.
1) Ranges from 0x31000008 to 0x3100007A, then from 0x32000380 to 0x3200038C. Includes duplicates.
The mappings appear to be many-to-many (each account in multiple groups, each group holding multiple accounts) as expected. I'm guessing the first column is accounts and groups, and the second is the groups that the account or group belongs to. Given that some values appear in both columns (through in different records), I'm guessing nesting of groups is allowed.
I dumped and CSV-d this database, and it is attached as well. Ideas as to what's up with it are welcome too.

Hi all,
I came across this article which explains how malcious code can be pushed on our android phones through malicious ad networks.
I will only highlight the important points and include the countermesaures which I think we can use to atleast avoid/prevent this type of malware.
1) Ads displayed within mobile apps are served by code that's actually part of those applications.
2) Application owners typically include SDK's in the application for various ad network's.
3) Not all developers verify the Ad network and if the developer does not care or simply goes with the highest bidder, then the chances of siding with a malicious ad network are high.
4) If an ad from a malicious network is displayed it can push malicious payload which runs quietly in device memory.
5) Detection by AV's can be difficult as this runs in memory and android AV's mostly verify the apk's only.
Not so good thing:
This is a very elegant approach that doesn’t really require the end-user to do anything “wrong”.
The user could download a valid application from a valid app store, and ultimately be silently infected by a disreputable ad network
--
Countermeasures:
1) Do not install applications from untrusted sources. This is configured by default under :Settings->Security->Device Administration->Unknown Sources.
2) Always verify the permissions the application is requesting.
3) Rooted phones can utilize applications like AdAway which simply block all traffic to known ad networks. (Make sure you update it frequently).
4) Av's help in atleast verifying the apk's and there are applications to detect adnetworks like (Lookout,Symantec,TrustGo Ad detectors, etc).
If I get some time, I will try to get list of known malicious networks so we can manually add them to our host file and block all traffic to these networks.
I know these networks are dymanic but blocking can be helpful even for a short time.
If you think there are more better ways to prevent/detect this then please share and benefit the community.
References:
http://researchcenter.paloaltonetworks.com/2013/08/mobile-devices-new-malware-and-new-vectors/
http://www.businessinsider.com/malware-in-mobile-advertising-2013-8
http://www.google.com/ads/admob/monetize.html

Hi, guys, I've launched security testing service (hackapp.com) for mobile apps, which can download and analyse (static) app right from store (iTunes or Play). It can be useful for security-concerned developers, information security officers and bughunters.
Mission is to create security testing tool, which
- Informs developer about actual problems and fixes, without huge mind blowing listings and traces
- Doesn't require any maintaining environment on developers side
- Can be simply added into development cycle, like "Yet another testing tool"
Current version performs static analysis and identifies critical and suspicious information in bundle:
- Certificates and keys
- Authentication secrets
- License Control
- Compilation flaws, and other.
Known Bugs:
- It can't download paid apps
- It can't download apps restricted for regions (iTunes)
- It can't download apps restricted for devices (Play)
I hope you'll find it usefull and I'm counting on your feedback
You can read more about it hackapp.com/about or in blog blog.hackapp.com

Please take a moment to read through this before posting, not only is a brief description of NFC and some of its uses included but also you will find a few of the more commonly asked questions. Over time these will be added to accommodate new or recurring queries that are being seen in this thread. If you have come to the thread to ask about emulating, copying or bypassing your Mifare card head down to the FAQs below .
What Is NFC
Near Field Communication (NFC) is a technology that was built upon Radio Frequency Identification (RFID). It allows for the storage of data without the need for a direct power supply. When a reader such as a NFC enabled phone comes within range (usually an inch or less) data can be read/written from/to the tag.
Objects containing NFC can be found in two varieties, active or passive. Passive devices are ones that contains data but do not read and generally will not have their own power supply. These are found in NFC tags such as those in Credit/Debit cards, Student or ID cards, Library books and passports among many. For a much larger of scannable objects see here. Their are also active devices, these can read information stored on other NFC devices and for the majority of us here these will be our phones. These active devices can also usually alter the data found on tags or transmit/exchange data with other active devices.
Uses for NFC
NFC has many uses both commercial and on a development/hobby level, here are just a few:
Contactless payment
Transfer of data from phone to phone
Share and log on to WI-FI
Sharing contact information
Automating tasks
Storing bitcoin wallets
Disabling alarms
Send Wake-On-Lan commands
FAQs
How can I emulate, copy, edit or bypass my Mifare card (student ID, work ID, Bus pass etc)?
The short answer: you can't
The long answer: There are numerous reasons why you may have had issues finding this information on XDA. Primarily because it is not possible from the vast majority of phones and for good reason. Mifare as mentioned above is a security layer for NFC cards and therefore the process isn't as simple as just downloading an app, scanning a security card and then forgetting about it. Secondly depending on the type of tag you are trying to use this is either A) illegal or B) against your companies, service provider, school's security policy and as such you will not find this information on XDA.
Your options from here are: look elsewhere for this information, just use your card as instructed or speak to your IT department about adding another form of NFC tag to the system, I for instance have an NFC tag implanted in my hand which my IT department was more than happy to add to my user profile at university. More information on this can be found here.
Click to expand...
Click to collapse
How can I hack my Bus pass, Oyster card etc to add more credit or extend its expiration date?
See the answer above ^
Click to expand...
Click to collapse
How can I unlock my Android phone using NFC
See "NFC LockscreenOffEnabler" for Xposed
Click to expand...
Click to collapse
How can I make Android trigger an event when I scan an NFC tag?
For simple commands you can use apps such as NFC Tools or Trigger.
For more complicated tasks a combination of Tasker and Locale can be used to launch just about any chain of events upon finding a specific tag. Of course alternatives do exist, so be sure to check out a few of the other projects around the site
Click to expand...
Click to collapse

Hey guys,
I am a web developer and decided to create a mobile application for Android and iOS using Phonegap. Creating the graphical interface isn't a problem, but somehow I need to store 2 tokens and a username (the app receives data from a server and somehow the user has to be authenticated. So the tokens and username get posted every time I request some data from the server). My question: I already heard about localstorage - is this a secure way to store the tokens? A https connection is available, so man-in-the-middle isn't possible. Localstorage is sandboxed, right? So there should be no problem to simply store it in this way. Or am I missing something? I already thought about encryption, but to be honest: Javascript and encryption don't make sense as you would need to somewhere store the secret and in this case it would be directly inside my JS file...
Thanks for your help!

Yes, localstorage is sandboxed so each app will have it's own dedicated space to avoid variable clashes. Though it's by no means secure in the sense that it's relatively easy to view it through external means.
As far as encryption in javascript, this depends on how secure you need it to be. Properly obfuscated JS is almost as difficult to reverse-engineer as Java byte code (though still quite doable if someone is determined enough).
To be more secure you would need to get the user to enter a password/passphrase at the beginning of each session which is only ever stored in memory and used to decrypt the data stored in the local storage using a decent open source encryption library. In this case access to the JS won't be a problem.

You need to define what types of threats you are trying to protect from. Traffic between your device and the server is protected from sniffing and tampering by HTTPS, so no problems there. But all that is local on your device could be examined, reverse engineered, and altered by the owner: local storage, encrypted or not, traffic between app and Android OS, data in RAM memory, etc. I would trust regular web component security features (cookies+HTTPS), as it is considered safe for things like online banking. But I don't think there is a way to protect data from the owner.