Nowadays we tend to use dd or fastboot over flash_image (as flash_image was for the MTD/Other weird)
fastboot flash recovery recovery.img (ONLY IN BOOTLOADER MODE)
dd if=/dev/mmccblk0p[partition of recovery]
Either way, the custom recovery image fails to pass the check that the earlier bootloader stages do to make sure it is official. The ONLY way we have been able to boot recoveries so far is with the fastboot boot command
fastboot boot recovery.img
for example, if you are able to get into bootloader mode, you can boot this recovery
Directory list
- Flashimage does not work (I can't remember the error off the top of my head)
- We DO NOT have the by-name feature (/dev/block/platform/msm_sdcc.1/by-name/recovery) so we must use the block device/partition real designation (/dev/mmcblk0p*)
- We are UNABLE to boot a custom recovery without the help of a USB cable each time because of certain checks the bootloader makes before it runs a recovery partition
- As of this post there is no way to get around this, that being said don't go around thinking that there will never be a way; it's extremely complicated to get around a locked bootloader and you usually have to have a very good understanding of the phone and it's software (linux/android and the lower level bootloader) before you can even attempt to do so. Even then, I find it easier to port android than to crack locked devices (but not as fun
)
For the lolz I feel like writing a bit of info about this so if anybody is interested, here it is:
How would we go about this?
Well at a very high level there is really 2 ways to do this:
1. Crack the bootloader ("Unlock" it)
2. Get around the bootloader (2nd-init, kexec)
Cracking the bootloader basically means we have to find some way to make the bootloader run unofficial bootimages. This is usually done by exploiting some sort of hole in the bootloader's boot process allowing us to run unofficial code. As times goes on, manufacturers get better and better at filling these holes (like motorola, who are infamous for how well they lock their phones). Things like loki would fall into this category.
Workarounds, like 2nd-init and kexec is where general linux knowledge comes in to play. Understanding how linux and android work, we know that we can run scripts early on in the init process by scripts the init system loads from partitions we can edit. From there we can have fun and cause havoc, like kill all the services and make our own init system (2nd-init) or just go through the process of loading a new kernel in place of an already running kernel (kexec).
Both of these have their pros and cons. 2nd-init although the easier way, but limits us by not allowing us to run a custom kernel. kexec is really hard to implement in a situation where we cannot load a custom kernel (as it's not designed to be built and loaded as a module, a lot of kernel source haxing is required) but it does basically give us everything any developer is going to need (the ability to load custom kernels)
rbheromax, cooldudezach tech dad and myself (and others) have been on and off trying to do these things for a while now, it doesn't mean it can't be done, just we do not have the time and resources this sort of thing tends to require.
we have put a few sources up on github (
https://github.com/rise-recon ) if anybody want's to take a look but sadly there isn't much in the way of documentation on the bootloader itself. We have some theories about what's going on but it's hard to prove any of it due to how easy it is to brick a device like this, and what the hex editor gives us can be hard to read.
), as people would come in to use their own phones instead of VM's phones. You'd have to find a good retailer that can do this for you. This should explain why VM's phones use CDMA, instead of GSM. The GSM phones use SIM cards, which can be easily unlocked to work on different carriers.
