Database Users

Can we try EVO's new root method for 1.49?

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

[Q] .sh script help

Hey guys, need some help with this one from some of you with more android/linux experience than me.
In my continuing quest to make Blackhole as customizable as possible I've been working on a way for users to easily install paid apps (legally downloaded of course), and stuff that I don't have available in rom manager in one easy step at the same time the rom is installed. In pursuit of this goal I've found that it's possible for the update-script file inside a clockworkmod zip to call a script in the zip as well. I've gotten it to say it's run the script, but it doesn't do what it's supposed to. here's what i've got:
#! /bin/
busybox cp /sdcard/app/* /system/app/
When I type the command into a terminal on the phone it works. When I open an adb shell and type "bash install.sh" it works. But when I get the update.zip to run the script, or run it in root explorer it just says it's run it, but doesn't do anything.
Is there something I'm missing about how to call the script? Do I need to somehow add the bash program to the zip file so it can run the script right? Has anyone ever done something like this who can point me in the right direction?

do you have an output you can show us?
Sent from my SCH-I500 using XDA App

This is a shot in the dark but does writing to /system/app require root permissions? It could be that you've given your terminal app root, so it runs under su. But when the script is being executed it does not have root and fails, but perhaps the output is being held back a bit and you're not seeing the permission denied.

Steve_ ?!
whoa, didn't expect it to be you of all people
Anyhoo, this is a bit off topic, but I've got a small request, can you somehow make BlackHole 2.4 an option on Rom manager? I don't have DL09 so I can't use 3.0, but I really like the ability to select everything to customize, instead of me going and installing one thing at a time....

Why not just add the following to the end of the update-script:
Code:
copy_dir /sdcard/app SYSTEM:
Also, is the SDCard mounted by default when the phone boots to recovery? If it isn't, or it isn't mounted while the update is processing, that will also cause the problem.

wizang said:
This is a shot in the dark but does writing to /system/app require root permissions? It could be that you've given your terminal app root, so it runs under su. But when the script is being executed it does not have root and fails, but perhaps the output is being held back a bit and you're not seeing the permission denied.
Click to expand...
Click to collapse
Could very well be, it's not showing me any output when i run it the two ways it doesn't work, just says it's been run.
vegittoss15 said:
Steve_ ?!
whoa, didn't expect it to be you of all people
Anyhoo, this is a bit off topic, but I've got a small request, can you somehow make BlackHole 2.4 an option on Rom manager? I don't have DL09 so I can't use 3.0, but I really like the ability to select everything to customize, instead of me going and installing one thing at a time....
Click to expand...
Click to collapse
Haha, caught me. I was trying to remain incognito Yeah, i'll get 2.4 loaded back up on rom manager for you today. But if you flash 3.0 it will upgrade you to DL09 and the DJ05 kernels and modem are compatible, or at least no one i know of has had issues.
imnuts said:
Why not just add the following to the end of the update-script:
Code:
copy_dir /sdcard/app SYSTEM:
Also, is the SDCard mounted by default when the phone boots to recovery? If it isn't, or it isn't mounted while the update is processing, that will also cause the problem.
Click to expand...
Click to collapse
sdcard is mounted when you go to recovery, because it's got to access the update.zip file on it to install anything. I'll try your code, do you know what to put after SYSTEM: to make it go to the /app directory? thanks for the idea, it's a different way to go, i didn't think about the fact the update-script could access the device if you don't use the "package" tag.

Don't you need to add "sh" to the bin directory and define the script as so:
#! /bin/sh
if you want it to execute properly..

dcow90 said:
Don't you need to add "sh" to the bin directory and define the script as so:
#! /bin/sh
if you want it to execute properly..
Click to expand...
Click to collapse
normally yes, but there doesn't seem to be a /bin/sh directory on my fascinate, only /bin and that's where the cp and mv and cat, etc. are.

I made a script to do this forever ago on my G1 when it first came out... Let me see if I can find it.

This has been done lots of times before. If you look around on xda there are some backup scripts which do the same thing.
Sent from my SCH-I500

imnuts said:
Why not just add the following to the end of the update-script:
Code:
copy_dir /sdcard/app SYSTEM:
Also, is the SDCard mounted by default when the phone boots to recovery? If it isn't, or it isn't mounted while the update is processing, that will also cause the problem.
Click to expand...
Click to collapse
Well I gave that a shot, and i think it could work, but the recovery wouldnt do it. it says "non-package source path not yet supported" good idea tho.
yutsoku said:
I made a script to do this forever ago on my G1 when it first came out... Let me see if I can find it.
Click to expand...
Click to collapse
If you can that would be great.
n0yd said:
This has been done lots of times before. If you look around on xda there are some backup scripts which do the same thing.
Sent from my SCH-I500
Click to expand...
Click to collapse
I spent a good bit of time searching and most of the scripts I found were much more complex than what i need, or were written to run on a computer, which i've already done.

sonofskywalker3 said:
normally yes, but there doesn't seem to be a /bin/sh directory on my fascinate, only /bin and that's where the cp and mv and cat, etc. are.
Click to expand...
Click to collapse
Thats not the point. You need to set a shell interpreter, not a path. Cwm uses busybox sh, which is in /bin in recovery mode. Google search shebang
Sent from my SCH-I500 using XDA App

jt1134 said:
Thats not the point. You need to set a shell interpreter, not a path. Cwm uses busybox sh, which is in /bin in recovery mode. Google search shebang
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
Going to go ahead and parade my stupidity in front of everyone here:
so does that mean i'm right using #! /bin/ or that it should be #! /bin/sh/ or something else entirely? I'm so confused.

sonofskywalker3 said:
Going to go ahead and parade my stupidity in front of everyone here:
so does that mean i'm right using #! /bin/ or that it should be #! /bin/sh/ or something else entirely? I'm so confused.
Click to expand...
Click to collapse
#!/bin/sh for scripts in recovery. #!/system/bin/sh for scripts in android.
Sent from my SCH-I500 using XDA App

How to make rootfs / writable

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.

Understanding Root

Now I am a very avid linux user (used the terminal a time or two) and I bought an acer a500 yesterday. This is my first android device and the first 2 things I did were update it and root it with iconia-root1.3 (gingerbreak didn't work). Now I have 3.1 and the root checker says that I have root. And the busybox installer says I have busybox installed.
Now this is where I get lost...
The root checker says I have root but not /system/bin/su or /sbin/su. Why would I have root if I don't have the application to switch users? Also it has su in /system/xbin but it won't let me move anything to /system/bin (which I assumed I could do as root??). So is root checker giving a false positive or what? and why can't I move any files above the directory /mnt (I'm using astro)? Do I have to selectively give certain apps root or what?
Also I need someone to explain this to me. Why do we need to root it if all of the applications are already in the android marketplace? Do they allow applications to be uploaded to the marketplace that won't work on non-rooted devices?? That seems like there would be a separate marketplace for rooted-only apps like cydia on iOS.

A quick reply: 'Root' allows you to have read/write access on /system/ . After root, you can add/remove any apps in /system/app, also, after root, you can flash CWM, you can then flash custom rom and kernel ... bla bla bla ~
Root is somehow different from 'jailbreak' in iOS. I think you could find more information on google. Cheers.

ardatdat said:
A quick reply: 'Root' allows you to have read/write access on /system/ . After root, you can add/remove any apps in /system/app, also, after root, you can flash CWM, you can then flash custom rom and kernel ... bla bla bla ~
Root is somehow different from 'jailbreak' in iOS. I think you could find more information on google. Cheers.
Click to expand...
Click to collapse
Root doesn't give you superuser(root user) access? I had always assumed that was the case, which means you can do any damn thing you please. Obviously you can't write to ro filesystems, but you could always remount them.

snowman4839 said:
Now this is where I get lost...
The root checker says I have root but not /system/bin/su or /sbin/su. Why would I have root if I don't have the application to switch users? Also it has su in /system/xbin but it won't let me move anything to /system/bin (which I assumed I could do as root??). So is root checker giving a false positive or what? and why can't I move any files above the directory /mnt (I'm using astro)? Do I have to selectively give certain apps root or what?
Also I need someone to explain this to me. Why do we need to root it if all of the applications are already in the android marketplace? Do they allow applications to be uploaded to the marketplace that won't work on non-rooted devices?? That seems like there would be a separate marketplace for rooted-only apps like cydia on iOS.
Click to expand...
Click to collapse
1.) The root app is in /system/app/ and the binary is in /system/xbin/ so you do have root.
2.) You won't be able to just write to any of those folders. You either have to remount them to be writable and use adb or use an app like root explorer that lets you remount on the fly and edit the files.
The same answer goes for the question why can't you move files to anything above /mnt. And yes to the second question. You'll have to set root permissions selectively.
Root doesn't have any effect on the marketplace or the apps you can download. This is not an iDevice.
Some apps need root to work (usually the ones that change system files) and that's why you have to have root. It's not necessary unless you either change system files or use an app that requires it (screen-shot apps, adfree,some file managers, reboot apps,...).
It's early so apologies for any mistakes I made. I hope that it's a little clearer now.

Alternative thoughts on preventing OTA update

I don't think I have seen any mention of this idea yet. Sorry if I missed it...
In a recent thread about the 6.2.2 update and people wanting to prevent it, I thought I read that someone saw the file show up in the update directory. I'm assuming this means the same 'kindleupdates' directory you could manually drop the update into -- but if not, the idea is the same. Why not just take some step to prevent access to this directory?
The exact step to take would depend on how smart the developers were about dealing with problems in the update process
The easiest step would be to chmod 555 it. But of course if the update process is running as root it is under no requirement to honor those permissions! (My experience in the unix world tells me that about half the time, programs running as root do honor the permissions even though technically root overrides them).
Another easy step would be to delete it altogether. But they probably thought of that (if it's /mnt/sdcard/kindleupdates where someone could easily accidentally delete it) and recreate it if it's missing.
One trick that is often done is to replace the directory with a file. Some programmers do not think to check this kind of condition - they see there is something there, but they get an error opening it as a directory, and they just declare it's an error.
A more subtle trick would be to replace the directory with a symlink that points to a read-only directory (such as /system). In this case, they could open it as a directory, and just fail to write there. The programmer probably would not have thought to check whether it's a link vs. a real directory. One possible gotcha is if you point to /system, and /system is r/w, then the update could screw something up under /system. So maybe mount /system r/w, mkdir /system/kindleupdates, remount /system r/o, then link the update dir to /system/kindleupdates.
And finally, I don't know if Android has any kind of loopback filesystem capability, but loopback-mounting something read/only on that directory would certainly fake the OS into thinking there was a directory there; it would definitely be read/only, and I don't think they would ever think to check whether there is actually some filesystem mounted there! (and if there was, all you need is an app that constantly accesses some file you put there, which would make it busy so that it couldn't be unmounted).

The first method won't work because the sdcard partition is fat32 and doesn't accept unix permissions.

it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...

well, i just deregistered my kindle acount and i'm still in 6.2.1...

b63 said:
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
Click to expand...
Click to collapse
Ah, that makes this less practical. Still, perhaps when the next update comes out I can try a variation on this but it requires the filename to be known.
If the update is downloaded as a single file to /cache, which is named the same as the file you can manually grab, then someone who hasn't gotten 6.2.2 (and is not averse to this failing) can try this in a root shell:
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin/blah
The purpose here is to put something unremovable in the way of the file it wants to download. Most likely if the update sees something with the existing name there it would probably want to blow it away (after determining it's incomplete) - and since any update there would normally be a regular file, they probably would do nothing more complicated than a simple unlink syscall to delete it before re-downloading. However, since it's a directory with something in it, that unlink will fail. In actuality, making the subdirectory (second command above) should be unnecessary because the unlink should not work for directories; there's a special rmdir syscall for them.
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
Click to expand...
Click to collapse
I did read a lot of that last time and I don't think I actually saw a definitively successful method. If there is one it should be stickied
My interest in this is a little different from most of you guys - I have very limited satellite internet and I don't like these unscheduled 185-meg downloads so I want to be able to update only when I want mostly to control that. This kind of means looking for the least-intrusive way to accomplish this.

/cache/update-kindle-6.2.2_D01E_3205220.bin is exactly where it downloads
if you find a way to even prevent the download, that would be greatly appreciated

Unfortunately I already got the update so I can't try it this time.

at least you could try your method with a dummy file of an other name and try to overwrite it with adb - if you can't overwrite it there's a good chance

I think I'm about the only one who prevented 6.2.1. I did it by constantly checking the cache folder. Found the update by chance and deleted it before it updated. Waited over a week for it to come back. Never did. An app that watched the cache folder for the updates and then moved/deleted them would work fine
Sent from my SGH-I897 using xda premium

jcase already work a way around this automatic OTA update, so when FIREMOD is ready to replace burrito I think we will have no more problem with this OTA issue. (you can find jcase announcement in the kindle developer section)

Heres what I have done to prevent this.
1) Droidwall (white list only the apps you want to allow internet access)
2) Removed "otacerts.zip" from /system/etc/security/otacerts.zip.
3) I removed "OTASilentInstall.apk" /system/app
4) Installed this 6.2.2 based Rom http://forum.xda-developers.com/showthread.php?t=1439916
Hopefully this eliminates the OTA. I had my Fire rooted on 6.2.1 with twrp and it OTA'd on its own, broke root and twrp. So I rerooted with burritoroot2 and installed CWM based recovery.