Related
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
bowtieduece said:
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
Click to expand...
Click to collapse
Even though I didn't really think it would work, I gave it a shot anyway. Naturally, it was unsuccessful. The Eris take FOREVER to load that website, and it never triggers the shell script to ask for a reload, therefore permission is denied for the second part when you reboot with adb shell.
Interesting exploit, though. I wonder if there is some way to modify it for the Eris. Maybe you could contact the devs.
Really, nobody else is interested in this?
MyFixofAndroid said:
Yep that's what I expected. Yea there's gotta be someone here that can do the changes to the EVO files so they work with Eris, and upload the proper files to file sites and have us downloading in no time, so we can get root finally. Yes please anyone here up and willing
Click to expand...
Click to collapse
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
sickbox said:
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
Click to expand...
Click to collapse
Thanks for the tip. I sent him a PM. Will report back when I find something.
Anyone with an Eris can help out - rooted or unrooted.
I looked at those scripts last night - what seems like the necessary conditions for the beginning of the exploit (part1) are:
(1) there is a directory read/write/traversal permission security flaw in the data area for flash-lite;
(2) apparently, when flash-lite is running it must have root privilege at a moment when it performs a file "chmod" operation
So, an unprivileged user goes in, and makes a symlink (at the correct moment in time) in flash-lite's data area that points to a mtd partition - moments later, flash-lite "chmods" what it thinks is a file in it's data area, but instead, it is chmod'ing the target of a symlink - the normally protected mtd partition.
This allows use of flash_image to write whatever is wanted to that partition - even as an unprivileged user.
It should be easy enough for someone with Linux/Unix command line scripting experience to test to see if these conditions prevail on the Eris. You don't even need to be root - make your symlink point to something in /data/local if you are worried about something bad happening to a mtd partition. Chmod it initially to 600, and see if it get's changed by flash-lite when (and if) you drop the symlink into place.
I would do it, but I've got to go buy all the parts for ( & build) a new computer (no dev station as of last night ).
bftb0
bftb0 said:
Anyone with an Eris can help out - rooted or unrooted.
bftb0
Click to expand...
Click to collapse
Thank you for the detailed explanation. I'll have a look at the scripts, though it's more about learning new things for me, as this exceeds the current state of my unix knowledge. Hope others with more immediate knowledge of the subject will take a crack at it.
The shell script points to sharedobjects within /data/data/com.android.browser/flashlite, but sharedobjects, nor any folder for that matter, exists within that directory on the Eris. Is there a different place this could point; does the Eris have the same objects stored in a different location?
UPDATE: I'm searching my filesystem on my Eris right now to find it. I will report back later with results.
Also If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
MyFixofAndroid said:
Maybe the "sharedobjects" folder and other missing folders are really on the Eris, one of you should look for them. Use ASTRO or a different file manager and search most of the whole filesystem and see if you can find "sharedobjects" on your Erises.
In the meantime I'll try the same thing. Maybe there's a search engine for the file system of the Eris that you can get in the Android Market, that would do the trick. A file and/or folder search engine.
If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
Click to expand...
Click to collapse
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
I checked on my other Eris which is rooted. It seems that these may be the directories that we are looking for. However I don't find anything in an app-cache directory.
# find / -name *flashlite
find / -name *flashlite
/data/data/com.android.browser/flashlite
find: /proc/851: No such file or directory
# find / -name com.android.browser
find / -name com.android.browser
/data/data/com.android.browser
Well this appears to be the deal breaker then. Because non-root users of Eris cannot access /data as non-root, they cannot see anything in app-cache, and therefore cannot root yet, at least with this particular method unless there's another way to do it.
We should think of a way to still exploit Flash Lite on Eris, but use a different folder/folders in the Part? scripts that they point to for the operations of the script. This may be possible to do, however, still unlikely to work, and it is still going to be hard at this point.
But does anyone want to give my modified EVO method but for Eris a try? One of you should, so that we can root this thing and get it over with.
jimbonj said:
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
Click to expand...
Click to collapse
I dont think we would need read write permissions to begin with to use this root, if we had them to start we would be rooted
Because is he using a exploit in flash lite to write to a restricted folder, hes not just found a folder where the permissions aren't set correctly.
If flash lite can invoke admin access and we can exploit it there should be a way to root this.
I am going to the bar going to get some beers for my friends birthday, when I get home I am going to see if I can modify this into an eris root
Yeah JVWARD!
On your rooting effort, all the better, try modifying it for Eris and let all of us know if you succeed, hope you can, so we can get root too. Keep trying it with different changes until you get it to work.
Thanks.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
Click to expand...
Click to collapse
Yes sickbox, by all means, keep trying stuff, and finding that "flashlite" directory etc. till you get it to root. Hope your touchscreen returns to normal, and that you can create the directory that you mentioned in your previous post by using a flash site.
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
hey can someone with a rooted Eris using a an almost 100% stock Rom setup dump there file system and post it. Anyone using a highly customized Rom don't bother.
Sent from my Eris using Tapatalk
lostpilot28 said:
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
Click to expand...
Click to collapse
Link to the Evo instructions is in the OP. Currently working to see if it's possible on the Eris, so that's a no-go for now.
Stay tuned.
Team,
I've been working with the scripts with the awesome folks on IRC and have currently gotten thus far:
Part1 - http://pastebin.com/FUJWM3zW
Part2 - http://pastebin.com/6h07zrdm
I believe at this point I've screwed up my FlashLite plugin with my testing, so I'm going to try to recover that and keep moving along.
LR
Hi just asking if anyone knows any links or archives or anything i can read through, im looking to build my own ROM. any help would be much appreciated and dont mind donating to someone that can help me start to learn.
Thanks
Well, first of all you need to be able to compile Android. This is pretty easy and it's explained directly in the developers google website. If you're not running a Nexus One or a Nexus S, you can't actually compile a working android copy for your own phone "as is" from AOSP. Because of this, you firstly need to change / create some dirs and files in order to add the support for your particular device. I'd start searching on CM repositories for this (I've got the Nexus One and thus I don't have such problems).
After you've compiled Android for your device and your changes (for example root), you'll have some disk images (you can find them all under out/target/product/PHONE_MODEL/, they are the .img files). You can directly flash them via fastboot ("fastboot flash boot boot.img" etc.). You can though create an update.zip file, and this can be made extracting the system.img file in a folder. Remember that you'll have to recreate the symlinks (to toolbox and/or busybox if you want to include it in your build) and set permissions, as zip doesn't save the permissions of the files once compressed.
Thus so far, if you succeed making every single step you should have your ROM on your phone
The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
I'm fairly noobish w.r.t. Android (but rapidly less so!), but long in the tooth with unix and linux.
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
For the life of me, examing the output of mount, I can't figure out what device path to use in the command,
mount -o rw -o remount <device> /
I'm guessing it probably isn't this simple, and there is some convoluted loop config with mount or something as part of the Android security mechanism.
You can mount it as r/w with Root Explorer...
SubnetMask said:
You can mount it as r/w with Root Explorer...
Click to expand...
Click to collapse
ES File explorer will also allow you mount as writable. Under Menu>Settings>Root options.
It's a little flaky though, I have to turn on the root options then shut down the app and restart it to get it to work. It's free and available in the Android Market.
dwallersv said:
The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
Click to expand...
Click to collapse
You can remount / as read-write with:
Code:
mount -wo remount rootfs /
and read-only again with:
Code:
mount -ro remount rootfs /
However, the root filesystem is actually a ram disk (initramfs), so any changes to it aren't persistent across reboots. You can modify the initramfs, but it requires rebuilding it and packaging it with a kernel, and flashing the kernel containing the new initramfs.
dwallersv said:
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
Click to expand...
Click to collapse
Can you get away with placing it in /data or even /system? If you can't recompile bash, you'll have to invoke it with "bash --init-file /data/local/.bashrc" or something.
If you're using ConnectBot Local, you can do that automatically with "Post-login automation", e.g., "exec bash --init-file /whatever/.bashrc".
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
DiGi760 said:
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
Click to expand...
Click to collapse
That's for "/system", OP is asking about "/".
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot.
The only way you can accomplish what you want, in this circumstance, is the method listed above, or to modify the initramfs.
Thanks everyone, for all the great information... Man, I love this place!
@mkasick: Crap!! Well, that torpedoes this one.
I've already used the various "workarounds" you cited (use connect automation with ConnectBot, for example). My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
I'm not going to go to all the trouble to rebuild a custom initramfs for just this.
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Once again, mkasick, you are a most helpful fellow around here. I must say -- and it may make you blush -- I am a big fan and admirer of yours, with the things you've found and fixed for the community. You are unique among the devs in my view, given the nature of what you have looked into and fixed. I'm a pretty experienced, knowlegable software guy myself, and fancy learning enough about Android to make contributions in the not-too-distant future like you have.
As I mentioned in another thread, I'm looking at a major driver re-design for the keyboard based on your analysis and patch for the dropped keypress problem... I plan to have some discussions with you (if your interested) sometime in the next few weeks about what I'm planning, just to get your feedback, if nothing else. Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Keep up the good work, friend. You are a uniquely valuable member of this community, in my judgement
-- And that's not to shortchange any of the other devs here, it's just that the nature of your work resonates with me especially, given my own background, career, interests, and past work in software.
Dameon87 said:
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot
Click to expand...
Click to collapse
Spot-on, and very good point. However, there are ways around that:
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Click to expand...
Click to collapse
In fact, in a more generalized sense, this approach can be used to make any changes to the rootfs that "persists" across boots, without the pain of rebuilding initramfs and repackaging the kernel. This is especially messy to track and manage when you take advantage of one of the excellent custom ROMs here (in my case, Bonsai).
FWIW, and maybe helpful to others, I already have organically evolved as "reinstall" framework/process for doing some customizations to the system after installing a new/updated ROM. I use shell scripting for a lot of little things, and keeping this stuff working became a challenge across ROM releases, because necessary components -- like shells, busybox versions, whether busybox of toolbox is being called by the default path, and a bunch of other things (like the ALSA tools) are present in places like the /system filesystem.
All this gets mucked up with each ROM/kernel update. Now, I'm slicing this bologna even thinner by messing with rootfs, so I've got to get things to persist across boots!
I have a simple, one-step process for fixing all this after a new ROM. Nothing fancy -- just a flashable, Edify zip of my stuff that I hit right after a ROM update. Found a template zip with very generic Edify script in it that simply copies the file tree. I keep my custom stuff updated there.
dwallersv said:
My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
Click to expand...
Click to collapse
How about setting BASH_ENV or HOME in telnetd's environment? Or is the environment not preserved?
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only.
Click to expand...
Click to collapse
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
There's also using gscript, maybe Tasker, or another program that hooks ACTION_BOOT_COMPLETED. Those won't run at root privileges, but a tie in to "su -c" should work.
dwallersv said:
You are unique among the devs in my view, given the nature of what you have looked into and fixed.
Click to expand...
Click to collapse
Thanks!
I think of my contributions as complementary though. I don't really have the time or patience for "maintaining stuff" that other folks do here very well.
dwallersv said:
Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Click to expand...
Click to collapse
I suppose discussion elsewhere is appropriate. Sounds ambitious, but a good idea. The existing keyboard driver architecture could be improved for certain. To date though, I've tried to make my kernel changes relatively non-invasive, even if not ideal, for maintenance sake.
In a perfect world, a rewritten driver would make it back to Samsung and that would be the "end of it" for us. Personally, I wouldn't want to expend the effort to do so unless I knew it would be merged. But if that something you feel like attempting, there's no harm in trying and seeing what results.
mkasick said:
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
Click to expand...
Click to collapse
I'm not 100% certain at this point, but from what I've found investigating this, it looks like the "user scripts" /etc/init.d/<scripts> mechanism is a standard part of the Android system. I'll see if I can find where I saw that and post a link.
Hello everyone.
I developed a kitchen (it's already online) where you can create zip updates for a lot of apps. Before I sharing it with all you, I need to know one thing - I'm sorry for the question but I only "know" the filesystem of my phone since it was the only android device I used - it's a samsung galaxy spica and I'm not a very active user in this forum for a long time, so I honestly do not know how other devices work.
So what I need to know is: in general, all android phones have /system and /data partition, where apps are saved?
Also, all rooted devices have a recovery which accept ZIP Updates?
Thank you all.
The apps saved to data partition
and the most(if not all) rooted devices can updated via zip files.
dancer_69 said:
The apps saved to data partition
and the most(if not all) rooted devices can updated via zip files.
Click to expand...
Click to collapse
Thanks. I just wanted to be sure.
there are a few things that differ between phone (eg. /sdcard vs. /mnt/sdcard) but I'm fairly certain that all of them will have /system and /data. It just wouldn't make sense otherwise.
What's the difference of /syste/bin and /system/xbin?
I'd like to root my Nexus 7, but don't know what is the proper folder to put su.
The updater script of Superuser symlink /system/xbin/su to /system/bin/su, which further confused me...
Lol just flash a supersu package. And be done with it . And its xbin that is where it needs to be.
Sent from my Nexus 7
ÜBER™ said:
Lol just flash a supersu package. And be done with it . And its xbin that is where it needs to be.
Sent from my Nexus 7
Click to expand...
Click to collapse
Yes I've done that and it works. But I don't see the philosophy behind having two separate folders for executables...
Bin is for all the executables used by the system to perform various tasks such as reboot, clear cache, shut down, mkdir, rmdir, mount, etc. The xbin folder is used for all the root related executables (except su is stored in bin as well) such as busy box. I don't know the reasoning behind the separation of folders, except to keep root files separate form OS ones.
I assume that su will work whether you place it in bin or xbin?
z_extend_99 said:
I assume that su will work whether you place it in bin or xbin?
Click to expand...
Click to collapse
If you point everything you need to /bin instead, sure, but it's hardly advisable. You're just asking for a headache.
Rirere said:
If you point everything you need to /bin instead, sure, but it's hardly advisable. You're just asking for a headache.
Click to expand...
Click to collapse
For appreciation purposes, may you educate me why?
Sent from my Galaxy Nexus using Tapatalk
z_extend_99 said:
For appreciation purposes, may you educate me why?
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Sure. People like to avoid modifying /bin for good reason-- if you screw up something in there, you're liable to trash your current install. /xbin is essentially a "safe" version of /bin-- you can dump system critical utilities in there (a common point) without fear of screwing up /bin. Theoretically, you could also put a different version of an executable in /xbin, but that's largely beside the point here.
Enough apps requiring superuser access respect the /xbin convention that they'll look for su/request su access by looking in /xbin. If you install your su binary into /bin, then you'd need to get all of your apps to look in /bin instead, and some are hardcoded to look in /xbin. Sure, you could symlink /xbin/su to /bin/su, but there's no real reason to (and links don't always work, either).
Rirere said:
Sure. People like to avoid modifying /bin for good reason-- if you screw up something in there, you're liable to trash your current install. /xbin is essentially a "safe" version of /bin-- you can dump system critical utilities in there (a common point) without fear of screwing up /bin. Theoretically, you could also put a different version of an executable in /xbin, but that's largely beside the point here.
Enough apps requiring superuser access respect the /xbin convention that they'll look for su/request su access by looking in /xbin. If you install your su binary into /bin, then you'd need to get all of your apps to look in /bin instead, and some are hardcoded to look in /xbin. Sure, you could symlink /xbin/su to /bin/su, but there's no real reason to (and links don't always work, either).
Click to expand...
Click to collapse
Thanks. That makes sense. I'd like to see it as the xbin is used for user created binary files that operating system can work without them while the bin is where the baseline binary files that the operating system needs.
May you site a real life app where it was hard coded to look into xbin?
I'm getting a little bit uncomfortable. When I had my Galaxy Nexus rooted, I just flashed a zip file through CWM. I have downloaded the zip file somewhere here in XDA. When I checked where my SU resides, it's in the bin, not in the xbin.
I have a Galaxy Ace before I got my Galaxy Nexus, and it was rooted the same way. I used a different zip file, and the SU was placed under the xbin.
As far as anything goes, I'm not comfortable to touch the bin/xbin folders on my Galaxy Nexus at this moment as I have not encountered any problems so far since I have it rooted on day 1.
z_extend_99 said:
Thanks. That makes sense. I'd like to see it as the xbin is used for user created binary files that operating system can work without them while the bin is where the baseline binary files that the operating system needs.
May you site a real life app where it was hard coded to look into xbin?
I'm getting a little bit uncomfortable. When I had my Galaxy Nexus rooted, I just flashed a zip file through CWM. I have downloaded the zip file somewhere here in XDA. When I checked where my SU resides, it's in the bin, not in the xbin.
I have a Galaxy Ace before I got my Galaxy Nexus, and it was rooted the same way. I used a different zip file, and the SU was placed under the xbin.
As far as anything goes, I'm not comfortable to touch the bin/xbin folders on my Galaxy Nexus at this moment as I have not encountered any problems so far since I have it rooted on day 1.
Click to expand...
Click to collapse
I believe individual superuser apps are hardcoded to look in a particular place (and why wouldn't they be? They're usually flashed side by side with the binary). Are you using Chainfire's Superuser, SuperSU, or Koush's Superuser? SuperSU on my HTC One is set in /xbin. It can also depend on the preferences of whoever developed your root exploit.
Both /bin and /xbin will work, but with a community of independent developers, you're going to find disagreement/varying levels of interest in this convention.