Showing posts with label android. Show all posts
Showing posts with label android. Show all posts

Sunday, October 29, 2017

Threema - white paper

Latest white paper Sept 2017

https://threema.ch/press-files/2_documentation/cryptography_whitepaper.pdf

Threema-iTunes
 
Threema is the world’s favourite secure messenger and keeps your data out of the hands of hackers, corporations and governments. Threema can be used completely anonymously, allows to make end-to-end encrypted voice calls, and offers every feature one would expect from a state-of-the-art instant messenger.

Useful for running lab tests.
https://itunes.apple.com/gb/app/threema/id578665578?mt=8

Wednesday, June 28, 2017

IM Telegram Replay Attack - Android

Hopefully, readers will have had the opportunity and time to read about WhatsApp here at the trewmte.blogspot:

WhatsApp network forensics - http://trewmte.blogspot.co.uk/2017/06/whatsapp-network-forensics.html
Whisper Signal WhatsApp - http://trewmte.blogspot.co.uk/2017/06/whisper-signal-whatsapp.html

So it's time to move on to the next instant messaging app known as Telegram. It is relevant to mention this app at this time as it appears the Russians are targeting this app as well -
http://www.bbc.co.uk/news/world-europe-40404842 - and the thought must be what will they discover by way of a flaw or vulnerability or do they what they are already?
 
The IM Telegram Replay Attack - Android uncovered from the following research published in Tomáš Sušánka thesis can be found here:  https://www.susanka.eu/files/master-thesis-final.pdf .
 
As a primer, a replay attack is an attack where an attacker sniffs data sent by the application and then resends them at a different time with a malicious intent. Unlike WhatsApp where all accounts are controlled by source; Telegram relies upon some third party developers to implement security updates that Telegram has informed them about; if developers don't update after that many devices using Telegram could be unsafe even today potentially enabling attacks across networks.
 
Deobfuscator.cpp file
 
To gain a background understanding to IM and security related issues the thesis considers other IM apps, including WhatsApp, and noted security issues with them.
 
One interesting comment noted in a paragraph in the conclusion reveals the influences foreign policy subjects itself on software developers regarding censorship: "We have scrutinized the code base of the official application for Android and concluded that the state of the application is at serious odds with the documentation. This concerns mainly the undocumented obfuscation method Telegram uses. The MTProto traffic is encrypted one more time with the key and IV prepended to the data. This has no effect on the data security and is easily debunked by the deobfuscation program we have implemented. When the Telegram team was confronted with these claims, they noted the method is used to circumvent some of the less sophisticated methods of censorship in certain countries."
The author's research relating to apparent Telegram vulnerability, that has been published, he has also provided his background research e.g. source code etc., (so you better get it before it goes) https://www.susanka.eu/files/master-thesis-cd.zip :
 
CD's directory structure is:
-  data
- Telegram source code
-  src 
- Telegram Deobfuscator
- Telegram Extractor
- Trudy Go module
- LaTeX source codes
- diagrams
source codes
- text
- appendices
- thesis.pdf
Excellent research and discovery!
 

Sunday, April 02, 2017

Crime: Base Station Monitoring and Regular Stress Tests

Photo courtesy of the Macau Post Daily

There is no shortage of police investigations, articles and reports into cellular technology being used for some sort of illegal purposes, and that is beyond the normal seizure of mobile devices in criminal proceedings. The recent prosecution of a construction worker, reported (10-03-2017) in the Macau Post Daily, running not one but two fake base stations, is such an example.

Whilst there is a huge effort to deal with Cybercrime attacks over networks, there is a growing emphasis suggesting that more attention could be focussed to actually dealing with physical devices creating the cyber activity behind the crime.

On the 22-03-2017 Information Age website reported Chinese cybercriminals sent Android malware via fake BTSs ( http://www.information-age.com/chinese-cybercriminals-use-fake-telecom-stations-spread-malware-123465203/ ). The report was also mentioned at a number of other websites ( http://thehackernews.com/2017/03/rogue-bts-android-malware.html ;  https://blog.knowbe4.com/chinese-hackers-use-fake-cellphone-tower-to-spread-android-banking-trojan and so on). Blog.knowbe4 added useful information content beyond Information Age's report that the malware was involved, but identifies the malware as attack called "Smishing"; a subject mentioned here at trewmte.blogspot.com previously back in 2015 ( Smishing Maybe Smashed, but Fake Tache Goes On  - http://trewmte.blogspot.co.uk/2015/04/smishing-maybe-smashed-but-fake-tache.html ).

It isn't clear from these reports as to what is actually meant by 'fake BTSs'? Are the attackers merely hacking the network exploiting (S3000688) MAP security and getting hold of authentication vectors to mount a false base station attack?; maybe this is a man-in-the-middle attack using a false mobile BTS? (3GPP TS 21.133); using mobile redirector techniques for Android smartphones opening the SMS text message link to download the '.apk'; or whether a false physical tower has been erected on land through which the attacks are made?   If the latter is correct, there is more involved with this than anonymously hiding in the background. For a false physical tower to happen either the attacker/s might 'hijack' equipment on an existing tower?; add new equipment to an existing tower?; or land-base a whole new tower? The latter is possibly the most improbable to happen without the attacker/s needing new landline connections, microwave, RF and electrical power facilities, cabinets, cabling, tower rig, antenna/TRXs, etc. etc., something that resembles a cellular tower in order to get a smartphone to use its rogue radio coverage.

How can a mobile network operator deal with this? It largely depends how well the operator knows its own installation base and how regularly the operator OMC (operations and maintenance centre) and site visits are co-ordinated for stress testing. Those co-ordinated tests may need to take into account site inventory inspection across a wide range of components. For instance, has the operator sufficient information of Inventory of components for each site? One example being the Antenna Interface Standards Group (AISG), which has been around for many years, its members count amongst some of the leading global players in this arena ( http://www.aisg.org.uk/ ):

Membership of the Group at 1st May 2016

Ace Technologies Corp.
Kathrein Werke KG
Amphenol Antenna Solutions
KGP Tech Co. Ltd.
China Mobile
KMW Inc.
Comba Telecom Systems Int'l
Nokia
Commscope, Inc
NXP
Communications Components Inc.
Orange / France Telecom
Ericsson AB
Oriel Laboratories Ltd
Galtronics Corporation Ltd
Radio Design
Gammanu Inc
RFS Inc
Gemintek Corporation
RFM Wireless
Gemtek Technology Co. Ltd.
Rosenberger Asia Pacific Electronic Co. Ltd.
Guangzhou Sunrise Telecoms Equipment Co Ltd
SGC Technologies Inc
Heji Co Ltd.
Shenzhen Haina Telecom Equipment Co Ltd
Huawei Technologies Co Ltd
Shenzhen Tatfook Technology Co Ltd.
Innertron Inc
Sunsea Telecommunication Co Ltd.
Innova Telecommunication Co. Ltd.
Sunwoo Communication Co Ltd
Jiangsu YaXin Electronics, Science & Technology Co Ltd
Wuhan Hongxin Telecommunication Technologies Co. Ltd.
JMA Wireless LLC
Tongyu Communications Equipment Co Ltd
Kaelus Pty Ltd
Westell, Inc.
  
The following companies are members of the Ancillary Equipment Group
Amphenol-Tuchel GmbHRecodeal Interconnect System Co. Ltd.
Franz-Binder GmbHSam Woo Electroncs Co. Ltd.
Guangzhou Huafeng Qiwang Electronic                               Technology Co. Ltd.Syskim International
Lumberg Connect GmbH

Furthermore, the obvious site checks, such as, break-in to an external cabinet or site equipment room, checking CCTV and trip alarms should normally be examined against regular site visit logs and also time-to-site and time-at-site. Checking fault management, configuration management, performance management & Security Management ports and panels at site to see if they have not been tampered with to disguise normal operation is another consideration. There is a full range of security measures at site and network stress tests that can be performed.

Regulators may wish to assess the security breach with an operator and see if an industry-wide practice is involved selling equipment on the merits on merely the forecast of Total Cost of Ownership and Return On Investment as opposed to an assessment of the person/organisation buying equipment? Another assessment might be to considered reports of stolen equipment and marking of components etc.

It isn't difficult to imagine more cases like the above could occur but it doesn't mean it will; and doom and gloom is not the note this discussion is going to end. Think about all of the towers and base station installed around the world and the customer-base they serve. The mobile network operators provide an amazing service delivering trillions of calls, communications and other services annually. It is a testament to their predominantly well run mobile networks that they operate that the majority of users will not be talking in terms of throwing in the towel and ditching their mobiles tomorrow for landline telephones because of these crime reports.

Finally, India's state-owned quality control agency, Standardisation Testing & Quality Certification (STQC), has started ( http://economictimes.indiatimes.com/news/company/corporate-trends/india-to-start-screening-imported-telecom-gear-from-april-2017/articleshow/56054263.cms ) screening of all mobile network components, feature phones and smartphone under the requirements of National Security. This may pave the way for other countries without such a screen procedure to adopt a similar model.

Friday, September 02, 2016

Smartphone Platform Leader

According to Statista Android is the undisputed smartphone platform leader. Of course, a single identified platform does not of itself identify which of the Android OS versions is used more than any other. Wikipedia Android version history states Android Lollipop 5.0-5.1 ( https://en.wikipedia.org/wiki/Android_version_history ) is the single most widely used Android version.

Additional information about Android - https://en.wikipedia.org/wiki/Android_(operating_system)

 
In comparison the above chart illustrates a decline in all other platforms. This again tends to suggest not dismissing other smartphone platforms until identified what they are ( https://en.wikipedia.org/wiki/List_of_mobile_software_distribution_platforms ) and identifying other smartphone OSs ( https://en.wikipedia.org/wiki/Mobile_operating_system ), which can assist forecasting how to structure the investigation process and what examination lab tool/s is/are most likely to be required.

Sunday, July 05, 2015

USB2USB File Management

Now here is a brilliant design highly lauded by the design media back in 2012/2013 that for some reason has yet to see the light of day. Which is a pity really as this has the potential to provide the answer to a number of student final year project ideas. For instance:

[Idea by Kkie21] "I was thinking about writing a program that would be put onto a USB stick and then once connected to a android device it will forensically image it. Everything will be placed on the USB stick which will be write protected once the data is copied."

There had been the suggestion that a USB stick has no screen thus making it difficult to see any form of displayed comparison between DUT storage device and recording device transferred data etc.

I had suggested "Before you give up on your idea, are you are willing to compromise on your physical device?

ChipDrive from Towitoko has previously been used for mobile SIM Card reading. Maybe check with the company to see if they have a USB version. If so then this would be a GUI sufficient to display commands, icons and/or progress indicator. Also there are control keys around the edge that could be used for stop/start etc.

As mentioned above, this device has been used previously and programmed for reading and writing in fields other than time keeping and SIM card reading.

Have a look and see whether it meets your 13-weeks project management schedule.

http://www.chipdrive.de/index.php/en/smart-card-solutions/time-tracking-solutions/chipdrive-time-recording-kit.htm"

However, when I look at this prototype design below and the ability of USB2USB to connect with varying interfaces, user navigation buttons and screen etc etc could make this product, subject to spec, suitable for the above project idea. I really like the design of this product.

- 3 millimeters thick
- fits easily into your wallet
- equipped with an OLED touchscreen
- SD card slot
- 2 USB connectors.

[*Yankodesign said] This device reads most popular types of external memory cards and flash drives. Users only need to plug in the external cards or flashdrives to view the files and folders. Then they can browse the contents of the USB flashdrive and a preview of the selected file will be displayed on the background of the touchscreen display. The files can be transferred or copied by using its drag-and-drop function. The USB connectors, which come with flexible rubberized wires that integrate with the shape of the device, are detachable when in use. This device can be charged directly using the USB connector.








Designers: Saharudin Busri, Mohd Nizam Najmuddin, Mohd Rohaizam Mohd Tahar, Nuzairi Yasin, Nazjimee Amat Omar - MIMOS Berhad http://www.mimos.my/

*http://www.yankodesign.com/2013/01/02/usb-2-usb-and-more%E2%80%A6/

Saturday, April 04, 2015

Android Botnet for SMS

Another area where SMS text messages may not have received as much scrutiny is regarding messages sent by mobile botnets. If I may I will re-emphasise the following point, the purpose of the discussions here and below are not as a criticism about tools or processes that are used in extracting, harvesting and/or treating recovered data but that data analysis is still required and cannot be rushed. If the examiner doesn't perform the analysis task does the officer or investigator (who may have considerably less experience) left to perform that role?

To avoid confusion a starting point about reference to botnets is required. One contribution is this intro into botnets: https://www.usenix.org/legacy/event/leet11/tech/slides/xiang.pdf 

The video below shows how one hacker, Georgia Weidman (2011), developed an Android Smartphone Botnet to send SMS text messages.




A brief description of the code (botPoCrelease-android.c) that use the smartphone to spawn messages using a Master/Slave/Target combination to hide the identity of the Master to the Slave.

==============================================================
Compile with arm-gcc with the -static flag set
Copy to anywhere on the underlying OS that is writable (/data/ is good).
Rename /dev/smd0/ to /dev/smd0real/
Start the bot application
Kill the radio application (ps | grep rild)
The radio will automatically respawn and now the bot proxy will be working
==============================================================

The original botnet code has been in the hacking community since 2011 but currently the code is hard to find. There is a sanitised version available though.














This proof of concept mobile botnet to generate SMS text messages still relies upon knowing the target's mobile number. The analysis thus focussing on the sending party (Master) knowing the recipient mobile number (Target) to hand to the donor (Slave). In the alternative, harvested mobile numbers returned from ICMP (or similar) pings via the internet could generate a high harvest of returned MSISDNs without the Target knowing his/her MSISDN has been acquired to send messages(SMS spam, etc.).


Thursday, April 02, 2015

Smishing Maybe Smashed, but Fake Tache Goes On

Credit to Google Play Store - Combined screen shots of apps purporting to fake SMS and call logs

Continuing on the text messaging discussion about examining raw data. Previously the subject was associated with Emotion Icons  http://trewmte.blogspot.co.uk/2015/03/emotion-icons.html and generally determining the bit-encoding scheme, Unicode, encrypted messaging hidden within Icons sent with messages.

Back in 2012 Android was reported to have a vulnerability in its platform that was labelled in the research **"Smishing Vulnerability in Multiple Android Platforms (including Gingerbread, Ice Cream Sandwich, and Jelly Bean)" by Xuxian Jiang, Associate Professor, Department of Computing Science, NC State University - http://www.csc.ncsu.edu/faculty/jiang/smishing.html. The research raised two important points:

(1) **"This vulnerability allows a running app on an Android phone to fake arbitrary SMS text messages, which will then be received by phone users."..." The affected platforms that have been confirmed range from Froyo (2.2.x), Gingerbread (2.3.x), Ice Cream Sandwich (4.0.x), and Jelly Bean (4.1)."

The Android Security Team produced a fix for this in Android 4.2, but the research does not confirm whether devices existing in the marketplace continuing to use Froyo (2.2.x), Gingerbread (2.3.x), Ice Cream Sandwich (4.0.x), and Jelly Bean (4.1) would also be fixed or remain with the vulnerability?

(2) **"Note that any app on the phone can fake incoming messages, including both SMS and MMS messages".

By late 2013  Aditya Mahajan, Laxmikant Gudipaty, Dr. M. S. Dahiya continued research beyond the findings of Xuxian Jiang. Their analysis focused on "Identification of Fake SMS generated using Android Applications in Android Devices" 54d35df10cf28e0697281a74.pdf which concluded it is possible to show the presence of a potential fake SMS text message based upon the file header  content e.g. the reply paths etc. Moreover, if an original message was deleted but later recovered and the fake message purporting to represent the original message (but with altered content) were analysed side-by-side, so to speak, then disparity in content and file header content could assist an investigation. The test case apps used by the authors on a selection of Android Smartphones phones were “SUPER SMS FAKER (SSF)” & “LogMe”.

Within our mobile/smartphone examination, forensics and evidence community we are still plagued by the fact that there are a huge range of apps purporting to fake:

- SMS Text Messages
- MMS Messages
- Calls Logs
- Etc.

See - Fake Call & SMS & Call Logs search of google play store: https://play.google.com/store/search?q=Fake%20Call%20%26%20SMS%20%26%20Call%20Logs

The above suggests students and newcomer examiners maybe tricked into giving lower scrutiny priority to these sources of evidence. Skillsets available in automated tools to extract and harvest data content from databases such as SMS text message history found in e.g. "/data/data/com.android.providers.telephony/databases/mmssms.db" are highly useful but the message should not be obfuscated when informing students and newcomers to mobile/smartphone examination, forensics and evidence that extracted and harvest data requires deeper analysis. That is not merely at the investigation/interpretation stage but at the atomic collection stage, too.

As mentioned previously viewing harvested data can be a trompe l'oeil (a lie to the eye). A faked SMS text message can be as simple as a perpetrator dressing up an innocent-looking fake message with (metaphorically speaking) a false moustache (fake tache) with a intent to falsify the impression in the message to be communicated.


Fake caption: Heeeyyyy, Briiaan, why the fake moustache? Stu-eey!!!!! I am just off to the bathroom.

Friday, July 19, 2013

Android DDMS Vulnerability

Android DDMS Vulnerability

A suggested in-memory patch solution to the DDMS vulnerability is reported in this article:

https://securityledger.com/2013/07/security-start-up-university-team-on-android-patch-app/

The article states "The flaw is located in an Android component known as the Dalvik Debug Monitor Service (or DDMS), the virtual machine that runs software on Android devices. The vulnerability affects almost all Android devices in use, could allow a malicious actor to modify a legitimate, signed Android application without affecting the application’s cryptographic signature. That would prevent Android from noticing the changes when the application is installed."

So to prevent any new threat occuring ReKey can help you do this. However, what is the solution where threat already existed on the Android phone prior to the in-memory patch being installed? Are there any known affects (exploits that add or alter data or cause call events etc)? Could those 'affects' impact on the weight given to evidence extracted and harvested from a particular smart phone?

How relevant is the above to device examination?   Computer forensic examiners spend hours and days sifting through data and studing how a program installs, executes and stores activity generated by use of a program. Smart phones are now highly complex radio communication and electronic devices running a multitude of internal operating programs, user access programs fashioned to the device, interfaces to connect to other devcies and, all importantly, programs to communicate using radio transmission/receiver technologies GSM, W/CDMA, LTE, Wi-Fi, Bluetooth/IRDA, RFID/NFC.

In the early days of mobile phone examination the SIM Card was the focus of attention as little occurred by way of the handset itself. Evolved feature handsets have transformed mobile phones to smart phones and processes of acquiring data have largely become mechanical with plug-in tools pumping out data in production line fashion. Invariably examiners cannot rely simply one one tool but require a toolbag of tools. These tools in themselves are still not enough as the art and skill of interpretation as to the cause and effect and meaning of data are not present in the tools. Sure, tools may show e.g. a (static/active) graph of internet activity of a smart phone once data has been harvested from it but does the tool confirm whether the smart phone automated that process or whether it involved human intervention to cause the intenet activity?

Evolved, too, has the (U)SIM. Which means understanding of what is actually stored on it and applications that run from it, the (U)SIM, cannot be ignored when it comes to automated processes and human intervention.

Image - SIM Toolkits (STKs): Proactive SIM enables and allows a SIM to issue commands and action responses and thus may be susceptable to generating events in a manner and form that needs to be understood (see: GSM11.14).

The DDMS vulnerability reminds us that over-reliance on a tool simply to extract and harvest data and then present the data in a eye-pleasing format is not enough. Understanding the program/s and apps on a smart phone and in a USIM, its genuineness and originality, how data and records are caused to be generated and the interpretation of the records and data is now where we are at. Production line (bang it on, bang it out) recordings of only call activity, phonebooks, texts, IM messages, graphics, internet etc is fast becoming an incomplete methodology for smart phone and USIM examination.

Sunday, April 21, 2013

iPhone to Android

iPhone to Android

Interesting tool:

1 Transfer iPhone SMS and MMS with attachments to Android
2 Transfer SMS and MMS to Android from iTunes Backup
3 Extract picture, video, audio attachments from iPhone MMS to computer
4 Save iPhone SMS and MMS to local database on computer
5 Copy SMS and MMS from PC local database to Android
6 Export iPhone SMS and MMS to document files
7 Print out iPhone SMS and MMS in amazing threading mode

http://www.backuptrans.com/iphone-sms-mms-to-android-transfer.html

Saturday, May 26, 2012

Trace Log Generator

Trace Log Generator

I am looking into creating a new handset tool that generates a trace log of commands sent to the handset and responses received.

Quite a few times I have raised this and largely there is a stone-wall silence about why examiners 'cannot' or 'will not' provide the actual trace log associated with their examination, so that this can be checked. That is an unhealthy taboo to be active in forensics (and for evidence) and needs to be side-stepped.

The idea of the trace log that produces units of information and exported for consideration is similar to that generated by some imaging tools, which allow, as complete as possible, an examination.

This tool I believe should not compete with current tools in the same way that they perform, but the trace log should be inexpensive as the generated file will be a trace log, secured in such a manner that the original should not be altered by accident and when an examination takes place should avoid accidental contamination of the original. However, the managed principle extraction technique is based upon starting at binary and working upwards in order to allow the data to be viewed through independent products.

Additionally, I expect the trace log generator to perform tracing on a make-by-make basis, which means there should be a trace log generator module for each make. This will allow examiners to only buy what they need as opposed to have the reading capability of X-makes/models where it is an extremely low probability of examiners coming into contact with them.

There is a list of benefits but I suspect two key objectives that will benefit in the mobile forensics industry

1) Those whose job requirement limits them to push-button selection for reading an exhibit can produce the trace log first and then use another tool

2) Those who are experienced can use the trace log without needing to hector the less experienced to qualify what they have done during the acquistion examination period.

Additionally, I also envisage some form of (self)employment to arise out of this where programmers can create modules within the framework of the trace log generator and share in the revenue generation stream and at the same time see their contribution in a product generated by and for the forensic community.

I liked to know what you think?

Sunday, May 20, 2012

Evidence is one thing, Understanding is another

Evidence is one thing, Understanding is another

I like Nokia. They were in at the beginning and presented the World with options, and so many walked behind, in their footsteps.  The Nokia 110 and 112 still hasn't stopped the examiner from seeing potential evidence:


Seeing through the eyes of experienced examiners:


Mobile phones - understanding their contribution to evidence.

Sunday, April 01, 2012

Blinking Ice Cream Sandwich (ICS)

Blinking Ice Cream Sandwich (ICS)

Security issue concerns raised about Samsung's 'Face Unlock' has received a boost in the new OS upgrade release of ICS as it is reported to contain an additional security feature requiring the user to 'blink', in addition to existing security already in place, according to global.samsungtomorrow. So for those who thought using a photo of the user for 'Face Unlock' now could require, additionally, a moving image of the user blinking. Whether that requires the genuine user to blink naturally or forced blinking is unclear. Certainly something else to consider when dealing with a DUT with ICS OS during mobile phone examination.

Friday, February 17, 2012

Examination Techniques2: Android

Examination Techniques2: Android

To assist formulate a conclusion how a device (DUT) has been used examining apps the user has recently used may provide some useful clues. Recently used apps can be identified by holding down the 'home' button, a popup window is then released listing the last opened apps.

Friday, February 03, 2012

Privacy Act for Mobile Devices

Privacy Act for Mobile Devices

Do you recall last year when the Carrier IQ story broke about user keystrokes being monitored by clandestine software on handsets, I wrote at that time here at trewmte.blogspot:

( http://www.trewmte.blogspot.com/2011/12/violation-of-wiretap-law-us-or-just.html )
"What is really needed here is not the "hang 'em high, shoot 'em, flog 'em brigade" but in fact absolute 'transparency' how consumers rights are given absolute precedence and with strict liability applied to manufatcurers and operators to reveal all embedded and hidden software on devices and detailed as to exactly what the software do. Importantly, this would allow a consumer to either accept or reject the device. This path of action shouldn't affect Intellectual Property Rights because IPRs are not being infringed. It is though 'clandestine' or 'veiled' knowledge that would be affected as it removes the right to use hiding tactics and avoid non-revelation. Without such transparency, a possible outcome from the articles is in having mentioned the brand names of Nokia, Android, and Blackberry devices in connection with this software. That may well influence how consumers decide to choose their brand named products for fear and uncertainty whether the device in use or about to be sold to them contains key sniffing software."

It would appear one US Congressman, Ed Markey ( http://markey.house.gov/ ) finds favour with the notion of 'transparency' and has introduced a draft bill for mobile phone privacy to be called The Mobile Device Privacy Act (MDPA) - download here Mobile Device Privacy Act Rep.Markey.pdf

 
Photo courtesy of photo gallery http://markey.house.gov/

The bill sets out a requirement for mobile operators and providers to 'tell' each subscriber whether tracking software has been installed on their mobile device. 

Republican Ed Markey is a senior member of the House Energy and Commerce Committee and who previously held the position of chairman of the Subcommittee on Telecommunications and the Internet said in a statement "Consumers have the right to know and to say no to the presence of software on their mobile devices that can collect and transmit their personal and sensitive information." ... "While consumers rely on their phones, their phones relay all sorts of information about them, often without their knowledge or consent. I am concerned about the threat to consumers’ privacy posed by electronic monitoring software on mobile phones, such as the software developed by Carrier IQ. Today I am releasing draft legislation to provide greater transparency into the transmission of consumers’ personal information and empower consumers to say no to such transmission. This is especially important for parents of children and teens. I look forward to working with stakeholders on my legislation and collaborating with my colleagues prior to the formal introduction of the final legislation." source of quote mashable.com

The strength of commitment to 'transparency' in this proposed Act, and when enacted, should place very tight obligations encumbent on operators/providers to have the means available to them to demonstrate unequivocably to each subscriber that their mobile device has no clandestine tracking software on it or in it.