1 archived comment

Comments are closed. These were posted on Disqus, and are archived here.

1. Jarmez May. 20, 2014

   Hi,

   Not sure what is up with Disqus but it's not letting log in? Seems to be irrelevant of browser type as well? Chrome, Internet exploder, Firefux what ever? Meh... Anyway, I didn't see when this was published, so I'm unsure if this is a maintained blog or something more of an useful archive? But I will post anyway because someone may find this interesting?

   Recently I had a situation put into play using the above sequence, essentially a lot of mobile phones these days use variations of linux file systems, take Android for instance...it is a lot like Linux, and with a few simple modifications can be made to be very powerful (yet small) Linux systems. So I was given a phone to repair which happened to be an Android device. Upon inspection I diagnosed that the IMEI had become corrupt or something similar, this meant the device would operate as normal but was no longer a phone. In otherwords it was usable as an operating system but could no longer register to a network or be able to connect calls other than through wifi. So pretty much an useful brick! In most cases people buy "wifi only" tablets for specific purposes and enjoy using them with their large screens to do a limited range of tasks inside the house....a mobile with small screen would not make a good tablet nor perform the same duties as one, with ease. So to unbrick the said device I had to go about things in a careful manner or else risk permanently bricking beyond recovery. The difficulty (I guess I will elaborate) was not in performing the commands as you have done, but more so in the retrieving the information from within the image in-tact and re-usable. So I guess this is more related to the steps after you have done as you described....that's the scary part most people are not prepared for.

   So here is what I did and what I discovered. First I gained root access (super user for what of a better word) Or Admin rights if you are talking Windows lingo (for those reading and not getting it). From there I performed the same command as you have stated but with a tiny bit more difficulty.
   1) The partition table was in unknown condition and the said partition that contained the IMEI information was corrupted and unmountable from the Android aka linux bash command line.
   2) I knew the basic address range for the binary data created an image for the spanned address. I wasn't going to take a full device image because that would be like finding a needle in a hay stack. So did as you described using the block address info and took an image of it's whole space of the unmounted partition.

   At the Linux command line I attempted to mount the image. The Linux command line I was of the believe was much more powerful than Windows especially in this instance where you're dealing with a file system that is essentially Linux, right? More on this later

   losetup /dev/loop0 efs.img
   fsck /dev/loop0
   

   This returned an awful message "Invalid Superblock" suggesting what I feared the most and that was that the image information I had obtained was basically stuffed not just the partition enclosing it.
   Most developers and phone repairers (if determined) could try some other undocumented ways or means to try retrieve the the corrupt information. These would include such tactics like *gulp* are you ready for it?....."Perform a complete NAND erase (keep in mind nand memory is like an SSD not like a spinning disk - once its gone it's GONE) on the partition at its address and then perform a complete repartition; boot the system now that it has no corrupt bytes interfering with mounting the partition and let it auto generate new data albeit blank data with no IMEI information at all, re-perform the image process of the now mountable partition, mount the new image and proceed to replace bytes from the good image into the corrupt image at similar address locations using a hex editor and hope for the best" some had succeeded at doing such tasks but not without the challenge or deciphering header information from relatively unknown files? Like I mean if it was known they would have had a backup of it before it was corrupted, but seeing as this was not my device that was about as far from the truth as you want to be.
   I was getting annoyed at booting into and out of my Linux box by this stage the device was connected and reading through my Windows box ala duel boot. Virtual machines are great but not when you want to port through a USB connection to physical hardware, it becomes messy with drivers bla bla bla forget it, enough stress already without more to top with things like that.

   So I decided to use a Windows application by Diskinternals called Partition Recovery which reads Ext3/Ext4 and a number of other file system formats, only thing is that it's not free. I only had the free trial. So I decided to check it out anyway, and guess what? That image that was not mountable inside of Linux for some reason was able to be mounted inside of this Partition Recovery app. So I proceed a step closer and find that I can in fact see the contents of the files the image contained. I just couldn't open them or access them, but I knew they were there! Ah-ha.....anyway I got sick of Alt+Tabing between mounted image and the image inside the app. I could have both images open inside but it was quite a bit of effort to flick between them inside the application, making it hard to try replace bytes from one to the other. I figured I should have the good one open read only and the other one open with the internal hex editor to paste bytes, so I downloaded Diskinternals other app which is free called Linux Reader. Here is the funny part. The trial of Partition Recovery let me retrieve a limited number of files for free. My plan from here would be to do my homework looking at the file sizes to workout which files they corresponded to in the mounted good image and import the IMEI byte data into the good image (essentially the reverse of what others were doing - but seeing as they didn't have the luxury of seeing file sizes and names I was still a step further ahead). When I mounted the good image in the what I believe to be "read only" Linux Reader it displayed an export function on the internal tab, I guess that is just to pull files from one file system to another? And then it occurred to me! I unmounted the corrupt image from Partition Recovery and mounted it in Linux Reader and I could see everything! I hit select all and then export and BAM all the efs partition files exported with ease as perfect as if I was reading them from the root partition it's self.

   From here I pretty much copied to the SDcard of the device, explored the root of the device, mounted the somewhat empty partition, and copied the retrieved files over the top, reset the permissions, rebooted the device and had a fully functioning IMEI connected to the network and able to place calls. All I did then was unroot the phone and handed it back to the owner :-) done and done.
   Who would have thought that a Windows GUI app of all things used to retrieve linux file system info could do a better job than Linux it's self? What I want to know is who/how did the developer make drivers for Windows that perform better than Linux, and why isn't this being pushed back up the tree into Linux sources? The thing is, I am not the first to try mount images like this and fail within Linux. Other developers using other breeds of Linux all got the same cringing information "Invalid Superblock" so my guess this is a bug that goes waaaaaay upstream in the source tree. Something needs to be done about it.

   Hopefully people coming here to read your blog may read my post and it helps them out. Feel free to hit me back on my email address if it displays in your blog.

   Cheers