Hey all,
I've been looking into how QDLTool works a bit and figured out how to swap the images that it flashes. Please note that QDLTool verifies image hashes for a good reason. You should understand the risks before attempting to meddle with QDLTool for any reason. Anything you do is at your own risk.
I would *strongly* recommend not flashing anything but amss, system, recovery and boot from any custom builds. Any time you flash a partition image, dbl, fsbl or osbl, you run the risk of bricking your device beyond recovery.
Important note: The information below is based entirely on analysis of QDLTool. I haven't used this to flash an image yet. If you plan on using this for development, you'll have to take that step.
Let's get to the details:
QDLTool automatically determines what to flash from the images/ directory. It stores a hash internally for each of the files that it will flash. This hash is basically just a 32-bit XOR of the bytes in the file:
Code:
#!/usr/bin/python
import sys
x = open(sys.argv[1], "rb").read()
print "%02x%02x%02x%02x" % (reduce(lambda x,y: x^ord(y), x[3::4], 0), reduce(lambda x,y: x^ord(y), x[2::4], 0), reduce(lambda x,y: x^ord(y), x[1::4], 0), reduce(lambda x,y: x^ord(y), x[0::4], 0))
To swap out an image, you need to patch the old hash of a file that was previously flashed with the new hash of the file that you'd like to flash.
For this post, I'll assume you're looking at QDLTool from streakflash.zip with MD5 = 63b64ba6a9d1ee770998d2a0e4a19df1.
In this file, the hashes start at offset 0x5fa90. There are 14 of them:
Code:
0005fa90 0b b0 a7 5c 3e e9 bb 29 17 4e 8d ac a0 dc 43 62
0005faa0 2c 3f 4e f1 fb 6b fc 80 11 9d 22 07 66 70 22 4a
0005fab0 bc 38 64 95 d2 c6 72 29 6d f8 99 e2 cc 74 14 49
0005fac0 1b ad 7a 9c 77 fb ee cc
As 32-bit words, they are:
5CA7B00B
29BBE93E
... etc ...
9C7AAD1B
CCEEFB77
In order, they are:
00. Partition (hash = 5CA7B00B)
04. Dbl (hash = 29BBE93E)
08. Fsbl
0c. Osbl
10. Amss
14. Dsp1
18. DT
1c. Appsbl
20. Boot
24. System
28. Userdata
2c. Recovery
30. Logfilter
34. RCFile
So, if I wanted to flash a new recovery, I'd take the hash of my recovery file via the Python script above, then replace the bytes at 0x5fa90 + 2c = 0x5fabc with my hash (stored in little-endian, of course).
It's a bit of manual work at this point, but I think a lot of this could be automated. You'd probably be better off and safer using batch files and fastboot though.
we discovered batch files to flash the images is a bad idea as some images cant be flashed using the normal fastboot mode
Thanks,
i'am looking some infomation about QDLTool also.
but i've no idea what hash was
i'll probatly wait for some "automated" way
QDLTools has so much potention. Somebody that knows coding should make it a automated system for us the little people...
Sent from my Dell Streak using XDA App
Yes, it would be nice if someone could figure out a way to insert new "roms" into the QDL tool, so when new updates are release, it would be a no brainer to do the updates without having to go through a bunch of command lines, or hocus-pokus to get an updated rom (minus the bloated carrier rom) onto the device.
Years ago, I played around with Linux, and found the same issue. A lot of command line knowledge is required. My command line stopped at dos 6.x, going all the way back to dos 2.x
Windows spoiled everyone
Hello,
Here is something potentially useful for the devs.
I took some time the past few days to experiment a bit with my phone and work on my hexdump skills. After a few days, I came up with some interesting results which I think is worth posting.
CDT Table for Droid X2
After unpacking and experimenting a bit with the two SBF files for the DX2, I noticed an interesting pattern develop in CG3 (Code Group?). CG3 describes the CDT (Code Description Table?) which defines contents of the SBF file by each CG and where in flash memory space the CG is installed (I'd publish that too but I'm not trusting what Depacker 1.3 is telling me). I used the DX1 CDT file (found in CG31) as a reference but was hard since the format changed between the DX1 and the DX2. There is a pattern and here is what I currently have.
HTML:
CDT Entry # CDT Start Byte CDT Name CG# Signed Partition Location within Partition Signature Location Exists in SBF
1 0x0010 rdl.bin ? ? ? ? ? ?
2 0x0058 ptable 2 N ? 0x00000000 - 0x000057FF - Y
3 0x00A0 cdt.bin 3 Y mmcblk0p2 0x00000000 - 0x0007FFFF 0x0007F7FC - 0x0007FC52 Y
4 0x00E8 configtable 39 Y ? 0x00000000 - 0x002FFFFF 0x002FF7FC - 0x002FFC50 Y
5 0x0130 partitiontable 40 ? ? ? ? N
6 0x0178 bootloader 42 Y mmcblk0p1 0x00000000 - 0x002FFFFF 0x002FF7FC - 0x002FFC50 Y
7 0x01c0 mbr 45 ? ? ? ? N
8 0x0208 ebb 46 ? ? ? ? N
9 0x0250 microboot 47 Y mmcblk0p1 0x00300000 - 0x0037FFFF 0x0037F7FC - 0x0037FC52 Y
10 0x0298 pds 51 N mmcblk0p3 0x00000000 - 0x001FFFFF - N
11 0x02E0 ebr 52 ? ? ? ? N
12 0x0328 sp 53 ? ? ? ? N
13 0x0370 cid 54 ? ? ? ? N
14 0x03B8 misc 55 ? ? ? ? N
15 0x0400 logo.bin 56 N ? 0x00000000 - 0x00031FFF - Y
16 0x0448 kpanic 57 ? ? ? ? N
17 0x0490 recovery 58 Y mmcblk0p10 0x00000000 - 0x007FFFFF 0x007FF7FC - 0x007FFC52 Y
18 0x04D8 boot 59 Y mmcblk0p11 0x00000000 - 0x007FFFFF 0x007FF7FC - 0x007FFC52 Y
19 0x0520 system 60 N mmcblk0p12 0x00000000 - 0x1C1FFFFF - Y
20 0x0568 webtop 61 ? ? ? ? N
21 0x05B0 cdrom 62 N mmcblk0p14 0x00000000 - 0x013FFFFF - Y
22 0x05F8 cache 63 N mmcblk0p15 0x00000000 - 0x133FFFFF - N
23 0x0640 userdata 64 N mmcblk0p16 0x00000000 - 0x7FFFFFFF - N
24 0x0688 preinstall 65 N mmcblk0p17 0x00000000 - 0x12BFFFFF - Y
25 0x06D0 sdcard 66 N mmcblk1 - - N
I also tried to map the CGs to partitions in /dev/block. It some cases it was really simple especially since most of the bottom of the table is already mounted (adb shell cat /proc/partitions). The others I had to pull a data copy (e.g. adb shell su -c "dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard-ext/Dev/Partitions/mmcblk0p1.img"), copied the blocks to the computer and did hex compares for the first 0x300 or so bytes. In some cases (particularly mmcblk0p1 where the bootloader and the microboot are made one block together), two CG files are flashed onto one partition back-to-back. In that case I got a bit lucky with hex searching.
Things got more interesting when comparing SBFs of the DX2's sister phones (Atrix 4G and Photon 4G). It turns out not only the table is located in the same CG (CG3) but it also follows the same byte order. Either the names and CG numbers are slightly different (Atrix) or the table is identical to the DX2 with a few extra entries (Photon). Here is what I have.
HTML:
CDT Entry # CDT Start Byte DX2 CDT Name DX2 CG# Atrix CDT Name Atrix CG# Photon CDT Name Photon CG#
1 0x0010 rdl.bin ? rdl.bin ? rdl.bin ?
2 0x0058 ptable 2 ptable 2 ptable 2
3 0x00A0 cdt.bin 3 CDT.bin 3 cdt.bin 3
4 0x00E8 configtable 39 BCT.bin 42 configtable 39
5 0x0130 partitiontable 40 PT.bin 43 partitiontable 40
6 0x0178 bootloader 42 EBT.bin 44 bootloader 42
7 0x01c0 mbr 45 MBR.bin 45 mbr 45
8 0x0208 ebb 46 EBB.bin 46 ebb 46
9 0x0250 microboot 47 NVC.bin 47 microboot 47
10 0x0298 pds 51 PDS.bin 48 pds 51
11 0x02E0 ebr 52 EBR.bin 49 ebr 52
12 0x0328 sp 53 SP.bin 50 sp 53
13 0x0370 cid 54 CID.bin 51 cid 54
14 0x03B8 misc 55 MSC.bin 52 misc 55
15 0x0400 logo.bin 56 LOG.bin 53 logo.bin 56
16 0x0448 kpanic 57 KPA.bin 54 kpanic 57
17 0x0490 recovery 58 SOS.bin 55 recovery 58
18 0x04D8 boot 59 LND.bin 56 boot 59
19 0x0520 system 60 APP.bin 57 system 60
20 0x0568 webtop 61 OSH.bin 58 webtop 61
21 0x05B0 cdrom 62 CDR.bin 59 cdrom 62
22 0x05F8 cache 63 CAC.bin 60 cache 63
23 0x0640 userdata 64 UDA.bin 61 userdata 64
24 0x0688 preinstall 65 PIA.bin 62 preinstall 65
25 0x06D0 sdcard 66 SDC.bin 63 sdcard 66
26 0x0718 EBF.bin 64 gpt 67
27 0x0760 NVF.bin 65
Verification
One thought must be going through your head is "how is this single digit poster coming up with this stuff?" One, despite not being a true dev, I like looking at low level code and have some experience with it. Second, I encourage that someone takes the time verify my findings by replicating the methods I used as well as provide any thoughts on making low level hex analysis useful.
SBFs Used:
Droid X2: VRZ_MB870_DTN-14.8_1FF_01.sbf
Atrix 4G: OLYFR_U4_1.5.2_SIGNED.sbf
Photon 4G: 1FF-sunfire-user-2.3.4-4.5.1A-1_SUN-154_MR-3-CM-release-keys-signed-Sprint-US.sbf
Procedure
- Take a SBF file
- Unpack using Moto Android Depacker 1.3
- Open CG3 in a hex editor (Hex Fiend is free for MacOSX)
- Find the location where an ASCII name starts (e.g. 0x0178 = bootloader, see tables above)
- Exactly 0x21 bytes from the start of the name is the CG value in hex
Thoughts
This analysis comes to mind two things:
1. A "Full" SBF does not mean it has all the partitions. - There is a possibility of bricking your phone beyond belief and even an SBF may not save you.
2. The DX2 seems to be really close to its siblings (Atrix 4G and especially Photon 4G). - I hate the idea gets thrown around of "Don't use Atrix mods unless you like bricks" without any real technical explanation as to why not. I'm not saying that people tomorrow should flash Atrix SBFs onto DX2 phones. I am saying that we (the DX2 community) should be aware and work closely with the other sister communities to know EXACTLY where the differences between the two phones lie. And hopefully the communities can contribute something that everyone can benefit (i.e. DX2 and Photon 4G ports of the Atrix bootloader unlock).
I'll experiment with a few other ideas I have in mind and I'll post them as I find something. Thanks for reading.
- mostKnownUnknown
As this makes no sense to me as a whole, I definetely agree with the similarity of Atrix and DX2.
I am guessing we could [somewhat] easily port the IHOP sbf unlock straight to our phone, and give us an unlocked bootloader.
Very thorough research! Well done!
religi0n said:
As this makes no sense to me as a whole, I definetely agree with the similarity of Atrix and DX2.
I am guessing we could [somewhat] easily port the IHOP sbf unlock straight to our phone, and give us an unlocked bootloader.
Click to expand...
Click to collapse
I doubt this quite a bit, as even the international version of the Atrix required a different SBF for IHOP, and with the X2, we're talking about different amount of RAM (which, coincidentally, was actually an issue with the international Atrix), and a different radio/chipset. However, it isn't a stretch to imagine that a couple of devoted devs could figure out a way to port the unlocked bootloader, especially since the Tenfar System Recovery worked with minimal modifications. So, hopefully.
jeffster888 said:
I doubt this quite a bit, as even the international version of the Atrix required a different SBF for IHOP, and with the X2, we're talking about different amount of RAM (which, coincidentally, was actually an issue with the international Atrix), and a different radio/chipset. However, it isn't a stretch to imagine that a couple of devoted devs could figure out a way to port the unlocked bootloader, especially since the Tenfar System Recovery worked with minimal modifications. So, hopefully.
Click to expand...
Click to collapse
I agree with you. Could we get a unlocked boot loader ported? Possibly but leaning into to the "won't work area".
The real problem is right now, the people with the know how either don't have a device to experiment with or they don't care/to frustrated with (motorola, the og x never being cracked), or they're just to interested in another device. For what ever reason, it seems like the heavy hitters are mostly just ignoring the X2, for now (hopefully).
Sent from my DROID X2 using XDA Premium App
religi0n said:
As this makes no sense to me as a whole, I definetely agree with the similarity of Atrix and DX2.
I am guessing we could [somewhat] easily port the IHOP sbf unlock straight to our phone, and give us an unlocked bootloader.
Click to expand...
Click to collapse
Yeah. Sorry if this seems a bit overwhelming. I'd figure to get the data out there first and generate some thoughts. Here's a little bit of background.
So memory in your phone is broken up into a number of partitions. This is much like how you would break up your hard drive into a number of partitions if you plan to install multiple OSes on to your computer. Instead, partitions on your phone are there to organize the data into groups for certain functionality.
If you have adb running, you can verify what partitions you have by running "adb shell cat /proc/partitions":
HTML:
./adb shell cat /proc/partitions
major minor #blocks name
179 0 7804416 mmcblk0
179 1 3584 mmcblk0p1
179 2 512 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 1 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 1024 mmcblk0p8
179 9 2048 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 460800 mmcblk0p12
179 13 512 mmcblk0p13
179 14 20480 mmcblk0p14
179 15 315392 mmcblk0p15
179 16 2097152 mmcblk0p16
179 17 307200 mmcblk0p17
179 18 4574208 mmcblk0p18
179 32 7774208 mmcblk1
179 33 7773184 mmcblk1p1
Some partitions (particularly the bottom of the table) are easy to figure out since they are mounted when the operating system is run and you can open its file structure (usually with root).
HTML:
./adb shell mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p12 /system ext3 rw,relatime,data=ordered 0 0
/dev/block/mmcblk0p16 /data ext3 rw,nosuid,nodev,noatime,nodiratime,data=ordered 0 0
/dev/block/mmcblk0p15 /cache ext3 rw,nosuid,nodev,noatime,nodiratime,data=ordered 0 0
/dev/block/mmcblk0p3 /pds ext3 rw,nosuid,noexec,relatime,data=ordered 0 0
/dev/block/mmcblk0p17 /preinstall ext3 ro,noatime,nodiratime,data=ordered 0 0
However, most of the partitions are not in a file format that you can mount. And it's hard to figure out that the partition is used for. Since access to the partitions are located in "/dev/block/", I've begun pulling partition images from the phone and trying some low level hex/byte analysis with our SBF's CG data.
For example, in the table from my first post, CG42 (bootloader) and CG47 (microboot) get flashed onto the same memory partition (mmcblk0p1). This has some weird complications which we need to be aware of. Both CG42 and CG47 are already signed. So when I analyzed mmcblk0p1, there are actually two sets of signature data in that partition. I'm not sure what the consequences are for messing with a double-signed partition but at least it's information that we can be aware of now.
As for the bootloader, I actually doubt we can do a direct port of the Atrix unlocker. I don't think it's a memory addressing issue (since most of the partitions have a fixed size and are filled with 0xFF blank data at the end if necessary). I think I'll be getting around the signature checking. If you open any of the bootloader unlock SBFs from Atrix's Project Pudding, all of them are signed and the signatures are not the same between the unlockers for Atrix ATT vs. Atrix Bell. Wasn't the unlock SBFs a leak from Moto's development servers? If so, since it came from Moto, I severely doubt that Moto would use the same private key between carriers, let alone between phones.
As a whole, I plan to learn as much about my phone as possible even if I need to delve down into byte data and assembly code. If we want an unlocked bootloader, I'm going to at least try to do something about it rather than sit on my butt and pray to the phone gods. If anything, we'll learn something new about this phone which is at least something since there is so little DX2 data out there.
I am in love with you bro.
If you get us an unlocked bootloader, I will give you $500 cash in person.
Sent from my ADR6350
Avelnan said:
$500 cash in person.
Click to expand...
Click to collapse
And you will have the love and admiration of hundreds of people.
Is there anything I can do to help in this process? I sort of followed what you saying...
Sent from my DROID X2 using XDA Premium App
Ihatepullups said:
Is there anything I can do to help in this process? I sort of followed what you saying...
Click to expand...
Click to collapse
Let's hack moto's servers and download all the development crap we can for the DX2! ;D
Kidding aside, I too also am wondering if there is anything I can do to help.
Edit: @Mostknownunknown How did you unpack the .sbf file? I can't figure it out..
0vermind said:
Let's hack moto's servers and download all the development crap we can for the DX2! ;D
Kidding aside, I too also am wondering if there is anything I can do to help.
Edit: @Mostknownunknown How did you unpack the .sbf file? I can't figure it out..
Click to expand...
Click to collapse
He Mentioned Something About Depacker 1.3.
0vermind said:
Edit: @Mostknownunknown How did you unpack the .sbf file? I can't figure it out..
Click to expand...
Click to collapse
Yeah. Sorry. It would be good if people knew how to get the tools.
After doing some plenty of google searching, Skrilax_CZ's SBF Depacker 1.3 works in unpacking SBFs from terga-based moto phones. Apparently, SBFs have been in use through the Moto RAZR days, but the format keeps changing. Skrilax_CZ's 1.3 version is the only one I know that works.
Since I can't post links yet:
modmymobile.com/forums/402-general-motorola-android/530781-sbf-depacker-1-3-03-22-2011-a.html
Any good hex editor is useful. I'm a Macbook Pro user so I've found Hexfiend. Google it.
0vermind said:
Kidding aside, I too also am wondering if there is anything I can do to help.
Click to expand...
Click to collapse
I have some ideas. But the more I'm researching Pudding, the more it seems impossible for a port. But I'll share my thoughts once I get out of work.
Hello again,
Here are some conclusions I came up when I researched Atrix Pudding:
1. Pudding bootloader has the component that issues the unlock command (fastboot oem unlock #).
2. The unlock command causes a "fuse" to be burned in the phone's hardware.
3. Pudding bootloader has the component that recognizes the phone as unlocked.
Here are my thoughts:
1. The Pudding bootloader can take in the phone id to issue the unlock. Whereas the DX2 bootloader has the command (fastboot oem unlock) but no implementation if you send it your phone id number (fastboot oem unlock #).
2. When the unlock is issued, a bit in your hardware changes. (Most people call it a "fuse". I think it's probably a small EEPROM since as a company, I would probably like to re-lock it if I could.) People who have worked on Pudding have found an indication to see if you are unlocked (see http://forum.xda-developers.com/showthread.php?p=16003820&highlight=fuse#post16003820). You can look up that same indication on the DX2 (adb shell, su, cat /sys/firmware/fuse/ReservedOdm) and mine reads 10000000000010001000100000000. I think this file is only a place holder for the fuse indications since overwriting it does not work.
3. I asked around if SBF-ing to original after unlocking re-locks you. Apparently, it sorta does and it sorta doesn't. SBF-ing to original after unlock removes the UNLOCKED at boot up and prevents you from flashing custom kernels and recovery. But when you re-flash Pudding again, the UNLOCKED appears and you can flash custom kernels and recovery without having to re-issue the unlock command (fastboot oem unlock #). This means that there is something in the Pudding bootloader which recognizes the unlock fuse.
This actually depresses me a bit. My initial thought about the bootloader is that the unlocked indication was held in a hidden partition that isn't SBFed. So if I verified the Atrix partitions before and after the unlock, I could determine what changed in a partition and attempt to apply the change to the DX2.
But since #2 is true and the unlocked indication is located external to the partition, the only way to unlock the DX2 is to feed the "fuse" component with the right commands to "burn". There's no coping a file/partiton that will give you the unlock.
#3 is interesting in that the bootloader needs to have the processing to test if you are unlocked and allow for the unlock. Which means that we need to mess with the bootloader in order to add this processing (since I'm pretty sure the DX2 bootloader doesn't have it). This was another item that I kinda wanted to avoid since I don't think we can easily inject new code into the bootloader because of the signature. Also, if we mess up with the bootloader partition, there is a strong possibility that the phone won't make it to the fastboot or rsd protocol setup and we'd be stuck with a hard brick.
I still have plenty of questions which are still good investigates/discussion points from here.
- What are the commands the bootloader gives to the "fuse" component to request an unlock?
- Is there a way to log/monitor bootloader commands?
- Can you instruct the "fuse" component a request for an unlock after the kernel is loaded? (Holy grail here - an APK-packaged unlocker)
- In the pudding bootloader, where is the check for the unlocked indication? (possible exploit to always indicate to the bootloader that the phone is unlocked without calling the external fuse check)
- Where in the DX2 bootloader does the signature check occur?
Again, I'm not a pure dev so I'm not thinking of implementation of anything here. I'm taking the academic approach of trying to discover some loophole and then asking a dev later to package and implement it. Also, I ask you to think and analyze for the sake of understanding our phone. The more info definitely helps no matter how little it is.
Thanks,
mostKnownUnknown
This is some great reading. Really, I love the research standpoint you are taking.
If I may comment, I do not think an APK packaged unlocker would be possible because the bootloader is called at system startup.
Just like if you have GRUB installed on your computer, you cant call GRUB to boot up to your Linux box from your windoze.
The ODM fuse is read at every boot. If you were to go into stock android recovery, it reads the ODM fuse. It says Reading ODM Fuse: 1.
I am not sure what that could mean, but maybe its a true/false indicator? As in if it Read the ODM Fuse as 0, we could be unlocked.
That is what I would have to say, nothing as much as you just my ideas.
There's gotta be an exploit or something that we can do, maybe some kind of code injection, something similar to 2nd-init, that allows some kind of injected code that loads our custom kernel. I flash a lot of phones for people. I've actually made it into a business here where I live, and one of the phones I flashed, the mytouch 4g, it initially wouldn't root, and I remember there was an update.zip exploit someone posted that you "flashed" in stock recovery and it would run a small exploit and open clockwork mod recovery, and it worked very well.
There's gotta be something, some kind of exploit. I used to do tons of programming in the past, I'm so not ready to let this one go. I know there has to be a way. Encrypted? Bullsh*t. Everything is hackable.
Thanks for your research though!! This is wayyyy interesting. I love it. I want to get my hands on an Atrix... haha.
religi0n said:
This is some great reading. Really, I love the research standpoint you are taking.
If I may comment, I do not think an APK packaged unlocker would be possible because the bootloader is called at system startup.
Just like if you have GRUB installed on your computer, you cant call GRUB to boot up to your Linux box from your windoze.
The ODM fuse is read at every boot. If you were to go into stock android recovery, it reads the ODM fuse. It says Reading ODM Fuse: 1.
I am not sure what that could mean, but maybe its a true/false indicator? As in if it Read the ODM Fuse as 0, we could be unlocked.
That is what I would have to say, nothing as much as you just my ideas.
Click to expand...
Click to collapse
I like where you are going with this, although that's not entirely true about not being able to call Grub from windows. You can tell the computer to reboot into Grub, but yeah you can't run grub on top of Windows.
Avelnan said:
I am in love with you bro.
If you get us an unlocked bootloader, I will give you $500 cash in person.
Sent from my ADR6350
Click to expand...
Click to collapse
There is a bounty thread here:
http://forum.xda-developers.com/showthread.php?t=1224166
At least $750 has been pledged already! Avelnan, can we add your $500 to the pot?
Spread the word!
Sent from my DROID X2 using Tapatalk
I think this thread needs to be bumped to the top. This has the potential to be a big help in the bootloader unlock process (if it happens).
I never even saw this thread! Where did this guy go? I could have sworn I saw him post recently!
AtLemacks said:
I never even saw this thread! Where did this guy go? I could have sworn I saw him post recently!
Click to expand...
Click to collapse
IDK. This was a hot topic for all of Aug then all the sudden nothing.
first of all bump!
second thanks for this I enjoy learning all this new information, anything else interesting you have to share you have found?
Hello, readers.
I am about to receive a MT6577-based phone. My religion prohibits me from using windows :silly: and I am using Linux since good old 1993,
I have done a lot of reading during the past months. I have installed the Android SDK, and thus I have adb up and running and I believe
I won't have problem in rooting the phone (which I must do as first thing). I have found a terminal application. I believe it will be
reasonably easy for me to find myself at home.
The only big gap I still have is on how to proceed about flashing updated/modified roms to the phone. There is a very informative thread
on china-iphone.ru about the specific phone I will get. It is in Russian, but thanks to Babelfish I was able to understand a lot. Most
important, I got hold of the latest official rom for the phone I will receive.
But then, how to proceed with flashing? all tutorials I found describe the windows way of transferring this file's
contents to the phone. Use is made of one of two tools that Mediatek apparently released. This is a no-no for me. I mean: Android is
Linux. I should not have to downgrade to windows to deal with my Linux phone! And then, I simply have no windows whatsoever here.
I see three possible ways for me to proceed:
Find an equivalent software that runs under Linux
Try to run one of Mediatek's softwares under Wine
Obtain from Mediatek, or elsewhere, the precise specs about the USB protocol being used, and implement my tool
Reverse-engineer the protocol
The first item is, I believe, a dead end. I think my search has been exhaustive enough.
The second one is a path I'd rather not tread.
The third one would be a nice project, but I perceive that Mediatek is a bit opaque when it comes to providing technical specifications.
The fourth one would very quickly come to a dead end, I believe, with a bricked device.
Any suggestion on the above, or on other possible ways?
Also: I have come across some very vague mentions about flashing this sort of devices from recovery mode.
From what I have gathered, you put the rom file on a SD card, and then enter recovery mode and let the phone do its own flashing.
This would be ideal for me, but I came across no mention about this mechanism on threads that are specific to this class of phone.
Do MT6577-based phones come with recovery mode? How is it used?
I would be thankful to anyone who could provide details on this aspect.
So far I have only flashed a custom recovery into my MTK6577 phone and I did it with dd.
The full ROM is exposed on /dev/block/mmcblk0.
Once you have rooted your phone you can use dd along with the info in the scater file (from windows tool) or from Memory/eMMC in the EngineerMode (at least in my phone).
Good Luck
P.S.: In my phone the recovery can be booted into from the phone info in Settings.
Or pressing volume up when turning on the phone and releasing volume up once it vibrates (if not it goes to factory mode that has a bunch of tests in it).
Or using adb reboot revovery
FrankVM said:
The full ROM is exposed on /dev/block/mmcblk0.
Once you have rooted your phone you can use dd along with the info in the scater file (from windows tool) or from Memory/eMMC in the EngineerMode (at least in my phone).
Click to expand...
Click to collapse
Thanks a lot.
Indeed, I had found out about using dd plus the info in the scatter file. At first I completed the task of loading a different recovery image, and that was sufficient at the moment. Later on, I spent another weekend on this: I started working on a Ruby script that, by interfacing with the phone via ADB, would dump and upload any partition, and possibly do the reverse, too. The upload part sort-of worked, and I was able to get hold of the current booting partition. What I wanted to do was to modify the boot script to let me run at boot a script resident on one of the sdcards.
I got to the point of unpacking the data in the gzipped/cpio-ed root fs archive, and certainly I would not have had problems modifying the script. But I was blocked when I tried to find the data about the format of ROOTFS. I mean: I could find the start of the compressed material, but I could not find exact reference about those few bytes that preceed it. Must those bytes change if the actual content changes?
I only have one phone, and I certainly do not want to brick it (or have to pour half-days of work into blind-man debugging mode...)
The block is 512 bytes long, filled with 0xff's except for (in my case)
00000000 88 16 88 58 │ 9F 94 08 00 │ 52 4F 4F 54 │ 46 53 00 00 │ 00 00 00 00 . X ..ROOTFS......
00000014 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 ....................
and it seems quite clear that the only data that may change are the first 8 bytes - presumably 4 shorts, which in my case would have the values:
5768
22664
38047
8
When I find out what these numbers are, and when I have another free weekend, I may go on in my exploring path.
I looked into modifying boot/recovery images a few weeks back but haven’t gotten around to fiddling with mine.
The initial data is the uboot header, if I remember correctly. It does need to change.
There is a tool out there in perl that does all the required to unpack and repack the boot images for MTK65xx phones.
Here is forum page with the tool info: http://forum.xda-developers.com/showthread.php?t=1587411
my way to do it on ubuntu
well I basically did it on ubuntu, but it was actually virtual box windows under ubuntu so...whatever
This thread is from 2012... 3 years later in 2015 and not a single mtk flash tool was developed for linux... i bet using a windows based phone it will be easyer to find that kinda tool
Now there is a flash tool for Linux available, (look for needrom.com -> sp-flash-tool-v5-1424-00),but I can't get it to work. I suppose there is a vcom driver missing. Unfortunately my phone (UMI Hammer) does not support adb flash, otherwise I would be very happy to do it that way.
I think it took so long that a linux flash tool became available because MediaTek didn't share their code with developers. They changed their policy about a year ago, though.
I wrote a tutorial for setting up the SP_Flash_Tool_Linux
It works
I have a NOOK tablet 16GB that is somehow locked from modifying partitions
I have tried
the repart image , which has worked many times for me in the past
the AdamOutler Ubuntu Disk
formatting / wiping options in various versions of CWM and TWRP
fastboot erases
fastboot formats
dd'ing /zero to various partitions
parted
sgdisk
a zillion scripts
something at a low level is preventing modifications to the partitions
Im wasting far too much time on this , but I hate being beat (-:
I have a backup of rom and factory , and dd images of stock parttions so I am 100% comfortable with something that
will COMPLETELY ZAP the device
if I boot a known good CM10 image from SD card, it fails to boot , I was assuming if I could get a running android from the card, I'd have access to lots of tools... , but it just fails to tun CM10
any help appreciated.
Thanks
To completely zap the device, erase the partition table. That will leave you one, giant, unallocated space.
From there, you need to recreate all partitions from scratch.
You will not be able to boot without a bootable CWM SD, so have that handy.
sagirfahmid3 said:
To completely zap the device, erase the partition table. That will leave you one, giant, unallocated space.
From there, you need to recreate all partitions from scratch.
You will not be able to boot without a bootable CWM SD, so have that handy.
Click to expand...
Click to collapse
Thanks for responding, Yes, I have tried multiple ways to to zap the table and it doesnt stick.
sgdisk -Z, sgdisk -z parted,
no matter what I do the partitions remain untouched.
I reboot and it still boots into an old stock OS that has a FC shortly after startup, and the internal recovery (factory) , which I can not overwrite, gives the please restart and try again message.
hmm,
I WAS able to get a CM7 SD card image to boot and run
appears to work "normally" , but Internal storage shows as "not available" in settings
mikeataol said:
hmm,
I WAS able to get a CM7 SD card image to boot and run
appears to work "normally" , but Internal storage shows as "not available" in settings
Click to expand...
Click to collapse
You're supposed to do:
# gdisk
# o
# w
# q
That will for sure give you an empty partition table. You probably forgot to write the changes before exiting.
sagirfahmid3 said:
You're supposed to do:
# gdisk
# o
# w
# q
That will for sure give you an empty partition table. You probably forgot to write the changes before exiting.
Click to expand...
Click to collapse
Hi, no, I didnt forget to "write" after the "o"
/tmp # ./gdisk /dev/block/mmcblk0
./gdisk /dev/block/mmcblk0
GPT fdisk (gdisk) version 0.8.4
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Command (? for help): o
o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y
y
Command (? for help): w
w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
y
OK; writing new GUID partition table (GPT) to /dev/block/mmcblk0.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
/tmp # q
/tmp #
after reboot
Command (? for help): p
p
Disk /dev/block/mmcblk0: 31105024 sectors, 14.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): CE21388C-B927-4A5C-91CE-DBD1DE4AB3BC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30535678
Partitions will be aligned on 256-sector boundaries
Total free space is 1285 sectors (642.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 256 511 128.0 KiB 8300 xloader
2 512 1023 256.0 KiB 8300 bootloader
3 1024 31743 15.0 MiB 8300 recovery
4 32768 65535 16.0 MiB 8300 boot
5 65536 163839 48.0 MiB 8300 rom
6 163840 262143 48.0 MiB 8300 bootdata
7 262144 1019903 370.0 MiB 8300 factory
8 1019904 2273279 612.0 MiB 8300 system
9 2273280 3145727 426.0 MiB 8300 cache
10 3145728 5242879 1024.0 MiB 8300 media
11 5242880 30535639 12.1 GiB 8300 userdata
Humm...wow, that's pretty crazy. Try writing zeroes to your emmc and then retrying.
# dd if=/dev/zero of=/dev/block/mmcblk0
Is there any way to re-partition ROM eMMC ? since /cache has 500 MB ,it can be re - partitioned to merge into /data partition . so any body here know how to re-partition ROM ? is it possible ?
Parted dump:
Code:
31 106824kB 117268kB 10445kB boot
32 117268kB 127795kB 10527kB recovery
33 127795kB 603980kB 476185kB ext4 cache
34 603980kB 1543504kB 939524kB ext4 system
35 1543504kB 1551892kB 8389kB kpan
36 1551892kB 3958768kB 2406875kB ext4 userdata
Since the "important" partitions are towards the end, something can well be done (as long as you have full OS installation media in zip or nandroid format, plus some tools which may not even be needed on this phone)... If you can wait a week I'll try to write a guide
After some testing, it appears to be impossible, like there is some S-ON on the partition table area...
full partition table needed please..
Ryccardo said:
Parted dump:
Code:
31 106824kB 117268kB 10445kB boot
32 117268kB 127795kB 10527kB recovery
33 127795kB 603980kB 476185kB ext4 cache
34 603980kB 1543504kB 939524kB ext4 system
35 1543504kB 1551892kB 8389kB kpan
36 1551892kB 3958768kB 2406875kB ext4 userdata
Since the "important" partitions are towards the end, something can well be done (as long as you have full OS installation media in zip or nandroid format, plus some tools which may not even be needed on this phone)... If you can wait a week I'll try to write a guide
Click to expand...
Click to collapse
Hey bro, could you please provide me a full partition table in that same format?