• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root ClockWorkMod

Eh sorry for the confusion. bobloadmire posted that like 2 months ago as a joke. It's actually frighteningly accurate as GP seems to be working his wizardry once again.
 
Here are the boot and recovery partitions that are running on my phone right now. If you want, you can try flashing them with whatever method you feel safe with and see if they work for you. We still don't know if it the method that I am replacing the kernel/ramdisk or the way I am flashing these to the phone that is different from all the attempts from the start of this thread. If you do decide to flash these and it works, make sure to let us know how it was that you flashed it. If it doesn't work, double check that you have the same md5 as mine before posting that it doesn't work and how it was that you flashed it. No warranty at all, do so at your own risk, yadda yadda.

The recovery is stock, just repacked. The boot one has some small modifications to the kernel.
I still have service, 3g, wifi, all my apps update from the play store, ect.
Download lgoe_test_partitions.tar.gz from Sendspace.com - send big files the easy way


Code: 
j@media-pc:~$ adb wait-for-device shell
$ getprop | grep product
[ro.product.model]: [LG-VM696]
[ro.product.brand]: [lge]
[ro.product.name]: [m3s_virgin_us]
[ro.product.device]: [m3s]
[ro.product.board]: [lge_m3s]
[ro.product.cpu.abi]: [armeabi-v7a]
[ro.product.cpu.abi2]: [armeabi]
[ro.product.manufacturer]: [LGE]
[ro.product.locale.language]: [en]
[ro.product.locale.region]: [US]
[ro.build.product]: [m3s]
$ uname -a
Linux localhost 2.6.35.11 #27 PREEMPT Tue Sep 18 10:17:19 EDT 2012 armv7l GNU/Linux
$ su
# md5sum /dev/block/mmcblk0p9 /dev/block/mmcblk0p14
285e3033a504b6d168b8f61953123d4a  /dev/block/mmcblk0p9
0278dc358b5c321faebd26639d609d8f  /dev/block/mmcblk0p14
 
so i flash like i flashed jcase firmware or how? and how do i get a working custom recovery after? i will be a piggy (:
 
That is an archive containing 2 partitions. I would suggest first extracting them, pushing them to /data/local/tmp with adb, verifying the hash after they are on your phone, using dd to create a backup of your original partitions, using dd to write my images to your block devices, and then verifying the md5 of your block device. It probably wouldn't be a bad idea to do 1 at a time in case something doesn't work like we want it to.

The way I am flashing these is not exactly the safest in the world and if we can get by using dd, it would be a lot better. I have re'd our bootloader a bit and sniffed the usb traffic while flashing the tot and used that information to write my own tool to flash these directly from download mode. The tool and the method work great, but it is a very powerful tool with the ability to completely and utterly brick the phone while providing little error checking. So I would really hope we can use a safer means to flash the images with like dd.
 
slutyman said:
can we. o teamviewer so u can help me please?
Click to expand...

I suggest you avoid this, unless you understand what it is giantpune did and how to install and revert back on your own. While this does appear to be progress, it will not directly lead to you having a custom recovery.

If you're still determined to test the partitions yourself, you can do it the same way we tested previous CWM builds using cat or dd commands or Fastboot. I suggest writing only the recovery partition (mmcblk0p14) first to see if that works.

Giantpune, are these partitions from the ZV4 source?
 
ktb83 said:
Giantpune, are these partitions from the ZV4 source?
Click to expand...
These are made by fooling around with the partitions from the v5 update. As far as the kernel is concerned, I did a recursive compare and the source code for the kernel is identical. So even though the kernel is not a byte-for-byte match, it should be functionally the same.

I extracted the ramdisks from the stock recovery of v4 and v5. on doing a recursive file compare, everything is the same except default.prop and /sbin/recovery.
this is a diff of the buildprop
Code: 
10,13c10,13
< ro.build.id=ZV5.GWK74
< ro.build.display.id=ZV5.GWK74
< ro.build.version.lge=VM696ZV5
< ro.build.version.incremental=47E5087D
---
> ro.build.id=ZV4.GWK74
> ro.build.display.id=ZV4.GWK74
> ro.build.version.lge=VM696ZV4
> ro.build.version.incremental=47C45DFC
17,18c17,18
< ro.build.date=Tue Jun 19 22:54:59 KST 2012
< ro.build.date.utc=1340114099
---
> ro.build.date=Thu Apr  5 14:53:48 KST 2012
> ro.build.date.utc=1333605228
21c21
< ro.build.host=builder2.nuribom.com
---
> ro.build.host=builder1.nuribom.com
40,41c40,41
< ro.build.description=m3s_virgin_us-user 2.3.7 ZV5.GWK74 47E5087D release-keys
< ro.build.fingerprint=lge/m3s_virgin_us/m3s:2.3.7/ZV5.GWK74/47E5087D:user/release-keys
---
> ro.build.description=m3s_virgin_us-user 2.3.7 ZV4.GWK74 47C45DFC release-keys
> ro.build.fingerprint=lge/m3s_virgin_us/m3s:2.3.7/ZV4.GWK74/47C45DFC:user/release-keys
180c180
< ro.com.google.gmsversion=2.3_r10
---
> ro.com.google.gmsversion=2.3_r9









EDIT:
I spent some time messing with slutyman on irc. We were able to flash my recovery using "dd" and then boot directly into it. So no brick there. However, as expected, on rebooting, that recovery.boot-from.crap takes the stock kernel, checks the sha1 of it, then checks the sha1 of the kernel in the recovery partition, and then overwrites the kernel inside my recovery with the stock one.

The reason it doesn't do this for me is because I have already overwritten the kernel in my boot partition. So recovery.boot.from.crap starts to do what it normally does, but it sees that the sha1 is different, and stops before it overwrites the kernel from my recovery partition. It means that if you have a stock kernel on your boot partition, it will be written to your recovery partition. If you have a non-stock kernel on the boot partition, then it will do nothing to your recovery partition.
 
giantpune said:
These are made by fooling around with the partitions from the v5 update. As far as the kernel is concerned, I did a recursive compare and the source code for the kernel is identical. So even though the kernel is not a byte-for-byte match, it should be functionally the same.

I extracted the ramdisks from the stock recovery of v4 and v5. on doing a recursive file compare, everything is the same except default.prop and /sbin/recovery.
this is a diff of the buildprop
Code: 
10,13c10,13
< ro.build.id=ZV5.GWK74
< ro.build.display.id=ZV5.GWK74
< ro.build.version.lge=VM696ZV5
< ro.build.version.incremental=47E5087D
---
> ro.build.id=ZV4.GWK74
> ro.build.display.id=ZV4.GWK74
> ro.build.version.lge=VM696ZV4
> ro.build.version.incremental=47C45DFC
17,18c17,18
< ro.build.date=Tue Jun 19 22:54:59 KST 2012
< ro.build.date.utc=1340114099
---
> ro.build.date=Thu Apr  5 14:53:48 KST 2012
> ro.build.date.utc=1333605228
21c21
< ro.build.host=builder2.nuribom.com
---
> ro.build.host=builder1.nuribom.com
40,41c40,41
< ro.build.description=m3s_virgin_us-user 2.3.7 ZV5.GWK74 47E5087D release-keys
< ro.build.fingerprint=lge/m3s_virgin_us/m3s:2.3.7/ZV5.GWK74/47E5087D:user/release-keys
---
> ro.build.description=m3s_virgin_us-user 2.3.7 ZV4.GWK74 47C45DFC release-keys
> ro.build.fingerprint=lge/m3s_virgin_us/m3s:2.3.7/ZV4.GWK74/47C45DFC:user/release-keys
180c180
< ro.com.google.gmsversion=2.3_r10
---
> ro.com.google.gmsversion=2.3_r9









EDIT:
I spent some time messing with slutyman on irc. We were able to flash my recovery using "dd" and then boot directly into it. So no brick there. However, as expected, on rebooting, that recovery.boot-from.crap takes the stock kernel, checks the sha1 of it, then checks the sha1 of the kernel in the recovery partition, and then overwrites the kernel inside my recovery with the stock one.

The reason it doesn't do this for me is because I have already overwritten the kernel in my boot partition. So recovery.boot.from.crap starts to do what it normally does, but it sees that the sha1 is different, and stops before it overwrites the kernel from my recovery partition. It means that if you have a stock kernel on your boot partition, it will be written to your recovery partition. If you have a non-stock kernel on the boot partition, then it will do nothing to your recovery partition.
Click to expand...

Yup, it worked for me too.

Code: 
C:\Windows\system32>cd C:\Program Files\Android\android-sdk\platform-tools

C:\Program Files\Android\android-sdk\platform-tools>adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
A00000316AE6D6  device


C:\Program Files\Android\android-sdk\platform-tools>adb push recovery_lgoe_stock_repacked.bin /sdcard/
4220 KB/s (8388608 bytes in 1.941s)

C:\Program Files\Android\android-sdk\platform-tools>adb shell
$ su
su
#  busybox md5sum /sdcard/recovery_lgoe_stock_repacked.bin
 busybox md5sum /sdcard/recovery_lgoe_stock_repacked.bin
0278dc358b5c321faebd26639d609d8f  /sdcard/recovery_lgoe_stock_repacked.bin
# cat /dev/zero > /dev/block/mmcblk0p14
cat /dev/zero > /dev/block/mmcblk0p14
write: No space left on device
# dd if=/sdcard/recovery_lgoe_stock_repacked.bin of=/dev/block/mmcblk0p14
dd if=/sdcard/recovery_lgoe_stock_repacked.bin of=/dev/block/mmcblk0p14
16384+0 records in
16384+0 records out
8388608 bytes transferred in 2.216 secs (3785472 bytes/sec)
# exit
exit
$ exit
exit
 
ktb83 said:
Yup, it worked for me too.
Click to expand...

You might want to put the stock recovery back after you reboot the phone. Since they are overwriting part of the recovery partition again, you will end up with something that is half theirs and half mine. I'm not sure I would trust it in that state.
 
So, in other words, we're throwing science at the wall here and seeing what sticks - and, so far, it's sticking pretty well?

I have to ask since, well, I'm certainly no programmer, and in my free time I'll need to read up on dd and other stuff to even know what it is, etc.... exactly how I was able to do jcase's method :D
 
What we have stuck to the wall so far is that
1) The phone will boot recoveries that contain stuff we put into it
2) There doesn't appear to be any sort of special mumbojumbo needed to flash these. Simply writing to the block device works.
3) There is no hidden checksum or super-secret lock placed there by LG that will keep is from running a CWM
4) Somebody said months ago that they unpacked and repacked a stock recovery and it didn't boot. It looks like it was the way they packed it that caused it not to boot.
 
This would be my first time flashing an android device. I'm intimately familiar with computers, but I've only had a smartphone for about a month now.

That being said, what would you guys recommend as a good primer in order to verse myself in Android rom flashing. I'm not about to try something without knowing what I'm doing first.

Thanks for your hard work hacking away and such.
 
Giantpune, are you pretty much saying that it's possible to boot CWM if we replace the kernel in the boot partition? And by doing that it prevents it from writing back the stock recovery? You should try seeing if any of the CWM's in the beginning of this thread work at all and let us know your results and tests and try and see what detailed log results are after trying to dk so. Seeing how your kernel in the boot is different, I'm sure there will be some great clues and info in the logs somewhere on our next step.
 
hmm..just reread this entire thread from first post. there has been a lot of talented people trying to crack this thing. i wonder if any of them would be willing to revisit the issue now that giantpune has found a way to inject a recovery into the phone? from reading the thread forward,the info gp has posted was tried once it appears but not exactly the same way. it was early on and not explored throughly,other methods had higher priority at the time. the stuff gp posted i think is the right avenue. it is working with the test stuff. meaning its not bricking and looping when repacking something different than stock.
 
You must log in or register to reply here.
Back
Top Bottom