In the past few years, we’ve seen a boom of different cloud services sprout up. There are numerous major players in this market, with Google, Microsoft, Dropbox and others all trying to dominate the cloud. With so many choices to choose from, what makes one cloud service stand above the rest? Is it the price, feature support, or maybe something entirely different? Let us know what makes a cloud service appealing to you and why.
There’s been noticeable disquiet around the combination of Android and audio for many years, and understandably so. We posted an article last month on how the changes in the upcoming Android M could affect the implementation of audio applications and what we hoped that would mean for the platform as a whole, and since then we’ve come across a few sources that make the logic behind all this a lot easier to digest.
Really what’s underpinning this is the issue of audio latency in Android, especially when compared to other operating systems. Latency, for those who are unfamiliar with the term, is simply the time it takes a signal to reach a certain point (usually a round trip). In popular culture you find it mentioned a lot in online gaming, where latency contributes to the ‘lag’ that a player experiences between their input and its response on a shared game. In audio, it’s easiest to describe it as the time it takes an audio signal to come into your device, go through some sort of conversion and processing, and come back out again.
Android was never built with low-latency concerns in mind. Due simply to the way it was designed, it’s impossible to achieve the kind of latency required for powerful audio manipulation apps or in live situations where synchronicity is key. This is something that enthusiasts are only too aware of, but for the average user, the lack of audio software in the Play Store especially when compared to rival iOS is what makes this obvious. Some manufacturers, like Samsung, have gone as far as creating their own APIs in order to try to reduce the latency on their devices, and with some success, but in doing that they’re still limiting the commercial scope of any audio app to their products only, discouraging companies from putting the time into developing the software in the first place.
To demonstrate this in real world terms, check out this article to find a fairly extensive list of Android devices and what the latency of this audio journey actually is. This could be useful for developers who ARE looking to create music focussed applications, and at least we can see a marked increase (generally) as the OS has matured. Again, Android M should continue this trend, but it’s not clear by how much, and personally we doubt it’ll be the game-changer it needs to be quite yet.
Secondly, if you’d like a full explanation of why this is the case, jump into this excellent article. It explains in detailed but clear tones what actually happens to an audio signal and the many stages it has to go through within the OS. One thing to bear in mind is that the writers are trying to push their own solution to the issue by trying to replace most or all of this process, but if this is adopted and ends up benefiting the consumer, then we all profit.
Hopefully in the not too distant future, these kind of concerns will be negated, and musicians and producers won’t be instantly pushed towards the relatively better equipped Apple camp. Google needs to put some focus on this aspect of Android as it will take some serious work for it to become competitive in this regard, but thankfully it does look like Android M will be a start.
Can you see yourself using Android as part of your audio set up in the future? Let us know in the comments!
A few days ago, images of the new Samsung Galaxy A8 surfaced online on Chinese website pconline.com.cn. The Samsung Galaxy A8 will reportedly feature a 1.5 GHz 64-bit Snapdragon 615 processor along with Adreno 405 GPU. The phone will also feature 2GB of RAM and 16GB of internal storage, which thankfully, will be expandable via a micro-sd card slot. The phone will also boast a 16 MP rear camera and a 5 MP front camera, along with a 3050 mAh battery. For the display, the Galaxy A8 will pack a 5.7-inch full-HD Super AMOLED display and a fingerprint sensor doubling as the home button.
The internals of the phone are not really exciting by Samsung standards. At best, the Samsung Galaxy A8 will feature in the mid range category as it is nowhere in competition to Samsung’s flagship S Series offerings. However, the key drawing feature of this phone, as well as of the A Series lineup, will be its design, as the phone’s images show Samsung’s slimmest phone yet with a thickness of 5.94mm, having metallic sides and rather thin vertical bezels.
If you notice the trend, the Galaxy A series is becoming more of a testing ground for market feedback and reception, as far as design is concerned. And as far as Samsung is concerned, it was definitely late to the metal party.
The Galaxy S3 was the first to be criticized on its design, as many critics felt it continued to play out on the long drawn plastic that became synonymous with Samsung and all the devices it released. The Hyperglazed finish on the back drew mixed reactions from the public, with some loving the overall ease of handling of the device and some feeling that the device was not up to flagship standards, feeling more like a plastic toy than a forerunner of Touchwiz.
The Galaxy S4 continued on the Hyperglazed trend, with only a minor texture differentiation separating it from the previous year’s flagship. As an “improvement”, the bezels were faux-metal, trying to emulate metal through a chrome paint finish. The competition did not help either, as the Sony Xperia Z and the HTC One (M7), both were praised highly for their premium feel and their glass and metal builds respectively.
Moving on to the Galaxy S5, the band-aid design drew heavy criticism from both reviewers as well as the market, with many a meme made in its honor. This design stagnation and regression, along with only minor improvements on the spec sheet, translated into disappointing sales for Samsung’s flagship of 2014. In turn, the competition, specifically the HTC One M8, got wide appraisals as it became one of the top contenders for the best phone of 2014.
Indeed, the Galaxy S5 was the nail in the coffin for plastic designs, as Samsung then shuffled around top positions in its design departments in May 2014, roughly two months after the announcement of the Galaxy S5. Chang Dong-hoon, Samsung’s Head of the mobile design team, was substituted by Lee Min-hyouk who had served as Vice-President under him.
It was widely wondered whether such a shuffle in positions would yield tangible results. And as it seems, Mr. Lee did deliver. Announced in August 2014, the Samsung Galaxy Alpha became the first Samsung phone to feature a metallic body.
The phone, as far as design was concerned, featured a metal chassis. Not faux-metal this time, but actual metal which could be felt on the sides. The back of the phone continued on the band-aid design, but with minor adjustments done to it. Overall, the Samsung Galaxy Alpha brought Samsung’s metal game up to par with the competition, and it was only a matter of time till the design language would have been adopted over at the flagship level.
The Galaxy Alpha did have its own flaw: the pricing. The phone was priced at a rather whopping $650, while its specifications did not really offer as much value for the investment. Nonetheless, the Alpha was just the beginning of the metal trend for Samsung, as the Samsung Galaxy Note 4, announced in September 2014, evolved on the Alpha by opting for its metal frame.
Further along the line, the Galaxy A series replaced the Galaxy Alpha in favor of a more mid-range lineup to fight against the likes of Chinese competitors. The Galaxy A3, Galaxy A5 and the Galaxy A7; all followed along the same principles of metal-frame-plastic-back.
Here’s a quick GIF showing the design of the phones so far.
As you can see, all the phones tried to evolve from the previous ones, while still attempting to add their own flavor. Phones announced after Mr. Lee Min-hyouk’s appointment ditched plastic for the main frame, in order to achieve a more premium feel.
The shocker of the club came in the form of the Samsung Galaxy S6, as the phone looked inspired more from the iPhone 6 rather than the Galaxy Alpha or the A Series. Design wise, the phone went for a complete overhaul from anything Samsung had created previously. The body of the phone consists of a brushed metal frame, with Corning’s Gorilla Glass 4 on both the front and rear panels. Samsung entirely ditched the metal-frame-plastic-back, but still kept the look of the device inline with the Galaxy lineup. The end result is a phone that gave stiff competition to a previously-loved design of the HTC flagship, turning the tides in Samsung’s favor as HTC bore the heat of stagnating its design.
After the Galaxy S6, speculation ensued on which design line would Samsung focus on: whether they would continue on with the glass & metal look of the Galaxy S6, or whether the metal-frame-plastic-back look would make its return. With the Galaxy A8, mentioned and pictured in the very beginning of this article, Samsung does seek a return to plastic in the back panel (as it appears in the pictures).
With the announcement for the Galaxy Note 5 becoming imminent by the day, we can speculate on where Samsung wishes to lead the Note lineup. Currently, the company is at an interesting cross road on where it can adopt either design approach. The Galaxy S6 was a success as far as critic reception is concerned, so it would make sense for Samsung to go for glass the second time. That is what prominent leaker @OnLeaks has also suggested in one of his latest leaked renders.
Here's your very first look at the #Samsung #GalaxyNote5 ! Fresh from my "Leaky Foxconn Server" (LOL)… https://t.co/GqDaUcIVWj
— OnLeaks (@OnLeaks) July 6, 2015
However, the Note 5 also provides Samsung an interesting opportunity. Samsung could evolve the Note 5 from the Galaxy A8, opting for genuine leather à la LG G4 (instead of the faux-leather of the Note 4) along with the metal framework and trimmed side bezels of the Galaxy A8. This would help Samsung vary its product lineup in terms of design. The Galaxy S series could work for fans of metal and glass, the Galaxy A series serving for fans of metal and plastic (and its mid range prices), while the Galaxy Note lineup offers something for those who prefer leather and metal.
Irrespective of the course the Note lineup takes, we hope the days of all-plastic are past and buried deep. Samsung already does push the boundaries of smartphone internals, and now, it can push the boundaries of smartphone exteriors too.
What do you think of Samsung’s recent design trend and the work of Mr. Lee Min-hyouk so far? Do you think the Galaxy A8 and the Galaxy Note 5 will also meet success on their designs? Let us know your thoughts and views in the comments below!
Image Cred: GSMArena
It’s great to see the increasing adoption of certificate pinning in Android apps. When I run into an app that throws connection errors while attempting to proxy requests, I tend to become more interested in diving deeper. Such was the case when I recently used the Subway app. Reversing the APK revealed cert pinning among some other interesting findings.
Starting the app while proxying requests caused this error:
Pinning is simple enough to bypass. I started by decompiling the app and analyzing the source code for pinning keywords. I actually found pinning implementations in two separate classes that implemented X509TrustManager . Here is one of the methods that enforced pinning:
public void checkServerTrusted(X509Certificate ax509certificate[], String s)
throws CertificateException
{
if (ax509certificate == null || ax509certificate.length == 0)
{
throw new CertificateException(new IllegalArgumentException("No X509Certificates found."));
}
javax.net.ssl.TrustManager atrustmanager[];
int i;
int j;
try
{
TrustManagerFactory trustmanagerfactory = TrustManagerFactory.getInstance("X509");
trustmanagerfactory.init((KeyStore)null);
atrustmanager = trustmanagerfactory.getTrustManagers();
j = atrustmanager.length;
}
// Misplaced declaration of an exception variable
catch (X509Certificate ax509certificate[])
{
throw new CertificateException(ax509certificate);
}
// Misplaced declaration of an exception variable
catch (X509Certificate ax509certificate[])
{
throw new CertificateException(ax509certificate);
}
i = 0;
if (i >= j)
{
break; /* Loop/switch isn't completed */
}
((X509TrustManager)atrustmanager[i]).checkServerTrusted(ax509certificate, s);
i++;
if (true) goto _L2; else goto _L1
_L2:
break MISSING_BLOCK_LABEL_52;
_L1:
boolean flag;
label0:
{
s = PaydiantApplicationConfig.getPaydiantApplicationConfig().getPinningCertInfo();
boolean flag1 = false;
flag = flag1;
if (s == null)
{
break label0;
}
s = s.iterator();
com.paydiant.android.config.er er;
byte abyte0[];
do
{
flag = flag1;
if (!s.hasNext())
{
break label0;
}
er = (com.paydiant.android.config.Config)s.next();
if (er.print == null || er.print.length == 0)
{
throw new CertificateException(new IllegalArgumentException("Invalid X509Certificate info provided."));
}
abyte0 = messageDigest.digest(ax509certificate[er.osition].getEncoded());
messageDigest.reset();
} while (!Arrays.equals(abyte0, er.print));
flag = true;
}
if (!flag)
{
throw new CertificateException("Invalid X509Certificate used.");
} else
{
return;
}
}
Bypassing this was as simple as adding a return statement in the smali code to skip the pinning code in the method above. Note the addition of the return-void statement below:
.method public checkServerTrusted([Ljava/security/cert/X509Certificate;Ljava/lang/String;)V
.locals 13
.param p1, "chain" # [Ljava/security/cert/X509Certificate;
.param p2, "authType" # Ljava/lang/String;
.annotation system Ldalvik/annotation/Throws;
value = {
Ljava/security/cert/CertificateException;
}
.end annotation
.prologue
.line 583
return-void
if-eqz p1, :cond_0
After recompiling the App and installing, I was surprised to see this new error:
Subway was using a custom app signature verification process in order to prevent reversing of their APK. Grepping the source for mentions of this process, I traced it back to the following method:
public static void verifyAppSignature(Context context)
{
AppVerificationUtils.verifyAppSignature(context, PaydiantApplicationContext.getPaydiantApplicationContext().getKeyFingerprint(), new com.paydiant.android.common.util.AppVerificationUtils.IVerificationCallback(context) {
final Context val$context;
public void onVerificationComplete(boolean flag)
{
if (!flag)
{
Object obj = PaydiantApplicationContext.getPaydiantApplicationContext().getApplictionLabel();
android.app.AlertDialog.Builder builder = new android.app.AlertDialog.Builder(context);
builder.setTitle(0x7f0c02f5);
builder.setMessage(context.getString(0x7f0c02f4, new Object[] {
obj
}));
builder.setCancelable(false);
builder.setPositiveButton(0x7f0c006c, ((_cls1) (obj)). new android.content.DialogInterface.OnClickListener() {
final _cls1 this$0;
final String val$appLabel;
public void onClick(DialogInterface dialoginterface, int i)
{
dialoginterface.dismiss();
try
{
dialoginterface = Class.forName(new String(new byte[] {
97, 110, 100, 114, 111, 105, 100, 46, 99, 111,
110, 116, 101, 110, 116, 46, 73, 110, 116, 101,
110, 116
}));
Object obj = new Intent((String)dialoginterface.getField(new String(new byte[] {
65, 67, 84, 73, 79, 78, 95, 83, 69, 78,
68
})).get(null));
String s = context.getString(0x7f0c00ad);
((Intent) (obj)).putExtra((String)dialoginterface.getField(new String(new byte[] {
69, 88, 84, 82, 65, 95, 69, 77, 65, 73,
76
})).get(null), new String[] {
s
});
((Intent) (obj)).putExtra((String)dialoginterface.getField(new String(new byte[] {
69, 88, 84, 82, 65, 95, 83, 85, 66, 74,
69, 67, 84
})).get(null), context.getString(0x7f0c02f6, new Object[] {
appLabel
}));
((Intent) (obj)).setType(new String(new byte[] {
112, 108, 97, 105, 110, 47, 116, 101, 120, 116
}));
((Intent) (obj)).addFlags(0x800000);
((Intent) (obj)).addFlags(0x10000000);
context.startActivity(((Intent) (obj)));
Log.d(SecurityUtils.TAG, "Invalid App signature. Terminating ...");
dialoginterface = Class.forName(new String(new byte[] {
97, 110, 100, 114, 111, 105, 100, 46, 111, 115,
46, 80, 114, 111, 99, 101, 115, 115
}));
obj = dialoginterface.getMethod(new String(new byte[] {
109, 121, 80, 105, 100
}), new Class[0]).invoke(null, new Object[0]);
dialoginterface.getMethod(new String(new byte[] {
115, 101, 110, 100, 83, 105, 103, 110, 97, 108
}), new Class[] {
Integer.TYPE, Integer.TYPE
}).invoke(null, new Object[] {
obj, Integer.valueOf(15)
});
return;
}
// Misplaced declaration of an exception variable
catch (DialogInterface dialoginterface)
{
Log.d(SecurityUtils.TAG, dialoginterface.getMessage(), dialoginterface);
return;
}
// Misplaced declaration of an exception variable
catch (DialogInterface dialoginterface)
{
Log.d(SecurityUtils.TAG, dialoginterface.getMessage(), dialoginterface);
return;
}
// Misplaced declaration of an exception variable
catch (DialogInterface dialoginterface)
{
Log.d(SecurityUtils.TAG, dialoginterface.getMessage(), dialoginterface);
return;
}
// Misplaced declaration of an exception variable
catch (DialogInterface dialoginterface)
{
Log.d(SecurityUtils.TAG, dialoginterface.getMessage(), dialoginterface);
return;
}
// Misplaced declaration of an exception variable
catch (DialogInterface dialoginterface)
{
Log.d(SecurityUtils.TAG, dialoginterface.getMessage(), dialoginterface);
return;
}
// Misplaced declaration of an exception variable
catch (DialogInterface dialoginterface)
{
Log.d(SecurityUtils.TAG, dialoginterface.getMessage(), dialoginterface);
}
}
{
this$0 = final__pcls1;
appLabel = String.this;
super();
}
});
obj = builder.create();
((AlertDialog) (obj)).getWindow().setType(2003);
((AlertDialog) (obj)).show();
context.sendBroadcast(new Intent(SecurityUtils.ACTION_APP_VERIFICATION_FAILED));
}
}
{
context = context1;
super();
}
});
}
This was an interesting attempt at preventing reverse engineering, though it actually only caused a slight delay. In order to bypass this process, I simply added a line to skip the method’s execution by adding another return-void line, similar to the pinning bypass process above.
.method public static verifyAppSignature(Landroid/content/Context;)V
.locals 2
.param p0, "context" # Landroid/content/Context;
.prologue
.line 70
return-void
invoke-static {}, Lcom/paydiant/common/PaydiantApplicationContext;->getPaydiantApplicationContext()Lcom/paydiant/common/PaydiantApplicationContext;
After recompiling and installing the app, I was able to successfully proxy requests:
During my research, I stumbled on this Reddit post. Apparently, Subway was also determining whether the user’s device had been rooted. I searched around in the source and confirmed mentions of root detection methods.
public static boolean isDeviceRooted(Context context)
{
A aa[] = new A[12];
aa[0] = new t>("find /system/app/Superuser.apk");
aa[1] = new t>("busybox df");
aa[2] = new t>("/sbin/su");
aa[3] = new t>("/system/bin/su");
aa[4] = new t>("/system/xbin/su");
aa[5] = new t>("/system/su");
aa[6] = new t>("/system/bin/.ext/.su");
aa[7] = new t>("/system/usr/we-need-root/su-backup");
aa[8] = new t>("/system/xbin/mu");
aa[9] = new t>("id");
aa[10] = new t>("cat /system/build.prop | grep ro.build.tags");
aa[11] = new t>("pm list packages");
A aa1[][] = new t>[12][];
aa1[0] = null;
aa1[1] = null;
aa1[2] = null;
aa1[3] = null;
aa1[4] = null;
aa1[5] = null;
aa1[6] = null;
aa1[7] = null;
aa1[8] = null;
aa1[9] = (new t>[] {
new <init>(new String[] {
"uid=0(root)"
}, null, null)
});
aa1[10] = (new <init>[] {
new <init>(new String[] {
"test-keys"
}, null, null)
});
aa1[11] = (new <init>[] {
new <init>(new String[] {
"eu.chainfire.supersu", "com.thirdparty.superuser", "com.koushikdutta.superuser", "com.zachspong.temprootremovejb", "com.ramdroid.appquarantine", "com.noshufou.android.su"
}, null, "1")
});
int j = 0;
java.util.List list = null;
int k = aa.length;
for (int i = 0; i < k; i++)
{
A a = aa[i];
if (aa1[j] != null)
{
list = Arrays.asList(aa1[j]);
}
if (a.ute(list))
{
Log.d("com.paydiant.android.common.util.RootedDeviceUtils", "Device is Rooted");
return true;
}
j++;
}
if (isCyanogenmodSuperuserExist(context))
{
Log.d("com.paydiant.android.common.util.RootedDeviceUtils", "Device is Rooted");
return true;
} else
{
Log.d("com.paydiant.android.common.util.RootedDeviceUtils", "Device is Not Rooted");
return false;
}
}
This is a great example of an app taking security very seriously, but I’m not quite sure of the reasoning behind the root checking process. Though certificate pinning and signature verification techniques are generally a good idea, they only slightly impede the reverse engineering process.
The YotaPhone 2 has released its kernel source. That and much more news is covered by Jordan when he reviews all the important stories from this week. Included in this week’s news is the announcement of a 50% rebate on Android Nanodegrees and be sure to check out the article talking about Windows 7 booting on the ASUS ZenFone 2. That’s not all that’s covered in today’s video!
Jordan talks about the other videos released this week on XDA TV. XDA TV Producer TK released an Xposed Tuesday video covering ProtectedApps. Then TK gave use a beginners lesson on flashing a custom ROM. Also, TK gave us an app review of Solid Explorer. Pull up a chair and check out this video.
Be sure to check out other great XDA TV Videos
Check out Jordan’s YouTube Channel and Jordan’s Gaming YouTube Channel
Android Developer Preview 2 is now available just two months after the original was released. The update brings many improvements and bug fixes including those reported by developers during the first preview. Google recommends that developers update to the new version as soon as possible.
Smartphone theft protection and security has become a serious concern as of late, with numerous official solutions such as Google Device Manager arising in addition to third-party ones like Cerberus and Comodo. One such official solution is Sony’s My Xperia app, which functions similarly to Device Manager, allowing you to locate, lock, factory reset or ring your device.
However, all is not well with Sony’s Theft Protection, as it has recently come to light that using the service prevents users from unlocking their device’s bootloader, which is a justifiable reaction, given that modifications may interfere with the device security. However, the real problem lies with users who already have an unlocked bootloader, with Sony releasing a disclaimer on their website stating that such users may experience device “malfunctions”:
“After unlocking your device, you should not enable My Xperia (found in the settings menu under security on some devices running Android 5.0) as this might cause the device to malfunction.”
While the malfunction isn’t explained, and could be anything from a minor reboot to a bricked device, users are better off not taking a risk, and disabling My Xperia. Have you faced any issues on your Xperia using My Xperia? Let us know in the comments section below