Search the Community
Showing results for tags 'andriod'.
Found 3 results
-
Folks, the day that we Android fans across the globe have been waiting for is finally here! Google has just now formally announced the highly anticipated (and heavily rumored) Google Nexus 6 and Google Nexus 9, as well as the official name of Android 5.0 “Lollipop” and the new Nexus Player device. Google Nexus 6First up, we have Google’s new phlagship flagship smartphone, the Google Nexus 6. This phablet features pretty much everything we expected from past rumors such as a 6-inch Quad-HD AMOLED display (2560×1440 at 493 ppi), a 13 megapixel camera with optical image stabilization and 4k video capture at 30 fps, 3 gigs of RAM, 32 or 64 gigs of internal storage, and a 2.7 GHz quad-core Snapdragon 805 CPU. All this will be packed into a frame that comes in at 82.98mm wide x 159.26mm tall x 10.06mm thick and weighing just 184g. In addition to sheer specs, the device also packs stereo speakers and a rather ginormous 3220 mAh battery and a new Turbo Charging mode that will charge your device with 6 hours of battery life in just 15 minutes when using the provided charger. The Google Nexus 6, which will be sold alongside the existing Nexus 5, will be available in Midnight Blue and Cloud White. According to Motorola, it will be available for $649 later this month (preorder on the 17th) via the Google Play Store, Motorola.com, and through regional carriers in 28 countries. Google Nexus 9Next, we have Google’s newest tablet, the Google Nexus 9. Similar to the Nexus 6, the HTC-built Google Nexus 9 remains quite true to the previous rumors. The Google Nexus 9 will feature an 8.9″ QXGA (2048×1536) display with a 4:3 aspect ratio and double-tap to wake, the 64-bit Nvidia Tegra K1 processor (Kepler GPU) running at a yet unknown speed, 2 gigs of RAM, 16 or 32 gigs of internal storage, an 8 MP rear camera, and a 1.6 MP front camera. All this horsepower will be packed into a shell with design aesthetics similar to the outgoing Nexus 7-2013, but with HTC-inspired flair such as brushed metal sides. The shell will come in at 153.68mm wide x 228.25mm tall x 7.95mm thick. It will weigh 425g for the WiFi-only variant and 436g for the LTE model. Unlike the Nexus 6, the Nexus 9 will not live alongside its predecessor. Rather, the Nexus 9 will replace both the Nexus 7-2013 and the Nexus 10. The device will launch in three colors: Indigo Black, Lunar White, and Sand, but availability and pricing is not yet known. However, preorders will open on the 17th. Google Nexus PlayerFinally, we have the new Google Nexus Player. This device is Google’s newest attempt at conquering your living room. Building upon the success of the Chromecast, the Google Nexus Player is billed as an easy and convienient way of getting apps, games, and media content to your TV. It comes in the form of a sleek and streamlined console unit, a remote with voice search, and a precision gamepad with dual-analog thumbsticks (available separately) for gaming fun. The device’s modified Android interface will feature personalized content recommendations, will support Google Cast, and it will respond to voice searches with the press of a button. Those wondering about the device’s gaming capabilities will be glad to learn that it features a 1.8 GHz quad-core Intel Atom CPU with an Imagination PowerVR Series 6 GPU. It only packs 1 gig of RAM and 8 gigs of internal storage, but perhaps the lightweight games geared to the console don’t require much in the way of memory demands. The console itself will come in at just 120 mm x 120 mm x 20 mm thick, and it will weigh just 235g. Availability and pricing are not yet known, but preorders, like for the Nexus 6 and 9, will open up on the 17th. Android 5.0 LollipopWhile new devices are cool–and the Nexus 6, Nexus 9, and Nexus Player are certainly quite exciting–the real star of the show here is Android 5.0 Lollipop. As we’ve seen in the two developer previews released thus far, Android L is a massive departure from what we saw in KitKat. And now, we’re on the verge of its final release. As expected, Lollipop will premiere first on the new Nexus 6, Nexus 9, and Nexus Player. But as stated by Google, Android 5.0 will also make its way to older Google Play edition and Nexus devices such as the Nexus 4, 5, 7 (presumably both models), and 10. Finally, developers can rejoice as well, as the full Android 5.0 Lollipop SDK will be available in two days, alongside the release of updated Android L Developer Preview images for the Nexus 5 and Nexus 7. You can learn more and read the full announcement over on the official Android blog and Android Developers G+ post. via: http://www.xda-developers.com/android/google-nexus-6-9-player-android-5-lollipop/ -
64-bit smartphones are already a reality with the iPhone 5s while several manufacturers are competing to be the first to bring a 64-bit Android to market. HTC might claim that title with the mid-range Desire 820. The phone has been officially confirmed via the HTC Weibo account though details are very scarce – all the teaser images really say is "64-bit" and "September 4". The first image lists off the HTC firsts – first Android phone, first 1080p phone, first f/2.0 camera aperture and so on. The second image is more interesting and shows what appears to be the front-facing camera, off to the side of a front-facing speaker grill. Our Chinese is spotty but that big "64" is hard to misinterpret. HTC Desire 820 teaser images The short text accompanying the second teaser image claims this is the "world's first octa-core 64-bit phone". If it's a Qualcomm chipset then it must be the Snapdragon 615 – it has eight Cortex-A53 cores (the 64-bit replacement of the Cortex-A7) and a next-gen Adreno 405 GPU. A previous rumor of the HTC A11 claimed a Snapdragon 410 chipset (quad Cortex-A53 with Adreno 306) but that may be a different mid-range Desire phone. September 4 of course means HTC's IFA event where the company will make a bit for another "world's first" title. Source: http://www.gsmarena.com/htc_confirms_desire_820_to_pack_64bit_snapdragon_615_chipset-news-9455.php
-
Every Android application has its own unique identity, typically inherited from the corporate developer’s identity. The Bluebox Security research team, Bluebox Labs, recently discovered a new vulnerability in Android, which allows these identities to be copied and used for nefarious purposes. Dubbed “Fake ID,” the vulnerability allows malicious applications to impersonate specially recognized trusted applications without any user notification. This can result in a wide spectrum of consequences. For example, the vulnerability can be used by malware to escape the normal application sandbox and take one or more malicious actions: insert a Trojan horse into an application by impersonating Adobe Systems; gain access to NFC financial and payment data by impersonating Google Wallet; or take full management control of the entire device by impersonating 3LM. Implications: This is a widespread vulnerability dating back to the January 2010 release of Android 2.1 and affecting all devices that are not patched for Google bug 13678484, disclosed to Google and released for patching in April 2014. All devices prior to Android 4.4 (“KitKat”) are vulnerable to the Adobe System webview plugin privilege escalation, which allows a malicious application to inject Trojan horse code (in the form of a webview plugin) into other apps, which leads to taking control of the entire app, all of the apps’s data, and being able to do anything the app is allowed to do. Android 4.4 is vulnerable to Fake ID, but not specifically to the Adobe System webview plugin due to a change in the webview component (the switch from webkit to Chromium moved away from the vulnerable Adobe-centric plugin code). Users of devices from specific vendors that include device administration extensions are at risk for a partial or full device compromise by malware. The 3LM device extensions (temporarily owned by Motorola and Google) are present in various HTC, Pantech, Sharp, Sony Ericsson, and Motorola devices – and are susceptible to the vulnerability as well. Other devices and applications that depend upon the presence of specific signatures to authenticate an application may also be vulnerable. Essentially anything that relies on verified signature chains of an Android application is undermined by this vulnerability. How it works: Android applications are typically cryptographically signed by a single identity, via the use of a PKI identity certificate. The use of identity certificates to sign and verify data is commonplace on the Internet, particularly for HTTPS/SSL use in web browsers. As part of the PKI standard, an identity certificate can have a relationship with another identity certificate: a parent certificate (“issuer”) can be used to verify the child certificate. Again, this is how HTTPS/SSL works – a specific web site SSL certificate may be issued by a certificate authority such as Symantec/Verisign. The web site SSL certificate will be “issued” by Verisign, and Verisign’s digital identity certificate will be included with the website certificate. Effectively, the web browser trusts any certificate issued by Verisign through cryptographic proof that a web site SSL certificate was issued by Verisign. Android applications use the same certificate signature concepts as SSL, including full support for certificates that are issued by other issuing parties (commonly referred to as a “certificate chain”). On an Android system, the digital certificate(s) used to sign an Android application become the application’s literal package “signature”, which is accessible to other applications via normal application meta-data APIs (such as those in PackageManager). Application signatures play an important role in the Android security model. An application’s signature establishes who can update the application, what applications can share it’s data, etc. Certain permissions, used to gate access to functionality, are only usable by applications that have the same signature as the permission creator. More interestingly, very specific signatures are given special privileges in certain cases. For example, an application bearing the signature (i.e. the digital certificate identity) of Adobe Systems is allowed to act as a webview plugin of all other applications, presumably to support the Adobe Flash plugin. In another example, the application with the signature specified by the device’s nfc_access.xml file (usually the signature of the Google Wallet application) is allowed to access the NFC SE hardware. Both of these special signature privileges are hard coded into the Android base code (AOSP). On specific devices, applications with the signature of the device manufacture, or trusted third parties, are allowed to access the vendor-specific device administration (MDM) extensions that allow for silent management, configuration, and control of the device. Overall, this is an appropriate use of digital signatures in a system that supports the notion of PKI digital certificate identities. However, Bluebox Labs discovered a vulnerability that has been relatively present in all Android versions since Android 2.1, which undermines the validity of the signature system and breaks the PKI fundamental operation. The Android package installer makes no attempt to verify the authenticity of a certificate chain; in other words, an identity can claim to be issued by another identity, and the Android cryptographic code will not verify the claim (normally done by verifying the issuer signature of the child certificate against the public certificate of the issuer). For example, an attacker can create a new digital identity certificate, forge a claim that the identity certificate was issued by Adobe Systems, and sign an application with a certificate chain that contains a malicious identity certificate and the Adobe Systems certificate. Upon installation, the Android package installer will not verify the claim of the malicious identity certificate, and create a package signature that contains the both certificates. This, in turn, tricks the certificate-checking code in the webview plugin manager (who explicitly checks the chain for the Adobe certificate) and allows the application to be granted the special webview plugin privilege given to Adobe Systems – leading to a sandbox escape and insertion of malicious code, in the form of a webview plugin, into other applications. The problem is further compounded by the fact that multiple signers can sign an Android application (as long as each signer signs all the same application pieces). This allows a hacker to create a single malicious application that carries multiple fake identities at once, taking advantage of multiple signature verification privilege opportunities to escape the sandbox, access NFC hardware used in secure payments, and take device administrative control without any prompt or notification provide to the user of the device. For the PKI & code savvy, you can see for yourself in the createChain() and findCert() functions of the AOSP JarUtils class – there is a conspicuous absence of cryptographic verification of any issuer cert claims, instead defaulting to simple subjectDN to issuerDN string matching. An example of the Adobe Systems hardcoded certificate is in the AOSP webkit PluginManager class. Source: https://bluebox.com/blog/technical/android-fake-id-vulnerability/
