Motorola Droid 4 – Broken screen and data recovery
At the beginning of this year my Motorola Droid 4 phone started dying on me. I looked for help on the XDA Developers Forum where I kept track of the different steps I took. For archiving reasons I created this write up to have a single page containing all information that I found on the issue. Sadly enough I was not able to repair the phone, however I was able to recover my data by rooting the device. The original XDA Forum thread can be found here: http://forum.xda-developers.com/showthread.php?t=2552978
It seemed I had the exact same problem as described in the first post on the issue by someone else, and my issues started only recently. To give some more information, these are the phases the phone went through:
It started with the phone acting like the proximity sensor was activated, the screen would go out at random times or turn off and on. I got the idea it was the sensor next to the right of the Motorola logo, there actually was a scratch right on this sensor and I thought this was the problem. When I would put my thumb over this sensor the phone would work normally as long as I kept it covered, alternatively the phone would work normally when I would slide open the phone.
The next part was that the screen no longer would come on when I pressed the power button, it would activate some part of the backlight, but the screen would stay black. Rebooting the phone would help, the Motorola logo showed fine, then the Droid logo came on fine and also made sound. But the moment where it should show the SIM lock screen in Portrait mode it did not show anything at all anymore. Sliding the keyboard open resulted in showing the SIM lock screen, however it would not take any input from the keyboard at that moment, so I could not unlock the phone.
When trying the Droid@Screen application I could view the screen perfectly on my laptop, so the phone was still working, but it would simply not show anything on the screen. Touching the screen on the phone would result in buttons pressed on the Droid@Screen screenshots, so I could unlock my phone this way. So even though the screen would not show anything the touchscreen would still work.
Sadly enough the next phase of the failure is the screen shown in the image below  (it doesn’t even show the Motorola boot logo anymore), so the phone can no longer be used and also Droid@Screen does not show any screenshots anymore. However the phone is still being recognized by ADB.
I got the feeling the problems are a combination of some hardware problem and the software reacting very badly on it. I originally had the idea to disable the proximity sensor somehow by flashing a different rom (running stock now). However I ended up not following that road.
The last phase is the phone not showing anything at all anymore. Some boots it might show the white scrambled screen from the start, but most of the time it is just a black screen. However, connecting to it can still be done through adb, but since the phone was not rooted this gave limited possibilities.
 ADB access
> adb shell getprop ro.build.description cdma_maserati_mmi-user 4.1.2 9.8.2O-72_VZW-18 19 release-keys
shell@cdma_maserati:/ $ lsmod lsmod pvrsrvkm_sgx540_120 321639 0 - Live 0x00000000 btwilink 3478 0 - Live 0x00000000 wl12xx 136026 0 - Live 0x00000000 mac80211 220250 1 wl12xx, Live 0x00000000 cfg80211 163432 2 wl12xx,mac80211, Live 0x00000000 compat 2546 0 - Live 0x00000000 evfwd 4666 0 - Live 0x00000000 cifs 254412 0 - Live 0x00000000 moto_crypto 95621 1 - Live 0x00000000
The log file (adb logcat -s *:E) shows me the following:
--------- beginning of /dev/log/main 12-07 01:22:58.125 7534 7535 E FramebufferNativeWindow: couldn't open framebuffer HAL (Not a typewriter) 12-07 01:22:58.125 7534 7535 E FramebufferNativeWindow: couldn't open gralloc HAL (Not a typewriter) 12-07 01:22:58.125 7534 7535 E SurfaceFlinger: Display subsystem failed to initialize. check logs. exiting... 12-07 01:22:59.671 7554 7554 E PhonePolicy: Could not preload class for phone policy: com.android.internal.policy.impl.PhoneWindow$ContextMenuCallback 12-07 01:23:03.289 7555 7556 E FramebufferNativeWindow: couldn't open framebuffer HAL (Not a typewriter) 12-07 01:23:03.289 7555 7556 E FramebufferNativeWindow: couldn't open gralloc HAL (Not a typewriter) 12-07 01:23:03.289 7555 7556 E SurfaceFlinger: Display subsystem failed to initialize. check logs. exiting... 12-07 01:23:04.828 7572 7572 E PhonePolicy: Could not preload class for phone policy: com.android.internal.policy.impl.PhoneWindow$ContextMenuCallback
Snippet from adb logcat -s *:I):
12-07 13:18:19.093 6237 6237 I ServiceManager: Waiting for service SurfaceFlinger... 12-07 13:18:19.093 5822 5822 I ServiceManager: Waiting for service SurfaceFlinger... 12-07 13:18:19.117 5799 5799 I ServiceManager: Waiting for service SurfaceFlinger... 12-07 13:18:19.125 5741 5741 I ServiceManager: Waiting for service SurfaceFlinger... 12-07 13:18:19.125 6064 6064 I ServiceManager: Waiting for service SurfaceFlinger... 12-07 13:18:19.140 4752 4752 I ServiceManager: Waiting for service SurfaceFlinger...
I do know it is a phone and not a typewriter 
The SurfaceFlinger error might be where the problem is.
Like suggested on the Forum I tried fastbooting to the stock firmware (http://forum.xda-developers.com/show….php?t=2207384, option 2). This did not fix the issue for me neither.
Before trying the fastboot stuff, be sure to have a full battery (the battery might keep draining because of the constant white scrambled screen). To check the battery status with adb use:
adb shell cat /sys/class/power_supply/battery/capacity
Inside the Droid 4
Because the screen became more and more faulty over time one of the theories was that the flex-cable of the screen might have been broken. I have had this problem in the past with Samsung clam-shell phones, and I actually hoped this issue would not exist anymore in the current day. But it would explain the phone slowly degrading more and more until it doesn’t do anything at all anymore with the screen. My next step step was to take the Droid 4 apart to see if the flex-cable was indeed broken. However, before doing that I first wanted to recover my data from the device. After doing that (which is described in the next part) I took my Droid apart, however the LCD cable did not have any clear rips in it, only some really small marks, which might as well have been the result of taking it apart. I could have ordered a new LCD cable to see if replacing it would help. But I never bought the LCD cable, because it was almost 50% of buying a new (2nd hand) phone (from Ebay), so I went with that option. I made a picture of the Droid 4 after taking it apart, so people know what they are up to…
Rooting
Since the phone was not working anymore my focus was to recover my data from it. However, the problem I was facing was that I could not access the user files on the phone since I did not have root rights. The solution I sought for was getting root access on the Droid4 by exploiting a vulnerability.
I looked in to using the exploit by Dan Rosenberg on this device to get root access (http://vulnfactory.org/blog/2012/02/…ty-experiment/ ). However this exploit needs a device which actually boots. Which in this case is not happening, so this exploit does not give root permissions. Because I only had adb access to a not fully started system the exploit by Dan Rosenberg did not work so I had to look for something like a kernel exploit. I luckily had some help from some friends, and they pointed me to the following exploit which worked: https://github.com/android-rooting-tools/android_run_root_shell
It seems that the Droid 4 is running Linux Kernal 3.0.8
Linux localhost 3.0.8-g473e586 #1 SMP PREEMPT Fri Feb 8 13:28:58 CST 2013 armv7l GNU/Linux
To use the exploit, compile the source code and copy the file to the Droid4 (also copy the device.db file):
adb push run_root_shell /data/local/tmp/run_root_shell adb push device.db /data/local/tmp/device.db
You can copy the files to the /data/local/tmp directory on the phone (you can write here as a user without root rights), make sure to make the file executable and then run the exploit. The exploit can find all the values it needs itself (slow) or get them from the device.db database (fast), for a single use root exploit the slow approach will do, but if you need to use the exploit a couple of times I recommend to use the device.db. The device.db on the site did not contain the Droid 4, so we had to find these values ourselves. You can insert the following information in to the device.db file to add the Droid 4.
insert into supported_devices(device_id, device, build_id, check_property_name, check_property_value) values(185, 'DROID4', '9.8.2O-72_VZW-18', null, null); insert into device_address(device_id, name, value) values(185, 'prepare_kernel_cred', 3221997068); insert into device_address(device_id, name, value) values(185, 'commit_creds', 3221995156); insert into device_address(device_id, name, value) values(185, 'remap_pfn_range', 3222276972); insert into device_address(device_id, name, value) values(185, 'ptmx_fops', 3230673008);
Output of the slow version of the exploit (without the information added to device.db):
127|shell@cdma_maserati:/data/local/tmp $ ./run_root_shell ./run_root_shell Device detected: DROID4 (9.8.2O-72_VZW-18) Try to find address in memory... Attempt msm_cameraconfig exploit... Detected kernel physical address at 0x80008000 form iomem Attempt fb_mem exploit... Detected kernel physical address at 0x80008000 form iomem Failed to open /dev/graphics/fb0 due to No such file or directory You need to manage to get remap_pfn_range addresses. Try copying kernel memory... It will take a long time. Attempt get_user exploit... Search address in memroy... Using kallsyms_in_memroy... prepare_kernel_cred = 0xc00bc60c commit_creds = 0xc00bbe94 ptmx_fops = 0xc0902870 Attempt acdb exploit... DROID4 (9.8.2O-72_VZW-18) is not supported. Attempt fj_hdcp exploit... Attempt msm_cameraconfig exploit... Detected kernel physical address at 0x80008000 form iomem Attempt put_user exploit... root@cdma_maserati:/data/local/tmp # id uid=0(root) gid=0(root)
The fast version of the exploit (with the information added to device.db):
127|shell@cdma_maserati:/data/local/tmp $ ./run_root_shell ./run_root_shell Device detected: DROID4 (9.8.2O-72_VZW-18) Attempt acdb exploit... DROID4 (9.8.2O-72_VZW-18) is not supported. Attempt fj_hdcp exploit... Attempt msm_cameraconfig exploit... Detected kernel physical address at 0x80008000 form iomem Attempt put_user exploit... root@cdma_maserati:/data/local/tmp # id id uid=0(root) gid=0(root)
Now we have root access we can access the partitions we want, to easily download the partitions through adb (on Linux) you can change the rights to the partitions with the following command:
chmod 777 /dev/block/mmc*
With the non-root user now having access to the partitions, you can download them with the following commands.
For the userdata partition:
./adb pull /dev/block/mmcblk1p24
For the full disk inside the phone:
./adb pull /dev/block/mmcblk1
For the sdcard it will be:
./adb pull /dev/block/mmcblk0
This pull request will take a while, statistics from downloading the userdata partition and whole disk on my machine:
755 KB/s (3279945728 bytes in 4239.895s) 414 KB/s (15938355200 bytes in 37526.406s)
To read the information from the partitions you downloaded you can, among other things, mount them in Linux or use a tool like FTK Imager on Windows.
I would like to thank and credit both blasty and ius for helping me out and finding the right exploit plus device.db values. In case anyone needs the compiled exploit and updated device.db file, they can be downloaded below:
Leave a Reply