Related
Hi All,
This is just a quick 2 part question as I see many threads for the GNEX on rooting, but none very concrete on removing root. I've tried searching, but I must have missed it.
So, my questions are:
1. Once rooted via whatever method (I used fastboot method myself, thanks efrant for teaching the fastboot stuff), how do I unroot this thing to bring it back to stock configuration?
2. To make the unit truly stock again, can I just use fastboot and flash a factory google image? I know doing this will eliminate all my data, but will it remove all traces of any rooting done? (Insecure Kernal, SU, Busybox and whatever else)?
Please let me know.
Thanks guys... wasn't planning on rooting, but I miss the ability to do it. lol
1. See two.
2. Yes.
Flashing the stock image will bring your phone back to an out-of-the-box state.
Sent from my Galaxy Nexus using Tapatalk 2
infazzdar said:
1. See two.
2. Yes.
Flashing the stock image will bring your phone back to an out-of-the-box state.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Thanks man,
Makes me feel better about my decision to root this phone.
Appreciate the reply.
If you installed Superuser to system when you rooted then you'll need to remove that also but here are the basic adb commands for the job (make sure you have data and system mounted via CWM so you have access):
Code:
adb shell
rm /system/bin/su
mount -o remount,ro -t ext4 /dev/block/mmcblk0p1 /system
exit
BusyBox is another matter since CWM installs it to sbin every time you boot with it. Perhaps someone has a better idea (?), but from messing around a bit the other night the best method I've come up with is to use BusyBox to remove BusyBox, as follows:
Code:
adb shell
cd /sbin
cp busybox /data/local/tmp/busybox
chmod 06755 /data/local/tmp/busybox
rm busybox
/data/local/tmp/busybox rm `/data/local/tmp/busybox find -follow -maxdepth 1 -type l`
/data/local/tmp/busybox rm /data/local/tmp/*
exit
that second to last line gets rid of all the stray symlinks busybox left behind, not sure if CWM leaves any of those recovery/symlinks in sbin also or if those should be removed as well; perhaps someone else can fill us in on that point!
osm0sis said:
If you installed Superuser to system when you rooted then you'll need to remove that also but here are the basic adb commands for the job (make sure you have data and system mounted via CWM so you have access):
Code:
adb shell
rm /system/bin/su
mount -o remount,ro -t ext4 /dev/block/mmcblk0p1 /system
exit
BusyBox is another matter since CWM installs it to sbin every time you boot with it. Perhaps someone has a better idea (?), but from messing around a bit the other night the best method I've come up with is to use BusyBox to remove BusyBox, as follows:
Code:
adb shell
cd /sbin
cp busybox /data/local/tmp/busybox
chmod 06755 /data/local/tmp/busybox
rm busybox
/data/local/tmp/busybox rm `/data/local/tmp/busybox find -follow -maxdepth 1 -type l`
/data/local/tmp/busybox rm /data/local/tmp/*
exit
that second to last line gets rid of all the stray symlinks busybox left behind, not sure if CWM leaves any of those recovery/symlinks in sbin also or if those should be removed as well; perhaps someone else can fill us in on that point!
Click to expand...
Click to collapse
So flashing a Google factory image won't remove root? Or it will, but won't remove all evidence if someone went searching around trying to deny warranty.
When I rooted, I used the method of flashing recovery, then installed the su.zip via recovery. When I unrooted I simply flashed a factory image.
when you say installed superuser to system I'm guessing you mean something more advanced than the typical root process, correct?
Sent from my Galaxy Nexus using XDA
thos25 said:
So flashing a Google factory image won't remove root? Or it will, but won't remove all evidence if someone went searching around trying to deny warranty.
When I rooted, I used the method of flashing recovery, then installed the su.zip via recovery. When I unrooted I simply flashed a factory image.
when you say installed superuser to system I'm guessing you mean something more advanced than the typical root process, correct?
Sent from my Galaxy Nexus using XDA
Click to expand...
Click to collapse
Flashing the factory system image DOES remove root (and busybox and anything else you changed on the ROM).There is no need to do anything that osm0sis said to do.
And there is no "more advanced" process of rooting. Root is two files placed on you system: /system/bin/su and /system/app/Superuser.apk. Nothing more. (Whether you place them there yourself, or have CWM do it for you, is irrelevant.) Remove those those and root is gone.
Sent from my Galaxy Nexus using Tapatalk 2
if you grab wugfresh's toolkit itll do all of that with one-click convenience. thats what I do to un-root my Nexus.
Zbraptorsdr said:
if you grab wugfresh's toolkit itll do all of that with one-click convenience. thats what I do to un-root my Nexus.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?p=21936493
Sent from my Galaxy Nexus using Tapatalk 2
efrant said:
Flashing the factory system image DOES remove root (and busybox and anything else you changed on the ROM).There is no need to do anything that osm0sis said to do.
Click to expand...
Click to collapse
Right, I was referring to "unroot"ing without reflashing the system.img, since my intent with that method was to keep all settings, etc. as-is, just remove all traces of root.
osm0sis said:
Right, I was referring to "unroot"ing without reflashing the system.img, since my intent with that method was to keep all settings, etc. as-is, just remove all traces of root.
Click to expand...
Click to collapse
Yup, you would need to remove it manually if you were running a custom ROM, but with a stock ROM, flashing the system partition only WOULD leave all your data/settings as is.
osm0sis said:
BusyBox is another matter since CWM installs it to sbin every time you boot with it.
Click to expand...
Click to collapse
IS this true? Can someone confirm? And is it true for all phones?
Zbraptorsdr said:
if you grab wugfresh's toolkit itll do all of that with one-click convenience. thats what I do to un-root my Nexus.
Click to expand...
Click to collapse
The easiest way to do it, just click and its does it on its own.
The-Droidster said:
IS this true? Can someone confirm? And is it true for all phones?
Click to expand...
Click to collapse
Just wanted to clear this up now that I'm a bit more wise on the subject. The sbin stuff doesn't matter since it's all part of the ramdisk, and gets generated on each boot (to recovery or OS) and otherwise doesn't exist. No need to delete anything but su. :good:
osm0sis said:
Just wanted to clear this up now that I'm a bit more wise on the subject. The sbin stuff doesn't matter since it's all part of the ramdisk, and gets generated on each boot (to recovery or OS) and otherwise doesn't exist. No need to delete anything but su. :good:
Click to expand...
Click to collapse
he means, of course, "su" as in /system/bin/su AND /system/app/Superuser.apk. partially correct, i think, ramdisk is only used for early OS boot. Ramdisk + kernel = boot.img.
Recovery is on a different partition, for starters, and AFAIK, deploys needed files to a temporary location on the phone's ram or in the file system, which would be the recovery partition. Busybox gets placed in there as well.
Sent from my i9250
stock kernel has a ramdisk but not all kernels are packaged with one. recovery also has a ramdisk, just as it also has a kernel. Decompile/split/unzip one some time and you'll see /sys/ and /proc/ and /sbin/ all get generated from the ramdisk. And yes, if you for some reason put Superuser.apk or SuperSU.apk in /system/app/ (a completely unnecessary step), then naturally they need to go too.
I have managed to get CIFS working on stock Nexus 10.
It's quite a bit more problematic on the Nexus 10 than normal.
There are 2 main issues to deal with. Newer versions of the Linux kernel require a UNC variable to be passed to them and the current version of busybox doesn't do this. There is a patch out. I have extracted the patched busybox binary from craigacomez's AOSP Nexus 10 rom.
(Check it out here: http://forum.xda-developers.com/showthread.php?t=1998585 ). Otherwise it should work on the stock mount command if you specify the unc= mount option with the share.
The other issue is the multiuser stuff. If you execute the mount command from inside Terminal Emulator (or a script program) it looks like it mounts ok and you can 'ls' in the directory but it doesn't work for Android apps, they just see an empty directory but if you do it via a 'adb shell' it works fine in Android apps. My theory is ADB is outside of the multiuser stuff. adb actually ships on the device.
1) Unlock bootloader (fastboot oem unlock)
2) Flash recovery adb flash recovery whatever.img
3) Root device (flash CWM-SuperSU-0.98.zip)
4) Install BusyBox (from the market)
5) Copy md4.ko and cifs.ko to device. The files can go anywhere you like. In this example I will just use the root of the sdcard. Some people like them in /system/modules or /system/lib/modules
6) busybox mount -o rw,remount /
7) adb shell
8) Override /system/bin/busybox with the patched version (maybe move it first so it's backed up).
9) insmod /sdcard/md4.ko
10) insmod /sdcard/cifs.ko
11) busybox mount -t cifs -o username=MYUSER,password=MYPASS,unc=\\\\192.168.1.1\\storage //192.168.1.1/storage /data/media/0/cifs/Storage
You will need to manually preform the last 3 commands each time you reboot the device from a adb shell.
NOTE: You can probably get rid of the -o flags completely. In theory the patched version of busybox makes the UNC bit redundant. Possibly you can use the stock busybox with the UNC flag and avoid using the patched one totally. I have just included it to be sure.
Make sure you type 'busybox mount' not 'mount', by default they are different binaries. Otherwise you can remove the /system/bin/mount command and make a new one linking /system/bin/mount to /system/bin/busybox.
Possibly there is some way to get the mount working in the multiuser environment without requiring busybox. If you figure it out please tell ☺
Some threads on the issue:
http://forum.xda-developers.com/showthread.php?p=34397868#post34397868
http://forum.xda-developers.com/showthread.php?t=733490&page=6
http://www.mail-archive.com/[email protected]/msg17650.html
The modules are for 3.4.5-g4e6298b.
EDIT: I added nls_utf8.ko by request
EDIT2: Since adb comes on the device, it is possible to use it to connect to local host:
1) Install cifs modules to /system/lib/modules
2) Install Script Manager from the play store
3) Copy script to device
4) Start SManager
5) Find your script and open it.
6) Tick the su box
7) Hit save
8) Goto home sccreen
9) Add a 'SMShortcuts' widget to your home screen
10) "Add one script shortcut"
11) Choose your script
12) Optionally use this pretty icon ☺
13) Give it a nice name like "Mount Shares"
Here is a shell script...
Code:
#!/system/bin/sh
# Your settings here
USERNAME="USERNAME"
PASSWORD="PASSWORD"
IPADDRESS="192.168.1.1"
SHARE="storage"
MOUNT_POINT="/data/media/0/cifs/Storage"
# If you need to change the mount command edit this
MOUNT_CMD="\
mount -t cifs \
\
-o \
user=$USERNAME,\
password=$PASSWORD,\
unc=\\\\\\\\\\\\\\\\$IPADDRESS\\\\\\\\$SHARE \
\
//$IPADDRESS/$SHARE \
$MOUNT_POINT"
COMMANDS="\
insmod /system/lib/modules/md4.ko; \
insmod /system/lib/modules/nls_utf8.ko; \
insmod /system/lib/modules/cifs.ko; \
$MOUNT_CMD
"
# Starting ADB...
PORT=`getprop service.adb.tcp.port`
setprop service.adb.tcp.port 5555
adb kill-server
adb start-server
stop adbd
start adbd
adb connect localhost
# Make sure we only use the first device (sometimes there is more than one)
SERIAL=`adb devices | head -n2 | tail -n1 | cut -f1`
if [ "$SERIAL" = "" ] ; then
echo "ERROR: Could not find ADB device.";
fi
echo Mounting share via adb...
adb -s $SERIAL shell su root -c "$COMMANDS"
# If you started adb, then stop it here for security:
adb disconnect localhost
stop adbd
setprop service.adb.tcp.port $PORT
start adbd
RESULT=`mount | grep $MOUNT_POINT`
if [ "$RESULT" = "" ] ; then
echo "Mounting failed..."
else
echo "Mounting sucess!"
fi
echo Done... You may close this script window.
EDIT3: Added usbserial.ko, option.ko and usb_wwan.ko
EDIT4: Some users have reported that the need to modify the script to get it working with their version of SU.
EDIT5: I have uploaded modules for 4.2.2, kernel 3.4.5-gaf9c307 but I haven't actually tested them myself (still on 4.2.1). Apparently the adb loophole has also been patched but it is possible to reenable it by putting a RSA key onto the device. Check out this set of instructions here.
EDIT6: I have updated to 4.2.2 on my Nexus 10 and can confirm the new modules work.
You must setup the adbkey or you will get a "device: offline" message. By default adb when adb first runs it tries to create the keys in the $HOME dir which is /data/.android, but the data directory isn't accessible by the 'shell' user.
I got it working simply by setting the HOME variable to /sdcard and restarting the adb server in the script then Android popped up a query (I have update the script above).
IMPORTANT: The Android Media scanner recursively scans folders for media to add the the database so it shows up in programs like Google Music. On large shares this can be a long process and use heaps of battery life. To prevent this add a blank file with the name ".nomedia" to the root of your mount points (or each individual share if you aren't used 1 folder for all your mounts). This will stop music showing up in programs though.
If you find that the device stops responding (the launcher might work but apps fail to load) or you get reboots (often after the previous bug) this is probably due to a bad wifi connection.
Is it posible to make a CWM flash file?
Great
This is great progress, do you know if there is some way I can use the same to mount my usb OTG with ADB shell so that I can read/write to my pen drives from my android apps/file managers?
I have tried using the busybox mount but that didn't work, do I need the modified mount or will none of this help anyway?
alias_neo said:
This is great progress, do you know if there is some way I can use the same to mount my usb OTG with ADB shell so that I can read/write to my pen drives from my android apps/file managers?
I have tried using the busybox mount but that didn't work, do I need the modified mount or will none of this help anyway?
Click to expand...
Click to collapse
Code:
busybox mount -t FSTYPE /dev/block/sda1 MOUNT_LOCATION
Example:
Code:
busybox mount -t vfat /dev/block/sda1 /storage/sdcard0/usbotg
craigacgomez said:
Code:
busybox mount -t FSTYPE /dev/block/sda1 MOUNT_LOCATION
Example:
Code:
busybox mount -t vfat /dev/block/sda1 /storage/sdcard0/usbotg
Click to expand...
Click to collapse
How is this different to what I'm doing already? Mounting this way doesn't work, only the process that mounted it can see the files.
Although I don't have nexus 10, I am having the similar mounting issue on my nexus 7 until I saw this post.
Advise about "adb shell" really helps me resolve the multiuser issue.
Thanks for sharing.
Any chance you could post the nls-utf8.ko for utf8 support?
Thanks!
H3g3m0n said:
1) Unlock bootloader (adb oem unlock)
Click to expand...
Click to collapse
Isn't it fastboot that unlocks the bootloader, and not adb? (unless adb can do it too; I've only heard of fastboot though)
momulah said:
Is it posible to make a CWM flash file?
Click to expand...
Click to collapse
Not a high priority right now as currently you need to do the manual adb shell stuff by hand to get things mounted, a little extra setup work isn't a huge difference.
alias_neo said:
How is this different to what I'm doing already? Mounting this way doesn't work, only the process that mounted it can see the files.
Click to expand...
Click to collapse
Are you mounting in a 'adb shell' or locally in something like terminal emulator? My OTG cable won't be here for a while so I can't really test myself.
weasal said:
Any chance you could post the nls-utf8.ko for utf8 support?
Thanks!
Click to expand...
Click to collapse
Posted, haven't tested it but it seemed to insmod fine.
espionage724 said:
Isn't it fastboot that unlocks the bootloader, and not adb? (unless adb can do it too; I've only heard of fastboot though)
Click to expand...
Click to collapse
Yeh typoed, i'll fix that now.
Currently I'm thinking of ways to hack around the 'adb shell' requirement, as a basic hackish fix would be to make a program that turns on adb wireless, connects to the local device and issues a command. Of course possibly there is a 'proper' way to do mounting. Another lazy way for those with their shares on a Linux system would be a script issue commands to the server via a ssh, getting it to log back into the phone and mount stuff over adb wireless.
alias_neo said:
How is this different to what I'm doing already? Mounting this way doesn't work, only the process that mounted it can see the files.
Click to expand...
Click to collapse
I've been working on getting OTG support natively in my AOSP based custom ROM and I have had some success... check out my ROM for details
H3g3m0n said:
Currently I'm thinking of ways to hack around the 'adb shell' requirement, as a basic hackish fix would be to make a program that turns on adb wireless, connects to the local device and issues a command. Of course possibly there is a 'proper' way to do mounting. Another lazy way for those with their shares on a Linux system would be a script issue commands to the server via a ssh, getting it to log back into the phone and mount stuff over adb wireless.
Click to expand...
Click to collapse
Just wanted to thank H3g3m0n as I was able to successfully mount over adb. Also came up with a workaround to bypass connecting to a PC, grabbed the arm fastboot binary from this thread and installed it on my nexus 7. Used it to connect wireless adb on the 10 and ran the mount commands on the 7.
H3g3m0n said:
Posted, haven't tested it but it seemed to insmod fine.
Click to expand...
Click to collapse
Thanks, I'll give it a try!
You might find my posts #156 and #162 at http://forum.xda-developers.com/showthread.php?t=1781411&page=17 helpful.
Sorry for the noob ? ...
What are the KO's do?
What is the practical use of then.
Sorry I did a little research on then but I could not find an answer in layman terms
Thank you for allowing me to learn.
Sent from my toroplus using xda premium
spdwiz18 said:
Sorry for the noob ? ...
What are the KO's do?
What is the practical use of then.
Sorry I did a little research on then but I could not find an answer in layman terms
Thank you for allowing me to learn.
Sent from my toroplus using xda premium
Click to expand...
Click to collapse
http://en.wikipedia.org/wiki/Loadable_kernel_module
craigacgomez said:
http://en.wikipedia.org/wiki/Loadable_kernel_module
Click to expand...
Click to collapse
That helps allot.... Now i have an understanding of ko's in general. But what specificly do the modules this thread refers to do and the practical use of then. Thanks foot the help.
Sent from my toroplus using xda premium
spdwiz18 said:
That helps allot.... Now i have an understanding of ko's in general. But what specificly do the modules this thread refers to do and the practical use of then. Thanks foot the help.
Sent from my toroplus using xda premium
Click to expand...
Click to collapse
These modules are needed to enable support for CIFS (Windows share) mounts...
spdwiz18 said:
That helps allot.... Now i have an understanding of ko's in general. But what specificly do the modules this thread refers to do and the practical use of then. Thanks foot the help.
Sent from my toroplus using xda premium
Click to expand...
Click to collapse
Basically you can setup a shared folder from a remote computer. It allows you to have files on another system accessible as if it was part of the internal storage in the device.
Just found out that Android ships with the adb binary on the device itself (after crosscompiling it myself :/, oh well the experience was useful).
It should be possible to setup a script to start the adb server, connect to the localhost and execute the mount without too much difficulty.
Ok, added a script and instructions to the front page for simple on tablet mounting.
This is a thread that will allow you to ask specific questions and get some help with any dev work you may be attempting.
This will be a community effort between enewman17, loserskater, stratatak7, and myself. It would be great if other devs want to join in.
Acceptable questions
"I am trying to recompile X using APK Tool and I get this error. What am I doing wrong?".
"I am trying to flash the ROM I just built and I keep getting a status 0 error. Any thoughts?".
Unacceptable questions
"How do I compile/decompile apks?"
"How do I mod a kernel"
Theming questions go here.
Thread Rules
Do not post unless you have searched the thread.
Only post specific questions.
Only post long sections of code using the code or hide tags.
Your question may not be answered immediately. Be patient.
Use the thanks button (even if you don't get the answer you want).
Many thanks to kennyglass123 for the sticky!
Re: So you want to be a dev?
Just wanted to comment about questions.
The more info the better!
Bad comment: "I can't get X mod to work."
Better: "I'm trying to get X mod to work, and settings keeps FCing. Here's my modified files and a logcat."
Sent from my SAMSUNG-SGH-I747
Anyone feel free to PM me and I'll help you get the ball rolling if you feel your question does not meet thread criteria and you're looking to start development. I realize everyone has to start somewhere. Just be prepared for work.
mine
Now that we have thoroughly thanked each other, maybe someone will stop by with some questions. :silly:
upndwn4par said:
Now that we have thoroughly thanked each other, maybe someone will stop by with some questions. :silly:
Click to expand...
Click to collapse
LOL. I sure hope so.
For those of you reading this, feel free to ask any questions you have about Android development-related modification. I'm sure between the four of us and anyone else who wants to help out that knows what they are doing will know. I'm happy to help out with anything I can.
How do you double the hours in a day so you have enough time to actually do this stuff
Seriously though, this is a great thread and nice to see 4 of the top devs working together and willing to help.
If I ever do find the time I'm sure I'll be back.
Sent from my SGH-I747 using xda premium
jde984 said:
How do you double the hours in a day so you have enough time to actually do this stuff
Click to expand...
Click to collapse
A (somewhat) valid question: For me, it requires a very understanding wife and sleep deprivation.
______________
OK, now let's keep this thread clean and on topic. Thanks!
See in my sig a guide how to decompile apks, edit, and recompile apks! link: http://forum.xda-developers.com/showthread.php?t=2147425
My question: I'm attempting to edit smali for the first time. However, it's pretty foreign. Any guides or tutorials out there? I've searched, but nothing substantive (just some pages on the nomenclature for the dalvik bytecode). My issue is that the instructions for the mod have different registers than me and I can't figure out how to adjust the changes.
It's difficult to answer generic questions like that.
Post up what you are trying to do and maybe we can all work it our together.
headsest control for AOSP
Ok... Team LiquidSmooth is stumped as am I, and I've spent about 8-10 hours searching all in all, through Google, CM threads, Android General/q&a and githubs... I'm still looking but wondering if I could get some help before their team or I pull any more hair out. Basically just what my title says, need the code for controlling music and phone calls from headset controls. The capacitive keys light up when the buttons are pressed but no actions are performed. It's as if the rom is just missing the path for them or something. Any help on where to search or anything, I'm game. Thanks guys.
SOLVED, thanks anyways guys :good:
upndwn4par said:
It's difficult to answer generic questions like that.
Post up what you are trying to do and maybe we can all work it our together.
Click to expand...
Click to collapse
Got it. I'll write up my issues...but, I've been having some trouble with adb and think that might be a bigger issue, haha:
I'm trying to allow adb to run as root. I decompiled boot.img, changed ro.secure to 0, recompiled boot.img, and pushed. Default.prop now shows ro.secure=0. But, I tried running adb remount and I still get permission denied? Someone said there may be other edits required, but I can't seem to find any.
Here's what I changed it to:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Here's what ADB is telling me:
Code:
[email protected]:/ $ getprop ro.secure
getprop ro.secure
0
[email protected]:/ $ exit
exit
adb remount
[B]remount failed: Operation not permitted[/B]
ikjadoon said:
Got it. I'll write up my issues...but, I've been having some trouble with adb and think that might be a bigger issue, haha:
I'm trying to allow adb to run as root. I decompiled boot.img, changed ro.secure to 0, recompiled boot.img, and pushed. Default.prop now shows ro.secure=0. But, I tried running adb remount and I still get permission denied? Someone said there may be other edits required, but I can't seem to find any.
Here's what I changed it to:
Here's what ADB is telling me:
Code:
[email protected]:/ $ getprop ro.secure
getprop ro.secure
0
[email protected]:/ $ exit
exit
adb remount
[B]remount failed: Operation not permitted[/B]
Click to expand...
Click to collapse
Try this in terminal...
adb root
Then
adb remount
That should do it for ya.
task650 said:
Try this in terminal...
adb root
Then
adb remount
That should do it for ya.
Click to expand...
Click to collapse
Thanks for the reply! Right: I should probably be root before I try that command. Unfortunately, I tried "adb root" and it said: "adbd cannot run as root in production builds." I did some Google'ing and a few threads said that I should have changed ro.debuggable to 1 as well in default.prop.
So, I changed ro.debuggable=1 and, right, ro.secure=0 still. Then the oddest thing happened: I typed "adb root" into terminal and it went to a new line, no message. And then it disconnected my phone from ADB (I heard the little "ding ding" noise of disconnection). Unfettered, I typed in "adb remount," but of course then it complained that no devices were attached! I thought it was a fluke, so I tried it a few more times. It happened again and again.
In an ostensibly unrelated problem, I couldn't get SecSettings.apk to push back (even though android.policy.jar pushed fine), so I tried a Nandroid. TWRP seemingly did not like my changes to default.prop, as it went crazy (froze a few times) saying "cannot unmount /system" every time I tried a restore and then "Restore failed." Hmm...I pushed back my backed up boot.img and it restored fine.
I'm messing up somehow. So, I'm using VTS to unpack and repack the image. I saw that the output boot.img's are about 6MB, while the default ones I pulled are 10.1MB. Dev said it was probably just compression? Also, I'm pulling the boot.img via adb dd if=/dev/mnt/mmcblk0p7 of=/sdcard/boot.img. Are either of these too weird/wrong?
ikjadoon said:
Thanks for the reply! Right: I should probably be root before I try that command. Unfortunately, I tried "adb root" and it said: "adbd cannot run as root in production builds." I did some Google'ing and a few threads said that I should have changed ro.debuggable to 1 as well in default.prop.
So, I changed ro.debuggable=1 and, right, ro.secure=0 still. Then the oddest thing happened: I typed "adb root" into terminal and it went to a new line, no message. And then it disconnected my phone from ADB (I heard the little "ding ding" noise of disconnection). Unfettered, I typed in "adb remount," but of course then it complained that no devices were attached! I thought it was a fluke, so I tried it a few more times. It happened again and again.
In an ostensibly unrelated problem, I couldn't get SecSettings.apk to push back (even though android.policy.jar pushed fine), so I tried a Nandroid. TWRP seemingly did not like my changes to default.prop, as it went crazy (froze a few times) saying "cannot unmount /system" every time I tried a restore and then "Restore failed." Hmm...I pushed back my backed up boot.img and it restored fine.
I'm messing up somehow. So, I'm using VTS to unpack and repack the image. I saw that the output boot.img's are about 6MB, while the default ones I pulled are 10.1MB. Dev said it was probably just compression? Also, I'm pulling the boot.img via adb dd if=/dev/mnt/mmcblk0p7 of=/sdcard/boot.img. Are either of these too weird/wrong?
Click to expand...
Click to collapse
Are you running adb shell as superuser?
Try:
adb shell
su
adb remount
After typing su you will need to grant superuser permission on your device.
Things to check when pushing with adb:
System, app, and framework folders are mounted r/w in root explorer.
USB debugging is enabled.
I am lazy so I use Eclipse for pushing and pulling files.
Repacked boot images are almost always smaller than the original (sometimes a lot smaller).
upndwn4par said:
Are you running adb shell as superuser?
Try:
adb shell
su
adb remount
After typing su you will need to grant superuser permission on your device.
Things to check when pushing with adb:
System, app, and framework folders are mounted r/w in root explorer.
USB debugging is enabled.
I am lazy so I use Eclipse for pushing and pulling files.
Repacked boot images are almost always smaller than the original (sometimes a lot smaller).
Click to expand...
Click to collapse
EDIT: I gave up, haha. Thank you guys, though. I just copied and pasted both files onto /sdcard and then used the good 'ole adb shell mount -o remount,rw /system and then busybox cp of the files over. Copy worked. And the mod worked. And, honestly, I don't flash enough to make adb root worth it. It's a few extra seconds of my life to type the extra commands instead of taking 2 days to figure out this boot.img....
----
I re-did the ro.secure=0 edit in the boot.img through dsixda's kitchen, just to be sure it wasn't VTS. I also "flashed" it via adb dd in recovery this time instead of in Android. I also left ro.debuggable=0 as that does not seem pertinent to allowing adb to run as root, but simply to debug system apps, etc. Does anyone know any actual information on whether ro.debuggable=0 is required to allow adbd to run as root?
1) ADB shell as superuser: um, I didn't think about that! I thought adb root and adb remount were ADB commands, not shell commands? But, I tried it anyways, but it simply said "error: device not found". See http://prntscr.com/wvjmq
2) Right, ADB shell has SU rights as "always grant" per the SuperSU app.
3) Pushing with ADB: oh, huh! So, adb remount or mount -o remount,rw /system are not recursive? Meaning they only apply to the top-level directory? I think that's what you're saying, but that has never been a problem in the past...I think. And, technically, that doesn't explain why when I didn't mount /system/framework specifically android.policy.jar pushed fine. Pushing SecSettings.apk to /system/app causes a "Permission denied" error. Can Android reject apks? I did a few minor edits to SecSettings.apk, from this mod: http://forum.xda-developers.com/showthread.php?t=2002620
4) Thanks for the boot.img size clarification; got a little worried after having "lost" 40% of the image, haha!
tl;dr:
1) Using either VTS or dsixda's kitchen to modify boot.img to ro.secure=0 and running "adb root" = "adbd cannot run as root in production builds." Pulled and flashed boot.img via adb dd.
2) Unrelated to issue 1 (I think): after mounting system via adb shell (mount -o remount,rw /system), I cannot push SecSettings.apk into /system/app ("Permission denied"), while android.policy.jar pushes just fine /system/framework.
I appreciate everyone's help here. I think it's something really little that I've missed and I just can't figure it out.
ikjadoon said:
EDIT: I gave up, haha. Thank you guys, though. I just copied and pasted both files onto /sdcard and then used the good 'ole adb shell mount -o remount,rw /system and then busybox cp of the files over. Copy worked. And the mod worked. And, honestly, I don't flash enough to make adb root worth it. It's a few extra seconds of my life to type the extra commands instead of taking 2 days to figure out this boot.img....
----
I re-did the ro.secure=0 edit in the boot.img through dsixda's kitchen, just to be sure it wasn't VTS. I also "flashed" it via adb dd in recovery this time instead of in Android. I also left ro.debuggable=0 as that does not seem pertinent to allowing adb to run as root, but simply to debug system apps, etc. Does anyone know any actual information on whether ro.debuggable=0 is required to allow adbd to run as root?
1) ADB shell as superuser: um, I didn't think about that! I thought adb root and adb remount were ADB commands, not shell commands? But, I tried it anyways, but it simply said "error: device not found". See http://prntscr.com/wvjmq
2) Right, ADB shell has SU rights as "always grant" per the SuperSU app.
3) Pushing with ADB: oh, huh! So, adb remount or mount -o remount,rw /system are not recursive? Meaning they only apply to the top-level directory? I think that's what you're saying, but that has never been a problem in the past...I think. And, technically, that doesn't explain why when I didn't mount /system/framework specifically android.policy.jar pushed fine. Pushing SecSettings.apk to /system/app causes a "Permission denied" error. Can Android reject apks? I did a few minor edits to SecSettings.apk, from this mod: http://forum.xda-developers.com/showthread.php?t=2002620
4) Thanks for the boot.img size clarification; got a little worried after having "lost" 40% of the image, haha!
tl;dr:
1) Using either VTS or dsixda's kitchen to modify boot.img to ro.secure=0 and running "adb root" = "adbd cannot run as root in production builds." Pulled and flashed boot.img via adb dd.
2) Unrelated to issue 1 (I think): after mounting system via adb shell (mount -o remount,rw /system), I cannot push SecSettings.apk into /system/app ("Permission denied"), while android.policy.jar pushes just fine /system/framework.
I appreciate everyone's help here. I think it's something really little that I've missed and I just can't figure it out.
Click to expand...
Click to collapse
If you post the kernel (untouched) for me. I will go through the process myself. That when when/if it works I can tell you my exact steps so that you can try it out for yourself. Let me know exactly what you are trying to accomplish also.
task650 said:
If you post the kernel (untouched) for me. I will go through the process myself. That when when/if it works I can tell you my exact steps so that you can try it out for yourself. Let me know exactly what you are trying to accomplish also.
Click to expand...
Click to collapse
You guys are too kind. I feel like you have more important things to do than help a sucker like me. If you're very bored, go ahead.
Attached is my stock, unadulterated boot.img inside a zip. What I am trying to accomplish: push system files from ADB (without going into the shell). I think you need adbd to run as root to do that, right? So, an "insecure" kernel. Thus, I should be able to type "adb root" and then "adb remount" to make /system rw instead of ro and then type "adb push SystemUI.apk /system/app/SystemUI.apk" and it work. I thought I just needed to make ro.secure=0 in the boot.img's default.prop, but it looks like that is not enough.
But, honestly, if it looks like it takes too much time (I'm serious; I honestly think Samsung sent me a borked phone), it's all good. ADB shell and Busybox cp will suffice. I'm just more curious of what I am doing wrong here.
~Ibrahim~
Interesting. I am getting the same error (yes, ro.secure=0 and ro.debuggable=1).
As soon as I am finished with the update I am working on I will look in to this - unless Task figures it out first. If for no other reason, just because I want to know.
Code:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Me>cd c:\android
c:\Android>adb devices
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached
041b9c2b device
c:\Android>adb shell
[email protected]:/ $ adb root
adb root
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
error: device not found
1|[email protected]:/ $ su
su
[email protected]:/ # adb remount
adb remount
error: device not found
1|[email protected]:/ # adb root
adb root
error: device not found
1|[email protected]:/ #WTF?
upndwn4par said:
Interesting. I am getting the same error (yes, ro.secure=0 and ro.debuggable=1).
As soon as I am finished with the update I am working on I will look in to this - unless Task figures it out first. If for no other reason, just because I want to know.
Code:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Me>cd c:\android
c:\Android>adb devices
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached
041b9c2b device
c:\Android>adb shell
[email protected]:/ $ adb root
adb root
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
error: device not found
1|[email protected]:/ $ su
su
[email protected]:/ # adb remount
adb remount
error: device not found
1|[email protected]:/ # adb root
adb root
error: device not found
1|[email protected]:/ #WTF?
Click to expand...
Click to collapse
You shouldn't be running adb root inside of a shell. You're running two instances of adb and only need the first connection. The reason you're getting device not found is because you're running an instance of adb on the device and it's looking for other devices. Try it again without running adb shell.
Sent from my SAMSUNG-SGH-I747
Hello everyone.
I have been able to modify the framework-res.apk file to enable bluetooth tethering for UAMDL from T-Mobile
While I was making the changes in there I also removed from it the call to tethering provisioning and changed the csc files needed too.
So this is for stock UAMDL T-Mobile rooted roms.
I have included the files below to install it if you want.
It does go without saying to backup everything first.
Download from Google Drive
Use the following ADB commands to successfully copy over to the framework folder. Does need to be done via ADB.
Copy new framework-res-mod.apk to root of internal sd card.
adb shell stop (this will cause the screen on your phone to go black that is fine)
adb shell mount -o remount,rw /system
adb shell cp /sdcard/framework-res-mod.apk /system/framework/framework-res.apk
adb shell chmod 644 /system/framework/framework-res.apk
adb shell start (screen will come back on and look like phone is booting again)
after that you can use your favorite root file brower to copy and replace the files customer.xml and feature.xml in the system/csc folder.
If after this you are having problems with getting google play to install apps you might need to master reset.
I want to thank elesbb for help with getting this thing to be able to be compiled and also with the adb instructions to get it copied to the phone without needing a custom recovery but just root.
Awesome man. One question though, so wireless tethering works or only bluetooth tethering?
Yes.
Wireless hotspot, bluetooth (my main goal) and wired tether are working.
Ooops I goofed in the customer.xml file with the APN used for tethering.
I used apn epc.tmobile.com when it should be epc.t-mobile.com
For the time being you can adjust that I will upload a fixed copy tomorrow when I can be at my computer again.
Actually was able to edit and reupload from phone.
It is fixed now.
Apk File not shared for download.
Sorry about that.
Should be fixed.
Give it a try again.
this is what I get
c:\windows-sdk\platform-tools>adb shell stop <<<< phone screen doesnt go black
c:\windows-sdk\platform-tools>adb shell mount -o remount,rw /system
mount: Operation not permitted
c:\windows-sdk\platform-tools>adb shell cp /sdcard/framework-res-mod.apk /system
/framework/framework-res.apk
cp: /system/framework/framework-res.apk: Read-only file system
c:\windows-sdk\platform-tools>adb shell chmod 644 /system/framework/framework-re
s.apk
Unable to chmod /system/framework/framework-res.apk: Read-only file system
am i missing something here?
Sounds like the kernel is not running in insecure mode.
Try installing and enabling insecure adbd with this app and try again
http://forum.xda-developers.com/showthread.php?t=1687590
TheArtiszan said:
Sounds like the kernel is not running in insecure mode.
Try installing and enabling insecure adbd with this app and try again
http://forum.xda-developers.com/showthread.php?t=1687590
Click to expand...
Click to collapse
Thanks man we'll give it a shot after I get off work tonight and let you know how it happens
Sent from my SGH-M919 using xda premium
So far I thought I had bluetooth working on this since it shows as a option in the tethering program but when go to pair with something it does not see or be able to use that profile for internet even though it is enabled on the phone.
Wasn't able to test at the time since I had to send in my tablet but have came to find out that this was not working.
I will continue to try and see what I missed or what I can find.
If anyone has a idea that would be helpful thank you.
Is it possible to implement mod on this Framework mate
http://www.mediafire.com/download/z98oy0q9axmcavv/framework-res.apk
Note: Found out there is one small problem with this mode - "adb logcat" is not working. As a workaround run "adb shell su -c logcat"
The Problem:
I am a heavy ADB user (QtADB) and was having problems getting it to mount /system rw and pushing/editing files in real time. Had no problems doing all this by mounting /system in recovery but rebooting the phone just to make some system files changes is kind of inconvenient. So I did some research and found this:
HEXcube said:
The real reason behind adb root or insecure adb is the adb daemon in the device running at root permissions. In pre-Android 4.1 versions, this is usually decided by some initialisation script(like init.rc) at boot time. The script checks for value in default.prop,local.propand other environment variables.
If it finds build.prop,default.prop or local.prop property file with ro.secure=0 adbd is allowed to run as root. You'll get adb root and hence will be able to do commands like adb remount,adb root and adb shell's prompt'll be # by default. The user may be displayed as [email protected] or [email protected] adb GUIs like Android Commander and QtADB will get to work in Root mode.
But,if it's ro.secure=1, adb daemon is made to work in secure mode, and adb won't change to root mode on issuing adb root command. However, if su binary is present in $PATH, u can still call su command from adb shell. But, it's not enough for Android Commander to get Root Access. It is possible to attain adb root through any one of the following methods:
1.For CyanoGenMod based ROMs there is an option in Settings->Developer Settings->Root access to control root access. Choose ADB only or Apps and ADB in options to get adb root.
2.Else use adbd Insecure app by chainfire if you have a rooted device. This is useful, especially for Android 4.1+ devices.
3.Or, you may manually edit default.prop to set it's value to 0, but original default.prop will be restored from boot partition everytime you reboot(this is the reason why adb Insecure cannot permanently do adb root, though there is an option to repeat the rooting procedure everytime the device boots). This method is called temporary adb root. On pre-Android 4.0 ROMs default.prop file was located in / directory. I read that from Android 4.x this file is in ramdisk and so more difficult to edit. But Android 4.0 has local.prop which is easier to modify than default.prop( See method 5)
4.For permanent adb root, you'll have to extract boot.img, change default.prop, repack and then flash it back to device.
5. In Android 4.0 there's local.prop file in /data partition. Setting ro.secure=0 in this file will do adb root permanently. Else you can set another property ro.kernel.qemu=1 in the same file. But, this value makes the system think that it is running in an android emulator. Many exploits and root methods set this property temporarily to gain root. But, it may cause side effects if used permanently. Setting ro.secure=0 is recommended. Do this command in terminal app or adb shell:
echo ro.secure=0 >/data/local.prop
or you can manually copy a local.prop file with ro.secure=0 as it's content to /data.
6.Note that method 3,4 and 5 won't work in Android 4.0 Jelly Bean onwards. According to Dan Rosenburg(drjbliss in XDA),the researcher who discovered adb root emulator exploit and many other exploits, Jelly Bean doesn't parse any property files to set the ownership of adb daemon. The stock adbd will have to be replaced with an insecure one to gain adb root. But still,as adbd is located in /sbin whose contents are reloaded everytime on reboot from boot.img, it won't be permanent.
7. For permanent adb root, you may flash an insecure boot.img(one that contains and insecure adbd)
8. If you're really desperate and can't get adb root to work with any of the above methods use an exploit. Most of the adb based rooting methods utilise some exploit to make the adb daemon run as root. By studying the exploit and implementing it you could gain adb root atleast temporarily.I'm not recommending this method but as a last resort you could try them.
Acknowledgements: Thanks to Dan Rosenberg for explaining the reasons behind adb root, especially the one in Jelly Bean.
Click to expand...
Click to collapse
Original thread: Can't get ADB Root Access in certain ROMs?
So I desided to modify my favorite kernel img and give it a try. I used Imoseyon's leanKernel but it should work with any kernel.
How To:
1. Get Android Image Kitchen and extract it to your PC;
2. Open your_favorite_kernel.zip with 7zip and extract boot.img file to Android Image Kitchen folder;
3. Drag and Drop boot.img over unpackimg.bat. Kernel is unpacked and you will see 2 new folders - ramdisk and split_img;
4. Go to ramdisk folder and open default.prop file with text editor. This probably is not necessary but just in case change ro.secure and ro.adb.secure to 0 (zero):
Code:
ro.secure=0
ro.adb.secure=0
5. Get Chainfire's adbd Insecure v1.30, open it with 7zip, in assets folder you will see 3 .png files. Extract adbd.17.png to ramdisk\sbin folder;
6. Delete original kernel adbd file and rename adbd.17.png to adbd;
7. Go back to Android Image Kitchen folder and run repackimg.bat by just click on it. This will repack the modified kernel to image-new.img file ready for flashing;
8. Rename image-new.img to boot.img and replace the original one in your_favorite_kernel.zip by Drag and Drop in 7zip window;
9. Close 7zip, copy modified your_favorite_kernel.zip to /sdcard and flash it in recovery.
10. Enjoy ADB full root access for /system;
Warnings:
I can't guarantee 100% success with this mod. I did this only with leanKernel and it works great, Haven't tried any other kernels so I am note sure how all this will end up. IT CAN SOFT BRICK YOUR PHONE!!! Keep a copy of the original kernel on your /sdcard!!!
Doing this while trying to find the correct tools for proper repack of the modified kernel sometime I was ending up with the phone not booting to Android, goes straight to download mode. Don't panic... Just remove battery, place it back, hold Volume Up + Home + Power buttons booting to recovery. Flash the original kernel and you are back all good.
The usual stuff:
I AM NOT RESPONSIBLE FOR ANYTHING ... bla-bla-bla...
All the credits goes for the developers created the great tools used for this mod.
If you think it's useful fill free to say THEM and me thanks.
@nijel8
Thanks for sharing this. I will test this out on my device. If successful I would like to share this over in the One SV forums.
I never even considered this idea smh lol.
Edit: confirmed working
Thanks so much for sharing this. I too use adb a lot and need an insecure kernel.
Success. Nexus 5 and I changed Franco kernel to insecure.
Franco kernels used to be insecure but none thus far have been on the N5. Any reason behind this?
Fuzzy13 said:
Thanks so much for sharing this. I too use adb a lot and need an insecure kernel.
Success. Nexus 5 and I changed Franco kernel to insecure.
Franco kernels used to be insecure but none thus far have been on the N5. Any reason behind this?
Click to expand...
Click to collapse
My guess is devs play it safe so average Joe don't mess with /system... ha-ha
btw is "adb logcat" working for you?
Only problem with the adbd from chainfires ADB Insecure is that it breaks adb wireless,any solution ?
nijel8 said:
Note: Found out there is one small problem with this mode - "adb logcat" is not working. As a workaround run "adb shell su -c logcat"
The Problem:
I am a heavy ADB user (QtADB) and was having problems getting it to mount /system rw and pushing/editing files in real time. Had no problems doing all this by mounting /system in recovery but rebooting the phone just to make some system files changes is kind of inconvenient. So I did some research and found this:
Original thread: Can't get ADB Root Access in certain ROMs?
So I desided to modify my favorite kernel img and give it a try. I used Imoseyon's leanKernel but it should work with any kernel.
How To:
1. Get Android Image Kitchen and extract it to your PC;
2. Open your_favorite_kernel.zip with 7zip and extract boot.img file to Android Image Kitchen folder;
3. Drag and Drop boot.img over unpackimg.bat. Kernel is unpacked and you will see 2 new folders - ramdisk and split_img;
4. Go to ramdisk folder and open default.prop file with text editor. This probably is not necessary but just in case change ro.secure and ro.adb.secure to 0 (zero):
Code:
ro.secure=0
ro.adb.secure=0
5. Get Chainfire's adbd Insecure v1.30, open it with 7zip, in assets folder you will see 3 .png files. Extract adbd.17.png to ramdisk\sbin folder;
6. Delete original kernel adbd file and rename adbd.17.png to adbd;
7. Go back to Android Image Kitchen folder and run repackimg.bat by just click on it. This will repack the modified kernel to image-new.img file ready for flashing;
8. Rename image-new.img to boot.img and replace the original one in your_favorite_kernel.zip by Drag and Drop in 7zip window;
9. Close 7zip, copy modified your_favorite_kernel.zip to /sdcard and flash it in recovery.
10. Enjoy ADB full root access for /system;
Warnings:
I can't guarantee 100% success with this mod. I did this only with leanKernel and it works great, Haven't tried any other kernels so I am note sure how all this will end up. IT CAN SOFT BRICK YOUR PHONE!!! Keep a copy of the original kernel on your /sdcard!!!
Doing this while trying to find the correct tools for proper repack of the modified kernel sometime I was ending up with the phone not booting to Android, goes straight to download mode. Don't panic... Just remove battery, place it back, hold Volume Up + Home + Power buttons booting to recovery. Flash the original kernel and you are back all good.
The usual stuff:
I AM NOT RESPONSIBLE FOR ANYTHING ... bla-bla-bla...
All the credits goes for the developers created the great tools used for this mod.
If you think it's useful fill free to say THEM and me thanks.
Click to expand...
Click to collapse
Some time ago I 've tried to do this for a Nexus6, running Marshmallow.
Android has tighten up security, so I got bootloops.
Anyone has managed to do this?
Thank you!
nijel8 said:
Note: Found out there is one small problem with this mode - "adb logcat" is not working. As a workaround run "adb shell su -c logcat"
The Problem:
I am a heavy ADB user (QtADB) and was having problems getting it to mount /system rw and pushing/editing files in real time. Had no problems doing all this by mounting /system in recovery but rebooting the phone just to make some system files changes is kind of inconvenient. So I did some research and found this:
Original thread: Can't get ADB Root Access in certain ROMs?
So I desided to modify my favorite kernel img and give it a try. I used Imoseyon's leanKernel but it should work with any kernel.
How To:
1. Get Android Image Kitchen and extract it to your PC;
2. Open your_favorite_kernel.zip with 7zip and extract boot.img file to Android Image Kitchen folder;
3. Drag and Drop boot.img over unpackimg.bat. Kernel is unpacked and you will see 2 new folders - ramdisk and split_img;
4. Go to ramdisk folder and open default.prop file with text editor. This probably is not necessary but just in case change ro.secure and ro.adb.secure to 0 (zero):
Code:
ro.secure=0
ro.adb.secure=0
5. Get Chainfire's adbd Insecure v1.30, open it with 7zip, in assets folder you will see 3 .png files. Extract adbd.17.png to ramdisk\sbin folder;
6. Delete original kernel adbd file and rename adbd.17.png to adbd;
7. Go back to Android Image Kitchen folder and run repackimg.bat by just click on it. This will repack the modified kernel to image-new.img file ready for flashing;
8. Rename image-new.img to boot.img and replace the original one in your_favorite_kernel.zip by Drag and Drop in 7zip window;
9. Close 7zip, copy modified your_favorite_kernel.zip to /sdcard and flash it in recovery.
10. Enjoy ADB full root access for /system;
Warnings:
I can't guarantee 100% success with this mod. I did this only with leanKernel and it works great, Haven't tried any other kernels so I am note sure how all this will end up. IT CAN SOFT BRICK YOUR PHONE!!! Keep a copy of the original kernel on your /sdcard!!!
Doing this while trying to find the correct tools for proper repack of the modified kernel sometime I was ending up with the phone not booting to Android, goes straight to download mode. Don't panic... Just remove battery, place it back, hold Volume Up + Home + Power buttons booting to recovery. Flash the original kernel and you are back all good.
The usual stuff:
I AM NOT RESPONSIBLE FOR ANYTHING ... bla-bla-bla...
All the credits goes for the developers created the great tools used for this mod.
If you think it's useful fill free to say THEM and me thanks.
Click to expand...
Click to collapse
Can this work with Note 3 N900 (exynos kernel) sir? Or just only for snapdragon chipsrt kernel? Thanks sir!
does this work on locked bootloader devices?
a custom kernel exists for my devices (G928A) with AdB Insecure , but its got a few qwirks that need worked out ( that require fully rooting the device )
all im looking for is insecure Adb, ( which I have tried to change ro.secure=0 and adb.secure=0 both with Echo commands in shell) for temporary adb root on the device
how did ManIT make his custom kernel undetectable/passable by the bootloader but with modifications?
if this will work ... then I will just edit an image pulled from the devices current boot.img and do the same adb insecure edit to the ramdisk.. to update the root flash kernel... shes a bit dated.... and there isn't one for marshmallow specific one yet.
I was also reading about a filler file due to block sizing when repacking the image ... so I created a copy file and edited the contents till it zipped back to within 1kb of data... will this be detected and flagged at boot?
help please
Great tutorial.
I did it by following the steps in your post.
Thank you for clear and precise explanation.
Anybody have a pre-patched / adb root enabled adbd at hand (10.0.36 or higher - current is 10.0.41 I think)?