Related
I couldn't find a thread on this. If there is one and I just missed it, please direct me that way and I apologize for the duplicate.
I hacked the .config file (kernel), compiled it, tested it in fastboot's boot mode (from the bootloader) and then flashed it to the phone with the instructions on this site:
credentiality2.blogspot.com/2010/08/nexus-one-htc-passion-compile-and-flash.html
It works and is wonderful, but I would love to find a way to create a boot.img file with the kernel I've hacked. Do any of you have any insight or know where I can look for more info.?
Do any of you know how to create the boot.img-ramdisk.gz file? I know how to put that with my hacked boot.img-kernel file and create a boot.img file that way.
Any help is much appreciated.
Fixed!
I figured out the problem was I couldn't the boot.img file from my Android 2.2 phone because the read-write permissions did not allow me to do the adb pull command. Now, I've pulled that boot.img file and can unpack and repack it with my hacked kernel using the directions on the website I originally referenced.
I used this command to change the permissions so I could pull the boot.img file:
#mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Hi,
I have rooted my HTC Dream successfully. I have flashed in CyanogenMod ROM.
Now I have downloaded Android Kernel and rebuilt it. Now I have the zImage which is the kernel image. Now how do I use this new image? I guess must modify the boot.img to use this new kernel image.
Any idea how can I do this? I tried using "fastboot flash:raw boot <kernel directory> <ramdisk directory>"
For <ramdisk directory> I point to the one in the android-sdk. But after flashing it stuck in the "G1 T Mobile" screen and doesn't proceed. Not sure how to resolve.
Thanks In Advance,
Perumal
I downloaded the boot.img file, split it into boot.img-kernel and boot.img-ramdisk.gz. Then, renamed my newly-compiled kernel's "zImage" file as "boot.img-kernel" and zipped them back up into boot.img. Then, I flashed it to the phone with fastboot. All of the directions are on this website:
credentiality2.blogspot.com/2010/08/nexus-one-htc-passion-compile-and-flash.html
It was written for HTC Passion / Nexus One, so you may want to pull your existing boot.img file first in case it doesn't work on the HTC Dream and you need to go back to where you started. I found this tutorial helpful for that.
credentiality2.blogspot.com/2010/08/extract-bootimg-from-android-phone.html
You probably need to change your permissions to push and pull the boot.img file. I would do that on my computer (with it tethered to the phone), using the following commands in a terminal window:
$ adb shell
$ su
# mount -o remount,rw /dev
Discovering "adb shell" gave joy, experiencing the shell as minimal bash with awful line handling (backspace and command recall) gave annoyance, experiencing "adb root" refusing access gave frustration.
After some tracking, it turns out that adbd behaviour is determined by the property "ro.debuggable" which is set during system init. The initial value is located in the file "/default.prop". In JP6 it is set to 0 resulting is adbd refusing access. However, set to 1, "adbd root" will give the much better response of "restarting adbd as root".
Once set, the property value cannot be changed. To get this fixed you need to change the contents of the file default.prop which is located in the initial ramdisk image.
Optionally, you can put a replacement shell in /sbin of in ramdisk image so that when connected "exec bash" will make things more relaxing. I attached the version I am using, which is statically linked with ncurses/readline.
There is also a simple patch to unlock adbd if you dislike opening and rebuilding the ramdisk image. However, you do need binoffset which is located in the scripts directory of the linux source tree.
Code:
ofs=`scripts/binoffset initramfs.cpio \`echo -n 'debuggable=0' | od -t u1 -An\` 2>/dev/null`
echo 'debuggable=1' | dd bs=1 seek=$ofs conv=notrunc of=initramfs.cpio
Thanks...any help though?
Hi....thanks for the fix....could you point me to a decent howto on editting the initial ramdisk?
Thanks
M
it doesn't sound simple
i will try to figure that one out ...
Dear Hexabit,
I know it's an old topic.
But do you know how can I use this Fix on a windows 7?
tried searching for binoffset software/script..couldn't find anything
I have a Flytouch 3 tablet, rooted(Z4) with terminal emulator and root explorer.
is there a way to use you bash.rar to unlock adb access?
thanks for the help
doekoe87 said:
Dear Hexabit,
I know it's an old topic.
But do you know how can I use this Fix on a windows 7?
tried searching for binoffset software/script..couldn't find anything
I have a Flytouch 3 tablet, rooted(Z4) with terminal emulator and root explorer.
is there a way to use you bash.rar to unlock adb access?
thanks for the help
Click to expand...
Click to collapse
you have to split the kernel, then decompile the ramdisk and edit default.prop and change ro.debuggable to 1, then recompile and flash
confuse but giving me a clue
I use unpackbootimg in my ubuntu pc.
The adb root works not properly after set debuggable=1.
When I saw your thread that told the adbd should be unlocked too, then I replace the adbd with a unlocked one. It works!
Thanks for your help.
I am sorry but I don't understand how to use the file.
teoking said:
I use unpackbootimg in my ubuntu pc.
The adb root works not properly after set debuggable=1.
When I saw your thread that told the adbd should be unlocked too, then I replace the adbd with a unlocked one. It works!
Thanks for your help.
Click to expand...
Click to collapse
Hi,
I can upload nothing to my root catalog of my phone.
So how could I use the adbd file in this case?
Phone is rooted but I have a problem with adb root command like subject of this topic is.
Can u help me with the process because I kept the file in /sbin but still it's not working.
Active system
Sent from my SM-G900T3 using Tapatalk
'adb shell' gives me directly a root console. I don't know if it is something that I've changed at some point or it is the normal expected behaviour, but I would prefer to login as a normal user, and use su afterwards to gain root access (and authorize it explicitly with SuperSu). But for some reason, adb shell takes me directly to a root console. So, that's my newbie question: is it something that I have done or it is the normal behaviour. And in any case, is there any way to change it?
Thanks in advance.
Up
Sent from my Nexus 4 using xda app-developers app
Continuing with my monologue, I found my answer here http://android.stackexchange.com/qu...to-run-adb-shell-as-root-without-typing-in-su
It is managed by a flag in the boot partition, hence I did do something, I've flashed a boot.img with such a flag setted to allow accessing directly into root.
Therefore, in order to revert such a behaviour, I just need to flash a boot.img without such a flag.
Here is a quote from a reply in that stackexchange link (I modified it so it became the instructions to revert adb shell to give a normal user shell instead of a root shell)
Generally speaking, though, you need to pull your current boot.img from your phone, unpack it, extract the ramdisk, and find the default.prop file. This is a plaintext file, which you need to open in a text editor and then find the line that contains the value ro.secure. If the line says ro.secure=0 then you need to change it to ro.secure=1. After that you can re-pack the ramdisk and boot.img, then flash it to your phone. Once you reboot, you will be greeted with a $ prompt whenever you perform adb shell, having to run su to gain root.
Click to expand...
Click to collapse
I'm trying to edit the build.prop file on the G2 803 model. It's rooted and unlocked on a stock Bell Rom. The phone has the wi-fi forgetting problem. everytime I reboot it I have to reset the wifi password. I've tried editing the build.prop file to change the wifi.lge.patch line to=false but I can't seem to enter more than 4 characters after the = on that line. Am I missing something?
Use build prop editor free on playstore
_____________________________________Read more write less and be smart
siggey said:
Use build prop editor free on playstore
_____________________________________Read more write less and be smart
Click to expand...
Click to collapse
Thanks, I tried that but the changes don't appear to stick.
Fraggle_Shamy said:
Thanks, I tried that but the changes don't appear to stick.
Click to expand...
Click to collapse
Reason 1: Some build.prop values get their values from the ramdisk on each boot, so that's why some values wont stick.
Reason 2 (requires root): build.prop is located in /system. Your /system may be read-only, we want it to be read-write to make changes, so.. run the following command in a Terminal Emulator downloaded from the play store. Run the following commands,
Code:
su
mount -o rw,remount /system
Now make your build.prop changes. Once finished run the following command to get your system back to how it was,
Code:
mount -o ro,remount /system
If the app isnt helping you, download a file explorer such as ES and navigate to /system/build.prop, open the file and edit the values you want.
Note: It's nice to hit the "Thanks" button under our posts if you indeed are thankful. Saying thanks and not hitting the thanks button is a slap in the face .
Thanks for the suggestion, but the emulator didn't help. I'm guessing it's because it's locked to the boot rom (your first suggestion)? Any way around this? I have anohter 803 that doesn't have this issue. Can I copy the ROM from that phone to the problematic one?
Fraggle_Shamy said:
Thanks for the suggestion, but the emulator didn't help. I'm guessing it's because it's locked to the boot rom (your first suggestion)? Any way around this? I have anohter 803 that doesn't have this issue. Can I copy the ROM from that phone to the problematic one?
Click to expand...
Click to collapse
Try this. (Pretty much the same as a previous suggestion, doubt it will work)
Get a root capable browser. Jrummy has one that's free, I think it's called Root Browser.
Browse to /system there should be a button to mount it r/w, if not it may prompt you when you go to edit the file... Long click the file, and try to open for editing. (it may be some other combination, I don't have my phone handy right now). Make the a change or two, reboot and see if they stick.
Or the other thing you cna do is:
The other thing you can try is to do is check if they're being set on boot.
adb pull /*.rc
which will pull all of the ramdisk's initialization scripts into your current folder on your computer. Look through them and see if the values are indeed being set by the boot image. If they are, you'll need something like AIK (android image kitchen) to extract the ramdisk, either change or delete those lines, rebuild the boot.img and flash it (using flashify or manually using adb and dd). You have to rebuild them into the boot.img, any changes you make to them directly on the phone will never stay as they get re-created every boot. It's a pretty roundabout way to do it, but it's entirely possible to do.
A much easier, and less likely to cause you issues would simply be to create an init.d script that sets it. This will occur after whatever is setting it in your boot.img so there would be no need to recreate that.
create a file in /etc/init.d called something like... "Set_wifi_pass" set the permissions so that it can be executed and read by everyone.
Then enter the following:
Code:
[B][I]#!/system/bin/sh[/I][/B]
setprop wifi.lge.patch = WifiPassword
You can check that it worked by going through adb shell with
adb shell
getprop wifi.lge.patch
which should return that value you set. Same thing that build.prop is ultimately doing, just in a different way.
Hope that helps.
MoFo - Image Modification Methods
I have been helping people with other devices to make rooted ext4 images for their devices using @btdownloads7's method here:
http://forum.xda-developers.com/showpost.php?p=60389310&postcount=177
Works great. If they have the system images as sparse chunks, you can use @tal.aloni's SparseConverter.exe found here:
http://forum.xda-developers.com/showthread.php?t=2749797
to make an ext4 single image system.img but you have to use a hex editor to remove the header and the footer following tal.aloni's instructions in the thread, which I summarized here:
http://forum.xda-developers.com/showpost.php?p=61130622&postcount=41
Then you can use btdownloads7's method above to root it.
The problem is that for some devices like the XT1058 there was only the fxz available as a single file system.img, which is not an ext4 file. I don't know how to convert it to an ext4 image but I have an unlocked XT1060 and at least for the XT1058 what I found I could do was flash the XT1058 system.img to my XT1060 using mfastboot, then boot into recovery and go to Mount and check System. Then from an adb shell run the mount command. That told me where the system image was. On the XT1060 it was /dev/block/mmcblk0p38. Then from the adb shell I ran the command:
dd if=dev/block/mmcblk0p38 of=/sdcard/new_image.img
where if = input file, of = output file and dd is a command that copies the data in the input file to the output file.
Then I exited the adb shell and ran the command
adb pull /sdcard/new_image.img
to get the new_image.img on my computer. new_image.img is an ext4 file that you can flash using mfastboot if your bootloader is unlocked or mofo.exe if your bootloader is locked.
Since my XT1060's bootloader is unlocked and the XT1058 image boots on the XT1060, I could mod the XT1058 image while running android - install Xposed, busy box, etc. - then boot into recovery and run the commands above. I am sure I can also install a custom ROM in TWRP and then pull the image. The point being that for the XT1058 and the non-Dev Ed XT1060's,, which have locked bootloaders, I can modify the images using this method. My XT1060 won't work as a phone running an XT1058 image, but I can use wifi to connect to the playstore to download apps and then install them.
So, I was hoping that this would work the same for the XT1095 and our XT1096 devices. I can boot the Pure Edition XT1095 ext4 image fine on my XT1096 after flashing it with mofo.exe (although it won't make calls) so I think the XT1096 image would run on the XT1095. If someone has an XT1095, they should be able to make a nandroid of their sytem, do all of that above, add in whatever we want to the XT1096 image while running it, then boot into recovery, do the steps above and pull it as an ext4 file using adb, then restore their phone using the nandroid.
To summarize the method:
1) Make a nandroid of XT1095;
2) Use mfastboot to flash XT1096 system.img to XT1095;
3) Boot into TWRP recovery, wipe cache and data partitions, adb push SuperSU zip to /sdcard, install SuperSU zip and then boot into system;
4) Enable USB Debugging, add in Xposed, CFLumen, etc. while running Android and reboot as necessary;
5) Boot into Recovery;
6) Open an adb shell and type the command mount to determine where /system is in /dev/block;
7) Run the command dd if=dev/block/correctplace of=/sdcard/new_image.img, where correctplace is wherever /system is in /dev/block;
8) Exit adb shell and run command adb pull /sdcard/new_image.img; and
9) Restore the XT1095 to its previous state using the nandroid backup.
new_image.img would be an XT1096 rooted ext4 mofo.exe flashable file with Xposed, CFLumen, etc. baked in. In step #1, I would also copy the nandroid to my computer so that I would have a backup copy in case anything strange happened. It shouldn't but it is always better to be safe.
Note that my qe converts to 2/1 when I flash a different model's image but it returns to 1/1 once I reflash an XT1096 image.
How To Make an Ext4 Image from a Single File System.img
Requires an Android device of the same model as the system.img is for with an unlocked bootloader and TWRP installed as the custom recovery.
1) Flash the system.img using mfastboot;
2) Boot into TWRP, start an adb shell and run the command mount - note what folder /system is in /dev/block;
3) From the adb shell run the command:
dd if=dev/block/correctplace of=/sdcard/new_image.img
where correctplace is the folder you noted in Step #2.
4) Exit the adb shell and run the command
adb pull /sdcard/new_image.img
to get the new_image.img onto your computer. new_image.img is an ext4 file that you can flash using mfastboot if your bootloader is unlocked or mofo.exe if your bootloader is locked.
How To Make an Ext4 Image From Sparse Chunks
If you have the sparse chunks for your model - i.e., system.img_sparsechunk1, etc. - then you can use SparseConverter.exe to make a single file ext4 system.img that is flashable by mfastboot and mofo.exe:
http://forum.xda-developers.com/showthread.php?t=2749797
The command is:
SparseConverter.exe /decompress C:\system.img_sparsechunk1 C:\system.img
And it is run from the directory where SparseConverter.exe is. Of course, if your sparse chunks aren't in c:\ you would put in the path to where they are in the command above. And sometimes the first sparse chunk is not sparsechunk1 but rather sparsechunk0 and if so, of course you would start with sparsechunk0.
The system.img you make using SparseConverter.exe will have a header and a footer in it that need to be removed before the system.img is flashable by mfastboot and mofo.exe. The instructions for how to do that are here.
How to Root an Ext4 Image - Requires a Bootloader Unlocked Android Device With TWRP
Requires an Android device with an unlocked bootloader and TWRP installed as the custom recovery. Originally posted here.
btdownloads7 said:
Yes, but there was a slight change in the process (at least on the Nexus 7) from they way I described it originally. Since the image is huge, and wouldn't fit onto the system partition of the Nexus 7, i couldn't just flash it as a system image from fastboot. Here's what I ened up doing:
1. Make sure that you have at least 6 GB free on the SD card, and boot into TWRP
2. Copy the clean ext4 image file to the SD card (the links are a few pages back in this thread)
3. Create a "supersu" folder on the SD card
4. Download the SuperSU update zip (the current version is 2.46)
5. Extract the "armv7" and "common" folders from the update zip to the "supersu" folder from Step 3.
6. Extract the "update-script" binary from the attached zip, and copy it to the same "supersu" folder. It's a script from tha update binary that I modified for our purposes.
7. In TWRP gui, wipe the system partition (this may not have been necessary, but I did it just in case)
8. In TWRP gui, unmount the system partition from the TWRP menus
9. open ADB shell
10. run "rm -r /system", and disregard any errors that it gives you. This will clear the mount point for our image
11. run "mkdir /system", and ignore any errors it gives you
12. run "mount -t ext4 -o loop /sdcard/system.img /system"
13. run "chmod +x /sdcard/supersu/update-script"
14 run "cd /sdcard/supersu" followed by "./update-script". You might see some errors when it's running, but you can disregard them
15. In ADB shell, run "mount", and that should list all the partitions. Remember which path is for the system partition (on my end it was "/dev/block/loop0")
16. run "dd if=dev/block/loop0 of=/sdcard/new_image.img". Obviously replace "/dev/block/loop0" with whatever you got in the previous step
And thats it. Copy the new image back to your PC, and you're ready to flash it with mofo
Click to expand...
Click to collapse
General Info On Modding Images Using Linux
@Ekkoria's tutorial here provides general information on how to mod images using linux.
@ClydeDroid - can you give a synopsis of what needs to be done to add a symlink for the AdAway hosts files? I would like to add it to this thread. Thanks!
Adding Free WiFi Tether to a System Image
To add free WiFi tether to a system image, the /system/build.prop file needs to be edited to include the following line:
net.tethering.noprovisioning=true
The line can be added anywhere in the build.prop file. Please note that editing the build.prop file in some instances resulted in HDR camera problems (force close when a picture was taken with HDR on). Be sure to use NotePad++ to edit the build.prop file, not another editor.
Adding Xposed for Lollipop to a System Image
Here and here are the instructions for @mikeoswego's method for installing Xposed for Lollipop in a system image.
You need to download both the apk and the zip from this thread:
http://forum.xda-developers.com/showthread.php?t=3034811
as well as the script that is attached to this post (unzip the script).
mikeoswego said:
1) You must mount the image that you want to install Xposed to /system on your Linux box (or edit the script some more.)
2) Make the script executable (chmod 755) and then run the script like this:
sudo [full path to script] [full path to zip file]
On my system it looks like this:
sudo /home/mike/InstallXposed /home/mike/xposed-sdk21-arm-20150430.zip
There will be some chcon errors but it still sets the permissions correctly.
3) Before you flash the image having Xposed in it to your device, download the XposedInstaller apk to your phone from the first post in this thread: http://forum.xda-developers.com/showthread.php?p=58948978#post58948978 and delete the following folders from your /data partition:
/data/dalvik-cache/arm
/data/dalvik-cache/profiles
4) On reboot, it will take a little longer at the red Verizon screen, then it will upgrade/optimize apps claiming a very large number of apps to process but most of them go by very quickly. On subsequent reboots it upgrades/optimizes one app each time. Otherwise I've not noticed any other problems or side effects.)
Click to expand...
Click to collapse
reserved 7
JulesJam said:
reserved 4
@btdownloads7 Is it possible for you to write up a synopsis of how you got Busy Box and SQLite into the image? It doesn't have to be a step by step guide, but whatever insight you could give even a high level summary would be appreciated. Thanks!
Click to expand...
Click to collapse
Sqlite is easy -- you just put the binary into /system/xbin, and chmod 755 it.
Busybox is harder. The overall process is very similar to rooting it, but you have to run most of the script in a virtual machine, and one command in TWRP. You have to get the update zip for it, extract the proper binaries for the arm7 architecture, and extract the update script. Then modify the update script to remove any mention of the mounting/dismounting of partition, and to move the the extracted binaries instead of having the script extract them. At the very end of the script, it runs a "busybox --install" command, and that has to be run on the actual device (in TWRP).
@mikeoswego - did I get the instructions correct here? I wanted to combine 2 of your posts into 1 set of instructions. Please let me know if I paraphrased you correctly, thanks!
JulesJam said:
@mikeoswego - did I get the instructions correct here? I wanted to combine 2 of your posts into 1 set of instructions. Please let me know if I paraphrased you correctly, thanks!
Click to expand...
Click to collapse
Looks good!
---------- Post added at 06:45 PM ---------- Previous post was at 06:41 PM ----------
JulesJam said:
net.tethering.noprovisioning=true
Click to expand...
Click to collapse
I'm not sure this works for carriers other than Verizon.
mikeoswego said:
I'm not sure this works for carriers other than Verizon.
Click to expand...
Click to collapse
AFAIK it works for ATT but the problem is that ATT is not subject to the Block C license restrictions so if you enable it, you still need to hide the fact that you are tethering from ATT. There are ways to modify the /system partition to do that but idk how to do it.
If you have UDP and don't tether very much, from all I have read, ATT lets it go. But if you are going to use lots of data per month tethering, they send you a letter telling you that you are violating their TOS and if you don't stop, they will take away your UDP or terminate your contract, I can't remember which. So those with UDP have to hide that they are tethering somehow.
JulesJam said:
6) Open an adb shell and type the command mount to determine where /system is in /dev/block;
7) Run the command dd if=dev/block/correctplace of=/sdcard/new_image.img, where correctplace is wherever /system is in /dev/block;
Click to expand...
Click to collapse
Just so you know, there's an easier way to do this part. The directory "/dev/block/platform/msm_sdcc.1/by-name" contains links to all the partitions so you don't have to remember weird numbers like "mmcblk0p38". The app "DiskInfo" can also show you which partitions map to which block devices, and it doesn't even need root. Hope this helps.
Mmcblk0p38 on my XT1095
btdownloads7 said:
Sqlite is easy -- you just out the binary into /system/xbin, and chmod 755 it.
Click to expand...
Click to collapse
Where do you get the binary and what is "out"?
JulesJam said:
Where do you get the binary and what is "out"?
Click to expand...
Click to collapse
I don't remember where I originally got the binary, but if you do a google search, you should be able to easily find it. Here's a good place to start.
And "out" was a typo. Should have said "put"
btdownloads7 said:
And "out" was a typo. Should have said "put"
Click to expand...
Click to collapse
I thought so but I wanted to make sure in case it was some linux command I am not familiar with, lol!
I'm trying to do something that should be very simple using the Linux method: change the boot animation. No matter what bootanimation.zip I put into /system/media, set permissions to 644 and ownership to root:root, the animation seems to default to a pulsating text "android" logo. When I also change the bootanimation file in /system/bin I only get the pre-boot Motorola logo until boot up is complete.
Pulling a MoFo Flashable Image From an XT1095
This is useful for the AT&T XT1097. You can flash modified XT1095 images to an AT&T XT1097 since they both work on AT&T. Here is how you can pull a MoFo flashable image from an XT1095.
Open an adb shell by typing adb shell at the command prompt. Then type the command su. Then run this command:
dd if=/dev/block/mmcblk0p38 of=/sdcard/system.img
Then pull the image using the adb pull command:
adb pull /sdcard/system.img c:\
joshnat said:
I'm trying to do something that should be very simple using the Linux method: change the boot animation. No matter what bootanimation.zip I put into /system/media, set permissions to 644 and ownership to root:root, the animation seems to default to a pulsating text "android" logo. When I also change the bootanimation file in /system/bin I only get the pre-boot Motorola logo until boot up is complete.
Click to expand...
Click to collapse
@mikeoswego may be able to explain to you how to do it.