SU Password - G1 Android Development

I have looked on the boards for how to make a su password, and I think I saw it once, but I can't find it again, can someone point me to a link or post how to set the password please. I'd like to be protected for obvious reasons.

Are you concerned about a malicious user getting a hold of your G1, invoking su and causing damage? Or are you concerned about malicious programs using su to cause damage programmatically?
For the latter, all you need to do is install JF's v1.3+ Android and you're protected via Koush's su setup. It simply redirects all su invocations to the Superuser app where you can whitelist an app. For the former, I guess you'd have to rely on the KeyGuard. Maybe some future version of Superuser will include its own KeyGuard for blocking out malicious user access.
Edit: original forum posting about Superuser. Info there might be obsolete. Latest versions of Superuser comes bundled in JF builds.

jashsu said:
Are you concerned about a malicious user getting a hold of your G1, invoking su and causing damage? Or are you concerned about malicious programs using su to cause damage programmatically?
For the latter, all you need to do is install JF's v1.3+ Android and you're protected via Koush's su setup. It simply redirects all su invocations to the Superuser app where you can whitelist an app. For the former, I guess you'd have to rely on the KeyGuard. Maybe some future version of Superuser will include its own KeyGuard for blocking out malicious user access.
Edit: original forum posting about Superuser. Info there might be obsolete. Latest versions of Superuser comes bundled in JF builds.
Click to expand...
Click to collapse
I'm going to eventually add a configuration option to make Superuser password based. I'm pretty busy though, so I was hoping someone else could do it.

Hi,
please add an option to superuser app to use /etc/passwd or /etc/shadow if present. Currently I'm trying to improve the linux compatibility on my HTC dream 1.5 using busybox. I've already pushed upstream a patch to make it easier to use adduser and addgroup on android. Now i have a password protected su on the terminal but i need to intercept somehow su requests that are not on a tty
( if (!isatty() ) to fire up a yes/no dialog or password request dialog. The problem is that my C skills are good but my Java is unexistent.
I'll post more of my work as soon as I reach a minimum of stability, including:
1) a wrapper for vold to perform os setup tasks on boot
2) a patch to vold to allow working swap on file on the sdcard
3) android tailored busybox config, passwd, shadow, group, gshadow and
fstab.

Related

AdFree Hosts file

Since we currently can't write to /system while Android is running, the AdFree app is unfortunately unusable. However, here is the hosts file that the app supplies you with, so you can still put it into your phone manually.
Download the attached file, unzip it and place the hosts file on your sdcard. Then, open up a command prompt, load up your recovery menu (using the instructions in toastcfh's guide) and type:
Code:
adb shell
mount /system
mount /sdcard
cp /sdcard/hosts /system/etc/hosts
exit
Now you're AdFree
As in AD free while on the web only? Or does this block the ADs that are displayed within certain programs? Like Spare Parts for example.
VoXHTC said:
As in AD free while on the web only? Or does this block the ADs that are displayed within certain programs? Like Spare Parts for example.
Click to expand...
Click to collapse
Everytime the phone goes to download an ad, it gets blocked. So in both the browser and inside apps.
a) not development
b) i already did this thread
http://forum.xda-developers.com/showthread.php?t=695196&highlight=adfree
I'm guessing this requires root?
Also, those commands can't work AFAIK, because mount needs two arguments.
Or am I missing something here? I'm new.
I have actually had 0 problems running adfree right out of the box. Installed, ran and bam no ads. Didn't have to modify nothing through ADB.
superevilllama said:
I have actually had 0 problems running adfree right out of the box. Installed, ran and bam no ads. Didn't have to modify nothing through ADB.
Click to expand...
Click to collapse
U running 2.2? BC I see lots more adds since 2.2, it blocks some but not most.
Sent from my PC36100 using XDA App
You know, to my embarassing discovery, I never noticed (as I found this thread from google) but this is the forum specifically for EVO.
I'm running a DX (so 2.1), so that may be the problem. But still, I wouldn't think such things would be different in the OS. Guess the package it differently. Oh well. Not gonna bother rooting my toy just yet, hehe. Sorry bout the confusion.
AdFree is working perfect on CM7 nightly 23 & 25 & MikFroyo 4.5 but it does not work if you have BusyBox 1.18.3 but works perfect with BusyBox 1.17.1. I did not test other versions but I think the problem is related to BusyBox 1.18.3 by today 03/19/11.
Still there are ads running on some apps
like moneycontrol, and more.
Gregalous said:
Since we currently can't write to /system while Android is running, the AdFree app is unfortunately unusable. However, here is the hosts file that the app supplies you with, so you can still put it into your phone manually.
Download the attached file, unzip it and place the hosts file on your sdcard. Then, open up a command prompt, load up your recovery menu (using the instructions in toastcfh's guide) and type:
Code:
adb shell
mount /system
mount /sdcard
cp /sdcard/hosts /system/etc/hosts
exit
Now you're AdFree
Click to expand...
Click to collapse
earth08 said:
Still there are ads running on some apps
like moneycontrol, and more.
Click to expand...
Click to collapse
Its not updated, try absolute system tools from the Android Market. It downloads an updated script
If anyone is interested I created an app (Warning: requires ROOT) that allows you to enter one or more URLs and/or file paths and merges them and installs them as hosts. You may find the source-code here: https://code.google.com/p/android-ad-blocker/
I'll try to fix bugs for it but I can't promise I'll have time.
Edit: I made a new version because the old one had some issues transferring large files. You may find it here: http://dl.dropbox.com/u/8443626/android-ad-blocker.apk
Adfree works fine, Am I missing something? I just ran it, it updated my host file. I checked again and it said it's the latest version
Sent from my PC36100
karilofyore said:
If anyone is interested I created an app (Warning: requires ROOT) that allows you to enter one or more URLs and/or file paths and merges them and installs them as hosts. You may find the source-code here: https://code.google.com/p/android-ad-blocker/
I'll try to fix bugs for it but I can't promise I'll have time.
Click to expand...
Click to collapse
Can u help me... on how to use ur app
Sent from my °•EvO HD•°
Can u explain this process... where is the guide from toast...
Sent from my °•EvO HD•°
acme64 said:
Adfree works fine, Am I missing something? I just ran it, it updated my host file. I checked again and it said it's the latest version
Sent from my PC36100
Click to expand...
Click to collapse
x2 im confused
@ acme64 : Some people in market comments complained that it doesn't work fine anymore and it's a root app with closed source. Since it was simple to write a similar tool I did it for myself mainly.
@ Don74y3 : The way to use the application is to put a URL to a hosts file. You may use for example the one in the screenshot (I can't put the link here because of forum rules but use Google to search for "hosts file winhelp2002" and from the first link, take the address from "To view the HOSTS file in plain text form") and then click "Apply". What the program does is get that file and put it in your (rooted) Android phone. That file in turn lets the phone avoid domains that serve ads or malware. The app can take more URLs and merge them, but that's not necessary. After clicking "Apply" it is recommended to reboot the phone to make sure the changes go into effect. You will see that the pages load faster and without ads.
P.S. I'm not affiliated with the guys that make that hosts file, though I'm grateful for their work.
Unable to figure out system mount point.
Can you please help with this?
MattSkeet said:
Unable to figure out system mount point.
Can you please help with this?
Click to expand...
Click to collapse
Hi, the programs tries to figure out where the /system partition is mounted on your phone (this is because it has to switch it to read-write, put the hosts file and switch it back to read-only). I wrote the program to parse the output of the "mount" command.
Unfortunately it seems that on your phone the output is far different than what I expected. I don't know how to fix this unless you can send me the output of that command on your phone - by PM for example. To do this use adb (try to Google for how to get Android Debug Bridge) with your phone connected: run "adb shell" from a command prompt and at the shell prompt type "mount" without quotes and send me the output - at least the line that contains "/system".
Hi,
I have a different question.
I used adFree but then decided that I actually wanted see the ads on my apps.
I removed AdFree but the ads are still gone.
Is there a way to bring them back?

Attempting to change htc evo root passwd, but blocked?

so I have installed unrevoked and rooted my evo, which could not have been easier. But now I am trying to use my new superuser badassness to change my root passwd. So why does it keep denying me permission? if im root arent I already at the highest level of user access?
babelfish42, i think it is likely that the execute bit is not set on passwd or the write bit is not set on the passwd file. I don't have an evo so i can't check those things but if you look around the file system with ls -l you should be able to check that.
Unfortunately for Android "Permission denied" usually means "No such file or directory" . It's really annoying. But anyway there is no "passwd" binary.
Android handles users very differently than standard unix. Every Android application has it's own user it runs as (with a name like app_34). And there are not user passwords.
Why do you want to change the root password? If it's for protecting the "su" binary the Superuser.apk should take care of prompting you and remembering on a per-application basis.

[GUIDE][please correct] permaroot for the android newb (using Evostance's guide as b)

PREFACE & CRY FOR HELP:
I’m pretty sure this guide works. This is how I got permaroot and write access to my DHD system files and directories. But I might have made mistakes. I hope some experienced people will read this guide and point them out. I hope newbs will wait for a few people to say if this guide is correct or not before trying this.
I mainly used Evostance's guide. Thank you Evostance (and all the others whose work I've ripped off here!) and I hope you understand me for posting this rather longer, newbified guide;
The guide:
This is a guide to rooting and gaining write permission to your Desire HD, written for the Android newb.
You ain’t dumb, you just don’t know Android. Even though I’m learning to program for this OS, I don’t know Android either. Not enough to root and gain write without the help of expert reverse engineers and other guide writers who have much more experience than I do with this OS.
However, all the knowledge is very fragmented right now, due to everyone being VERY EXCITED about root now being available on a NAND locked DHD. The info is there, but it takes some looking around, some warnings, some things I didn’t find in one place, but scattered through many posts on many threads.
That’s why I wrote this: for the Android newb who wants a rooted phone and doesn’t have the time to spend hours tracking down the information and all the caveats.
WARNING: THIS IS DANGEROUS AND CAN BRICK YOUR PHONE. IF YOU TRY THIS, IT IS YOUR OWN RESPONSIBILITY, NOT THE APP WRITTERS, NOT THE GUIDE WRITERS, JUST YOURSELF.
1.
First things first: you might have a lot of programs running which use temproot.
Remove them. ALL.
Check SuperUser which apps have been granted root, and uninstall them, removing all data. For previous (temproot only) versions of Visionary, it might be safer to stop it temprooting at startup, and restart your phone (longpress power, select restart or power off), then remove visionary, just in case.
Finally, remove SuperUser itself.
All the above might not be necessary, but there have been reports of trouble from having these programs running whilst trying to achieve permroot. So be safer rather than sorrier.
2.
Now your phone is essentially running a stock version; no programs running root are active, no surprises at startup. Titanium Backup etc etc are not going to interfere.
Get the following files and programs:
From the Marketplace:
-Gscript (Lite is fine)
-Terminal Emulator
-a root file explorer. The only program I’ve found which does what I need is Root Eplorer. It will cost you money, but Android Mate or Astro haven’t been able to do the job for me.
(DO NOT INSTALL YET -SuperUser; we’ll get this later on; if you install it now you might run into trouble whilst trying to get root, as it might interfere with certain program’s checks to see if you have root already. I mention this program here so you know you’ll need it later, so either have access to the Marketplace or have the .apk ready to install later on.)
Install these on your ‘clean’ phone.
From the internet:
-the files listed in the first post of :
http://forum.xda-developers.com/showthread.php?t=805327 (adwinp’s guide)
or
http://forum.xda-developers.com/showthread.php?t=834427 (Evostance’s guide)
I used the second link (and the guide Evostance wrote which is included). Use this time to read through what Adwinp and Evostance say. Follow the link to their threads and understand what you’re doing.
-get Visionary+ from the awesome Paul O’Brian.
DO NOT INSTALL THIS YET!
http://android.modaco.com/content/t...350/10-nov-r12-test-visionary-one-click-root/
Use a version higher than v11 (v12, v 13, v14 … I don’t know what version he’s on; you might have to look for v13 in that thread, page 6, 7 or 8, if he hasn’t released a newer version).
3.
Now, get all these files and apk’s on your phone. Sync ‘em, download them direct, use wifi, whatever. Just don’t install them (yet). You want the raw files.
Specifically:
-the visionary apk
And from any of those packages you downloaded from the guides listed above:
-the wpx.sh and hboot.sh files (found in the gscript folder of Evostance’s guide’s package): these should be put on your SDCARD, in a directory named gscript (you might be able to put them anywhere, I put them here and the process worked for me).
-the correct wpx.ko and hboot-XXXXXX.nbo files. The XXXXXX refers to a specific hboot file, corresponding to if you updated your phone over the air with the HTC fixes or not. These files are found in rar/zip packages found in the previous mentioned guides (and probably many other mirrors). Pick the files which are located in the folder whose name corresponds to your kernel version (found on your phone using menu -> settings -> About phone -> Software Information -> kernel version).
These .ko files should be put in your SDCARD’s root directory
4. RECAP:
Now you should have
-Gscript and Terminal Emulator installed
-the Visionary .apk on your sd card somewhere
-wpx.sh and hboot.sh in the SDCARD\gscript directory
-wpx.ko and hboot-XXXXXX.nbo on your SDCARD’s root.
5.
Now we’re almost at the point of no return.
Run Gscript.
Hit the menu, “add script” and hit “load from file”. Select the wxp.sh file. Have “run as superuser” selected.
Do the same for hboot.sh.
Exit gscript.
6.
Install Visionary.
Don’t do anything except get temproot. ONLY hit the temproot button; don’t change anything else.
Wait.
You should have temproot now. To be sure, go and select ‘run at boot’ (the ‘re-get temproot’ checkbox) in Visionary and reboot your phone (long powerkey press, restart or shutdown, then restart your phone).
You should have temproot again. You can check this after the next step:
7.
Install SuperUser (preffereably from the Market, so you have the latest version).
If you start the Terminal Emulator, you should now be able to type
su
and hit enter, and the prompt will change from a $ to a #. If so, you have root. You might have to allow SuperUser access to the Terminal Emulator. Do so.
7.
After you have temproot, you should now start Gscript. In the next bits, you might get “Gscript is trying to use SuperUser status” (or somesuch) popup message. Allow this.
Run the wxp script. It should report an error. This is OK.
Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked.
If you get a message saying that this operation couldn’t run, you’ve done something wrong, somewhere. I can’t help you: try from the beginning or something. Sorry I can’t be more helpful than that.
8.
Point of no-return:
You have temproot, you have installed SuperUser and you have run the two Gscript commands.
In this next bit, SuperUser might prompt that Visionary is seeking root permission. DENY THIS. It’s my belief that Visionary expects NOT to get that permission and only then runs. Giving permission leads to not much happening after you press the root button. I suspect a few problems happen due to this. Anyway:
Startup Visionary again. (maybe select ‘mount system as r/w’ … for me it didn’t, which is part of why I’m writing this guide).
Now, in Visionary, hit the ‘get permroot’ button. This process might take a while. If it’s working, the menu you pushed the button on should whisk away to the side: that way, you know Visionary is getting you permroot. Your phone should reset and you should have permroot.
8.
Making it stick.
Use Root Explorer for this next part. I tried using other programs, but they wouldn’t work. Mainly because granting write access hadn’t worked properly.
Now copy
su to /system/bin/
and
Superuser.apk to /system/app/
You can find su in system/xbin/ and SuperUser.apk in /data/app/. You might have to mount the system directories as r/w (from r/o) using Root Explorer. I had to do this, as I didn’t have write access to system files, even though I asked Visionary to do this. No biggy, but it did mean I had to buy Root Explorer. Not a bad price to pay for permroot, write access and a pretty good file explorer 
Now, finally, open Terminal Emulator and type:
su <enter>
chmod 4755 /system/bin/su <enter>
After typing ‘su’, the prompt should change. If it doesn’t, as mentioned before, you don’t have any kind of root (or Term.Emu doesn’t have it, maybe resetting SuperUser’s settings will help) and I can’t help you.
Now you should have total control over your system files. You now finally own your phone.
9.
Thanks to everyone involved, from the hackers to the helpers to the guide writers to those who just chimed in. I didn’t do anything except steal all this info from them, use their files and programs and write this down.
Thank you; we NAND locked phone users are in your debt.
Hi MacDegger,
Good effort, a couple of things that when reading appear a little off, unnecessary or confusing
"You should have temproot now. To be sure, go and select ‘run at boot’ (the ‘re-get temproot’ checkbox) in Visionary and reboot your phone (long powerkey press, restart or shutdown, then restart your phone).
You should have temproot again. You can check this after the next step:
7.
Install SuperUser (preffereably from the Market, so you have the latest version).
If you start the Terminal Emulator, you should now be able to type"
- There is no need to reboot. Also, checking "run on bootup" is something I would refrain from. Simply temp-root is enough
- Why "install superuser" from market?! temprooting via visionary (r12 is what I used) already pushes Superuser.apk to /data/app, so there is no need to re-install from market
- So instead, I would simply temp root with visionary. No reboot, not market download
In this next bit, SuperUser might prompt that Visionary is seeking root permission. DENY THIS. It’s my belief that Visionary expects NOT to get that permission and only then runs. Giving permission leads to not much happening after you press the root button. I suspect a few problems happen due to this. Anyway:
Startup Visionary again. (maybe select ‘mount system as r/w’ … for me it didn’t, which is part of why I’m writing this guide).
Now, in Visionary, hit the ‘get permroot’ button. This process might take a while. If it’s working, the menu you pushed the button on should whisk away to the side: that way, you know Visionary is getting you permroot. Your phone should reset and you should have permroot.
Also not necessary. Visionary R12+ (actually use the R13 version as this one skips the "root already installed routine" some people have issues with) will permroot your device straight after temprooting it just fine. It will open the wpx.ko, will write busybox and su to system/xbin, will repush superuser.apk to /data, will then copy wpthis-lovinglymadebymodaco.ko to /data/local and then reboot.
After this reboot, you are already perm rooted. uninstall visionary, and reboot to test it.
Run the wxp script. It should report an error. This is OK.
NOTE: running visionarx to PERMROOT will copy the required wpthis.ko file (with the right kernel version to /data/local), and will call it "wpthis-lovinglymadeforyoubymodaco.ko."
So as a matter of fact you now have 2 (two) modules in /data/local, the wpx.ko and modaco (pauls) version of it. Whilst no biggy, I would simply adapt the wpx script to insmod pauls version, not wpx anymore. Just to be safe the right kernel is used when execuing and opening the exploit to remove the RW protection to /system, and I believe visionary+ actually checks the kernel and then pushed the correct wpthis*.ko to /data/local.
The next steps,
8.
Making it stick.
Use Root Explorer for this next part. I tried using other programs, but they wouldn’t work. Mainly because granting write access hadn’t worked properly.
Now copy
su to /system/bin/
and
Superuser.apk to /system/app/
You can find su in system/xbin/ and SuperUser.apk in /data/app/. You might have to mount the system directories as r/w (from r/o) using Root Explorer. I had to do this, as I didn’t have write access to system files, even though I asked Visionary to do this. No biggy, but it did mean I had to buy Root Explorer. Not a bad price to pay for permroot, write access and a pretty good file explorer 
Couple of things - visionary will only mount to /RW when flagged and executing TEMPROOT. SO by default, upon reboot the system is always in R/O mode, not R/W mode, whether you use visionary or install root manually. Thats fine and as you said, you can remout RW with RootExplore or via ADB.
Pushing SU and superuser.apk from /data/app and /system/xbin to /system/app and /system/bin is, whilst "safe" not really required. Superuser.apk is quite happy being on /data/app, and IF you must move it to /system/app, you should do a couple of things.
a) MOVE it, not copy it. This way, the user data (which permissions are allowing access to root) will not uninstall, and the permissions will also be set correctly (664 permissions for apps, or RWRWR). Copying it is not ideal, as it could simply kill/forget or cause other issues to it when you do it wrong. And if the permissions are missing as you didn't copy right, you basically blocked yourself our of your root-method permanently.
b) Copying su to system/bin is nice, but again, I would rather create a symlink to is in system/bin to execute/link to system/xbin. Again permissions are necessary and vital
They work just fine in /data/app and system/xbin. THe only reason to move su to system/bin is that some apps simply look for SU in /system/bin, and not in system/xbin. Most well programmed apps that require root will find it anyway, regardless of whether su is in /system/bin or system/xbin.
SO, I would, if I had to advice "noobs", simply leave them where they are. I would temproot, permroot and then install the s-off recovery. Nothing more after step 7.
PS the point of no return, the really dangerous bit, is actually THIS
Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked.
Thats where your system is flashing the bootloader, this is the risky part, where things can go terribly wrong. So "something worked" is maybe not very noob-friendly SO when writing for newbies, make sure they understand ONE thing.
ALL they do in your guide is reversible with flashing the RUU again if something got messed up.
But this
"Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked. "
This is where you CAN turn your device into a 600 USD paperweight!
I think this guide has too much info for the average user to understand.
It's better for the average user to just permroot only and leave hboot alone until they know what can go wrong.
My guide takes alot less steps to achieve S-OFF, because I use the kernel module Visionairy+ leaves behind after permrooting. In other words if you fail to permroot, you won't be able flash HBOOT until you read the other topics on how to modify the module. Which leaves the average Jo far away from a possible brick without some knowhow.
Just my two cents.
Thanks for your awesome comment, Thyrus! I think that an android newb (like me ) now has enough information, after reading this with your post, to do this safely.
I'm going to incorporate your comments into the post, but there's one thing I'm hazy on. Thing is, what I described above was the exact sequence I used to get root and write. You seem to suggest that the whole gscript thing is unnecessary and visionary13+ permroot does all of that anyway, except for flashing the hboot?
So basically I flashed my hboot twice, and because I ran the two gscript scripts, I basically rooted my phone twice?
Just to be sure, you suggest getting rid of the whole gscript section and replacing it with "run visionary permroot now, and if you really want to (and at your own risk) flash the hboot using the gscript hboot.sh"?
I'll wait for your response before changing, just to be sure. Anyway, thanks for your great post!

(noob-ish) AmazonKindleFire7-2019: Where to put startup scripts eg. iptables rules.

Hi all.
I'll make my apologies if this post is in the wrong place or against any rules, if so sorry for creating more work for the mods!
I dabble in Linux, so bear with me here. I am not a complete noob, but to some of you folks here, I am certainly in the gutter of the pecking order
So I got a cheap Amazon Kindle Fire 7" 2019 model, and thanks to this forum have used diplomatic's mtk-su tool to get superuser (su/root) on adb and Termux, which has allowed me to get rid of a lot of Amazon bloat and data collection, and system apps that just aren't useful, replace the launcher and generally make this tablet useable.
I have not, as of yet, installed a modified boot loader/twrp/magisk stuff. I am trying to avoid that route, as there is quite a chance of me messing up and I am destructive when trying to take things apart (maybe unplug battery required).
On to network interface security.
I've installed NetGuard, read a lot and understand the idea behind how it works. Dump unwanted traffic to a sinkhole VPN connection.
I would like to utilise iptables. After using mtk-su in termux, I can access and create rules and these apply instantly. All seems to work as expected, however, as we all know iptables rules are not persistent and a reboot clears them all out and replaces with the stock ruleset - which is a bit too open and has strange stuff in it.
Q:
Run a my_rules script on startup.
So I can write a .sh script with the iptables rules I want applied. It won't have root permission and won't run, but if executed at boot time by another script? ( .rc ) which does have permission to do root things, the script should run, rules be applied and I can be happy.
For one thing, I am not sure quite where to add my script. I have read somewhere that the .rc files I can see are actually created from a secure/encrypted/compressed store which is uncompressed at boot time. So editing an .rc file which is freshly created is pointless.
Secondly, I guess import <name of script -no.sh extension->? won't work, and will probably need service <name of script> and oneshot or another command.
Am I going to have to go the twrp/magisk route? Do I really need to make changes to more than I can access with root and a terminal on the running device?
Thank you for your time and patience to read this post.
I am obviously not reading enough!
It seems the /system/ folder is all read-only. I can't even "cp /system/bin/install-recovery.sh /system/bin/install-recovery_bak.sh" to back up the existing.
Will try mounting /system as rw, maybe.
*edit*
OK, a major problem is that /system is not writable. mount -o remount,rw /system or /dev/block/dm-0 looks like it works but the location still cannot accept new files created or changes to existing files.
There seems to be a watchdog or something running which prevents changes to the mounting here.
So, I conclude this is what people mean by rooting - booting a modified system which allows access to these such places. Having su in a terminal /adb is all great, but still can't do everything - opens up the opportunity of going further and changing boot loader, twrp and magisk though.
Sigh, I was hoping to avoid that path.
I can, at least, launch a small shell script which would leverage mtk-su to run and write my iptables rules into the running system. But this would be a manual exercise and I am bound to forget to apply it.
If mods wish to delete this thread, I have no objection. but maybe it might help someone else in my situation to understand a little more or maybe not.
I think I am showing how much of a noob I am here. Sorry.

Options other than Titanium Backup for backing up/restoring all Android apps?

Currently running a OnePlus 8T + 5G with unlocked/TWRP bootloader which is not rooted, since neither of the two methods want to work on my specific version (KB2007; unlocked former T-Mobile).
Anyway, I'm trying to switch to another ROM but I'm wondering how best to backup/restore all of my apps. Loved using Titanium Backup way back in the day, but am I still correct in assuming that it doesn't work correctly without root access? If so, are there any non-root methods of backing up all or most of my apps along with their current configurations/etc to restore into the new ROM once it's installed? Obviously, most ROMs will support doing it through Google Play, but then it takes forever to log back in to each app, set it all back up, etc. If I've been missing some basic way of restoring all the apps with their configurations intact, please feel free to smack me upside the head with the answer =)
And my apologies in advance if I'm misusing any of the terminology. Before this phone, it has been at least five years since I even tried rooting/unlocking/etc, so I'm a bit rusty.
In the world of computers an app belongs to person who installed it, app's data are owned by the app itself.
Hence it should be obvious that only an user with elevated rights ( AKA Superuser or Root ) can perform a backup and/or restore.
Take note that a temporary root is enough to do the jobs.
Got it. So, in other words, figure out how to root the phone despite the troubles I've been having trying to do so. Unless there's some sort of temporary root privs available that I've never heard of?
To get a temporary root all you have to do is to add to Android OS the binary called SU
Example
Code:
adb push <LOCATION-OF-SU-BINARY-ON-COMPUTER> /data/local/tmp/
adb shell "chmod +x /data/local/tmp/su"
what then allows you to run Android shell commands when elevated rights are needed
Example
Code:
adb devices
adb shell "/data/local/tmp/su -c '<SHELL-COMMAND-HERE>'"
Am I correct in assuming that SU is the same as "switch/substitute user" in *nix? Does that mean I can run TB from the ADB shell, assuming I include the correct command line arguments? Something along the lines of doing a SUDO in *nix before running something that requires admin access or whatever.
I know this might be quite different from what you're looking for maybe?
In the future if you get a rooted rom, I use something called Migrate from the play store, it requires root and just copies all your data into a bunch of twrp flashable zip files.
Play Store
silentrawr said:
Am I correct in assuming that SU is the same as "switch/substitute user" in *nix? Does that mean I can run TB from the ADB shell, assuming I include the correct command line arguments? Something along the lines of doing a SUDO in *nix before running something that requires admin access or whatever.
Click to expand...
Click to collapse
SU in root context usually means super user, as a user with all privileges, but it's the same thing as super user, so yes.
Hello Everyone,
I too am interested in a backup solution for my Android smartphone.
I would happily root or temporarily root, but despite having a computer background that dates back to Unix, I am an Android novice and do not know how to perform these operations which to most people here seem elementary.
Could someone please point me to an easy to understand primer on either temporary root or permanent root.
I would be very appreciative and I am sure that there are other readers of this post who would benefit as well.
Thank you.
AndroidNewbie9000 said:
Could someone please point me to an easy to understand primer on either temporary root or permanent root.
I would be very appreciative and I am sure that there are other readers of this post who would benefit as well.
Thank you.
Click to expand...
Click to collapse
The thing is, that the "official" way to root a device nowadays usually includes a wipe of all user data. You basically have to decide that you want to do full backups before you use an app. This is a security measure so that an attacker cannot use the official way to e.g. access app-internal data on a stolen phone, like secret tokens of 2FA-apps. In order to backup existing app-internal data you either need to use the per-app-backup that the creators of that app did hopefully include or hope that the allowed to do adb backup. That can be used without root, but depending on your Android, apps either need to allow this explicitly or at least not explicitly disallow that in their manifest file.
In principle you can use exploits for non-official rooting to backup existing data that is blocked from adb backup - but this is only an option if you do not have the latest security updates in place and an exploit is publicly available.

Categories

Resources