Related
I rooted my hero last night and tried out a few different ROMs but eventually decided to revert to stock and make some manual changes. I used nandroid to restore to just after the root (1.56.651.2). I was able to remove some apps using adb, but the adb remount command fails (permission denied), and I'm unable to push a new bootscreen on to the phone. I also tried a Root File Manager and pre-kitchen as alternatives for the bootscreen, and neither one works. The Root Manager won't paste the files from SD into /system/media/ and pre-kitchen just reboots the phone.
Any suggestions?
Any chance this has something to do with downloading only up to SDK Platform 1.5? I'm at a total loss. I RUU'd my phone, did a clean root at startup using adb shell, and I still have the same problem. The adb remount command won't work, and I can't push anything into the system directory. For what it's worth, when I still had Root Manager installed I was able to toggle RO R/W in any directory with no problem, and I could move files around within the ROM... but I couldn't move anything into it from the SD. I'm new at this, so I have no idea what the problem might be. Anyone else had this problem or have any suggestions?
If anyone else runs into this problem, this solution worked for me:
adb shell
# su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system (Or any subdirectory you want to push to inside system)
# exit
adb push <local file> <device location>
Restore modified permissions when done.
Though I'm still not sure why this is necessary in place of adb remount.
I'm pretty sure the adb remount command will not work on the stock rom. You should be able to do it with just this command instead:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
dametzg said:
I'm pretty sure the adb remount command will not work on the stock rom. You should be able to do it with just this command instead:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Click to expand...
Click to collapse
Thanks... didn't realize stock wouldn't accept adb remount. If I use the above line from within shell, that doesn't help me push anything on to the phone though... so I needed to enable global permission and then do the push. Oddly enough I tried the same approach last night using Root Manager, and the transfer from SD still failed, even after I applied 777 to the dir I was trying to modify. The current solution may be kind of tedious, but at least it works.
you really shouldn't do 777 on your filesystem, ANY app can then write to your system, overwrite things, or install malicious code. Just remount manually and you should be able to push anything you want, just remember that w/ the stock rom you also don't get a full busybox either.
I'm not positive, but I would think after you remount, you should be able to "adb push" to /system. I suppose it might be specific to that shell, but I would think not.
You just may have to do it once each time you boot your phone.
Edit - err nevermind... you're having permission errors.... um... change adbd on the phone to run as root? not sure how off the top of my head...
How To Deodex Your Device Tutorial
What is odexing?
What is deodexing?
Why you may consider deodexing over odexing.
Disclaimer: This tutorial is meant as a guide for education purposes only. If you decide to take the initiative to perform a deodexing operation on your device a family member’s device or a friend’s device – you (the surgeon) assume all responsibility for you own actions. In other words… Your problems are your own… Read before dissecting!
What is Odexing? – Within the Android Operating System applications come in the form of .APK packages compiled with .odex files that work with the primary application. Odex files are compiled with portions of the main application manifests and hold partial instructions for how this application will boot, how it will run and how it will act within the entire file structure. These odex files hold instruction for an application to pre-boot, pre-launch and how the service (if any) will function. Some assumptions are that the speed of the file system and application will be increased by way of pre launching the application prior to usage. My thoughts on this are that battery usage and memory are also being consumed while you may not even draw on that particular application. Simply put, the Odex file holds a set of functioning instructions for the application it belongs with. Think of it as sort of a pre-buffer and caching at the same time.
What is Deodexing? – Deodexing is the process of removing the child instruction file from the parent file and importing all the information that has been removed from the odex file into the APK. Full freedom to perform on its own without the aid of little odex.
Why may you consider deodexing a file system over having an odexed file structure? – Application modifying can be near impossible with many instructions for a single application existing in various places of the file structure. Consolidating all the functions of an APK in a single location will help to simplify the process.
Are you ready to become deodexed…?
So, get your scalpel ready and let’s begin…
This process will be described working within a Windows environment.
You will need to have a few things in order before we begin:
1) A Rooted phone – (A Must)
2) A working Windows workstation or desktop
3) xUltimate Utility v2.2.1 (see the link from my prior post to download the tool)
http://forum.xda-developers.com/showpost.php?p=12024563&postcount=126
4) Developers SDK toolkit – or – the ability to run adb commands
5) A little time to burn
Let’s get started:
1) Assuming that you have already downloaded xUtility v2.2.1 – unzip the package to a directory you can easily access.
2) Make sure to put your device in debugging mode and plug the USB cable from the PC into your device.
3) You can run the Test.exe to verify that the xUtility sees your device, but it’s not necessary and may cause a doubling effect with adb so that your device won’t be seen – so just execute the Main.exe and wait for the device to communicate with the application.
4) Once your device has been read by the xUtility, answer the questions in the prompts according to your make and model. (You do not need to upgrade to a newer version of xUtility because this is the newer version – regardless of what the application states)
5) Execute Action 1 then follow the instruction at the prompts
6) Execute Action 2 then follow the instruction at the prompts
*Note: For any reason the process fails to begin or hangs during the process – verify that there is only one instance of adb running on your PC or this could result in issues.
*Note: If issues occur, you can always perform an adb pull to the origi_app directory (within xUtility) and then the origin_frame directory (within xUtility)
*Note: This could take some time depending on the size of the directories
7) When the migration is complete - perform Action 3 in xUtility - This will perform the deodexing of the application APKs.
8) When the Application Deodexing is complete - perform Action 4 in xUtility - This will perform the deodexing of the framework APKs. (Mainly Java Files)
9) For safety purposes – backup the files in both the origin_app and the origin_frame directories and put them in a safe place just in case.
10) Close the prompt for xUtility – the process should be complete.
11) Exit debugging mode with your device and enter into mass storage mode. You will need to remove the USB cable before performing this, then plug the USB cable back in once the mode shift has occurred.
11) You should now see your device in Windows as a mass storage drive.
12) Go into the xUtility directory and copy the 2 folders named – “done_app” and “done_frame” to the root of your internal SDCard.
13) Get your command prompt open and get ready to type some code
Just my preference - Prior to migration of the deodexed files I chose to wipe the dalvik-cache from my device to ensure no rouge variant cached instructions would be present after the next boot. – You could CWM into the next soft boot and perform a dalvik wipe if you choose.
At The Command Prompt: Code Below:
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# cp /sdcard/done_app/* /system/app/
# cp /sdcard/done_frame/* /system/framework/
# rm /system/app/*.odex
# rm /system/framework/*.odex
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
After your device reboots it will take longer than usual to load the new file settings – so be patient and don’t panic.
You now have a deodexed device!
If you found this tutorial useful and helpful or you just enjoy reading my posts Show your gratitude by hitting that thanks button on this post.
All the best
Peace-
Liv33viL
Might want to point out that this is completely useless for anyone on a custom ROM.
MikeyMike01 said:
Might want to point out that this is completely useless for anyone on a custom ROM.
Click to expand...
Click to collapse
Might want to say why?
MikeyMike01 said:
Might want to point out that this is completely useless for anyone on a custom ROM.
Click to expand...
Click to collapse
If they knew enough to flash a custom ROM then they should know if the ROM that they flashed was deodexed or not if posted by the developer.
Then they wouldn't be on this thread reading this post unless they wanted a bit of an education on the topic.
Hence making your remark quite pointless!
Liv33viL said:
If they knew enough to flash a custom ROM then they should know if the ROM that they flashed was deodexed or not if posted by the developer.
Click to expand...
Click to collapse
O ye of far too much faith.
opcow said:
O ye of far too much faith.
Click to expand...
Click to collapse
agreed. so many people dont even bother to read the OP on a rom thread and ask if feature X exists, when its clearly labeled as such in the OP
not something I'd be willing to do regardless if my phone has a deodexed rom or not. seems a lot could go wrong if you made a slight mistake especially with running commands on your phone.
but at least I now know what deodexing is now
bunnsguy said:
not something I'd be willing to do regardless if my phone has a deodexed rom or not. seems a lot could go wrong if you made a slight mistake especially with running commands on your phone.
but at least I now know what deodexing is now
Click to expand...
Click to collapse
Yep, didn't know what it was.
You Take Your Shots When the Opportunity Presents Itself
opcow said:
O ye of far too much faith.
Click to expand...
Click to collapse
Yeah, I guess I was reaching on that statement... anticipating the best - but real world scenarios prevail!
What can I say... I prefer to be an eternal optimist.
But the statement was written to read "they should know" like as in if you lick the inside of a freezer door... "you should know" that it is highly likely that one would remain there until the thaw...minus a few layers of skin of course
Basically I got the idea to write this tutorial when reading a few threads whereas many users wanted to make some cosmetic mods to their devices, but really didn't want to jump out of their factory installed file systems. I noticed a few theme developers creating a skin pack for certain features, such as lock screens, docks, etc... and it required a deodexed file system. Many people didn't understand or even know what deodexed meant, let alone some never even heard of the word.
I posted in one of the threads that If I were feeling ambitious that I would create an educational tutorial and guidelines to perform the operation if one was interested... after getting injected with some knowledge.
You Take Your Shots When the Opportunity Presents Itself
Education = Key
Key = Knowledge
Knowledge = Insight
Insight leads to Applied Knowledge
Applied Knowledge = Power
Peace-
Very interesting, I learned a thing or two but of course the guys who really should be reading this are the ones that wont :/
Sent from my SGH-I897 using XDA App
Glad to have another resource just in case I ever decide to start developing my own custom ROM.
Herp derp Captivate XDA app.
Fantastic! - Glad to see an interest in some of the nuances of this file structure.
Peace-
A Common Philosophy
Liv33viL said:
Yeah, I guess I was reaching on that statement... anticipating the best - but real world scenarios prevail!
What can I say... I prefer to be an eternal optimist.
But the statement was written to read "they should know" like as in if you lick the inside of a freezer door... "you should know" that it is highly likely that one would remain there until the thaw...minus a few layers of skin of course
Basically I got the idea to write this tutorial when reading a few threads whereas many users wanted to make some cosmetic mods to their devices, but really didn't want to jump out of their factory installed file systems. I noticed a few theme developers creating a skin pack for certain features, such as lock screens, docks, etc... and it required a deodexed file system. Many people didn't understand or even know what deodexed meant, let alone some never even heard of the word.
I posted in one of the threads that If I were feeling ambitious that I would create an educational tutorial and guidelines to perform the operation if one was interested... after getting injected with some knowledge.
You Take Your Shots When the Opportunity Presents Itself
Education = Key
Key = Knowledge
Knowledge = Insight
Insight leads to Applied Knowledge
Applied Knowledge = Power
Peace-
Click to expand...
Click to collapse
I Agree with you on this.....WELL SAID! And Thank You for the time invested on a great tutorial/ lesson. I too learned a thing or two.
I would like to add four lines of code to the set of commands you type in adb shell
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# cp /sdcard/done_app/* /system/app/
# cp /sdcard/done_frame/* /system/framework/
# rm /system/app/*.odex
# rm /system/framework/*.odex
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
The reason for these additional commands is that when any files get moved to /sdcard, and directories under it, the ownership of the files becomes system.sdcard_rw and the permissions for the files become rwxrwxr-x. When these files are copied back to their original subdirectories under /system, they retain the new ownership and permissions. The original proper ownership and permission for the files before any changes were made was root.root and rw-r--r--. The four commands I added restores them to that original state, and therefore does not create any unintentional security risk. If anyone has already done the procedure. They can fix the files by doing just this in an adb shell.
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*[/COLOR]
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
ytt3r said:
Very interesting, I learned a thing or two but of course the guys who really should be reading this are the ones that wont :/
Sent from my SGH-I897 using XDA App
Click to expand...
Click to collapse
This statement kind of worries me coming from a developer. Haha.
Wisdom
AA “Information is not knowledge.”
whiteguypl said:
This statement kind of worries me coming from a developer. Haha.
Click to expand...
Click to collapse
I thought the same thing when I saw it.
[OP] Edit: See Edit Tag in OP For Details
rajendra82 said:
I would like to add four lines of code to the set of commands you type in adb shell
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# cp /sdcard/done_app/* /system/app/
# cp /sdcard/done_frame/* /system/framework/
# rm /system/app/*.odex
# rm /system/framework/*.odex
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
The reason for these additional commands is that when any files get moved to /sdcard, and directories under it, the ownership of the files becomes system.sdcard_rw and the permissions for the files become rwxrwxr-x. When these files are copied back to their original subdirectories under /system, they retain the new ownership and permissions. The original proper ownership and permission for the files before any changes were made was root.root and rw-r--r--. The four commands I added restores them to that original state, and therefore does not create any unintentional security risk. If anyone has already done the procedure. They can fix the files by doing just this in an adb shell.
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*[/COLOR]
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
Click to expand...
Click to collapse
Raj, thank you for providing the additional lines of code. Yes, you are absolutely correct. It was very late.... uhm very early in the AM when I was was proofreading and it didn't pop out at me then. Now, it pops.
The OP now reflects the additions and credit was given to you for the additions in the edit.
Thank you again my friend.
Peace-
This is the tutorial that I'm looking for. I already ask many times how to deodex my captivate but nobody answer it until I find this thread. Two thumbs up.
ps: could you add a video tutorial? I think a video is more informative for me because I don't have any experience with adb so that I little bit confuse if there is a command line using adb.
max_82 said:
This is the tutorial that I'm looking for. I already ask many times how to deodex my captivate but nobody answer it until I find this thread. Two thumbs up.
Click to expand...
Click to collapse
Fantastic Max!
Glad you finally found what you were looking for!
Peace-
Well this was a bit of a mess!
Firstly updating:
http://forum.xda-developers.com/showthread.php?t=1043349
http://phonedock.net/huawei-ideos-s7-froyo-2-2-2-update.html I followed this nice writeup. Be sure to delete the log file in dload for the second round of the upgrade as your device might, like mine, just blink on and off for a while trying to flash what it thinks it finds is already flashed but what just gives an error!
http://www.androidtablets.net/forum...uawei-ideos-s7-official-firmware-2-2-2-a.html Links to 2.2.2 Brazil which is the best for the 101 apparently, some tests done in that post on which rom work best for which model.
Now,
REMOVE YOUR SDCARD IF ANY! AND REBOOT THE DEVICE ! THIS HACK RELIES HEAVILY ON HIGH STRANGENESS AND SPOOKY ACTION AT A DISTANCE!
Originally i though modifying an ol doroot.sh script to using the psneuter exploit from SuperOneClick i would manage to root the device. Not without some fuzz, no. Firstly i discovered "cp" and many basic fileutils im used to in the world of *nix was missing from the 2.2.2 image kindly provided by Huawei ( The Norwegian Telenor image i might add that the camera on a model 101 will not work with!) so i found an easier way! push push push!
Here's what i did, for convenience ill try making it a script, but be prepared to copy these commands manually instead! For windows simply remove the ./ and add .exe .
Now, to make this work, simply get SuperOneClick from http://shortfuse.org/?page_id=2 and unzip, i used the adb from the google android sdk, but i guess the adb binary that comes with SOC is a simpler route if your just in for a quick root fix. Simply rename the appropriate adb for your system and use this method.
The simplest thing to do i guess is to copy Exploits/psneuter or gingerbreak to the ADB folder (in SuperOneClick's folder) and go on from there, also copy su-v3 (rename it to su) and Superuser.apk from "Root/" to the folder (ADB), or if you choose to, rewrite this "script" with the appropriate paths. Im unsure if the following script will work in every case, so you might want to do it manually, but most should get the drift, if you are not comfortable with this procedure you probably have no business or reason rooting the device in the first place. Disclaimer; if this bricks your device don't blame me, this is a fact of "it worked for me", your results may differ.
Be sure to set your USB mode to "Developer" mode
AND BE ROOT ON YOUR MACHINE!
Code:
#/bin/bash
echo "The BackAsswardsRootScript!\n\n"
echo "Lets start the adb server.\n\n"
./adb kill-server
./adb start-server
echo "Pushing the exploit psneuter onto the device.\n\n"
./adb push psneuter /data/local/tmp/psneuter
./adb shell "chmod 0755 /data/local/tmp/psneuter"
./adb push busybox /data/local/tmp/busybox
./adb shell "chmod 4755 /data/local/tmp/busybox"
echo "Now we run the root exploit.\n\n"
./adb shell "./data/local/tmp/psneuter"
echo "We should be root now, making sure.\n\n"
./adb root
echo "Remointing the FS as RW!\n\n"
./adb shell " /data/local/tmp/busybox mount -o rw,remount /system"
echo "Pushing the system files in place\n"
./adb shell "/data/local/tmp/busybox cp /data/local/tmp/busybox /system/bin/busybox"
./adb push su /system/bin/su
./adb push Superuser.apk /system/app/Superuser.apk
echo "Correct permissions might be nice.\n"
./adb shell "chmod 4755 /system/bin/busybox"
./adb shell "chmod 4755 /system/bin/su"
./adb shell "chmod 755 /system/app/Superuser.apk"
# Lets go back to read only, just for kicks!
echo "Remounting the filesystem as Read-Only\n\n"
./adb shell "busybox mount -o ro,remount -t /system"
echo "You should now be rooted my friend.\n Enjoy!\n"
Please help feed my Linux addiction! Go to http://threader.zapto.org and click Donate!
Rooting S7 using Gingerbreak
Just too inform you. I've just succesfully rooted the Indonesian 2.2.2 running on a
S7-105 using Chainfire's Gingerbreak v1.2.
Cool, theres a gingerbreak exploit in the superoneclick package also, i tried that after i though psneuter didnt work, just a matter of replacing psneuter with gingerbreak. Did you use this method though or did you find some other way?
I didn't change or replace anything. My terminal skills are not on a level to have the guts anyway.
I simply updated from S7V100R001C43B010 to S7v100R001C98B021.
Then ran the Gingerbreak 1.2 exploit.
Interesting, yeah the gingerbreak exploit will work, when i wrote the fist post i used the gingerbreak exploit instead of the psneuter one thinking psneuter didnt work, turns out it did though and i went back to that one as its designed for 2.2.2, didnt know of this wrapper though, thanks!
Just granted su superuser permissions on the Australian s7
Great work. Just noticed a missing final quotation mark:
threader said:
./adb shell "chmod 0755 /data/local/tmp/psneuter
Click to expand...
Click to collapse
Probably works because of the end of line but should be:
./adb shell "chmod 0755 /data/local/tmp/psneuter"
threader said:
Well this was a bit of a mess!
Firstly updating:
http://forum.xda-developers.com/showthread.php?t=1043349
http://phonedock.net/huawei-ideos-s7-froyo-2-2-2-update.html I followed this nice writeup. Be sure to delete the log file in dload for the second round of the upgrade as your device might like mine just blink on and off for a while trying to flash what it finds is already flashed but what just gives an error. !
http://www.androidtablets.net/forum...uawei-ideos-s7-official-firmware-2-2-2-a.html Links to 2.2.2 Brazil which is the best for the 101 apparently, some tests there on which roms work best for which models also.
Now,
REMOVE YOUR SDCARD IF ANY! AND REBOOT THE DEVICE ! THIS HACK RELIES HEAVILY ON HIGH STRANGENESS AND SPOOKY ACTION AT A DISTANCE!
Originally i though modifying an ol doroot.sh script to using the psneuter exploit from SuperOneClick i would manage to root the device. Not without some fuzz, no. Firstly i discovered "cp" and many basic fileutils was missing from the 2.2.2 image kindly provided by Huawei (Norwegian Telenor image, that i might add, the camera on a model 101 will not work with!) soo i found an easier way! push push push!
Heres what i did, for convenience ill try making it a script, but im making it as i type this post so this is untested as a script(!) Be prepared to copy these commands instead!
Now, to make this work, simply get SuperOneClick from http://shortfuse.org/?page_id=2 and unzip, i used the adb from the google android sdk, but i guess the adblinux binary that comes with SOC will work just as well, simply rename it to adb and use this method. The simplest thing to do i guess is copy Exploits/psneuter to the ADB folder (in SuperOneClick's folder) and go from there, also copy su-v3 (and rename it to su) and Superuser.apk from Root to the folder (ADB), or rewrite this "script"/collection of commands i used" with the appropriate paths. Im unsure if the following script will work as is as i said, so you might want to do it manually, but most should get the drift, if not you probably have no business or reason rooting the device in the first place. Disclaimer; if this bricks your device don't blame me, this is a fact of "it worked for me", your results may differ.
Be sure to set your usb mode to Developer mode
BE ROOT!
#/bin/bash
echo "The backasswardsrootscript!\n\n"
echo "Lets start the adb\n\n"
./adb kill-server
./adb start-server
./adb push psneuter /data/local/tmp/psneuter
./adb shell "chmod 0755 /data/local/tmp/psneuter
echo "Now we run the root exploit.\n\n"
./adb shell "./data/local/tmp/psneuter"
echo "Should say we are already root now.\n\n"
./adb root
echo "Remointing the FS as RW!\n\n"
# This really should be /dev/block/mmcblk0p1, i have no idea why this works.
./adb shell "mount -o rw,remount -t ext3 /dev/block/mmcblk1p1 /system"
# Now instead of copying using cp or moving with mv, considering "cp" was missing
# and mv just didnt work for some reason...! I found just pushing the files straight to the
# system after remounting worked just fine
echo "Pushing the system files in place\n"
./adb push su /system/bin/su
./adb push Superuser.apk /system/app/Superuser.apk
./adb push busybox /system/bin/busybox
echo "Correct permissions might be nice.\n"
./adb shell "chmod 4755 /system/bin/busybox
./adb shell "chmod 4755 /system/bin/su"
./adb shell "chmod 755 /system/app/Superuser.apk"
# Lets go back to read only just for kicks!
echo "Remounting the filesystem as Read-Only\n"
./adb shell "mount -o ro,remount -t ext3 /dev/block/mmcblk1p1 /system"
echo "You should be rooted my friend\n Enjoy!\n BE SURE TO DONATE TO SUPERONECLICK!!!"
# One of the main strangenesses i found was the block device was logically enough placed on
# partioton 1, of block1 which really should have been block 0 part 1, but that doesnt work.
# So it boils down to that this shouldnt work but does for no apparent reason(!).
# even /etc/mtab says that mmcblk0p1 is mounted to a non existent /mnt/dcard
# as an EXT4 partition which isnt supposed to be supported until 2.3.x
Click to expand...
Click to collapse
Dear S7 users,I am using the ideos s7 by Teltra supllier and i did unlock sim by norwegian rom.I read a lot of document but i didnt find out an easy way to run clockwork that i can run cook rom,can u help me how to run it in easy way.Thanks and appreciate that.
http://www.androidtablets.net/forum...wegian-2-2-2-s7v100r001c57b111.html#post82863
PuZZleDucK said:
Just granted su superuser permissions on the Australian s7
Great work. Just noticed a missing final quotation mark:
Probably works because of the end of line but should be:
./adb shell "chmod 0755 /data/local/tmp/psneuter"
Click to expand...
Click to collapse
Great! Thanks! Ops, yeah missed that, fixed now, thank you for pointing that out. I haven't spent much more time on this. the pad has pretty much been untouched since i moved house. I would like to make this easier for less technical inclined here but its just a matter of replacing ./adb with adb.exe if your on windows. Besides, i don't want to be at fault for bricking someone. And maybe i could write some simple application for installing Gnu/Linux as well, ( http://forum.xda-developers.com/showthread.php?t=1109730 ) but that will have to wait until someone bribes me or hits me over the head i guess.
tell me how you did it. i have a s7 - 105 too. please tell me the full tutorial, beginning to the end. cause i'm new to this android stuff. please..
---------- Post added at 08:53 PM ---------- Previous post was at 08:51 PM ----------
Maniacnl said:
Just too inform you. I've just succesfully rooted the Indonesian 2.2.2 running on a
S7-105 using Chainfire's Gingerbreak v1.2.
Click to expand...
Click to collapse
tell me how you did it. i have a s7 - 105 too. please tell me the full tutorial, beginning to the end. cause i'm new to this android stuff. please..
im curious if there is any way to push "su" to the the system?
i mean cmon there are pleanty of KITKAT 4.4.2 fastboot files.
i have tried pushing "su" maually with "pwn" exploit.
tried with following exploits
-psneuter
-pwn
but no luck there.
any one pleaseeeee...im dieing here..
our system details.
- LOCKED BOOTLOADER ( )
- KIT KAT 4.4.2
- Blur_Version.183.46.10.XT907.Verizon.en.US ( KDA20.62-10.1 )
what i tried is
Code:
adb devices
adb push pwn /data/local/tmp
adb shell
$ cd /data/local/tmp
$ chmod 777 pwn
$ ./pwn
( NO LUCK GETTING PERMISSION AFTER $ ./pwn )
At this point, the exploit will run and close the shell. You will need to run these commands to restart the ADB server.
adb kill-server
adb devices
Now comes the moment of truth. Use the
adb shell
command to open a shell. If you see a "#" sign, you have root access, so go ahead and continue to the next part.
If not, you can go back and try the previous steps again
We now need to make this root permanent. From the root shell you just opened, type the following commands.
# mount -o remount,rw -t rfs /dev/block/st19 /system
# exit
adb push busybox /system/bin
adb push su /system/bin
adb install Superuser.apk
adb shell
# chmod 4755 /system/bin/busybox
# chmod 4755 /system/bin/su
# mount -o remount,ro -t rfs /dev/block/st19 /system
# exit
adb reboot
gys lets make this happen any how.....lets roll...
even this wont work
http://www.kingoapp.com/
Every root method I've ever found for KK requires an unlocked bootloader, and I'm talking about looking outside the box at all different brands/models of phones too. I guess Google finally figured how to lock things up as well as Apple. I've read XDA user "jcase" had discovered a KK exploit that works on some Motorolas, but he's keeping it secret for some mysterious reason and will be presenting it at a Black Hat conference. Why anyone would rather help companies than consumers is beyond my comprehension, but it is what it is.
GnatGoSplat said:
Every root method I've ever found for KK requires an unlocked bootloader, and I'm talking about looking outside the box at all different brands/models of phones too. I guess Google finally figured how to lock things up as well as Apple. I've read XDA user "jcase" had discovered a KK exploit that works on some Motorolas, but he's keeping it secret for some mysterious reason and will be presenting it at a Black Hat conference. Why anyone would rather help companies than consumers is beyond my comprehension, but it is what it is.
Click to expand...
Click to collapse
Every exploit has two sides to it: it can be used more or less legitimately by users to obtain root privileges, but it can be also abused by rogue apps to gain control over someone else's device.
When you find an exploit, the sooner you publish it, the sooner it will be patched in a firmware update, making it unusable any more for gaining root privileges. And since you've published it, the bad guys can make their use of it as well.
Patching existing vulnerabilities by companies is natural and essentially made in favour of user's safety.
The specific timing of releasing details about some found vulnerability can be part of a tactic - you can give users a window for gaining root just after a specific expected firmware release for some device. If an exploit is published too soon, it will be patched in an upcoming firmware update and no one will be able to use it for rooting...
means that there is a possible way of course but the thing is will it could be found by or not......
of course for good reasons.......
It took some doing, but after following the instructions in this link:
http://forum.xda-developers.com/showthread.php?t=2559915
I was finally able to root my Nook Glowlight. The instructions are kind of sprawled out and extremely unclear so I will sum up.
As always, you will need the ADB. In order to install the ADB, you need the Java Development Kit and the Android Studio (formerly known as the Android SDK)
http://www.oracle.com/technetwork/java/javase/downloads/index.html
http://developer.android.com/sdk/installing/studio.html
How to obtain root via ADB: The ONLY way you can root is using Windows. I was successful on Windows 7 32 bit, but it may be possible on other versions.
step 1) install bootloader driver.
You need to grab the drivers from here (bnusbdrivers.zip):
http://forum.xda-developers.com/showpost.php?p=49665945&postcount=279&nocache=1&z=184593200683593
then, open the Device Manager (on Windows). Be ready to right click on the new device 'omap3660' that shows.
With the nook turned completely off, plug in a USB cable. you will have less than 3 seconds to right click the new omap3660 device that shows up in the system profiler.
If you were successful and you right clicked on it in time, manually install the Barnes & Noble USB driver (there are entries added to the generic Google drivers for both the TI Omap 3660 bootloader and the ADB device after you modify the uRamdisk later on)
***NOTE***
If you WEREN'T successful on your first try (took me THREE times to get to it in time), you aren't going to get another chance to install the drivers. At least not easily anyway, because after Windows tries to automatically install the drivers for the bootloader and fails, it will disregard the device any time it shows up after that. So, you are going to need to delete the registry entries that it created, which in my experience was easier said than done. Even admin access was not sufficient to make the necessary changes to the registry.
You will need to launch regedit.exe using another tool called psexec which is available here:
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
after you download the pstools package, copy those .exe files to C:\Windows\System32\ (in order to add them to $PATH in cmd.exe)
Then, once you've installed the pstools commands to C:\Windows\System32\, run cmd.exe as admin (right click it and select 'run as administrator') and then open regedit.exe with the following command
Code:
psexec -s -i -d regedit.exe
Then, once regedit is open you need to find the keys created by the Nook bootloader and delete them. The Nook bootloader's device ID is 0451:d00e
You are going to be looking in HKEY_LOCAL_MACHINE\Current Control Set\enum\usb\ for the keys with the bootloader's device IDs. There may also be keys generated in control set 001 and 002 as well. Delete all of those keys and then reboot your computer. Then with the nook power off completely, repeat the process from the first step. eventually you will be successful installing the bootloader driver.
Step 2) temporarily boot with uRamdisk-noogie
you need to download omaplink.exe from here:
http://www.temblast.com/android.htm
and you also need to download the four files which allow you to temporarily mount the boot partition; omap3_aboot.bin, u-boot-ng2-exp-v03.bin, uImage-ng2-130-stk and uRamdisk-noogie.
They are available here:
http://forum.xda-developers.com/showpost.php?p=49779966&postcount=285
download usbboot-ng2-images-noogie-v1.zip
The next part is easy.
Extract the .zip file and then fire up cmd.exe. cd into the directory of the newly extracted .zip
in the new working directory, enter the command
Code:
omaplink omap3_aboot.bin u-boot-ng2-exp-v03.bin uImage-ng2-130-stk uRamdisk-noogie
Then, with the Nook powered all the way off and omaplink running, plug it in and a few seconds later, after the device boots up all the way, you will be looking at the contents of the boot partition instead of the internal storage like normal.
Step 3) Edit uRamdisk
you will need to download bootutil.exe from here
http://www.temblast.com/android.htm
copy bootutil.exe to C:\Windows\System32
with the boot partition mounted, copy uRamdisk to your computer and extract the files init.rc and default.prop, eg;
Code:
bootutil /x /v uRamdisk init.rc default.prop
then using notepad++ (available here: http://notepad-plus-plus.org/) edit the files as follows
default.prop
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
and
init.rc
comment out lines 375 and 392-399
(do this by adding a # to the beginning of the line)
uncomment line 215
(do this by deleting the # at the beginning of the line)
save both files and then repack them into uRamdisk
Code:
bootutil /r /v uRamdisk init.rc default.prop
copy uRamdisk back onto the Nook, eject the disk and power off the device. Reboot and you should be able to connect to ADB via WiFi
eg;
Code:
adb connect 192.168.0.10
replacing '10' with whatever IP your Nook is grabbing from your router.
Step 4) Full Root
at this point, you have root access via ADB only. You will not have root access in any apps like Root Explorer, Terminal, TiBackup, etc.
In order to finish PROPERLY rooting your Nook, you need to install 'su' to /system/bin/ and install the superuser.apk
Code:
adb connect 192.168.0.10
adb shell mount -o remount, rw /system
adb push su /system/bin/
adb shell chmod 6755 /system/bin/su
adb install superuser.apk
reboot your device one more time and then you will be fully rooted.
*** Note ***
this devices firmware seems to be a strange hybrid between donut and eclair, although it purports itself to be Android 2.1. The Superuser.apk and su binary came from an old Cyanogenmod 4.6 build in case anyone was wondering (Android Donut). The ones from Cyanogenmod 5 (Android Eclair) do not work. you will get the 'install failed older sdk' error.
installing busybox
I tired installing busybox by using the stericson busybox pro.apk. It would always freeze at 6.47%.
I figured out that if I grabbed an older version of the busybox binary and pushed it to /system/xbin manually and then chmodded it to the proper permissions, auto updates and proper symlinking work using the busybox app
Code:
adb shell mount -o remount, rw /system
adb shell mkdir -p /system/xbin
adb push busybox /system/xbin
adb shell chmod 6755 /system/xbin/busybox
adb install busybox.apk
Then reboot, and run the busybox app to update and create symlinks.
enjoy!
installing nano and bash
Code:
adb connect 192.168.0.10
adb shell
mount -o remount, rw /system
adb push nano /system/xbin/
chmod 6755 /system/xbin/nano
adb push bash /system/xbin/
chmod 6755 /system/xbin/bash
bash
mv /system/bin/sh /system/bin/sh.bak
ln -s /system/xbin/bash /system/bin/sh
chmod 6755 /system/bin/sh
adb push profile /system/etc/
adb push terminfo /system/etc/
and then in terminal emulator under 'Preferences' change the initial command to
Code:
export TERMINFO=/system/etc/terminfo;export TERM=linux;export HOME=/sdcard;
and finally
Code:
adb push bashrc /sdcard
adb shell
mv /sdcard/bashrc /sdcard/.bashrc
exit
nano works just fine via ADB, but because of lack of 'ctrl' key (and physical buttons to assign it to) you won't be able to write files (ctrl+o) using the terminal on your nook. But between having full proper root access, busybox, a proper bash terminal emulator and nano for editing config files, this should REALLY extend the usefulness of your Nook Glowlight. It should work just fine on other versions of Nook too.
Hi N00b-un-2,
Many thanks for your summary!
There is one important edit that I think you missed,
in init.rc you also need to:
Line #375, comment out "disabled" with a # at the start of the line.
(see http://forum.xda-developers.com/showthread.php?p=49070213#post49070213)
without this I couldn't get adb to connect.
And since you already made it very noob friendly, might I suggested you clarify:
Line #215 remove # to enable adb over wifi
(rather than search for 5555)
Also, I'm not expert, but I believe the commands to get superuser on the device are (at least it worked for me):
adb connect 192.168.x.x
adb shell mount -o remount, rw /system
adb push su /system/bin/
adb shell chmod 6755 /system/bin/su
adb install superuser.apk
Finally, I'm not sure if this is important, but maybe remount system as read only again:
adb shell mount -o remount, ro /system
Thanks again, nice work!
---------- Post added at 01:48 PM ---------- Previous post was at 01:10 PM ----------
Hi again,
had similar issues with installing busybox, here's what worked for me (note needed to run su to create dir):
adb shell mount -o remount, rw /system
adb shell /system/bin/su
adb shell mkdir -p /system/xbin
adb push busybox /system/xbin
adb shell chmod 6755 /system/xbin/busybox
adb install busybox.apk
cheers.
As far as remounting /system as ro, I would HIGHLY recommend just rebooting at this point, otherwise your nook might be stuck in a weird pseudo-rooted state. Probably won't cause any problems, but why risk it?
Thanks for clarifying the line number. I will make the appropriate edits to my instructions. I was working off the top of my head and couldn't remember what exact line the ADB over TCP config was, as I just used ctrl+w '5555' to find it myself.
There are several pre-edited uRamdisk images floating around the forum with various features enabled which would be easier for noobs than extracting the config files and manually editing and then repacking them. In the future I'll probably throw those on here as well.
darz said:
Hi N00b-un-2,
Many thanks for your summary!
There is one important edit that I think you missed,
in init.rc you also need to:
Line #375, comment out "disabled" with a # at the start of the line.
(see http://forum.xda-developers.com/showthread.php?p=49070213#post49070213)
without this I couldn't get adb to connect.
And since you already made it very noob friendly, might I suggested you clarify:
Line #215 remove # to enable adb over wifi
(rather than search for 5555)
Also, I'm not expert, but I believe the commands to get superuser on the device are (at least it worked for me):
adb connect 192.168.x.x
adb shell mount -o remount, rw /system
adb push su /system/bin/
adb shell chmod 6755 /system/bin/su
adb install superuser.apk
Finally, I'm not sure if this is important, but maybe remount system as read only again:
adb shell mount -o remount, ro /system
Thanks again, nice work!
---------- Post added at 01:48 PM ---------- Previous post was at 01:10 PM ----------
Hi again,
had similar issues with installing busybox, here's what worked for me (note needed to run su to create dir):
adb shell mount -o remount, rw /system
adb shell /system/bin/su
adb shell mkdir -p /system/xbin
adb push busybox /system/xbin
adb shell chmod 6755 /system/xbin/busybox
adb install busybox.apk
cheers.
Click to expand...
Click to collapse
N00b-un-2 said:
There are several pre-edited uRamdisk images floating around the forum with various features enabled which would be easier for noobs than extracting the config files and manually editing and then repacking them. In the future I'll probably throw those on here as well.
Click to expand...
Click to collapse
Would have been good if I could have easily found a pre-edited image, but your instructions were a great alternative, thanks again
darz said:
Would have been good if I could have easily found a pre-edited image, but your instructions were a great alternative, thanks again
Click to expand...
Click to collapse
Sorry for the really noob question, I have rooted, wifi adb running and installed apps as per your instructions, but I can't seem to access any of it on the nook. How can I get access to the launcher I installed?
You mentioned pre-edited images, do any of those come with the apps I need to get access to a custom launcher?
Cheers,
Dariusz
==============
Updated: All sorted
==============
For some reason had some issues with ADW launcher, Launcher pro worked fine.
ps I think I made a mistake with the su step I suggested, if you run a one line shell command I don't think it keeps su privileges, so I believe you need to run commands within the shell as per below:
adb shell
mount -o remount, rw /system
/system/bin/su
mkdir -p /system/xbin
exit
adb push busybox /system/xbin
adb shell chmod 6755 /system/xbin/busybox
adb install busybox.apk
Noob
Hey guys any instructions noob friendly or a video in youtube,i stick up at dab connect 192.168.0.10.I dos't have a Windows PC and using Mac whit Parallels Desktop.Is it possible instructions for Mac?
The above instructions from N00b-un-2 should work fine running a vm with parallels on your Mac.
OB
Sent from my SPH-D710VMUB using Tapatalk 2
valentin1985 said:
Hey guys any instructions noob friendly or a video in youtube,i stick up at dab connect 192.168.0.10.I dos't have a Windows PC and using Mac whit Parallels Desktop.Is it possible instructions for Mac?
Click to expand...
Click to collapse
Before you perform the adb connect step you need to find out what your IP address is:
On your nook, click on the settings icon in the top right corner and then select "Change"
Under Wireless Networks, select the wifi name that you are already connected to (where it says "Connected to the internet")
This will display your connection details, remember that IP address
Now go back to your pc and type:
adb connect [IP address]
darz said:
Before you perform the adb connect step you need to find out what your IP address is:
On your nook, click on the settings icon in the top right corner and then select "Change"
Under Wireless Networks, select the wifi name that you are already connected to (where it says "Connected to the internet")
This will display your connection details, remember that IP address
Now go back to your pc and type:
adb connect [IP address]
Click to expand...
Click to collapse
BIG HINT! If you're using Powershell ISE, you have to type .\adb.exe connect [IP address] or else it won't recognize "adb" as an executable!
Don't ask why, because I don't know. :?
thenookieforlife3 said:
BIG HINT! If you're using Powershell ISE, you have to type .\adb.exe connect [IP address] or else it won't recognize "adb" as an executable!
Don't ask why, because I don't know. :?
Click to expand...
Click to collapse
So far so good,but now what?
valentin1985 said:
So far so good,but now what?
Click to expand...
Click to collapse
I just gave a little tip on Powershell ISE. I do not know much about the Nook GlowLight rooting process, as I have a NSTG, not a NG. Ask someone else.
thenookieforlife3 said:
I just gave a little tip on Powershell ISE. I do not know much about the Nook GlowLight rooting process, as I have a NSTG, not a NG. Ask someone else.
Click to expand...
Click to collapse
Yes,i try whit dis command .\adb.exe connect 192.168.0.9 but result is the same.
valentin1985 said:
Yes,i try whit dis command .\adb.exe connect 192.168.0.9 but result is the same.
Click to expand...
Click to collapse
But that's okay! What I said was, if you are using the command program Powershell ISE, do it that way instead. But you are just using cmd.exe, not Powershell ISE!
In cmd.exe, which is what you are using, it is not neccessary to type .\adb.exe. Just type adb.
From there, ask someone else in this thread.
thenookieforlife3 said:
But that's okay! What I said was, if you are using the command program Powershell ISE, do it that way instead. But you are just using cmd.exe, not Powershell ISE!
In cmd.exe, which is what you are using, it is not neccessary to type .\adb.exe. Just type adb.
From there, ask someone else in this thread.
Click to expand...
Click to collapse
I prefer to use ConEmu or Console2 when I am forced to use Windows. Not a big fan of CMD.EXE or Powershell/PowershellISE. there are plenty of other CLI alternatives out there
N00b-un-2 said:
I prefer to use ConEmu or Console2 when I am forced to use Windows. Not a big fan of CMD.EXE or Powershell/PowershellISE. there are plenty of other CLI alternatives out there
Click to expand...
Click to collapse
Well, as I ONLY use Windows and Powershell ISE has a nice-enough layout for my purposes, I use it. That's why I gave a tip on it.
Actually on a lot of installs just typing adb in the command console won't work either unless it's got the path variable set up correctly, I find it easiest to just right click and choose run as administrator, no need for the path to be setup.
OB
Sent from my SPH-D710VMUB using Tapatalk 2
FW 1.2.1
Hi guys,
thanks for creating this thread. I was wondering if this rooting procedure was tested with the firmware 1.2.1 ?
real-6 said:
Hi guys,
thanks for creating this thread. I was wondering if this rooting procedure was tested with the firmware 1.2.1 ?
Click to expand...
Click to collapse
This rooting procedure is for the new Nook GlowLight with firmware 1.3.1. Your device is a Nook Simple Touch with GlowLight, which can be rooted very easily using the rooting package here.