yashsingh1/xdaforums huggingface dataset:
[Motorola Droid 3] Pokelover980:
I don't use CodeSourcery's compiler, it kept causing me issues when trying to compile zsh, so I switched over to some packages I found in the Ubuntu software center (you can probably find them for other distros too) fittingly named arm-linux-gnueabi-***-4.# where the asterisks denote the compiler (gcc and g++) and # represents the version (I got both 4.4 and 4.5, though have been using 4.5).

Anyways, I compiled the code (as well as a bajillion other Linux kernel exploits just to make sure they couldn't be ruled out >_>) and it would work if we could hardlink, which we cannot.
[Motorola Droid 3] rweb:
It came back empty because there is no executable objdump on D3. You need to compile and copy it to your device before.

Or download the Android source and check there. I don't think D3 differs much to stock Android here.

Maybe I'll find some time to have a closer look at this, too. It is possible this exploit could help us.

EDIT: The exploit isn't 1:1 transferable since D3 has no cron. If it works, we would "only" be able to create a root-owned file on a rw-mounted partition. This would be a huge step, but we'd still need another idea how to really gain root access out of this.
[Motorola Droid 3] isaacgaretmia:
Don't forget... we don't necessarily need to find ONLY a file owned by root. System privileges might be sufficient enough to provide access to a directory with a root-owned file in it.
[Motorola Droid 3] isaacgaretmia:
Wait... that's perfect. The reason our hard-links weren't working was because we didn't have access to root-owned binaries on our accessable partition. This exploit would give us the file we need to hard link to.

Forget about cron... just get us the file. :)
[Motorola Droid 3] rweb:
I will try, but cannot give you a timeframe, I have to get familar with all this Android related stuff.

However, what you intend will not work, for 2 reasons: /system is mounted read-only, and the exploit can only create files, no hardlinks or directories.
[Motorola Droid 3] sparkyman216:
What about the debug that is stored on our sdcard that is also on the phonevits self.
[Motorola Droid 3] sparkyman216:
Bug2go I mean
[Motorola Droid 3] isaacgaretmia:
The way i read it, we don't need you to create directories OR hard-links. The hard link we create as part of our exploit. The only thing we need for our exploit to work is a root-owned file that we can hard-link to - which i believe your exploit can get for us.
[Motorola Droid 3] sparkyman216:
What about under mmt
[Motorola Droid 3] sparkyman216:
Mnt
[Motorola Droid 3] onethreeteeh:
if we want to use the hard link exploit, then it will need to have the suid or guid bit set as well. If we get a root owned file, that has either suid or guid, somewhere on /data (preferably /data/tmp) then we sould be able to get it to work
[Motorola Droid 3] isaacgaretmia:
Ah. I almost knew i was forgetting something...

Still, readable and writable...

...

Nah, I don't see how it's more than we had before... need to think more on this.

Edit:

It's root owned. That's how it's more than we had before.

Any way of going about setting bits ourselves, or adding something to the file that we can persuade root to execute? O.o
[Motorola Droid 3] onethreeteeh:
i'm pretty sure that we'd need root to chmod a root-owned file. i'm not sure which exact exploit was the one that could create a root owned file, but would it be possible to set the suid/guid bit as part of it?

another option is to continue along the lines of the dockless photon root exploit. we know that libpcprofile.so isn't on the d3, but that doesnt mean that none of the other DSO's aren't vulnerable. Someone posted the find command to check for vulnerable ones, but it wouldnt run on the phone because it doesnt have objdump. if someone copies the /system/lib folder to their sdcard and then to a linux box, they'll be able to do it through the terminal there. I'd do it, but i wont have access to a linux machine for another 12 hours or so
[Motorola Droid 3] calash:
I just did copy the system/lib to my card, then to my Ubuntu box. Running the command ended up with a bunch of errors like this:

Sections:
Idx Name Size VMA LMA File off Algn
objdump: section '.ctors' mentioned in a -j option, but not found in any input file
[Motorola Droid 3] onethreeteeh:
that's strange, i was pretty sure that all those files would have .ctors sections... I'll take a look tomorrow and see if i can find anything interesting
[Motorola Droid 3] isaacgaretmia:
The exploit you're talking about IS the one that will get us a root owned file. We can't complete that exploit because... well, i'll just quote it. :)
[Motorola Droid 3] onethreeteeh:
if you read the cve, it's stated that using cron isnt the only possible way to exploit it.

if you look at the photon root script, it's inserting a custom .so, rather than running cron
[Motorola Droid 3] edgan:
I did that exploit on the Photon, and it depends on glibc. The D3 only has bionic, Android's libc. It is a no go. The glibc comes from webtop on the Photon.
[Motorola Droid 3] edgan:
pppd-ril you can't run if I remember right, and run-as is very simple. Google for run-as.c and read the source.
[Motorola Droid 3] isaacgaretmia:
That wasn't the point of the exploit. It didn't matter whether they did or not. The point was to set the origin to the binary in order to hijack its root permissions. The way I read it, it didn't have to be executed at all.

Plus, it's irrelevant anyway. We need a root owned file with suid or guid bits on the data mount point.

Please? O.o
[Motorola Droid 3] rweb:
But there is no exploit which promises to be able to create a suid root. With such an exploit we most likely would be already all set.

These are all dead ends.

I will do more research on the exploit I mentioned yesterday. As is, it will not work for us because because the Android kernel has no econet support. But it is a combination of vulnerabilities, and Android kernel should be affected by the main vulnerability, and the developer said it could be combined with others.

This could take weaks and may end in a dead end (I'm really not experienced in this kind of hacking), too, but AFAICS this is the only chance to get root out of a Linux exploit.

I hope root out of an update or SBF will be available earlier. :-)
[Motorola Droid 3] elkay:
Roots out of updates and SBFs all require prior rooting or an already unlocked bootloader from what I've seen. Not sure that's going to help us, either.
[Motorola Droid 3] royolpunk:
SOURCEEEEEEEEEEEEEEEEEEEE

http://bit.ly/oS7k1U
[Motorola Droid 3] elkay:
Funny, I just checked for these on the Moto dev site last night.
[Motorola Droid 3] saintlikesniper:
hope this helps us root
[Motorola Droid 3] Adam.h.ogle:
I compiled the exploit for ARM and push it and a random executable with suid/guid to the /preinstall partition. The random executable was owned by root:root. The exploit did NOT work. When I read further about it, it will NOT work on a partition mounted with nosuid. This leaves /data/tmp as the desired partition for exploits, but we don't have a way to get something owned by root to it.
[Motorola Droid 3] isaacgaretmia:
Am I correct in assuming that besides root, system also has permission to write to /tmp?

If so, do we know of any other groups that may also have said permissions? I am well aware that sandboxed apps most likely do NOT, but there are other groups such as radio, bluetooth, and those mysterious moto_xxx groups that probably can do a few things...

Specifically, if moto_xxx groups have permissions, they might be another avenue into root. We no longer need a root exploit from them, just write permissions...
[Motorola Droid 3] onethreeteeh:
anything can write to /data/tmp, but even if something there that we've made, which has suid set, it's not owned by root so it wont get root privileges.

you can use find to find a list of files that have suid or guid set, but as app's and shell dont have read privileges for a lot of folders, its not a complete list
[Motorola Droid 3] Adam.h.ogle:
All partitions that can contain a setuid/setgid executable are either mounted read-only or nosuid.
[Motorola Droid 3] royolpunk:
We really just need an sbf xD
[Motorola Droid 3] isaacgaretmia:
I believe it has been amply pointed out already that an sbf is useless with a locked bootloader and/or an unrooted system.

Please, PLEASE tell me I'm wrong, but if i'm not, i'm starting to get tired of people mooning after an sbf that very realistically may not come for some time now, and actually may be useless when/IF it gets here.

/endrant
[Motorola Droid 3] calash:
Can somebody explain to me why the following did not work:

Using terminal I copied busybox to /tmp/ and gave it 7777 to set the suid and sgid bits. The resulting file was owned by app_192.

Logging in via adb I executed ./busybox sh . I expected the results to be a shell owned by app_192, yet I ended up with a shell owned by shell.

Am I not understanding what suid should be doing?
[Motorola Droid 3] rweb:
Because nothing is executed automatically as the user, if a suid bit is set. The program has to perform the change user id. Busybox of course doesn't do this.
[Motorola Droid 3] calash:
Ok, I see it now.

Browsing some if the source code, right now for run-as, and I see the setresuid command where it changes everything.

Thank you :)
[Motorola Droid 3] isaacgaretmia:
Edit: scratch that... forget it.

Edit2:

http://seclists.org/fulldisclosure/2010/Oct/423

There are 5 sudo exploits here.

Does sudo exist on android?
[Motorola Droid 3] Pokelover980:
EDIT: Ah, I see you retracted your statement before I posted.
[Motorola Droid 3] royolpunk:
If you want the fastest answers I would go on the IRC channel and ask
[Motorola Droid 3] isaacgaretmia:
I'm viewing this at work. I'm sure my brother and father (whom i work with) wouldn't be too pleased at me taking it one step further.

I'd like to, but it would have to be at home. I don't get home till late.
[Motorola Droid 3] evulhotdog:
Well you know the internet doesnt stop :)
[Motorola Droid 3] Adam.h.ogle:
You have it backwards. A program that has the setuid bit means it starts as the file owner. An application can demote itself, if it is root, which is what busybox is doing. In order for some of the busybox commands to run, it needs root (like su or mount). However, stuff like cp or vi have no need to run as root, so busybox switches from root back to the current user to prevent anything bad from happening. Setuid is a pretty interesting setup.
[Motorola Droid 3] Adam.h.ogle:
Sudo is a debian thing, I believe. Anyway, no, Android doesn't have sudo by default.
[Motorola Droid 3] royolpunk:
I'm getting so antsy for root :P

TeamBlackHat, where are you...
[Motorola Droid 3] beard0:
I just wanna say thanks you guys for going this and all the work you've put into it..id try myself but I don't have the time or resources to try this stuff out so I really owe you guys :) even if we never get root cause moto locked us down so much im still happy with all the effort you guys put into it..this is why I love android :)

/droid3
[Motorola Droid 3] royolpunk:
Haha <3 xD
[Motorola Droid 3] rweb:
I was the one misleading him, sorry. I could have sworn it would be like I said, but just checked it with a small program. Yes, you are right.
[Motorola Droid 3] beard0:
If its anything you can use I can make the browser force close

/droid3
[Motorola Droid 3] cellzealot:
Just want to make it clear that TBH has a lot of resources and experience with Motorola devices and we understand the firmware and access tool very well. We also have engineering devices for many older models, which allows us to play around safely and to use clever tricks to root successive builds for phones that already have a rooted build to start from.

We do not have any special skills for gaining root on a new device without an exploit, despite the fact that we understand how the process works.

We will be here to help however we can and hope some of our experience will be useful, but don't want to foster any false expectations. We have some leads for the SBF file that so far have not produced results, unfortunately.

We will keep trying...

There are a lot of very sharp folks working on this and that is what it's going to take to succeed...there is no magic bullet.
[Motorola Droid 3] dmclark83:
Glad to see so many people working on the D3! I will have 2 on monday so hopefully I can help!
[Motorola Droid 3] royolpunk:
if you could donate one of those to rootzwiki that'd be great :p
[Motorola Droid 3] pgzerwer:
Unbreakable?

Please tell me it is not possible that Motorola actually perfected the locked bootloader on this phone, and that ultimately someone will crack root on this otherwise pretty amazing phone.
[Motorola Droid 3] royolpunk:
from what i understand, they didn't patch everything. we're trying to get more d3s for devs to work on though, because it's impossible to root it without having it in your hands
[Motorola Droid 3] jjhiza:
Moto couldn't have patched everything, otherwise their own "reported" factory unlock (rumored to be coming late in Q4) would be next to impossible. The fact that there are loopholes, coupled with the fact that there are no less than 10 people on this site (not to mention those over at Droid forums) working to unlock it, means that we will probably see an exploit found well before November or December... :D
[Motorola Droid 3] elkay:
Umm.. the bootloader is pretty solid. They never cracked the one on the Droid X even to this day. Bootloaders have virtually nothing to do with gaining root if they're in a locked state.
[Motorola Droid 3] royolpunk:
I wonder what kind of potential the droid 3 will have when it gets it unlock. 2.0ghz kernel? :D
[Motorola Droid 3] dpwhitty11:
Lol, doubt it'll go THAT high.
[Motorola Droid 3] elkay:
I have no problems at all with the current max clocks. Everything, including emulation, runs solid. I'm actually more interested in getting it to underclock lower than 600Mhz, because that's a definite source of idle power drain. It would be perfectly fine at 200Mhz, at a significant increase in standby time.
[Motorola Droid 3] royolpunk:
Lol I said that just for fun, I mean seriously haha 2.0 ghx would drain my battery In like 1 hour. But yeah if kernels came out I would probably underclock to 800mhz
[Motorola Droid 3] elkay:
I was talking the stock clocking. Right now it doesn't go below 600Mhz and people are speculating that's a huge part of the idle battery problem with this phone.
[Motorola Droid 3] sparkyman216:
Mine goes below that. What
[Motorola Droid 3] sparkyman216:
I get amazing battery time
[Motorola Droid 3] elkay:
There were some people talking about it.. wish I still had the thread in my history but it was at least a week and a half or two that I saw it.
[Motorola Droid 3] elkay:
Mine isn't bad per say but it could be much better. With minimal use I could get 4 days of standby on my Droid X.
[Motorola Droid 3] braneed:
I must be getting screwed. Mine has a standby time of about 6 hours. If i don't charge it every night it won't make it through the next day.
[Motorola Droid 3] royolpunk:
Sounds like you need to recalibrate. I get a full days worth of about 14 hours. Not bad, but its usually crying for the charger around 9pm
[Motorola Droid 3] gravenimage:
I get about six hours on a charge myself. And I haven't been able to get a extended battery yet
[Motorola Droid 3] Shoop_D_Woop:
Uhh I have the overclock widget (even though I can't set clock speed it still reads current Mhz) and mine says it'll idle at 300 mhz. I have the extended battery and I'll get 2 days light use out of a charge.
[Motorola Droid 3] 640k:
setcpu tells me i sit at 300mHz too and I'm lucky if i get a half-days worth of use. my battery is usually starving by 8 or 9 hrs of use.
[Motorola Droid 3] suzook:
So how did this turn into a another battery thread? Guys, back on topic please.
[Motorola Droid 3] iomthd:
ROFL that was fantastic!
[Motorola Droid 3] royolpunk:
Lol. We're working on root
[Motorola Droid 3] elkay:
I haven't even installed a clock widget since nothing can be modified right now. If they were wrong, whatev. I was only stating what they said they saw. Back on topic.
[Motorola Droid 3] Lyxdeslic:
Just wanted to say thank you to everyone who has been working diligently to obtain Root access on this phone. I absolutely love this phone and I cannot wait to have Root access. I wish I could help, but unfortunately I know nothing about code or anything related. I still enjoy reading the technical responses on here, because it helps me to appreciate even more what the Devs are attempting to do for this phone.

If there's any way I can donate for a new Dev to get a Droid 3, I'd be more than happy to contribute to that cause. Thanks again guys, and good luck.
[Motorola Droid 3] royolpunk:
It would be awesome if you could contribute to rootzwiki. Their paypal is staff@rootzwiki.com

their trying to get their hands on a droid 3 as well.
[Motorola Droid 3] elkay:
With the Bionic only weeks out now, we can only hope that with the huge amount of dev attention it will draw that they will discover a hole in 2.3.4 that we can also exploit. If the Bionic isn't rooted within a month of its release, I'm pretty much going to give up hope on us ever seeing it without a bootloader unlock. At the same time, I'm also still very skeptical of us seeing the unlock because we're dealing with Verizon and they're the ones being fussy about it, not Motorola.
[Motorola Droid 3] krazykrivda:
I have a donate link up for that exact purpose. We have raised 400 thus far. The phone was originally for myself, however I am looking to find someone that would really be able to assist in our search for root. Feel free to look into that if interested.

-KrazyKrivda
[Motorola Droid 3] mwmeyer:
Nah, they have the ability to flash signed binaries. So they can just release a new unlocked bootloader that's been signed. We could do the same if we could create a signed binary, but cracking linux to get root is probably easier than cracking the crypto involved in signing a binary.
[Motorola Droid 3] elkay:
Yep, I believe they're 1024 bit. Not going to be breaking through the bootloader unless Moto lets us or something internal leaks.
[Motorola Droid 3] saintlikesniper:
Probably shouldn't says this but I know of a Linux that can crack 128wep keys within minutes maybe within hours a signed binary
[Motorola Droid 3] Shoop_D_Woop:
Me likes the way this guy talks...
[Motorola Droid 3] Pokelover980:
128 bit WEP encryption isn't similar to 1024 bit WhateverAlgorithmMotoUsedToSignTheBinary encryption, so that's not going to help.
[Motorola Droid 3] saintlikesniper:
I know that but it has the speed to crack passwords that fast nonetheless 1024bit or 1bit it can do it
[Motorola Droid 3] idkwhothatis123:
Give it a shot. Please.
[Motorola Droid 3] Adam.h.ogle:
Adding one bit doubles the number of possible combinations, so WEP (~128bit) versus Moto signing keys (~1024bit) means there are 2^896 additional combinations to choose from. That means 5.28e269 (528 followed by 267 zeros) additional choices.

Now, you say cracking WEP takes a few minutes or hours. Let's say it takes 2 hours to go through all possible combinations. So, our theoretical computer can process 2^127 keys an hour. Let's assume that it takes about the same amount of time to "hack" a Moto signing key as to crack a WEP key (this is not true, but it makes the math easier).

To process a 128-bit key, it will take 2 hours (from our given).

To process a 129-bit key, it will take 4 hours ((129-127)^2).

To process a 130-bit key, it will take 8 hours ((130-127)^2).

To process a 1024-bit key, it will take ~1e270 hours ((1024-127)^2), which is 1.2e266 years.

Basically put, even on average, it will take long ****ing time.

There is no point. It wouldn't be encryption if anyone could crack it.
[Motorola Droid 3] braneed:
Math is neat.
[Motorola Droid 3] rynosaur:
Agreed. Obviously, 90% of the devices supported on XDA are now "open" because a back door was provided as a leak or by the OEM letting certain users in, and in a few cases the back door was accidentally left open. The very first android devices shipped allowed root access if you were smart enough to figure out that typing "telnetd" on the G1 keyboard allowed you root access. Then, someone got a reconditioned/warranty G1 sent to them with the engineering bootloader still on the device, by accident, and voila, the device's security was then useless. Most other Android devices since then have had a thin veneer of security that repelled only uneducated end users' attempts to do what the telcos wouldn't want them to do. It seems that recently, the veneer has become much thicker. If the Linux kernel we're inherently secure we wouldn't have such issues.

We're going to get lucky by persistent effort in finding a back door, not by cracking the code of the front door lock.
[Motorola Droid 3] elkay:
Thanks, you beat me to posting all of that. 8 times as many bits does not make it only 8 times longer to crack. Wrong correlation, it's exponential as stated.
[Motorola Droid 3] royolpunk:
Why don't we get that small Decepticon from Transformers 2 to crack it. LOL
[Motorola Droid 3] Lumixz:
You mean Wheelie? Naw, he's just a salvage scrap drone. He doesn't have that kind of processing power. Also a fun fact, the voice actor that played him was the same one that did spongbob square pants.

Anywho, I'm hoping that the root for the Droid 3 works for my XT860, as it's pretty much the same phone except it's the Canadian version.
[Motorola Droid 3] mwmeyer:
WEP (the algorithm) uses RC4 for encryption. RC4 isn't designed to sign things, so Moto won't be using it to sign binaries. WEP has a number of problems that leak information about the key and allow it to be pretty simply determined by sniffing the network. I don't know if the Linux software you reference is cracking the key by searching the space (this is the tactic for which the key size analysis is correct, and WEP's problems reduce the search space) or by sniffing data on the network (in which case the key size analysis is irrelevant, but we can't use that tactic to find the key), but it won't really help here.

The key signing code is a relatively simple algorithm that has been subject to intense scrutiny by experts, and the implementation is probably straightforward and easy to verify. The chance of us finding a problem that the experts have overlooked is pretty small. The Linux code base, on the other hand, is a large collection of code, some of which may never have gone through a security audit for being run with priveleges. That's why the Linux attack is more likely to succeed.
[Motorola Droid 3] isaacgaretmia:
Wow. Such relavent, informative info... I had almost expected the poster to be Adam.h. Thanks for the info!

Now, moving away from encryption keys, anyone else found an exploit that we might be able to test? I don't care if you think it will work or not, throw it in here. Search Full Disclosure and CVE for them....

I really wouldn't mind people posting "i really hope we get root" if they were also posting "will this exploit work?" along with it...
[Motorola Droid 3] isaacgaretmia:
http://seclists.org/fulldisclosure/2011/Jan/421

Poster believes this is minor, but i haven't seen the capabilities referenced mentioned in these thread discussons hertofore.

Thoughts?
[Motorola Droid 3] isaacgaretmia:
http://seclists.org/fulldisclosure/2011/Feb/329

This is mostly a DoS, but maybe it could be used to make the system think our current user is the root user...
[Motorola Droid 3] calash:
The ping exploit does not look promising. As far as I can tell the Droid3 does not have ping6 on it so addressing the loopback is not working. Dropping in localhost just generates an error that the packet size is to large.

Good find though...Ping is one the commands I could see being a way in...provided a good exploit is found.
[Motorola Droid 3] isaacgaretmia:
Cool. Doing my best here, but i am slightly hindered by my not owning said device. :) Going to continue to search FD.
[Motorola Droid 3] 640k:
Can't you adjust the packet size?

ping -l 0

Maybe?
[Motorola Droid 3] pplude:
shell@cdma_solana:/$ ping -l 0
ping -l 0
ping: bad preload value, should be 1..65536