Related
To preface I am ignorant of the practical process/exploit for each of these devices. Knowledge of which may completely negate the point made here.
*CAUTION: Philosophical musings below*
It seems like we are seeing the most recent root successes being a result of a Race Condition exploit, as in: the Incredible, the ERIS ("Leakers" root) and, as far as I can tell so far, the DROID X.
Have devs stumbled upon a cross device methodology for achieving Root access on android based devices? Give the sheer variety upon android based devices I would have thought that a common approach to rooting being out of the question in anymore then a purely conceptual sense. Now,it seems like I may be wrong, and a common approach (baring certain practical differences) is in fact possible.
Thoughts?
The patent orifice here in the US just started a new web site where anyone can look at current patent applications and report if they have knowledge if the patent application may not be valid due to "prior art" or if it is already patented. I saw one article that said a patent officer only has about 22.5 hrs of research time allotted to each patent.
Should stop some of the frivolous patents issued and the related frivolous lawsuits that have inevitably followed. Kind of like a rectangle with rounded corners. LOL.
That was just an example. I don't want this to turn into another apple/google flame war.
This is a good thing, Help out the overburdened patent officers. and it will help out in many areas besides just IP or electronics.
News article:
http://www.makeuseof.com/tag/patent-offices-opens-website-uncover-prior-art-updates/
Actual patent orifice site:
http://patents.stackexchange.com/
OK lets move forward on this, opened. Thank You
http://www.moneycontrol.com/news/te...-similarities-between-8xlumia-820_761987.html
Oh suits are going to be going on for a while. Sooooo many patents were granted that should not have been and a lot of those we will see in the courts.
Maybe this new process will prevent bogus patents from being granted in the first place just for the simple fact that patent agents did not have time to sufficiently research previous patents or validity before they were granted.
Wow!! I can't believe there aren't more comments on this.
This is going to be HUGE!!!! The difference in what patents are granted and, in the future, what lawsuits are allowed to be filed!
This may make it easier for someone to find a patent they can challenge, but the process of challenging patents probably goes back to the late 18th century. My job in late 1960 was reviewing patent applications (we subscribed to a service that sent us extracts of all applications) to see if they would infringe on anything we had done, or were prior art. That's over 50 years ago.
Being able to use a computer to search for words would make it a lot easier, but it was definitely being done back then.
Responsible Disclosure is a term often used in security, but what is it?
In essence, responsible disclosure is the process of making the vendor or OEM of the vulnerable software or system aware of the problem before disclosing details of the vulnerability to the public. The idea here is that the vendor will promptly solve the issue, and release a fix to users of the software, and accredit the finding of the issue to the researcher, who then discloses the vulnerability in full, now the software has been patched.
Responsible disclosure is named as such, as vendors feel it's the most responsible way to go about handling a security issue you have found. It's often the best strategy to try if you do find an issue - look for a security contact for the company, and give them a shout.
Unfortunately, some companies are rather poor at dealing with security issues, and either don't respond, or don't issue a patch or inform users of a mitigation strategy. Or in severe cases, might not even inform users of there being an issue whatsoever, and appear to ignore the vulnerability. Do bear in mind though when dealing with mobile devices that many carriers add significant delays to software releases (where on the desktop, a fix may be available the next day, the OEM might take a week or more to make a patch available on unbranded firmware, since devices and firmwares often must be approved by regulators before release, and carriers will then want further changes applied to these firmwares before their own testing).
Often if a vendor acts like this, the only solution is Full Disclosure, a process where the full details of the vulnerability are publicly released, in order to raise awareness of the vendor's insecurity and inaction (particularly if efforts were already made to contact them). Full disclosure permits the end user to be made aware of the extent and details of the security issue, and attempt to mitigate or resolve it themselves (for example, by removing an affected plugin, deleting an APK, or using a firewall to prevent access to a vulnerable service until a fix is produced).
If you are new to security, and are unsure, responsible disclosure is usually the best way forwards, but there are plenty of people around who can give good advise about this. This may well change, in light of recent practices by some companies pertaining to how they handle security vulnerabilities which are responsibly disclosed (see https://www.openrightsgroup.org/blog/2013/nsa-affects-responsible-disclosure)
Good writeup, thanks!
Is full disclosure really an effective way of handling things though? I can understand that the intention is to make the vulnerability so well known that vendor has no choice but to fix it, but during that lead time there's going to be a vulnerability going around that people could really capitalize on. I don't have figures, but I would imagine that even if a user-made solution is found, the number of people that would actually adopt it has got to be a tiny fraction of a percent. If you're going full-disclosure, aren't you essentially ensuring the worst-case scenario? Security through obscurity is weak, but isn't it still better to sit on your hands and just hope that the vendor will get around to fixing it eventually?
Grand Guignol said:
Good writeup, thanks!
Is full disclosure really an effective way of handling things though? I can understand that the intention is to make the vulnerability so well known that vendor has no choice but to fix it, but during that lead time there's going to be a vulnerability going around that people could really capitalize on. I don't have figures, but I would imagine that even if a user-made solution is found, the number of people that would actually adopt it has got to be a tiny fraction of a percent. If you're going full-disclosure, aren't you essentially ensuring the worst-case scenario? Security through obscurity is weak, but isn't it still better to sit on your hands and just hope that the vendor will get around to fixing it eventually?
Click to expand...
Click to collapse
True, but also depends on the type of vulnerability. Is not the same finding a vulnerability where you need physical access to the device (ie a way of unlocking without PIN) than finding a vulnerabilty that allows remote access to sensite data without user action. I suppose that some sort of waiting can be defined. Like waiting for a week for the first type of vulnerabity and 3 months for the other....just my 2 cents.
Great writeup BTW!
For the security enthusiasts here: The Full DIsclosure Mailing List has been reopened. ENJOY!
Talking about responsible disclosure, I have the following question for you guys:
I found a vulnerability that can be exploited to drain the battery of a device. I informed the application vendor and they reacted that they agree with my finding and will fix it soon. I send my vulnerability and PoC 24th of February and they responded 3 weeks after. Now I am waiting for the vulnerability to be fixed.
I found this bug when writing my thesis and I really want to include it in my paper which should be published on the 31th of May. Does that fit responsible disclosure? Should I send them an e-mail stating that I will publish the details at the end of May?
It can't hurt to let them know youre doing it.
Sent from my Xperia ZL using XDA Free mobile app
Is full disclosure really an effective way of handling things though?
rakoczy12 said:
Is full disclosure really an effective way of handling things though?
Click to expand...
Click to collapse
If the end result of the disclousre is that the users can protect themselves, then yes. As the OP pointed out:
pulser_g2 said:
Full disclosure permits the end user to be made aware of the extent and details of the security issue, and attempt to mitigate or resolve it themselves (for example, by removing an affected plugin, deleting an APK, or using a firewall to prevent access to a vulnerable service until a fix is produced).
Click to expand...
Click to collapse
How did I just now see this forum? Pulser I was talking to you about such an area for many many moons ago.
@pulser_g2
I have a question about posting things I find that script kiddies would love. Like today, I opened up an apk that was supposed to be an icon pack. Instead, it has @Stericson 's RootTools package in it and someone else's libpush work. So it starts out as a script kiddies dream, cause that's all it is. But it would be good for people to learn from.
When I came here, before I installed @DaveShaw 's power menu .cab, I first learned what a cab was, what it did, how it worked, and what all the little bits and pieces did inside of it. You just can never be too safe. Which is probably why I don't go jumping on a new ROM, or app someone just released. I'll mull it over and let some other people be the testers. How could I post something like without giving away how it works, but showing what's inside. So as to let people know to be careful? Teach them how to open it up, the different parts of an apk, how to read it and such. That's the kind of thing I was meaning way back when I was asking you about making this kind of area. But you had the same concerns as me. It not turning into a scriptkiddy funhouse.
Are we going to be able to disclose threats among ourselves? You can't make everyone wear a white hat. Lord knows we didn't all wear one back in compsci. I see it like teaching firemen how to put out a fire. Yea they are going to learn what makes a really big fire that's hard to stop. But if you don't teach them how to build the fire, just put it out, then they have to go through just that extra bit of effort to do bad.
Maybe some parts of this thread belongs here. http://forum.xda-developers.com/general/security/security-threat-middle-attack-umts-t3374626
It is Awesome
wow
Perhaps upon reading that, you call to mind Thomas Jefferson pulling out his Android to thwart impeding forces. I actually like that idea, but I know that the time in which John Locke wrote the contributing phrase was much different than today. It was a time of change and also a time when people realized their full potential to make a difference. In the spirit of our Founding Fathers, and in an exercise of my own Personal Liberties, I have started a petition to require cell phone carriers to allow bootloader unlock on any Android device that is not under contract or subsidy. Many of you will know immediately what this means, and the exponential benefits of such a law. Many of you will flip to the next activity complacently believing this does not affect you. If you do not understand, I wish to enlighten you as to how this affects each and every Android user in the world. Signing the petition takes only a few moments of your time and adds to the greater good of our technology and innovation as a Nation.
So what exactly does this “Bootloader Unlock” thing mean?
Well, that is a great question. Most simply put, according to Motorla’s website, “bootloader is a little bit of code that tells your device's operating system how to boot up”. That does not mean much to the average user, I am sure. What it means in my own words is it is a piece of code that dictates what I can and cannot do, in terms of software modification, to my own personal Android device. On my wireless provider whom I will call Big Red, their requirement is that OEMs (Original Equipment Manufacturers, or simply phone makers) lock this bit of code to prevent modification by the end-user or customer. I am certain, to those that do not wish to modify their devices, this sounds like a good fail-safe to avoid breaking their devices. I am also certain that to those like myself, those who have the experience and knowledge to do things like flash custom firmware or software and modify our devices to suit our own personal taste and needs, this is a huge roadblock and an impediment on what we can do with our own personal property and how it can be improved. In order to modify system files as the user sees fit, a thing called Root is required. Root is, most simply privileged access to a phones file system. A locked bootloader means that in order to gain “Root” access, a security exploit must be found and exploited in order to modify system files. These exploits are literally holes that must be (and typically are) patched in software updates sent out by the service providers or manufacturers to protect the end-user. While the efforts of the security experts are always going to be required to keep us safe and updated, I personally do not want to rely on someone to hack the software so it can be modified. This should be an inherent ability of any user who does not have a subsidy or contract obligation. I also feel that any device that can be updated by the user allows the people who develop for Android to Innovate and push our technology farther forward. When manufacturers are required to lock down a device, ultimately, the user is the one who loses. My first Android device, the Droid 1 or A855 ran an under-volted overclocked kernel (simply another piece of code that tells a device how to boot and how to run its processor among other things) that ran 1.7ghz on it’s ~600mhz processor. I used that phone at least twice as long as I would have if it hadn’t been bootloader unlocked. Also, on the note of the OG Droid, I can say that this was the phone that helped Verizon to compete with the Iphone, bolstering the customer base and creating mass knowledge of the Andoid platform. This was done with a bootloader-unlocked device. It seems that once the market was realized, bootloader locking became the normative. The Droid line has been bootloader-locked ever since. There are several examples of the same hardware being sold, under different names, with the bootloader-unlockable right out of the box. The most recent example of this is the Motorola xt1250, or Moto Maxx (US CDMA). The international version of the same phone, the xt1225 is also bootloader-unlockable. All three are known as the Quark. They are identical in hardware aside from exteriors. Big Red required their version to have the bootloader locked. There is no way to have it unlocked for now.
So Why Would I Want to Sign This Petition?
Honestly, you may not care about Android at all. You could conceivably have never been interested, and care less. However, the technology available to you today is available because of innovations and advancements that have been made across a wide technological array of development. Android is no different. Love that Halo or Heads Up inspired feature ____ manufacturer just put on your new phone? People who develop are to be thanked. The possibilities are endless for what can be done and applied across many platforms. The future of mobile technology can be greatly advanced by creating open access for all who are inclined.
Catharsis
Okay, I admit it. It is really, really unlikely our politicians actually act upon this petition, even if 100,000 signatures are reached. As much as I like to think our law should “fix” things that are wrong, I can agree with one of my favorite developers from back in the day, @adrenalyne, when he said [government typically does not, and should not interfere with private business.] I can agree with that on the same grounds by which I feel we should be granted bootloader unlock on…if and only, if, no one’s rights are infringed upon. I feel it is all of our right to do what we please with our own personal property. There was a great analogy given on XDA Developers forum in the bounty thread where this all started by @Wynnded In essence, it said the carrier provides the highway, the OEM provides the device, but it is the carrier’s highway, so if the carrier requires the OEM to lock it down so be it. Personally, I feel that if the carrier has a highway, it is a toll-road, as I pay for my service. I purchase my vehicle outright, so if I want to modify it, and I pay for my vehicle, making no obligation to said toll operator, it is not within their range of rights to tell me I cannot modify my vehicle in the way I see fit. Thank you for your time. –kitcostantino @ medicbeard on twitter #unlockthedroids
https://petitions.whitehouse.gov/pe...e-not-subsized-or-attatched-contract/QfTmsspy
Original thread:
http://forum.xda-developers.com/dro...unlock-bootloader-root-turbo-t2927958/page115
Sources:
https://motorola-global-portal.custhelp.com/app/standalone/bootloader/unlock-your-device-a
http://en.wikipedia.org/wiki/Rooting_(Android_OS)
I ask for no donations, nor anything else. Simply share this if you feel so compelled. Really, it hurts nothing even if you don’t.
#unlockthedroids
There is an ongoing thread at the Official Flash Community about a possible "spyware" embedded in the firmware of TCL / Alcatel Flash Plus 2 and Flash 2 smartphones.
A local TV station might have also picked up on the story and is now following this as well.
You guys might want to check this out:
Code:
hxxp://community.flash3c.com/t/fp2-secretly-phoning-home-to-china-server/13708
Seriously though, is there still any Android smartphone manufacturer that we can still trust aside from Samsung?
Yes, Adups has already been found doing this before (see previous thread about Blu phone etc), they claim it's nothing to worry about but in my opinion it's is (especially for some people eg my sisters work duties has put her up against Chinese SOE's) due to the data sent & the identifying data & ability to make changes without user knowledge and possible the tentacles of the CCP government reaching into the company if it so chooses it could then monitor her & put her and her colleagues at risk given some of the dodgy countries she's had to go to.
Some of the guys are getting worked up about this on the crackberry forum as TCL is Blackberry's subby (though the thread quickly veered off to Blackberry hardware, so unrelated to the Adups issue).
http://forums.crackberry.com/genera...ding-customers-data-china-1095845/index4.html
FWIW, I agree with Sorinv & DaFoxGrey that it's possible (well to some degree) without Blackberry noticing as they would not test every phone for this sort of thing from every production run, and it may not trigger any connection unless under specific conditions. It could be done via a compromised employee flashing dodgy firmware or amended wafer negative when running a batch, though would be hard to pull off even by government agents. But that's all on a whole different level to the Adups issue, besides I don't think Blackberry phones have that app or Baidu apks etc so for them it should be a none issue, but for Chinese phones .......
As for trusting Samsung ..... they are part of a huge conglomerate with close links to an opaque government who are susceptible to influences of a few powerful families & others, so they would not be immune. Nor their employees being immune to blackmail to make changes. That said they are who I have put my faith in for the time being. At the end of the day we all have to trust someone, as I'm sure you are aware.
Trust is a matter of perspective. Most devices from China oem are expected to have e this as their government requires it to monitor its citizens. Which is completely legal there and why most devices from China are banned to be owned by US government employees. It's just the way it is.
If trust us a big thing then the last thing you should be buying is an oem device. Get a nexus and then you can see every bit of code you put into your device.