Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment MITM (Score 2) 76

I'm not sure if this is still true, but I do know that last week the Play store was still using HTTP downloads for the actual APK files instead of HTTPS (even though the API calls do use HTTPS). As such, even downloads from Play may be susceptible to man-in-the-middle attacks. I can't possibly explain it better than this group of comments:

http://it.slashdot.org/comments.pl?sid=3950207&cid=44220885

I'm not saying it's likely - but it doesn't seem impossible either. Seeing as it will be a long time before the average Android user will be running a phone with this patch, I would call "crisis averted" too soon. Of course, we don't know if the complete HTTP download is still verified with checksum gotten from the HTTPS API, but somethow I doubt it.

Comment Re:I've been using Android on one for a while (Score 1) 247

Even if it was $300, it would still be more than 6 times as expensive... the dollars come in here to show it is an absolute budget device, and as somebody else stated, how much effort went into the device.

These budget sticks usually have very slow RAM and flash (storage), with constant I/O stalling going on. This is a major part in the constant jerking and freezing. Especially noticeable the first few minutes after boot, but you'll pretty much notice it all over the place.

There's often kernel issues as well, as these budget OEMs often don't put in the time, effort and money to fix issues and/or optimize it. That's not a generic Android problem, it's an end-product problem.

The point is, what you're seeing is representative for the MK808B, not for Android. These things differ greatly per-device and their components. As such, "sluggish, jerky, freezing, ungainly and wonky" may not (or may) apply to other devices. There are many Android devices out there with lower specs than the MK808B that have much smoother performance ...

I'm not saying Android isn't slower, more jerky, more sluggish, etc than iOS would be on identical hardware, that might well be so - it just doesn't make sense to reach that conclusion based on your experience with the MK808B vs your iPhone4, as the specs aren't the same, and the numbers you are looking at do not represent fluidity - you've left out some major components to that equation.

Comment Re:Android Security? (Score 1) 107

I dabble in Android security myself, I just want to point out that every single app I have encountered that Trend Micro flagged has been a false positive warning about an exploit that isn't actually present. The cause of this appears to be that those apps include files or snippets of code also used by some well known exploits, but by themselves are not harmful. Rookie mistake.

Note that if you search well, you will find various security folk slamming Trend Micro all over the place. As such, I wouldn't put too much faith in whatever Trend Micro has published, they don't exactly appear up to speed on matters.

Android

Submission + - Google removing ad-blockers from Play (androidpolice.com)

SirJorgelOfBorgel writes: It appears Google has begun removing ad-blocker apps for Android from the Play store, citing breached of the Play Store Developer Distribution Agreement. The apps would be welcome back as soon as they no longer violated the agreement, though that doesn't seem possible while keeping the apps' core functionality intact.

Comment Re:Root (Score 1) 153

Who said anything about rushing ? That specific problem has been known for a long time, and most affected devices have received several updates since then. The fix is literally a one-liner in the kernel source, disabling "secure erase". When a user "resets to factory settings" (e.g. wipe all user data) the device performs an erase command. Somewhere in Android 3.x or 4.0 Google changed the default behavior from normal erase to a secure erase. The eMMC chips Samsung used were never properly tested for this, and due to a bug in the firmware of said eMMC chips, the flash memory would be corrupted during a secure erase, rendering the device completely unusable.

It's pretty much a jackpot affair, you hit the factory reset button, x% chance you end up with a full brick. Custom firmware users were much more likely to run into this because often a custom firmware would perform a factory reset upon installation - and a normal user would rarely use this function. But you did not need to run any custom software for this - it can happen on a fully original device without any modifications or even apps installed.

A few months ago, Samsung finally issued a fix - but this fix disabled secure erase being triggered by the format command itself, instead of disabling secure erase in the actual kernel. As a result, custom firmware users would still brick left and right, due to using Google-private update binaries that did not have this call disabled. They put a band-aid on the issue instead of actually fixing it (a one-liner to disable "secure erase" at kernel level (because it never actually works correctly) and revert to "normal erase" always).

Now, I have discussed these issues in person with high-level Samsung engineers, and in their opinion, how they fixed it is correct - even though an exploit like the one presented in this article allows a malicious attacker to hard-brick your device at will, thanks to this eMMC bug. Incidentally, that is exactly what I myself, as well as a number of other developers from the enthusiast community, have kept telling Samsung: with the current solution, all you need is an exploit and a viral app, and you could well end up with millions of hard-bricks.

Note that Samsung does usually warranty on a full hard-brick, so it doesn't have to be a real problem for the end-user, but if this got out of hand, it could easily cost Samsung millions and millions of dollars in repair costs. Just because it hasn't happened yet and it really is not that likely it will occur, it is certainly possible.

Comment Re:Root (Score 2, Interesting) 153

"although it would have been nice if he reported it to Samsung a little in advance of the release of the problem"

While that would have been nice, it is very debatable if it is wise. With Samsung, you just don't know. Security holes have been reported to Samsung that have been fixed nigh instantly, while other well known problems that can cause hard-bricks (device becomes a non-recoverable paperweight) on various devices have been known for almost a year - including the fixes - and the issue is still present in the latest firmwares.

And in the exploit author's defense (as if needed), he actually says somewhere he didn't know whom to contact so he just put it on XDA, assuming it would somehow get to the right people. And even though it is weekend, I'm sure various Samsung engineers on the right levels are aware of the problem :) The not knowing who to contact thing is a valid issue - if you don't have any "ins" at Samsung, it's actually pretty hard getting this kind of information to the right people.

Slashdot Top Deals

Have you reconsidered a computer career?

Working...