Trying to edit my init.rc to mount /dev/block/mmcblk0p2 on boot, starting to think beating myself to death with the phone would be easier. I have followed the tutorial here:
http://forum.xda-developers.com/showthread.php?t=443994
And tried the alternate method listed here:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
But no matter what I do the image never repacks right, I'm only changing 1 line so the file size should stay the same, but when I repack, I get 3.5mb with splitimg, 3.6mb when trying repack-boot.img, 4.4mb when using mkbootimg, and I'm starting off with a 4.2mb boot.img. Even weirder, when I use the splitimg method, the old and new boot.img.ramdisk.gz are the same size, I use the same kernel, and it still repacks a different size than the original. Erasing everything every time to make sure no files are being overwritten. Using ubuntu 9.10. What could cause a different file size and non-booting image each time? Also, when I use the split_bootimg script on the new file, the kernel & ramdisk are the same size. So does that mean it's throwing out data not related to those 2 things, and that's what's killing it? Or is it like the Nexus, where you have to add --base to mkbootimg, and if so, where do I get the number to go with --base?
Watch the video in my signature it'll help you
Thanks, I was already doing it right, but watching your video I decided to redownload the files you had, my mkbootfs was corrupting the ramdisk, it is a good tutorial though, easy to follow even without sound.
Related
Hi guys,
I'm at my wit's end with this one.
I have a 1.2GB data.img file created with Clockworkmod Recovery backup. I believe it was one of the older versions, in the 3.x.x.x range. When this was created I had plenty of space available on the SD and the MD5 was created successfully.
I have had no luck restoring this with any version of CWM. Restoring simply results in a system that won't boot; I am presented with either a black screen or a boot-loop. I have since learned that this is because my backup has too many files. Apparently CWM is hard-coded to restore a maximum of 10,000 files and will not restore anything past that point. I found a thread where someone had edited the source code to increase this limit to 50,000, compiled and flashed it, then successfully restored their backup. Aside from the initial editing, I would not know where to start to do this for my phone (SGS2)
Furthermore, I cannot extract the contents with unyaffs.exe for Windows. When I try to do this, it extracts a small portion of files (around 170MB), then exits with the following report :
Code:
read image file
: Bad file descriptor
read image file
: Bad file descriptor
I have since learnt that this is due to NTFS limitations with the length of pathnames. 'No problem' I think, and decide to install Ubuntu 11.10 so that I can use the linux version of unyaffs to extract the full thing without these limitations.
After a bit of messing around, I successfully compile the unyaffs source (I'm no expert in these matters). I then attempt to extract data.img and after a short while processing I get another error! :
Code:
Segmentation fault
Out of interest, I checked how much data had been extracted and got 9,544 items, totalling 204.2 MB. So I'm roughly 1 GB down.
Please help, you might not believe the hours I've spent to get to this stage and I still can't get all of my data back. I need my contacts (Google didn't back them up apparently), messages, app data and anything else I can get my hands on. If there's a better utility I can use for extracting, or perhaps a modified version of CWM I can flash onto my SGS2 so that I can restore the backup properly, I'm all ears.
Look forward to any responses and thanks in advance.
Just to update, I have now tried ext2explore on Windows 7, as well as yaffs2 explorer on Android. Both will open the .img file but display a blank window.
Exploit: Modify System Files w/o Flashing Boot Partition
Background
One of the serious inconveniences of the stock Nook Tablet firmware is the inability to copy & paste in text fields. I hacked together a solution (see this thread) that requires replacing the file /system/framework/framework.jar. However, when I did replaced that file, my tablet no longer boots.
It turns out that there are two files in the ramdisk that specify (what I assume to be) checksums of system files: /manifest00 and /manifest01. B&N has added a "feature" to the /init process that checks if system files on disk match the checksums in /manifest00 and /manifest01, and will crash the system if it finds a discrepancy, resulting in a boot loop.
/manifest00 and /manifest01 cover essentially all of the system files that one would be interested to modify, including my /system/framework/framework.jar. It is possible to get around this by using a ramdisk that has an empty /manifest00 and /manifest01, because /init only checks files with a checksum listed in /manifest00 and /manifest01, and will happily ignore everything else. But this would require me to flash a new boot partition, and since the NT has a locked bootloader, I would have to use bauwks's 2nduboot or Cyanoboot.
In essence, B & N is quite clever:
1. To modify system files (/system), you need to modify the boot partition (/manifest00 and /manifest01).
2. To modify the boot partition, you need to modify the boot loader.
3. The bootloader is locked.
Of course, with bauwks's 2nduboot hack, 3 is no longer an obstacle, but I would still rather not flash and damage my boot partition, having almost bricked my tablet once by doing so.
Exploit
I studied the /manifest00 and /manifest01 in the 1.4.2 ROM on my NT 8GB and compared them with /init.rc and /init.omap4430.rc, and discovered that /init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist. In addition, /system/bin/uim-sysfs is not in /manifest00 or /manifest01, and is thus not verified by /init.
Upon further testing, /system/bin/uim-sysfs is run after /init checks the checksums of system files, which means that /system/bin/uim-sysfs can modify /system as it wishes, with the caveat that it must restore its modifications before a reboot lest /init catches it at it.
So I placed a shell script at /system/bin/uim-sysfs that replaces /system/framework/framework.jar with my custom build, restarts the zygote process, and restores the stock /system/framework/framework.jar. I'm now able to use copy & paste on my Nook Tablet
If anyone's interested, you can check out the uim-sysfs script I'm using for the copy & paste hack in the linked file in this thread.
Interesting and very useful for stock users. Well done!
~ Veronica
Stop it, BN. Stop it.
/init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist!
Click to expand...
Click to collapse
Interesting find. What is BN thinking with this manifest checking stuff. BN, just stop it. Seriously. Stop it.
Stop it, BN.
FWIW, uim-sysfs is the no-longer-used userspace side of the "shared transport" wireless daemon stuff (the other side is called "kim" in the kernel) that's used for bluetooth, FM, and gps on the 1271... it's used in CM7/CM9 (backported from 2.6.35 to 2.6.32) for nookcolor to make bluetooth work.
BN likely just modified TI's stock init.omap3.rc and left lines like the uim service as-is. Running this non-existent file as root is kinda a "security" hole, IMO, assuming the manifest verification was supposed to be some kind of security. Remove this, there will doubtlessly be other examples of the same thing.
All that said, is this script, which is replacing system files on-the-fly any more "safe" than just replacing the boot partition in the first place? Add CyanoBoot, shift current boot.img contents 512 bytes. Done.
Nice discovery tho.
fattire said:
All that said, is this script, which is replacing system files on-the-fly any more "safe" than just replacing the boot partition in the first place? Add CyanoBoot, shift current boot.img contents 512 bytes. Done.
Click to expand...
Click to collapse
Well, the only real difference for me is what happens when you screw something up. When I screwed up /system, I could always use the "8 failed reboots" method to go back to stock /system. When I screwed up my boot partition, I almost bricked my tablet and there was no way of getting back to the factory restore interface.
In addition, it's also really, really easy for development because we'd be working with simple files, not images. For my copy & paste hack, I was editing /system/bin/uim-sysfs directly on the tablet using a text editor. Boot images are much harder to work with.
The last advantage is that it's a lot less intrusive. There's no scary flashing going on here; just drop a file in /system/bin/ and you're set.
care to share the files?
jichuan89 said:
Exploit: Modify System Files w/o Flashing Boot Partition
Background
One of the serious inconveniences of the stock Nook Tablet firmware is the inability to copy & paste in text fields. I hacked together a solution (will post details later) that requires replacing the file /system/framework/framework.jar. However, when I did replaced that file, my tablet no longer boots.
It turns out that there are two files in the ramdisk that specify (what I assume to be) checksums of system files: /manifest00 and /manifest01. B&N has added a "feature" to the /init process that checks if system files on disk match the checksums in /manifest00 and /manifest01, and will crash the system if it finds a discrepancy, resulting in a boot loop.
/manifest00 and /manifest01 cover essentially all of the system files that one would be interested to modify, including my /system/framework/framework.jar. It is possible to get around this by using a ramdisk that has an empty /manifest00 and /manifest01, because /init only checks files with a checksum listed in /manifest00 and /manifest01, and will happily ignore everything else. But this would require me to flash a new boot partition, and since the NT has a locked bootloader, I would have to use bauwks's 2nduboot or Cyanoboot.
In essence, B & N is quite clever:
1. To modify system files (/system), you need to modify the boot partition (/manifest00 and /manifest01).
2. To modify the boot partition, you need to modify the boot loader.
3. The bootloader is locked.
Of course, with bauwks's 2nduboot hack, 3 is no longer an obstacle, but I would still rather not flash and damage my boot partition.
Exploit
I studied the /manifest00 and /manifest01 in the 1.4.2 ROM on my NT 8GB and compared them with /init.rc and /init.omap4430.rc, and discovered that /init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist. In addition, /system/bin/uim-sysfs is not in /manifest00 or /manifest01, and is thus not verified by /init.
Upon further testing, /system/bin/uim-sysfs is run after /init checks the checksums of system files, which means that /system/bin/uim-sysfs can modify /system as it wishes, with the caveat that it must restore its modifications before a reboot lest /init catches it at it.
So I placed a shell script at /system/bin/uim-sysfs that replaces /system/framework/framework.jar with my custom build, restarts the zygote process, and restores the stock /system/framework/framework.jar. I'm now able to use copy & paste on my Nook Tablet
Click to expand...
Click to collapse
would be nice if you can share some files
MikeCh said:
would be nice if you can share some files
Click to expand...
Click to collapse
If you're interested in copy & paste, I've now posted instructions at http://forum.xda-developers.com/showthread.php?t=1534757
jichuan89 said:
Well, the only real difference for me is what happens when you screw something up. When I screwed up /system, I could always use the "8 failed reboots" method to go back to stock /system. When I screwed up my boot partition, I almost bricked my tablet and there was no way of getting back to the factory restore interface.
Click to expand...
Click to collapse
Well, "bricking" in the classic sense of creating a permanently damaged system is a bit difficult-- you can always boot from SD card and reflash from CWM, right?
In addition, it's also really, really easy for development because we'd be working with simple files, not images. For my copy & paste hack, I was editing /system/bin/uim-sysfs directly on the tablet using a text editor. Boot images are much harder to work with.
Click to expand...
Click to collapse
do you mean for the developer or end user?
The last advantage is that it's a lot less intrusive. There's no scary flashing going on here; just drop a file in /system/bin/ and you're set.
Click to expand...
Click to collapse
but aren't you still moving framework files around "on the fly"?
Well, in any event it was a good observation that can be used for all kinds of purposes-- rooting, running background processes, etc. You could even drop a cwm recovery binary in there to instantly turn stock into cwm I bet...
fattire said:
Well, "bricking" in the classic sense of creating a permanently damaged system is a bit difficult-- you can always boot from SD card and reflash from CWM, right?
Click to expand...
Click to collapse
True.
fattire said:
do you mean for the developer or end user?
Click to expand...
Click to collapse
I guess that's personal preference more than anything else. Please disregard.
fattire said:
but aren't you still moving framework files around "on the fly"?
Click to expand...
Click to collapse
Yes - but the process is automated by the script in uim-sysfs. From the user's perspective it's just copying a file to /system/bin say using ES File Explorer, rather than burning an image to an SD card and booting from it which appears to scare/confuse a lot of people. Also they wouldn't need a computer or a card reader or a spare SD card or a USB cable or any special software on their computer.
I used Cm 13 sources to build a bootimage for my device and everything compiled without any serious error, but i got a very large boot image 8 megabytes. I tried flashing it via TWRP but it constantly gave me error saying bootimage too large for the device.
I also forced flash the bootimage that resulted into a bricked any help would be great
My device is Samsung vibrant
Now im currently compiling the entire rom
try
http://k.japko.eu/boot-img-manipulation.html
or
Okay, first off, let me tell you I'm not at all familiar with your device...so, instead of specifically answering your questions (which would be dangerous/irresponsible of me to have you do something for which I cannot be sure of or vouch since I don't have experience with your device), I'll try to give you some general information (it does seem like you have a good grasp of many of the concepts for getting where you want to go, so maybe I can just fill-in some gaps ).
1. Regarding renaming initlogo.rle to initlogo.rle.old: I'm not sure that doing that will change the splash screen or break something when it goes to look for the initlogo.rle file (a special image file). As you've probably researched, these files are a bit odd and are not just simple image files we're all used to dealing with. I've never successfully been able to create a new initlogo.rle file on my previous attempts a few years back.
2. When you re-pack a bootable image file (boot.img or recovery.img), you need:
- re-pack the updated ramdisk to a new ramdisk.gz file
- rebuild the .img file using mkbootimg utility, specifying the kernel file and the updated ramdisk.gz file
- it's might also be important / necessary to specify the base boot address using the --base <address> parameters when issuing the mkbootimg command where <address> is the base boot address of your device; your bootable image split/unpacking utility should tell you what it sees that the base address is; here is the information I saw when I unpacked the boot.img file that you supplied in your first post:
[email protected] ~/boot-img-split-tools/ameen
$ ../split_boot.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 9600396 (0x00927d8c)
Ramdisk size: 1313051 (0x0014091b)
Second size: 0 (0x00000000)
Board name:
Command line: 'console=ttyS0,115200 rw init=/init loglevel=5'
Base address: (0x40000000)
Writing boot/boot.img-kernel ... complete.
Writing boot/boot.img-ramdisk.cpio.gz ... complete.
Unpacking ramdisk... complete.
[email protected] ~/boot-img-split-tools/ameen
- not having properly set the base boot address might explain why your device didn't boot
- not properly re-packing the ramdisk might explain why your device didn't boot
- not properly rebuilding the bootable image (using the mkbootimg utility)
3. I kind of understand what you were trying to do by changing the the .md5 file...I'm guessing that you calculated a new MD5 sum of the new boot.img file thinking that would help CWM restore it; that probably doesn't matter unless you've got the MD5/checksum verification enabled; asking/using CWM to restore / install your boot.img is an interesting and non-traditional way of doing that
4. Is the CWM custom recovery specifically built for your device? I did a quick search for it and couldn't find anything. You do indeed need a custom recovery that is built specifically for your device and it's hardware & partition / filesystem layouts and sizes. Just want to make sure that you were aware of that...using the "wrong" custom recovery might be "problematic" (bad).
Edit: I think I might have found which one you used? http://forum.xda-developers.com/showthread.php?t=2189640
5. If you had previously booted into custom recovery on your "broken" device, you still should be able to re-flash or re-launch the custom recovery in the same way that you originally did, yes? The boot and recovery partitions should be separate--so, if you only messed with the boot partition, then you should be okay--unless you've got an incompatible custom recovery that overwrote important things (like your recovery partition...).
I hope that helps...I know I didn't touch on all of your questions...that's probably enough for this post and for what follow-up questions you might have .
Cheers!
source
http://androidforums.com/threads/help-with-boot-img.963358/
I dont have much knowledge about building bootimage but while i was compiling the bootimage i got an error saying no rule to make busybox flash image. So i just copied those file from kernel sources to the out directoru i dont know if that was the problem. Also i had tried using omni 6 sources a few days back i got the right bootimage size but none of my bootimages would bootup my device. Everytime id flash the omni bootimages i got a buggy twrp recovery(faded colors, unreadable text and bootloops. Also regarding the recovery you mentioned there were some dev that built omni lollipop for my device i used TWRP 2.8 to flash all the bootimages
Well, as the title sugests, I've tried to root my phone (Samsung Galaxy J1 SM-J100MU) and failed. Since no twrp or any other custom recovery is made for my specific model, I tried the method that involves mounting the android systems and modifying the famous build.prop, or putting su binaries inside the /system folder.
I ran an unpack script from ubuntu to decompress the boot file, and simg2img to be able to mount /system following some guides I've found, and made use of mkbootimg to repack it and flash it.
The thing is that the phone won't boot because the modified boot image size differs from the original. The system also differs but Odin won't even flash it and I'll have to reflash the stock rom.
Any ideas about what it can happen? I get no apparently errors during the process of unpacking/repacking the images so I don't know. The only thing I can think of is that the unpack script says something like "There's an extra file in ramdisk; though this file can exist, the script is not made for this type of ramdisk", so I edited the script in order to skip this warning, and everything else went well. The bootimg got unpacked and then the ramdisk and then I modified default.prop.
Well, that's it, I hope you can understand and give me some help in order to proceed.
Thank you in advance.
I need help editing the default.prop of my rooted boot.img for an LG LM-X210ULM K8+. I want to mark ro.debuggable off as 1 instead of 0 but which i have no problem doing but when i use any kitchen program it puts it back together as 15mb instead of 32mb and when i flash it to my device it always bootloops.
If any one could help i would appreciate it. Im including a copy of the rooted boot.img freshly pulled ftom my device
The size probably isn't the issue. Using AIK the size was even bigger than the original.
It's all just 0x00 the rest of that partition...
By using my old uImage/_recovery unpack-repack batch file
http://cxzstuff.blogspot.com/2013/03/uimagerecovery-unpack-repack-batch-file.html
the result was smaller but still a bit bigger than the Magisk had made.
But that is irrelevant really... result attached.
Yea i dont get it. The size doesnt matter as long as it diesnt exceed the max amount of space the partition can hold. But why does changing one value cause the boot.img to boot loop after flashing.
Even the boot.img you made looped after flashing
Duhjoker said:
Even the boot.img you made looped after flashing
Click to expand...
Click to collapse
Just tells that it's not the tool used. Or mine oldie is as bad/good as the newer one in this case.
What that Magisk img had was like it had some signature but it should not be needed and probably just garbage left there from the stock...
Should not matter, but how about doing it other way around? Modify the stock boot first and then give it to Magisk for rooting.
I think it was stock. Ill have to make sure though. wonder why magisk doesnt make the image debuggable to begin with. But your right it might be that im using a magisk patched image. Ive got some firmware already broke down ill give it another try here in a bit and post my results.
Duhjoker said:
I think it was stock. Ill have to make sure though. wonder why magisk doesnt make the image debuggable to begin with. But your right it might be that im using a magisk patched image. Ive got some firmware already broke down ill give it another try here in a bit and post my results.
Click to expand...
Click to collapse
So here we are. There should be some shortcut or something left to the original sub forum at least for a week or two when you boys move these threads - dammit...
Any luck? You have a customized recovery? How about these?
https://forum.xda-developers.com/an...g/mod-bootimage-adb-unsecure-patcher-t3618558
Yes luck tonight i did a fresh reflashing on my QC Lg k8+ and decided to break open the boot.bin from the kdz i used and made my changes to default.prop then i put the renamed to boot.img on my phone and let magisk patch it then flashed it via fastboot and dared it to go into system. Then i double dared it. Then for safe measure i double dog dared it to boot into system to which it had no choice but to go along with the or be labled a @!%\**__(€.
It booted.
So the lesson learned is to patch a fresh boot.img with your default.prop changes then have magisk patch it for root.
Now oddly when i patched and tweaked my recovery using carlive kitchen, i also made sure that the same changes to default.prop or rather i made sure they had been made and they had. But any terminal like emulator or termux pulls up the props using getprop with the changes unmade and i still cannot change the values of the system build.prop and when i patch it manually it reverts on reboot.
I literally have to open a vi in twrp to make changes. And forget about copying my own patched build.prop to system in twrp. Because that leads to boot loop as well
Ok so is there a reason that you dont make those changes in the boot.img any more? Because the past two days i have woke up to no root. I have had to reflash my boot.img both times
Ok i just compiled my first kernel from lg source code and now i dont know which of the split images in my folder is the zimage
Back to the drawing board quite literally. Im stuck for sure.
I need to make edits to a few files like init.rc and init.lge.power.rc to allow for changes in my newly compiled kernels. Basically im adding a couple properties and some cpu frequency stuff. Plus i want to make it back to adoptable storage and add a second sd partition for ext4 projects im working that would work best right off the root file system.
Im using the stock extracted boot.img from a kdz using salt and carliv kitchen to unpack and repack i have also mkbootimg tools that i compiled myself and some static arm version.
I extracted the ramdisk place my new kernel image in and repack with the init files changed and flash using recovery or fastboot and bootloop every time. And magisk isnt signing with the verity key.
ok i dont know whst was going on the other day but i can split boot.img again and make changes with out looping.
i used gparted on my linux machine to partition my 128gb sd card with 3/4 vfat and 1/4 ext4 i know that by using adb it will automount but thats one timr and i may need to switch out every now and then plus it put a center part in it of about 15mb. with gparted i get the two parts with no bs. any way i created a script that mounts the second part and even symlinks some stuff. it works good but im having trouble getting init.rc to run it.
on early-init
chmod 0755 /system/etc/init/init.mntsd.sh
exec system system /system/bin/sh /system/etc/init.mntsd.sh
any tips