Hi,
Backround:
My approach is to fullfil a full memory acquisition of an GSG i9000 (but thats not really relevant). The acquisition should be as forensic as possible by legal term. I approach is to apply as less changes as possible. So there is no option to turn on the device, root it and install ROM Manager or equal...
My Idea was to flash the Recovery Mode with CWM. After that I fullfil the acquisition with dd. (I could place the dd and su binaries to /sdcard/ext_sdcard and mount it with executable rights)
Problem and Approach
The bootloader of the device is not acceable, so I can't use fastboot to flash the recovery mode. Instead I have to use the Heimdall Suite over the download mode.
The Test/CrashDummy Device: is also a SGS-i9000, which had CWM 3.x allready installed. I flashed the recovery partition with an 2.5.x CMW image. However this didn't work out, v3.x was still booting when going to recovery mode. I did it many times, but it didn't help.
Then I read that the recovery mode-kernel is in the original linux/android kernel zImage. So I flashed it the kernel partition with Heimdall, which worked out for the recovery mode, but not for the Android OS itself..., was hanging on boot-bricked.
The second approach, flashing the original kernel, is the thing I would like to avoid generally.
The Question
Many users reported in forums that flashing recovery mode did it, my expirience showed the oposite. I also seed blog posts which told the /recovery is holding only the backup of the kernel partition.
What is or has to be flashed for a custom recovery mode eg CWM?
The Android kernel partition or only the recovery partition? Where is the recovery mode is actually stored?
I am really interested in the technical background, but can't find any documentation either on the official side nor in forums/wikis. Any links would be also helpful!
I looked at the PIT, is there a need to adjust the pit when the size of kernel images changes? Only the start address is relevant?
Also would be interested in the overall situation, am I missing something, logical flaws in the mentioned constelation?
Is there a way to pull the kernel image over the download mode, not only flash it? Maybe even other partitions, e.g. the whole flash?
Did somebody tried to read yourself in into the Odin protocol besides Glass Echidna, I started read the source of Heimdall. It's clean code but without documentation...
thanks in advance
ps: I spared time to search all the links of the flashimages, but I always used the official sources(HPs of the MODs) when it was possible.
EDIT: I found the link where the authors tells recovery is only a backup partition: vincent.bernat.im/en/blog/2011-android-samsung-galaxy-s.html
Related
Recently I got Wind Optimus 2x (p999). Before I change anything, I want to create a full backup in case of warranty. Searching forum and google for couple of days I found several different "stock" recovery images. But all of them have different size/date/etc.. So I want to make my own recovery image.
My idea is make stock recovery image (via dd or nvflash), replace recovery with cwm, make backup, flash custom ROM. If i need to go back - do in reverse order .
1. From what I found, using
dd of=/path_to_store/myimage.img if=/dev/block/mmcblk0p7
should produce required image, but size is about 1.6M, while all other recovery images have size 3-5M
Am I doing something wrong?
2. I cannot find anywhere information about correct use of nvflash utility. Some shell scripts have bunch of parameters to write image into phone, but there is no info about how to read data from phone and create image..
Any help please?
I am sorry if I don't understand your questions but, I will try nonetheless. It seems you do not understand what nv flash or cwm do. Nv flash is how you CORRECTLY install a version of the clockworkmod recovery. Once installed, you choose the back up option to copy your system image. This recovery has the ability to do anything that has to do with rom flashing. Also is does it all simply by choosing what you want to do. There's no ADB or entering commands. Just look for TGA_gunnmans one click nv recovery flasher, this is all the info you will need.
Sent from the fastest g2x in the world
well, not exactly correct. nvflash is "low level" (means it accesses EPROM on hardware level) flash utility. It's designed to write data into EPROM. In most cases such utility can be used to read data as well (for backup purposes). That is why I am trying to find more information about nvflash and how to use it.
dd us *nix utility which works on higher than nvflash level, but lower than cp (copy).
By the time cwr is installed, the phone is different from factory - one of partitions is replaced. I am trying to backup this partition before replacement.
cy_mpak said:
well, not exactly correct. nvflash is "low level" (means it accesses EPROM on hardware level) flash utility. It's designed to write data into EPROM. In most cases such utility can be used to read data as well (for backup purposes). That is why I am trying to find more information about nvflash and how to use it.
dd us *nix utility which works on higher than nvflash level, but lower than cp (copy).
By the time cwr is installed, the phone is different from factory - one of partitions is replaced. I am trying to backup this partition before replacement.
Click to expand...
Click to collapse
There are stock recoveries available! Look in the optional files section.
http://forum.xda-developers.com/showthread.php?t=1054492"
After some more research and experiments I have found that recovery partition on G2x is mmcblk0p5.
Thanks to all who answered my questions directly or indirectly
So in looking around I have not found any answer to my question. Why is everything to flash on the shield a .img instead of building zip files you can flash directly from recovery? I have been messing with android for quite a long time and know how to flash .img, fastboot, adb, ect. But dl'd and flashing a zip is far easier.
Any answers?
thanks.
*I think* that base factory images (.img files.) are meant to be flashed via fastboot, since they have a direct relationship with device specific partitions. Imagine a bit to bit flash, like a Ghost/Acronis image?!?
As for .zip files, they are installed via recoveries (CWM, TWRP, etc), because you just want to add/replace files in the / partition.
And with our Shield, until now, all OTAs are full system images, not updates.
I hope that I've explained this properly, if not please someone correct me
http://en.wikipedia.org/wiki/Fastboot#Fastboot
anthonws said:
*I think* that base factory images (.img files.) are meant to be flashed via fastboot, since they have a direct relationship with device specific partitions. Imagine a bit to bit flash, like a Ghost/Acronis image?!?
As for .zip files, they are installed via recoveries (CWM, TWRP, etc), because you just want to add/replace files in the / partition.
And with our Shield, until now, all OTAs are full system images, not updates.
I hope that I've explained this properly, if not please someone correct me
http://en.wikipedia.org/wiki/Fastboot#Fastboot
Click to expand...
Click to collapse
Not all ota are full system images, ota 65 and 67 are simple delta updates.
BTW, the main reason of .img files for images is because this can't depend on the recovery. How do you flash a recovery .zip file without a recovery?
You need to have a .img file that can be flashed via fastboot, it is VERY much "bricked" proff that a flashable zip
Thanks for the explanations. I realize some things need to be done via fastboot like unlocking or flashing a recovery for the first time.
I guess I have become spoiled by xda and the simplicity of modification that is available today. Far cry from hacking htcs back in the day.
thx -jason
Both answers are correct - it all depends on which software (on the device) is used to flash, and what format it accepts.
With Tegra devices you have at least 3 ways to flash stuff, from lowest to highest level:
- nvflash/tegrarcm mode. This is a very small firmware that is burnt in ROM and is thus always available no matter how hard you screw your device. It can run small programs (typically, a flasher) that are sent through USB. Problem is, for Tegra4 it will only accept signed binaries, which makes it useless for modders.
- bootloader/fastboot. The bootloader supports the fastboot protocol, which can flash .img files. The bootloader is written in flash memory so your bootloader partition must be in good shape.
- recovery/zip files. The recovery is a Linux image, so this means it is a full-blown system of its own right. Because of this it can support more format, including .zip archives with a script to describe how the archive should be installed.
So in the boot chain, you have 3 anchors from which you can flash images: boot rom (always available but unusable to us) -> bootloader -> recovery. The fact the boot rom cannot be used without a signed image (which is not available publicly) means that screwing your bootloader is sufficient to permanently brick your device.
Recovery images are more convenient since they are in .zip format and can for some be device-independent (e.g. superSU recovery images are flashed the same on every single device out there), contrary to the bootloader which can be different for every device. But they require a working recovery, which is not always granted - so for actual recovery, fastboot images are also useful.
That's why I love XDA
You're never alone!
Thanks for the additional info to all
Anthonws
Hello all,
I really need, for a commercial project, to flash a great number (>100) of Galaxy Camera 2 (EK-GC200() device, all with the same firmware, rooted and modified as I need.
I have to flash boot.img (modified by me) and system.img (rooted).
I have now to root the camera, then start the system, enable developer options, enable adb debug and at the end flash a new boot.img, and the system.img itself (adb shell, dd ...).
This is time consuming, and error prone.
I'm sure the boot.img & system.img are correct, cause I can flash them without error (and they work fine) with dd from the internal emulated sdcard.
I can see two viable alternatives:
1. A custom recovery, from where I could make a nandroid backup, which I can use later on to update all the rest of the cameras.
But:
I tried to port the EK-GC100 cwm recovery, I've been able to boot it up, but the touchscreen is unusable and I got a lot of error coming from the file system.
Please help me! Any suggestion, half project, everything is really appreciated!
2. To create an Odin package, using the .img files I can optain with dd from a ready camera.
But:
I tried all I can do to build a Odin package, but every time I got an error (Odin Fail) when I try to flash system.img.
I tried to build a package containing recovery.img + boot.img, and that works.
I tried to build a package containing only system.img, and it doesn't work, every time I got a Fail from Odin.
I tried manual compression (tar + md5sum on Linux), and automated scripts you can find on XDA, both under Linux and Windows.
Why is system.img impossible to flash?
What am I missing?
Thank you in advance.
Ciao,
Giovanni
DISCLAIMER
Code:
The usual disclaimer with an extra warning, this recovery
WILL automatically modify your phone on first boot.
While this should be an entirely safe modification
it is always possible your phone is in a broken state
either on a software or hardware level causing further problems.
This recovery should under no circumstances be flashed
for the first time on a bricked phone
as the automatic changes might damage it further.
ONLY FLASH THIS ON A PHONE IN GOOD CONDITION!
By flashing this recovery you consent to a vendor partition
being created and to take full personal responsibility of any damage
the usage of this recovery may cause rather than blaming it on me.
ABOUT
This modified TWRP is the recovery image i have been using on my personal OnePlus 3T for the past month, with the increasing popularity of system-as-root roms and the issues this causes for older zip files (Such as Google Apps not flashing with wrong arm version errors) i have decided that it would be worth sharing with the community. This recovery image is a ramdisk modification of the TWRP supplied by the LineageOS Unofficial Treble Port Project (Similar to how SHRP is a ramdisk modification of existing TWRP images). Because this is not a source modification (and neither has TWRP been compiled from source) you can find the original source code in their topic. I hope this recovery will be useful to those who often flash multiple kinds of roms and want one recovery that does it all. It has been tested on the Oxygen OS 4, 5 and 9 firmwares and should have great compatibility with all of them.
Included Features
Automatic Vendor Partition Creation and full Treble support
WARNING: Because this recovery will automatically create the vendor partition it should exclusively be used on devices in good conditions. In the very rare case that bricks occur you can revert the change using the MSMDownloadTool (This can only be used on healthy hardware). If you are unsure about the condition of your device or if your device is currently in a bricked state it is best to use another recovery. I am not responsible for further damage to your phone.
Originally the TWRP image provided by the Treble project needs you to type in the 'treblize' command followed by manual reboots, I have automated this process. From the moment you first boot this recovery the vendor partition will automatically be created and the recovery reboots automatically in a new recovery session (This is not a crash and only happens once). If vendor partition has been detected you will be able to see /treblized as a directory on your phone (This is done in RAM and only visible during your recovery session). The vendor partition does not conflict in any way, you can use and pass safetynet on regular roms at will as it is invisible to a rom using a non treble kernel. Before flashing GSI roms please first flash a proper vendor partiton (This can be done by flashing the LineageOS treble rom the regular way).
/system and /system_root hybrid for maximum compatibility!
This is one of my main reasons for sharing this recovery publicly, i have modified the /etc/fstab file to be able to both mount to /system and to /system_root. This means that older zips that expect /system now work again without breaking compatibility with newer system as root or GSI roms. This is one recovery that can do it all! Inside the root folder you will find a flashable zip called Mount-System.zip. This can be used before incompatible zips to mount the /system partition correctly. This tool will automatically detect system-as-root if present and mount /system to /system_root/system, if not present it mounts /system to /system_root. You should prefer this method over the mounting options found in the menu, these should only be used for unmounting system. Keep in mind that by doing this you are messing around with scenario's the original developers have not foreseen and while flashing these previously broken zips is now possible you cause issues in your ROM. Always flash these previously incompatible zips with care and make a backup first! Do not use this Mount-System.zip to flash new roms, those are best flashed in an unmounted state. The same applies for Magisk and any other system-as-root compatible zips. If you are flashing regular roms my fstab changes will be enough and mount-system will not be needed.
Magisk + Magisk Manager on the ramdisk
In the / directory alongside the other zip files you will find Install-Magisk.zip and Manage-Magisk.zip, these can be used to both install and recovery from Magisk related issues. You no longer need to worry about keeping a copy of Magisk at hand after wiping the data or when you are in need of a downgrade, with this a copy of Magisk and a GUI management tool is always available to you directly from the recovery's root folder.
Persist Backup Tool
It is very important that you keep a spare backup of your persist partition, even the MSMDownloadTool will not be able to repair this as it is unique to your device. In addition devices with persist issues (Sensors, LTE, IMSEI, Wifi, not working / blank) should not use the MSMDownloadTool at all since it can leave you with an unbootable phone. Flash the Backup-Persist.zip file (Found in the recovery's root directory) to automatically create a copy of your persist partition stored on your sdcard so you can easily back this up to a secure location. Persist is even more important than backing up the EFS! An EFS backup alone will NOT recover your phone in the case of persist corruption!
Download
Modified Files
This project contains work from
TWRP Base Image and original Treblize scripts : The Unofficial LineageOS Treble Project
Install-Magisk.zip : Magisk
Manage-Magisk.zip : Magisk Manager Recovery Tool
Known issues
Before uploading i did extensive testing, in some scenario's i managed to cause a hard crash of the recovery image, this is not related to any of the included tweaks but seems to be an issue with flashing a rom when you have just formatted partitions. I advice to always reboot after a partition format or before flashing a system rom to ensure that everything is in a state it can be properly mounted. If you did trigger this white light crash do not fear, your device is not bricked (Unless whatever you flashed bricked it). You should be able to turn it off using the power button after which it will boot up just fine and you can try flashing again.
<deleted>
henk717 said:
Before uploading i did extensive testing, in some scenario's i managed to cause a hard crash of the recovery image, this is not related to any of the included tweaks but seems to be an issue with flashing a rom when you have just formatted partitions. I advice to always reboot after a partition format or before flashing a system rom to ensure that everything is in a state it can be properly mounted. If you did trigger this white light crash do not fear, your device is not bricked (Unless whatever you flashed bricked it). You should be able to turn it off using the power button after which it will boot up just fine and you can try flashing again.
Click to expand...
Click to collapse
Might not be restricted to just your recovery.
This happens to me on official TWRP as well, when I restore a system image from a backup. It gets stuck on a white light, and I have to hard reset it. The restore does seem to work though.
I flashed the backup persist but did not found the file it should create. Where is it located? Thanks in advance
It should be located in the main directory of your storage and be called persist.img.
However when i just did another test i noticed the zip gives a 255 error that does not happen on the zip on my gitlab.
I am unsure how this difference happened but generated a new img file where i tested and verified all the zip's manually, if you run into the 255 error please redownload and reflash.
First released twrp for BLU G90 phone.
Whats working:
Adb
Mtp
USb-OTG
MicroSD
Flash Image
Mount System , Vendor, product (contents of SUPER).... mount allows reading the partitions, but was not able to write to them
Back-Up/Restore to/from usb (or micro sdcard).... Due to size of super.img needed to format card ext4
Logcat
Screenshot
Known bug:
**Solved with new tree file**--data decryption is not working, so not able to read or backup internal storage.--
Built with Minimum Manifest _branch 10.0 :
https://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni
Kernel source :
https://github.com/mrmazakblu/Blu_G90_G0310WW_stock_kernal
Device Tree :
New
GitHub - mrmazakblu/device_PBRP_BLU_G90_G0310WW at TWRP
Contribute to mrmazakblu/device_PBRP_BLU_G90_G0310WW development by creating an account on GitHub.
github.com
Download :
Releases · mrmazakblu/device_PBRP_BLU_G90_G0310WW
Contribute to mrmazakblu/device_PBRP_BLU_G90_G0310WW development by creating an account on GitHub.
github.com
Old
https://github.com/mrmazakblu/device_TWRP_BLU_G90_G0310WW
Download : https://github.com/mrmazakblu/device_TWRP_BLU_G90_G0310WW/releases
ADB Sideload is also broken.
Shananiganeer said:
ADB Sideload is also broken.
Click to expand...
Click to collapse
Most likely due to no able to read/ write to /data there is no place to temp store the zip.
Working on alternative options at the moment, as I am having trouble getting build correct to make decrypt.
Alternative is a modified /vendor.img, so device is not encrypted. But this of course is less secure.
I reformatted /data so it was unencrypted, but still couldn't use adb sideload. I was able to use adb push to put files onto the phone, but that didn't end up mattering as without rw to /system I can't install gapps XD. I'll have some time this weekend to take a look at things and try and help debug the decryption.
Appearently, this build is only missing data decryption.
Spoke with TWRP maintainer, they said this is working as intended. Super.img partitions are not currently meant to be mounted as r/w.
After I asked about flashing GApps, I was informed that there might be changes to TWRP source to allow mounting as r/w sometime sooner or later.
mrmazak said:
Appearently, this build is only missing data decryption.
Spoke with TWRP maintainer, they said this is working as intended. Super.img partitions are not currently meant to be mounted as r/w.
After I asked about flashing GApps, I was informed that there might be changes to TWRP source to allow mounting as r/w sometime sooner or later.
Click to expand...
Click to collapse
so it may seem we are waiting on how to affectively be able to modify the dynamic partitions before we can see a fully successful root. I am fairly new to these things so might be looking at it wrong.
Ivisibl3 said:
so it may seem we are waiting on how to affectively be able to modify the dynamic partitions before we can see a fully successful root. I am fairly new to these things so might be looking at it wrong.
Click to expand...
Click to collapse
To modify it "live" yes maybe.
You can modify the extracted system, as I did , using linux mount, and flash the system back modified, just like a gsi rom.
But for root, can't say.
On the latest build, was able to mount /system r/w. And successfully change the contents of it.
The patches in twrp source is not finished yet, so normal zip installs are not coded. But using adb shell (or TWRP terminal ) seem to be working.
This New build to be uploaded on github device source, as release "test build 9"
I have the G90 Pro and would love to be able to edit the build.prop file... the phone has a ridiculously low number of volume steps for media, 7.
Is there any way to boot into TWRP temporarily and edit the file, just to see if that will increase the steps? (by adding ro.config.media_vol_steps=30 for example)
johnsag49 said:
I have the G90 Pro and would love to be able to edit the build.prop file... the phone has a ridiculously low number of volume steps for media, 7.
Is there any way to boot into TWRP temporarily and edit the file, just to see if that will increase the steps? (by adding ro.config.media_vol_steps=30 for example)
Click to expand...
Click to collapse
Well, the first thing I'm concerned with here is , I'm not sure if THIS TWRP will work on the g90 pro.
But it might be possible. I was able to mount system as r/w on my g90 in TWRP.
You would need to fastboot flash --disable-verity vbmeta and vbmeta_system to prevent red state bootloader lockout.
Ok I've found one potential bug and have a question you may be able to answer. With your build of TWRP I cannot access fastbootd. Running adb/fastboot reboot fastboot just puts me back into recovery. To change images I've been doing the following:
1. Enter bootloader and flash stock recovery you provided in your other G90 thread
2. Enter fastbootd and flash the image
3. Re-enter bootloader and flash twrp
The question I have is, how can the super partition be increased? I tried to flash the LOSQ build with gapps, but the image is > half the size of the super partition. I want to take 1GB away from the userdata partition and add it to the super partition instead. Do I mount the stock super.img in Linux and modify it to be 5GB, adjust the partitions on the eMMC so the new img will fit, flash the new super.img from bootloader, and then go into fastbootd and flash LOSQ? Where does modifying BoardConfig.mk with the new size fit in? If you don't know or don't wanna bother answering that's cool, I've been doing some digging trying to get to the bottom and I'm just not understanding how to adjust the new dynamic partition scheme.
Shananiganeer said:
Ok I've found one potential bug and have a question you may be able to answer. With your build of TWRP I cannot access fastbootd. Running adb/fastboot reboot fastboot just puts me back into recovery. To change images I've been doing the following:
1. Enter bootloader and flash stock recovery you provided in your other G90 thread
2. Enter fastbootd and flash the image
3. Re-enter bootloader and flash twrp
The question I have is, how can the super partition be increased? I tried to flash the LOSQ build with gapps, but the image is > half the size of the super partition. I want to take 1GB away from the userdata partition and add it to the super partition instead. Do I mount the stock super.img in Linux and modify it to be 5GB, adjust the partitions on the eMMC so the new img will fit, flash the new super.img from bootloader, and then go into fastbootd and flash LOSQ? Where does modifying BoardConfig.mk with the new size fit in? If you don't know or don't wanna bother answering that's cool, I've been doing some digging trying to get to the bottom and I'm just not understanding how to adjust the new dynamic partition scheme.
Click to expand...
Click to collapse
The stock /product partition is not needed in non stock roms. Google gsi flashing guide tells show to delete logical partition product.
Code:
fastboot delete-logical-partition product
This is probably what is needed.
Don't know about your plan to increase stock super.img. no idea about why you mention boardconfig.mk
This TWRP is before the patch for TWRP fastbootd, so it is not included. I have resynced source, and will see if new build works, or not. If it does will post new release.
I mentioned BoardConfig.mk because the size of the super partition is listed there, but you were totally right about the product partition and I was able to flash LOSQ+gapps after deleting it. Thanks for the assist, and your work on porting TWRP to this awesome device! Will continue to keep an eye on your work as TWRP finalizes their support for Android 10.
Will this work for the G90 Pro? My guess is not but figured I'd ask
KryptekKnight said:
Will this work for the G90 Pro? My guess is not but figured I'd ask
Click to expand...
Click to collapse
I assume not. But if you send device stock recovery, I can try to bring it up. But cannot test it, I don't have the device.
mrmazak said:
I assume not. But if you send device stock recovery, I can try to bring it up. But cannot test it, I don't have the device.
Click to expand...
Click to collapse
Would you be able to compile a Gcam pretty for this phone? I would be willing to supply you with whatever is within my means to provide
KryptekKnight said:
Would you be able to compile a Gcam pretty for this phone? I would be willing to supply you with whatever is within my means to provide
Click to expand...
Click to collapse
I have no idea about gcam
johnsag49 said:
I have the G90 Pro and would love to be able to edit the build.prop file... the phone has a ridiculously low number of volume steps for media, 7.
Is there any way to boot into TWRP temporarily and edit the file, just to see if that will increase the steps? (by adding ro.config.media_vol_steps=30 for example)
Click to expand...
Click to collapse
Sorry OP.....
I need to get 01 post of your topic to report on custom recoveries on the G90 Pro.
For new users, you should know about the Android 10 permission structure.
In TWRP or PBRP, through the File Manager, it is not possible to copy files to the superpartition. But you can copy files from the superpartition to the internal SD card.
Therefore, to modify files from the super partition, it will be necessary to extract the super partition and extract system-product-vendor to then carry out the modifications and repackage.
Using Havocv3.11 the volume issue dissapears...........
Well all, thanks to @lopestom , we may soon have a new device tree to build recovery from , and data decryption is working on first test img. New recovery would be pbrp instead of twrp.