Windows Phone 8.1 Gets an Official File Manager


Windows Phone 8.1 hasn’t yet seen its official release, but many of us have already gotten a good taste of what this update will bring thanks to the WP8.1 Developer Preview. This update, which was originally announced at last month’s Build 2014 conference, brings quite a bit of added functionality such as Cortana Voice Assistant, a new Action Center notification handler, and improved device personalization options.

Despite all of WP8.1′s improvements, it still misses some key functionality that many power users would enjoy–most notably, a robust, built-in file manager. Yes, there’s no shortage of aftermarket file management apps for WP8/8.1, but having a good first party option is never a bad thing.

Now, Microsoft hopes to rectify this with the release of the new Windows Phone 8.1-exclusive app Files. Files is a free file manager app that is able to access files stored on both your WP8.1 phone’s internal storage and SD card. You are able to browse, search, launch, and share files. You’re also able to create folders and move, rename, copy, or delete files–basically, everything you’d expect from a traditional file manager. Finally, Windows 8/8.1 users will immediately feel at home, as the interface mirrors Microsoft’s file selection UI on the desktop, and given Microsoft’s ability to produce cohesive, high quality interface designs, that’s a good thing.

If you’re a WP8.1 user and you wish to give Files a try, head over to its listing in the Windows Phone App Store. Just be aware that you need to be running the WP8.1 Developer Preview in order to play–but you’re already running it anyway.

[Source: Windows Phone App StoreMicrosoft Windows Phone Blog | Via PocketNow]


Next Version of Android to Bring Even More Root Headaches


About a week and a half ago, we took a look at a few recent AOSP merges initially spotted by XDA Senior Recognized Developer Chainfire that severely impact root app developers due to changes in SELinux, default runtime compiler, and the requirement of PIE (Position-Independent Executable) for non-statically built executables. These changes compounded previous headaches caused by commits that prevent SU from executing files stored on the /data partition. Luckily, potential workarounds for the above changes were quickly publicized by Chainfire when he updated his How to SU guide.

Now, the breakage continues, as new AOSP commits are poised to make life more difficult for root app developers and users in upcoming versions of Android. And this time, the workarounds aren’t so simple. The changes in question relate to SELinux and the limiting of /system write access to the recovery context. This would ordinarily be fine and lead to heightened security, but combined with another change that then limited this recovery context to the actual system recovery, it could be a serious blow to the root app community and lead to additional end user difficulty when using root-enabled apps that need to write to the /system partition.

So what do these changes actually mean? For starters, this means that going forward, write access to the /system partition is no longer possible on “rooted stock” ROMs. Instead, developers will have to use custom recoveries to handle /system partition write access through APIs such as Open Recovery System (ORS), which was introduced alongside TWRP2 two years ago. This would be fine if everyone were using a compatible (and updated) custom recovery. However, the sad reality is that not every root user is even on a custom recovery–much less, an updated one that supports ORS or similar functionality flawlessly. And naturally, if a root app doesn’t work well with a particular recovery, it’s likely that the app developer (and not the recovery developer) will be blamed by the end user.

What about the ramifications? In addition to the developer headaches from having to shift over to recovery-based /system partition write access, these changes also place an additional burden on users who will now have to reboot any time they want to write to the /system partition. Moreover, even with a properly compatible custom recovery and updated apps to take advantage of the recovery scripting, certain types of root apps will simply not work without a hack to get around these limitations.

It’s important to keep in mind that there are a few potential saving graces. First of all, /system write access can obviously be re-enabled by a custom kernel. Moreover, it’s not known at this time whether these commits will actually make their way into the next version of Android or another version further down the line. However, not every device is able to run a custom kernel (or custom recovery, for that matter), and devices with locked bootloaders are unfortunately all too common at the moment.

You can read the original post over on Chainfire’s G+ page. Are you a root-enabled user dreading these changes, or do you welcome the increase in security that changes to SELinux bring? Let us know in the comments below.


GPL-Mandated Moto E Kernel Source Finally Released, Razr M/HD Source Updated to KitKat


We’ve talked quite a bit about the highly affordable Moto E ever since its launch earlier this month. We first shared a system dump a little under two weeks ago, and that was quickly followed by a preliminary TWRP build. Then two days after that, Motorola graciously allowed us to bootloader unlock the device.

Despite all of this early progress, one thing had been missing up until now, and that’s functional kernel source. Now, however, Motorola has finally complied with the GPL-requirements and released the open source kernel code for the Moto E.

Ordinarily, we wouldn’t be celebrating an OEM for taking a half month in releasing something that should have been available at device launch. But as you would expect, this is still a great thing for developers, who now no longer have to rely on code from other devices to create development work on the E. In addition to the kernel source release for the Moto E, Motorola has also updated its Razr M and Razr HD to match its KitKat updates that we saw not too long ago–again, better late than never.

Developers, it’s time to get those engines started. Head over to the source links below to get in on the source-built development action.

[Source: Motorola GitHubCondor Instructions | Via Motorola Blog]


Leaky Apps Cause Expensive Headaches

A couple recent stories illustrate how unsecured apps can create big headaches for the companies that create them and underscore the need for consumers to be vigilant about their own mobile security — no matter how seemingly benign, well-known or trustworthy the app provider seems to be.

Back in March, the FTC reached a settlement with Fandango and Credit Karma over charges that they deceived consumers by misrepresenting the security of their mobile apps and failing to secure the transmission of millions of consumers’ sensitive personal information. The complaints charged that Fandango and Credit Karma disabled a critical default process, known as SSL certificate validation, which would have verified that the apps’ communications were secure.

This exposed the apps to “man-in-the-middle” attacks, which would allow an attacker to intercept any of the information the apps sent or received. The FTC release noted this type of attack is especially dangerous on public Wi-Fi networks.

“Our cases…should remind app developers of the need to make data security central to how they design their apps.” – Edith Ramirez, FTC Chairwoman

“Consumers are increasingly using mobile apps for sensitive transactions. Yet research suggests that many companies, like Fandango and Credit Karma, have failed to properly implement SSL encryption,” said FTC Chairwoman Edith Ramirez. “Our cases against Fandango and Credit Karma should remind app developers of the need to make data security central to how they design their apps.”

More recently, LifeLock suspended its LifeLock Wallet mobile payment application after informing the FTC not fully compliant with applicable payment card industry (PCI) security standards. LifeLock acquired the Wallet application as part of its $42.6M deal for Lemon announced in late 2013. Though there was no evidence user data was compromised, the security oversight came with a hefty price, as shares of Lifelock dropped more than 17% once the news was made public.

These examples should serve as a warning to companies who still see app security as an afterthought. Failing to protect your users can result in real-world costs from fines, drops in stock price, and loss of business. Yet as our research has discovered, more than 60% of apps have security vulnerabilities that put users at risk.

We applaud the FTC for enforcing laws like the Gramm-Leach-Bliley Act and for bringing more awareness to the mobile security in general. But with the overwhelming number of apps coming on the market each day, it’s paramount that individual consumers educate themselves about the privacy risks mobile apps represent and how best to protect their devices and themselves.

If you would like to know more about how viaForensics can help you secure your mobile applications, contact us using the button below.

Contact viaForensics


Deodex APKs and JARs with Ease Using Ultimate Deodexer


If you theme or otherwise modify your device and its applications, you have surely deodexed either your entire ROM or certain apps. This process isn’t particularly difficult by any stretch of the imagination, but it can be a bit annoying and burdensome if not done with a user-friendly, GUI-based tool. Luckily, there’s Ultimate Deodexer.

Ultimate Deodexer by XDA Recognized Themer BDFreak is an incredibly user-friendly deodexing tool that allows anyone to deodex any APK or JAR with just a few clicks. This works for all Android versions, even 4.3 and 4.4, which were initially troublesome with certain utilities. All you have to do is load the appropriate files and click the start button. The tool even allows you to drag and drop files and folders to deodex. And once done, you are given a log that shows how everything went.

If you find yourself deodexing APK or JAR files 0ften, head over to the utility thread to give Ultimate Deodexer a shot.


Making the Business Case for a Software Security Requirements Program

Most of our customers need to justify the costs of implementing a software security requirements program when they purchase SD Elements.  This post will explain how to build an effective business case based on real data. We will show you how application security program will be both more cost effective and more secure by implementing a software security requirements program.

We make certain assumptions based on the actual cost of finding, fixing, retesting, and validation of remediation of a high/critical vulnerability.  Industry experts estimate that cost to be around $4,000 to patch each identified high/critical vulnerability. Some of our clients have quoted numbers closer to $7,000 based on their internal evaluation. In our formulas we will use $2,000 be conservative. Feel free to substitute your company’s own internal cost to fix a vulnerability. We have also developed an Excel spreadsheet to help you enter in your own company’s numbers: Supporting Formulas for Making the Business Case for a Software Security Requirements Program.

Method to validate potential cost savings on existing applications

A very simple method to quickly determine the potential savings of the use of SD Elements would be to select a random set of applications which have recently gone through a pen-test, static code scan or dynamic code scan and have some high/critical findings.  Using your selected applications:

  • count the number of applications;
  • count the number of high/critical vulnerabilities testing identified that you would not have accepted into production without remediation;
  • model the applications in your security requirements solution, such as SD Elements and identify how many of the vulnerabilities could have been prevented by correctly implementing the security requirements. Our empirical data suggests 97%-100% of vulnerabilities will be correctly identified by comprehensive security requirements. A more conservative figure would be 90% however you may want to substitute your own calculated number after implementing a software security requirements program on a pilot basis.

Next multiply your company’s average cost of finding, fixing, retesting and validating the fixes by the number of vulnerabilities that could have been prevented.

Real Client Example #1: 

A real world example of this value prop comes from a company where our service organization ran a popular commercial dynamic scanner against 1200 applications.  There were many findings.  During the scanning all high/critical findings were compared to the SD Elements recommendations and 100% of them could have been avoided by using the product.  Every single finding correlated to a recommendation.

Cost savings from avoidance of labor associated with cleaning reports from scanners

As a part of using commercial scanners there is a high labor associated with scrubbing through test results to manually validate whether or not each finding is real or a false positive.  Normally this cost is unavoidable; however, this cost can be avoided by using software security requirements to prevent developers from introducing them into production from the beginning.

Select a set of applications you have scanned and divide the number of scanning findings by the number of applications.  Multiply this number by the cost per minute for an average hand validation of the defect by an expert.  This calculation gives you the average cost per application of scanner reports that could be avoided by using software security requirements from the beginning.

Real Client Example #2:

An example is a large medical company that is a client of ours who re-wrote two applications.  They use SD Elements on one of them.  After completion they ran a commercial dynamic scanner against both applications.  The application written without SD Elements had over 800 findings while the application written with SD Elements had zero findings.  We have had multiple customers that have created applications and then used code scanning products and/or dynamic scanning products against those applications with zero high or critical findings.

Cost savings from avoidance of remediation efforts associated with Testing findings

As a part of performing testing there is a high cost of remediation associated fixing the vulnerabilities that are found.  Simply put, it is very expensive to introduce a vulnerability into production which could have been avoided.  Industry analysis from NIST estimated this cost to be thirty three (33) times higher than finding a vulnerability in the design stage.   Software requirements when introduced at the beginning of a project enable companies to avoid these costs by providing the appropriate requirements to prevent developers from introducing domain agnostic threats into production from the beginning.

Select a set of applications you have manually tested and determine your average hourly cost for developers to remediate applications; the average number of hours to remediate an application; your average hourly cost of Quality Assurance and Security testing of remediated applications and the average number of hours to validate remediation efforts.  These added give you the total cost per application of remediation efforts.  If you multiply that number by the likely percentage of avoidable remediation efforts (we use 90% here again) then you get the average cost per application that could be avoided by using software security requirements from the beginning.

Real Customer Example #3:

Multiple customers have created applications using SD Elements and then performed pen testing against those applications with zero high or critical findings and have purchased licenses of SD Elements because of this cost avoidance analysis.  The costs can vary wildly for each company as well as the total number of applications in the portfolio which could benefit from the use of the product.  We have several clients who have attempted to build something similar to SD Elements internally after identifying that the injection of security requirements into the SDLC would be a major security improvement resulting in significant cost avoidance.  In each case, when they found out about SD Elements a pilot program was established followed by a full rollout plan.

Other possible cost savings to consider

There are several other areas where customers are report finding cost savings by implementing a software security requirements program but which are difficult to quantify based on varying project types and industries but you may also want to consider the following:

  • The cost to an organization of not knowing what domain agnostic threats your application may be susceptible to and whether you have built in the compensating control
  • The cost savings of having your security requirements controlled in one place and distributed to your whole organization (security, development and testing)
  • The cost savings of being able to quickly determine if a new threat affects the applications in your organization
  • The cost savings of having your pen testing teams focus on domain specific threats instead of domain agnostic threats.  For example, your pen testers can focus on making sure the functionality of the application is secure.  That a banking application cannot be tricked into processing a loan for someone who doesn’t qualify or that an online shopping application will not process an item for an incorrect price.