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?
Related
Can someone please dump the partition mmcblk0p34 for me?
Command
dd if=/dev/block/mmcblk0p34 of=/sdcard/misc.img
Then upload it to dropbox or something.
Scaryghoul said:
Can someone please dump the partition mmcblk0p34 for me?
Command
dd if=/dev/block/mmcblk0p34 of=/sdcard/misc.img
Then upload it to dropbox or something.
Click to expand...
Click to collapse
Hey guys, someone lend this guy a hand if you can. He has done a lot of great kernel work on the EVO Shift! I'd help you Scary but I don't have a computer here for the next few days. Are you going to be deving for the 3D now?
I'm going to do it right now.
UPDATE: Error, Error Error.....user error I'm sure. I will see about getting this for you before work, but my computer is acting a fool.
lol i just did that for you and was about to post a link to my dropbox and i remembered im unlocked...doh....sorry
ty080279 said:
lol i just did that for you and was about to post a link to my dropbox and i remembered im unlocked...doh....sorry
Click to expand...
Click to collapse
What about S-OFF, is that okay or are you refering to just the HTC Unlock?
I only want an S-ON dump, so you may need temp root to grab what I want.
@Paul - Something like that, but we'll see how things go.
I'm guessing that's my error. I'm not getting full access having S-On, and my bootloader is still locked. I don't trust HTC. I'm not used to not being rooted. I'm not sure how to temp root 1.5, or if we can. I've never done temp root.
PM me. My 3D is still fully stock. If you wanna help a bit I will get it for you.
p34, that's the misc partition isnt it? Are you going to try to edit the mainver in the misc partition and try to downgrade the 1.50 Hboot? If so it doesnt work :-/ both myself and IEF from alpharev tried and it was a no go.. If you know another way, I could do you one better than just the misc partition, I can give you ssh access to my linux box and have a evo 3d hooked up to it that's s-on hboot 1.50 I just need a day or two to get my friend's from him and I can only have it for a day or two but can have it connected to the linux box non stop during that time
graffixnyc said:
p34, that's the misc partition isnt it? Are you going to try to edit the mainver in the misc partition and try to downgrade the 1.50 Hboot? If so it doesnt work :-/ both myself and IEF from alpharev tried and it was a no go.. If you know another way, I could do you one better than just the misc partition, I can give you ssh access to my linux box and have a evo 3d hooked up to it that's s-on hboot 1.50 I just need a day or two to get my friend's from him and I can only have it for a day or two but can have it connected to the linux box non stop during that time
Click to expand...
Click to collapse
Basically exactly what you said, we found that out yesterday for the evo shift as a downgrade option so we could root phones that had the ota. Joeykrim had already told me it wouldn't work on the 3d, but I was still curious what was on the misc partition, I opened up the shift & thunder bolt misc partitions for the older hboot already.
Shift thread, but you already know.
http://forum.xda-developers.com/showthread.php?t=1255474
Hmm, that would be nice but alas, I do not know a better way.
How much do you know about hboot? More specifically, the misc partition's FN0C strings, and the way htc & sprint sign packages, and how hboot verifies the signature.
I'm curious about the 3d's hboot before it's cracked because every single hboot version locked and unlocked has two similar strings. FN0C.
So I'm wondering if these are used in the verification or keys of some sort. For example, in RSA encryption there is public and private keys, public which encrypts and private which decrypts(I may have these backwards as it's been a very long time since I've done any encryption/decryption). So an example of practical use on sprint/htc's part would be encrypting with a key, then hboot decrypting it with FN0C. Although every encryption set of keys need to be related in some way since you can't just decrypt anything with any key. So it'd give a base to try and brute force finding the other key, or give us more information with how hboot works. Brute forcing an RSA key is generally unrealistic because of the sheer amount of time it'd take, but it'd be a fun learning experience messing with hboot.
edit: Well after a long afternoon I found out that sprint/htc takes a zip, takes it's sha256 hash and then encrypts that hash using an RSA private key, then stuffs it in the first 256bytes of the zip. Then when hboot loads it, it shaves off those 256 bytes and attempts to decrypt it using a public key.
Even disassembled hboot(Not using an arm disassembler though, couldn't find one, but an x86 one gave me an interesting output)
Doesn't look like misc has anything to do with the RSA encryption or hoot signatures though.
We did find it funny that out of 4 misc partitions on 3 different phones, FN0C showed up at the EXACT same offset, but it's probably nothing worth looking into.
So to anyone trying to decrypt this or recreate sprint/htc's signature algorithm, good luck.
misc partition
Scaryghoul said:
Can someone please dump the partition mmcblk0p34 for me?
Command
dd if=/dev/block/mmcblk0p34 of=/sdcard/misc.img
Then upload it to dropbox or something.
Click to expand...
Click to collapse
How do you know that's the misc partition ?
I have a HTC EVO 3D GSM version and I don't have that partition :
# ls /dev/block
loop0 loop7 mmcblk0p14 mmcblk0p20 mmcblk0p27 mmcblk0p5 platform
loop1 mmcblk0 mmcblk0p15 mmcblk0p21 mmcblk0p28 mmcblk0p6 vold
loop2 mmcblk0p1 mmcblk0p16 mmcblk0p22 mmcblk0p29 mmcblk0p7 zram0
loop3 mmcblk0p10 mmcblk0p17 mmcblk0p23 mmcblk0p3 mmcblk0p8
loop4 mmcblk0p11 mmcblk0p18 mmcblk0p24 mmcblk0p30 mmcblk0p9
loop5 mmcblk0p12 mmcblk0p19 mmcblk0p25 mmcblk0p31 mmcblk1
loop6 mmcblk0p13 mmcblk0p2 mmcblk0p26 mmcblk0p4 mmcblk1p1
justexpect said:
How do you know that's the misc partition ?
I have a HTC EVO 3D GSM version and I don't have that partition :
# ls /dev/block
loop0 loop7 mmcblk0p14 mmcblk0p20 mmcblk0p27 mmcblk0p5 platform
loop1 mmcblk0 mmcblk0p15 mmcblk0p21 mmcblk0p28 mmcblk0p6 vold
loop2 mmcblk0p1 mmcblk0p16 mmcblk0p22 mmcblk0p29 mmcblk0p7 zram0
loop3 mmcblk0p10 mmcblk0p17 mmcblk0p23 mmcblk0p3 mmcblk0p8
loop4 mmcblk0p11 mmcblk0p18 mmcblk0p24 mmcblk0p30 mmcblk0p9
loop5 mmcblk0p12 mmcblk0p19 mmcblk0p25 mmcblk0p31 mmcblk1
loop6 mmcblk0p13 mmcblk0p2 mmcblk0p26 mmcblk0p4 mmcblk1p1
Click to expand...
Click to collapse
The partitions between the cdma and GSM are different. And this thread is long gone...
Sent from my PG86100 using XDA
I know this thread is very old, But I didn't see the point of making a new one with one different word in the title.
Can someone with an Unlocked CDMA phone upload the misc partition to dropbox. I seem to have either a corrupted or incorrectly formatted partition.
I'm pretty sure its
Code:
/dev/block/mmcblk0p34
Or at least thats what all the errors point me to that.
Code:
E/STT:mtd ( 7738): mtd_open(): cannot find MTD partition [misc]!
D/STT:emmc( 7738): found emmc partition [misc]=[mmcblk0p34]
E/DMAgent ( 7738): the page size is -1, return false
E/DMAgent ( 7738): check_nand_info return abnormal!
E/STT:mtd ( 7768): mtd_open(): cannot find MTD partition [misc]!
D/STT:emmc( 7768): found emmc partition [misc]=[mmcblk0p34]
E/DMAgent ( 7768): the page size is -1, return false
E/DMAgent ( 7768): check_nand_info return abnormal!
I Have decided that this thread has served it's purpose and will now be closed to future posts. Please direct and 'non' SHV-E160L post's to
Brixfix V2
Please can all Ongoing jobs/works migrate to the above thread.
-----------Final Notes--------------
It has been mentioned many times that i should go back and correct the information below, i started to correct a few post's then realized i was removing the flavour in change of colour and size, parts of this thread documents my mistakes, assumptions and general lack of understanding of how we NOOBS post on XDA, It's with that in mind that i have decided to leave the mistakes in, so you can see in writing what i gained from the support of other Devs here.
Now, if you are NOOB in anyway or have a few questions please click HELP
If you are bricked and need help, read this thread first, there is NO one CLICK solution for anything, even this mentioned device.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
So you Brixed/bricced/BOD/QDL/EDLOAD/QHS-USB/05c6:9008/05c6:9025/ your device? Need a Oil and brush , Need help, follow this
One, Rules
Two, Understanding
--------------------------------------------------------------------------
Tip From the Author,
Some of you may have noticed that i did not start the original thread with a question, I did something my mentor taught me at around 9 years old but didn't put into good use until much later in life.
The tip is write things down as a question for yourself, in the writing process you get to pass the information past the part of your brain that interprets information, virtual sounding board, before posting as a question for others.
--------------------------------------------------------------------------
New Tools for debricking, goto
Brixfix V2
---------------------------Further Info Info -----------------------------
** I have Since Fixed the device and developed soultions for non shv-e160l devices. Prior posts are undergoing edit's for corrections.
** if you want the glory shot, sorry you will just have to read through.
** If you are selling this as a solution, dont. I know who you are.
---------------------------Original Post-----------------------------
Hi All
As i mentioned on this thread http://forum.xda-developers.com/showthread.php?p=32231827#post32231827 i will be attempting to come up with a home grown debrick solution for a SHV-E160L samsung note from korea.
I will use the forum to document what i am doing, i am very new to this so correct me please if i am wrong. I have never done Android dev work at any time but i have a very good understanding of the logic behind it all. `
Things i Have :-
Phone ( SHV-E160L)
bus pirate v3 with jtag firmware
openocd compiled on ubuntu and centos 6
smd jtag adapter and relay wire ( magnetic wire)
things i still need :-
openocd target config file for MSM8660 Snapdragon cpu (and a better understanding of eMMC access, how to load boot loaders either into ram or eMMC or trigger fail over boot to sc-card, USB via software or X0M/Boot pins)
assembled jtag (it's the smallest soldering i've ever seen)
.PIT file for 32GB model (if someone could pull the .PIT file from a working unit I would be happy, specify your radio/kernel versions when uploading)
micro fine solder iron tip and 20w iron (i've got 60w but too high for this type of work)
Does anyone have a idea of the SD-CARD partition layout, files for snapdragon devices, google has given me much for other devices but not a snapdragon .
Another question, I've used the USB jig to trigger 301K mode USB-Factory and seen no activity in dmesg for usb devices, i've yet to try windows, does windows/linux behave in a different way when it comes to usb , as in windows see's the qualcom usb mode but not linux ? does the usb client device always start the comms?
using the 615K usb jig i get nothing too, no pbl message from samsung (hence i am led to think is's the pbl/sbl thats damaged)
My understanding up boot is as follows
iROM code
This loads basic settings to boot the PBL (iROM is in rom) the PBL is loaded into radio(modem) cpu and then loads the SBL(s)
PBL/SBL stored in eMMC at address ????? (need to document the address for the masked access to eMMC and jtag/openocd access unmasked access)
Once the SBL is loaded you with have the ODIN mode (USB/UART)
from what i can see of commercial JTAG boxes is the access the radio cpu via jtag, write a new PBL/SBL to the eMMC then halt/reset cpu which now loads the new bootloaders, (resurrect dead body)
The openocd TAP id for the cpu should be 0x105310E1 but thats a number i got from a riff box log, not any actual testing ( still need to solder the fine pitch connector)
Here is a log from a riff box, not sure if the address's are usable accross to opencd
Taken from gsm-forums:-
Open serial port...OK
Connecting to the RIFF Box...OK
Firmware Version: 1.33, JTAG Manager Version: 1.44
Selected Resurrector: [Samsung E160K V1.0.4535.7001]
Connecting to the dead body...OK
Detected dead body ID: 0x105310E1 - IGNORED!
Set I/O Voltage reads as 1.79V, TCK Frequency is RTCK
Adaptive Clocking RTCK Sampling is: [Sample at MAX]
Resurrection sequence started.
Establish communication with the phone...OK
Initializing internal hardware configuration...OK
Uploading resurrector data into memory...OK
Starting communication with resurrector...OK
Detected an Initialized FLASH1 Chip, ID: 0x0015/0x0000 (KTS00M, 0x0003AB400000 Bytes = 14.68 GB)
Detected an Initialized FLASH2 Chip, ID: 0x0015/0x0000 (KTS00M, 0x000000200000 Bytes = 2.00 MB)
Flashing the dead body...OK
Resurrection complete!
Click to expand...
Click to collapse
I did notice one thing, the riff box opens the serial port, i wonder if they load PBL+SBL into memory, reset the cpu, then using the serial connection activate download mode ? (like on the captive)
I also dont know how the cpu (jtag TAP id? ) and flash variables translate accross to openocd as ive not found a target config file yet ( or my searching is wrong)
in the full stock Firmware I was able to extract the .tar file which contained,
Code:
amss.bin <-- application cpu boot files ?
boot.img <-- kernel/initrd ramdrive
mdm.bin <-- modem cpu boot files
recovery.img <--- recovery image
system.img.ext4 <---- rest of the system applications
so i think we have the two cpu firmware/boot loaders in the .bin files, these bin files are just fat32 images, to access in ubuntu use
Code:
mount -o loop mdm.bin /mnt/mdmmountlocation
My guess is my first approach is getting the right PBL/SBL into the system and getting some feed back via uart, i have the jtag pinouts and further reserach says there is a UART2 on the jtag header, so when soldering up my jtag adapter i will include all pins if i can and sniff for serial logic, i happen to have a Open source logic sniffer, great tool as i do a lot of hacking into serial devices like scales and till printers .
back to topic.
When i do get to the jtag part at a minimum i should have access to the modem radio, afaik jtag devices connect in chains and most of the IC's that have jtag on the phones board all should link to the master device (i am thinking it's the modem cpu, no application) and that the Two cpu's share the eMMC memory some how, or it could be one cpu loads it into the other (it is connected via jtag down the chain) .
hopefully someone could correct me there.
Most of this is theory and my guess work, correct me if you find a mistake. most of the research is only over a few days too so i am far from finished there, does not help that most of the users speak a language that google translate just does not have a flair for.
Most of the info seems to suggest the modem cpu is the first inline so i decided to look further into the files there, notice the mdm.bin file is 23Mb, thats large, when mounted i notice the is a folder called 'image' ( amms.bin has folder called IMAGE , note the case difference, dont yet know whay)
in image folder we have :-
Code:
1.3M Sep 30 13:07 AMSS.MBN
35K Sep 30 13:07 DBL.MBN
2.2M Sep 30 13:07 DSP1.MBN
19M Sep 30 13:07 DSP2.MBN
40 Sep 30 13:07 EFS1.MBN
40 Sep 30 13:07 EFS2.MBN
40 Sep 30 13:07 EFS3.MBN
295K Sep 30 13:07 OSBL.MBN
Ah, i see amss.mbm , that must be the boot loader for the application cpu, DBL.MBM seems to be the PBL , OSBL.MBM could be the SBL
then there is the DSP/EFS files, I did do the command strings on all the files,
DBL.MBM does not have any text in the file that points to being able to do UART on boot, all text seems internal like pointers and references to the original build files e.g
Code:
D:\Q1LGT_MDM\MDM9600\modem_proc\core\boot\secboot2\dbl\target\mdm9x00\src\dbl_ddr.c
9x00B-SCAQSVZM-31613102
D:\Q1LGT_MDM\MDM9600\modem_proc\core\boot\secboot2\dbl\target\mdm9x00\src\dbl_sahara.c
but it also does contain data like this
Code:
auth_image
@[email protected]
@configure_hw
@flash_init
l0:eek:SBL
load_osbl_img
@DBL, Start
hw_init
so it looks more likley that dbl is first in the chain, it refers to loading osbl and configure hardware, i wonder if it means USB/UART at this stage or setting up ram and other GPIO's
in OSBL.MBM we have more interesting text
Code:
MbP?
Unable to attached to ChipInfo DAL
SAMSUNG
TOSHIBA
Flash: Failed to do initialization for probe!
ONFIx
0:ALL
Flash: Multi 2X page read not supported!
Flash: Multi 2X page write not supported!
boot_qdsps
OSBL
hw_init
hw_init_secondary
OSBL, Start
create_vector_table
ram_init
retrieve_shared
clobber_add_protection
mmu_flush_cache
OSBL, End
OSBL, Delta
osbl_sahara_load_amss
osbl_sahara_load_dsp1
osbl_sahara_load_dsp2
osbl_sahara_load_ramfs1
osbl_sahara_load_ramfs2
osbl_sahara_load_ramfs3
smem_boot_init
so it is looking more and more like DBL then SBL which then loads all of the other parts , also if you notice EFS1/2/3 are all tiny 40byte files, now i see why, they are loaded as ram-drives, so i assume those file set out the basic EFS file system in the ram.
again from research the boot stages are often counted as 3, i am assuming the real first part is in rom of the cpu (is this what triggers the qualcom download mode ) that loads DBL from eMMC and chain loads SBL
Now looking around the riff forums i see the list the info in a different way
Code:
Partition 0
SBL1
SBL2
Partition 1
RPM
SBL3
eMMC APPSBoot
TZ
.PIT
Click to expand...
Click to collapse
TZ i think is Trusted Zone
RPM - Power manager ?
now how this translates to file name from full flash and to mmcblk0p1 partitions i have yet to find out, i still dont have a .PIT file from a 32gb model
More updates to come,
regards
DarkSpr1te
CPU Boot order updates
So my digging has taken me back round to some of me early searching which i forgot about , hardware level seems to support the qualcom usb mode, but it can be disabled by manufacturer, so even if you find a resistor to the BOOT_CONFIG GPIO and ground it , it still may not work, and you could toast your board. once the qfuse is gone for that track, the maker can now use the gpio for anything else, it no longer controls the iROM branch choice ( CPU:do i start usb first or last?), it my thinking that on the first board sent out by the designers for a final production run ( those first public devices) they keep the option open to print off DEV models by changing the resistors/value of while the hardware stays same, not to be confused with dev board, that is pin/track simlar but is used to design the software mainly, sometimes hardware debug but as you change the hardware between the dev platform and production this is less helpful, google new.intrinsyc.com and apq8060, they produce a dev board that is the same as the device we hold, but everything is broken out for testing so don't expect to see this left in a bar for you to e-bay.
EDIT:
Above I refer to a dev phone and dev board, these are SURF and FFA, FFA is form factor accurate and SURF is Subscriber Unit Reference.
Here is the link, http://forum.xda-developers.com/showthread.php?t=1856327
Now from what i see, it's the same(edit:simlar) X0M pin setup as other phones, ground the right pin, reverse boot order, but this maybe two pins in the snapdragon,
[copied from other link]
Simplified table:
Code:
------------------------------------------------------------------
BC[5:0] Mapping
------------------------------------------------------------------
0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001 SDC3 followed by SDC1 (eMMC)
0b00010 SDC3 followed by SDC2 (if used)
0b00011 SDC1 (eMMC)
Click to expand...
Click to collapse
So if 0b00000 is EM boot and the docs say the the two gpio's that control this (if qfuse not blown) are taken high then it's 0b00011, so grounding those two resistors should give us 0b00000 or EM boot, the cpu docs also say they are internally grounded, the schematic says the voltage goes throught a 10k resistor, so grounding that side of the resistor that 'goes' to the cpu should change the boot order, but before trying this out, remember if you get the live side of the resistor the is no resistor between your probe and ground, that full current, short, blown, no more johnny 5.
Have you managed to unbrick the E160L?
darkspr1te said:
So my digging has taken me back round to some of me early searching which i forgot about , hardware level seems to support the qualcom usb mode, but it can be disabled by manufacturer, so even if you find a resistor to the BOOT_CONFIG GPIO and ground it , it still may not work, and you could toast your board. once the qfuse is gone for that track, the maker can now use the gpio for anything else, it no longer controls the iROM branch choice ( CPU:do i start usb first or last?), it my thinking that on the first board sent out by the designers for a final production run ( those first public devices) they keep the option open to print off DEV models by changing the resistors/value of while the hardware stays same, not to be confused with dev board, that is pin/track simlar but is used to design the software mainly, sometimes hardware debug but as you change the hardware between the dev platform and production this is less helpful, google new.intrinsyc.com and apq8060, they produce a dev board that is the same as the device we hold, but everything is broken out for testing so don't expect to see this left in a bar for you to e-bay.
Here is the link, http://forum.xda-developers.com/showthread.php?t=1856327
Now from what i see, it's the same(edit:simlar) X0M pin setup as other phones, ground the right pin, reverse boot order, but this maybe two pins in the snapdragon,
[copied from other link]
Simplified table:
Code:
------------------------------------------------------------------
BC[5:0] Mapping
------------------------------------------------------------------
0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001 SDC3 followed by SDC1 (eMMC)
0b00010 SDC3 followed by SDC2 (if used)
0b00011 SDC1 (eMMC)
So if 0b00000 is EM boot and the docs say the the two gpio's that control this (if qfuse not blown) are taken high then it's 0b00011, so grounding those two resistors should give us 0b00000 or EM boot, the cpu docs also say they are internally grounded, the schematic says the voltage goes throught a 10k resistor, so grounding that side of the resistor that 'goes' to the cpu should change the boot order, but before trying this out, remember if you get the live side of the resistor the is no resistor between your probe and ground, that full current, short, blown, no more johnny 5.
Click to expand...
Click to collapse
I think my E160L got a real brick today after I tried to flash a modified Rom downloaded from a Chinese forum. It can not be powered on after rebooting (installed successfully). I desperately need advice now on how to deal with it.
Jeff_GTA said:
I think my E160L got a real brick today after I tried to flash a modified Rom downloaded from a Chinese forum. It can not be powered on after rebooting (installed successfully). I desperately need advice now on how to deal with it.
Click to expand...
Click to collapse
Do you have any backups like nandroid ? does the 3 button boot still work ?
Regards
Have you looked into using ort-jtag. It's only about $150 (USD).
I've been looking into this myself for low-level debugging/bootloader development on SGH-T959V and SGH-I717.
All three of these devices are supported by ort-jtag and have header connectors for the jtag pins.
So I'm also getting some of these from digi-key, and making a small receptacle, much like in AdamOutler's captivate bootloader development thread. (search for k-ww)
Again, ort-jtag does support the SHV-E160L. (search that link for SHV-E160L)
PBL Dump - I think
So ive been doing some tests.
I think i managed to dump the PBL
i dumped memory and a strings search return this
Code:
pbl_error_handler.c
pbl_flash_nand.c
pbl_flash.c
dload.c
pbl_flash_nand.c
pbl_flash_onenand.c
pbl_auth\secboot_rsa_math.c
pbl_error_handler.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_mc.c
pbl_mc.c
pbl_error_handler.c
and
Code:
qhsusb\src\dci\qhsusb_dci.c
}^PBL_DloadVER1.0
!8}^
}]^}^
Q`omm
z8}]
DEBUG
SW_ID
OEM_ID
pbl_flash_onfi.c
pbl_flash_nand.c
pbl_flash_sflashc.c
pbl_loader.c
pbl_flash_sdcc.c
pbl_auth.c
pbl_auth\secboot.c
pbl_auth\secboot_x509.c
QUALCOMM COPYRIGHT 2009BOOT ROM VERSION: 1.4QHSUSB VERSION: 00.00.08
BOOT ROM AUTHOR: DHAVAL PATEL
07 0000 SHA1
does any one want the dump that can reverse it ?
Dumps & execute address
I also need the help of other SHV-E160? owners, i need dumps from working phones, i managed to create a 8660_msimage.mbn and flashed it, but i was using i717 bootloaders and i dont think they will work, i need working dumps from working phones, starting with partition table layout, sbl1.mbn and sbl2.mbn
Does anyone know if the is is correct
SBL1 exec address 0x2A000000
SBL2 exec address 0x2E000000
as i can upload the sbl to 0x2a000000 but not the sbl2 to 0x2e000000
i can also upload the tz.mbn to 0x2a020000
i am trying to use sec boot 3 based call stack but am unsure of the real exec values
Ive seen in another post these values
"
It looks like ours deviates slightly from this.
If the headers are to be believed,
TZ is loaded at 0x2A000000
SBL3 is loaded at 0x8FF00000
APPSBL/aboot is loaded at 0x88E00000
"
the post is
http://forum.xda-developers.com/showpost.php?p=30057296&postcount=243
it does explain why i cant load into 0x2e000000
Progress
So today i made real progress, I have been able to flash a basic program to allow me to access the EMMC, i have taken a full backup and now i need to start scanning the dump for need information,
I still need help from other users so please if you are will to provide me dumps of your working device that would help me a great deal
So Part One is a sucess, I have been able to flash my own code and power on the galaxy note. next step is rebuilding the emmc partition tables, testdisk can find the partitions but is not alowing me to write a non standard partition table (which emmc seems to be formatted with)
Thanks
darkspr1te
help QPST Software Download
Hi,
I'm stuck with the same problem can you tell me what image you use to the phone. I stuck here. I' m really don't know what to do?
Thank you for your help.
tyllerdurdent said:
Hi,
I'm stuck with the same problem can you tell me what image you use to the phone. I stuck here. I' m really don't know what to do?
Thank you for your help.
Click to expand...
Click to collapse
First thing i must say is dont flash your phone just yet!! walking blindly into this could render your phone useless due to certain data being lost for good.
if you still wish to continue i will upload a basic guide and files. My method is still in development, it has many bugs ( i flashed the phone with i717 roms, working, SHV-E120 roms, working, N7000 rom complete fail)
But first some questions,
Which model phone is it?
what happened to get you to the point of needing the flash ? ( i ask so i can trace why the bricks are happening and hopefully fix it)
thank you for your help, I will be waiting your method and your files.
Thank you so much for your help.
My phone is a samsung galaxy note SHV-E160L korean version.
what happen was:
I tried to upgrade the firmware with kies and suddenly the program crash. My phone enter in an error issue with the firmware and said use emergency recovery mode.
I tried the recovery several times (uninstalling kies and install it again but that never work).
So, I download odin and this files to restore the original firmware:
CSC - GT-N7000-MULTI-CSC-OZSLPF.tar.md5
Phone - MODEM_N7000XXLR1_REV_05_CL1144476.tar.md5
Bootloader- N7000_APBOOT_N7000ZSLPF_CL558430_REV02_user_low_sh ip.tar.md5
PDA - N7000_CODE_N7000ZSLPF_CL558430_REV02_user_low_ship .tar.md5
Pit for 16GB - Q1_20110914_16GB.pit
I connect my phone and try to install the firmware again, but odin fail and my samsung became a nice brick.
The phone currently does not turn on, the phone is in download mode and I install QPST and the program recognize the system in download mode.
I want to try your method because other information I collected said that I have to send it to guarantee.
Can I install i717 rom in the E160L?
I will be waiting for your post because sincerely I don't know how to repair it.
Thank you so much.
Hello darkspr1te
First of all, nice work there (though I didn't understood most of the things there, but seems there is some good work going on on our SHV-E160's
On your comment;
( i flashed the phone with i717 roms, working, SHV-E120 roms, working, N7000 rom complete fail)
Does that mean that i717 roms can work on the SHV-E160 devices? Please share if that is the case.
The geeky bits
tyllerdurdent said:
Thank you so much for your help.
My phone is a samsung galaxy note SHV-E160L korean version.
what happen was:
I tried to upgrade the firmware with kies and suddenly the program crash. My phone enter in an error issue with the firmware and said use emergency recovery mode.
I tried the recovery several times (uninstalling kies and install it again but that never work).
So, I download odin and this files to restore the original firmware:
CSC - GT-N7000-MULTI-CSC-OZSLPF.tar.md5
Phone - MODEM_N7000XXLR1_REV_05_CL1144476.tar.md5
Bootloader- N7000_APBOOT_N7000ZSLPF_CL558430_REV02_user_low_sh ip.tar.md5
PDA - N7000_CODE_N7000ZSLPF_CL558430_REV02_user_low_ship .tar.md5
Pit for 16GB - Q1_20110914_16GB.pit
I connect my phone and try to install the firmware again, but odin fail and my samsung became a nice brick.
The phone currently does not turn on, the phone is in download mode and I install QPST and the program recognize the system in download mode.
I want to try your method because other information I collected said that I have to send it to guarantee.
Can I install i717 rom in the E160L?
I will be waiting for your post because sincerely I don't know how to repair it.
Thank you so much.
Click to expand...
Click to collapse
Ok, as i said it's still a work in progress at the moment.
I used the i717 bootloaders (thats why we have a brick as it's not getting to the aboot loader or little kernel as some other refer to it) and E160 modem and application cpu as my first target is getting odin mode back.
I was able to also use the E120 bootloaders (screen was messed up though )
I've just got home from a very long shift so i will do a full and clear write up ( STILL a work in progress ) tomorrow (20th)
but i will explain the basic now as you do need to download large files before we continue.
First you need to download the same firmware as you were originally on before the brick, The reason is because between versions i suspect there is minor changes in partition tables (that why the n7000 roms brick )
If you dont have the latest QPST (2.7.3xx or higher ) please google for it now, there are many sites that offer it. (links will folllow tomorrow)
also down load :-
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00.tar (or tar.md5 )
i717-GB-Modem.tar (or .md5)
now my initital work was based off a chinese link for the A820L
http://blog.csdn.net/su_ky/article/details/7773273
To save you the time of many hours of translation and cross reference here is the quick run down
When the phone is in QDLoad mode its because the PBL (Stored in ROM , read only memory) could not start SBL1 or SBL2 , it stores the error in IRAM location 0x3FF18 and then goes to QDLoad fail mode. At this point it has tried uart, sd-card before hand and those failed too.
IRAM is the small built in memory of the MSM8660 CPU, it has not initiated the main SYSTEM ram yet so our memory space ro running code is 87k and 256k (refer to document 8960_boot_architecture.pdf found the unlock bootloaders section.
Now because our partition table and or our bootloaders are damaged (or we have emmc brick bug) we have to rewrite that data again to revive our bricks.
This is where it gets hard, and where my warnings now come into play.
right now you must think of the EMMC chip (its the name for the internal SD-CARD we boot from and store our normal data, imei and all the other data of the system, it is just a sc-card with better security for our purpose)
This emmc chip holds all of you settings for phone function and we must not loose that,
But...
we have to write data to the chip to boot again, I am not fully aware of all the memory locations so this is assumptions on my part.
we are going to write a basic bootloader that turns the whole phone into a sd-card, then write new bootloaders
using QPST we upload 8660_msimage.mbn (its a out of the box emmc factory image) this file is ment for setting up of dev versions of the phone, it made up of the following parts
sector 0 partition table or (partition0.bin AFTER patching with info from patch0.xml) I do not have a real copy of the original of this, it can be pulled from a working SVH-E160x using the code at the end.
after the MBR (which is the first part of the partiton make up, EBR follows, we can have 3 primary partitions and the fourth is a extended which is just another partiton table pointing to the next EBR and so on, upto 29 parititons i think)
anyway, after the MBR is SBL1, which chainloads SBL2 then that side loads RPM, gets a go signal then loads SBL3, when SBL3 is done most of the device hardware has been mapped into the cpu's memory table, SDRAM is now ready for larger code,
aboot now loads
some of the above loading functions occur at the same time and some wait on go signals from other code in other CPU's and some fail due corruption and or security check fails( JTAG users can watch the memory as it changes and halt, change data and continue which is why JTAGers's have more power , we dont have loader outputting data yet so no feed back, hence the brick)
when aboot is loaded we now have access to odin, so thats the goal, get aboot loaded for now who cares about the rest of the funtions.
we do need to care about those function later so thats why we will backup the entire system, i dont know if this will really work when restored and bring back all of our settings, thats later,
So onto the writing and possibly overwriting of important information, WARNING, i dont know yet if we are overwriting imei or simalr data yet so proceed at your own risk.
We will get the required from factory (qualcomm test or dev board not samsung factory in the box for consumer) from the MUI phone firmware
http://bigota.d.miui.com/QDN43/Mioneplus_QDN43_fastboot_Android_4.0_d3d83nmdk2.zip
from this zip we want 8660_msimage.mbn, patch0.xml, partition0.bin MPRG8660.hex ( this file is uploaded first, its a serial bootloader that is loaded at 0x2a000000 (start of PBL IRAM space 256k in size) and that setups a emmc to command access (we use revskill to upload the same file and dump memory , sadly ive not found a way of pulling the entire emmc to a backup, if we can figure that out we can pull the entire boot chain, fix it and send it back with what ever versions we desire, for now revskill is used to read the PBL error so we can at least see why we cant boot, not quite jtag but best we got ))
so now we have a phone running a basic bit of code that allows us to use code sent to serial port to write (possibly read) the emmc
we then use QPST to write the 8660_msimage.mbn as a one to one copy to the very start of the emmc , reboot phone and then when the phone restarts, it sets up the ram, some hardware (charging system, you will now notice your phone gets warmer that before when plugged in) and gives us direct access to the emmc as if it was a sd-card
at this point you could move the phone to any pc and it's just a sd-card branded qualcomm
BUT at this point the pc or any other computer you connect it too only see's the partition table contained in the 8660_msimage.mbn file , you other data is there so i advise the next step you MUST do.
connect the phone to a linux computer (use a live cd or live usb if you are not a normal linux user)
you will then run the following command
Code:
dd if=/dev/sd? of=/mount/location/shv-e160-full-emmc.bin bs=512
? is the letter of the drive , use dmesg and look for sdb or sdc , if you dont understand this part then i would suggest waiting for a possible script/one click solution. right now i am still booting only 1 in 20 boots and do not yet know why the boots fail and why some work.
of=/mount... this is where you will place the entire 16GB (32GB for 32gb models ) which should be a one to one copy of the system
the bs=512 is very important, it's block size, again, if you dont understand then maybe wait.
Thats enough for now, i am going to spend a hour or two working on some theories i came up with today.
user with working phones, please google how to backup parts of your phone, this may happen to you so it's best to backup asap !!!
from the blog.csd site a script to grab the partition table data, if a working usr could please run this and post the file, it does not contain user data only the partiton table and a direct 1 to 1 restore for any phone, i think it possible to write that direct back to a QDLoad mode phone, re write the bootloaders from linux and bingo working phone. i dont have backups as it's not my phone, it belongs to a client who knows i like to tinker with electronics.
anyway, once i have the partition file i can overlay it on my test phone (which i can activate QSLoad at any time, hence it's unbrick-able dev mode)
once the partition file is written to my phone, i can build a script to backup your important data, write known working bootloaders, and reboot the phone into a usable device.
here is the script in python (user linux live cd with a copy of adb, just google adb linux pack, there is a windows and linux allin one pack)
or you can get the original from the link above, i've not tested this as i dont have a device in adb mode but i've read through it and it looks sound but never tested by me.
Well i hope that enlightens you, am sorry i dont have a all in one solution for you, it's still a dev project and most of the information i have has only been collected over the past week, i only discovered it's QSDload after getting a msm8660 schematic and i still dont know what i am trully shorting out to trigger the QSDload when ever i want, even when it's booted
If any one from the unbrickable project(s) want to get in touch to share info i would be happy, i am also sure this is a usable solution for HTC phones as well
oh and one last thing
i read only a hour ago (via cell phone while in a car so not 100%) that once the phone is in QSDload and stays in QSDload on every power cycle then we can write the partition table to a SD-CARD and it will boot that, i have not tested that yet, i will try and see if the 8660_msimage.mbn file written to a sd-card works
I also suspect that some of my good boots have been when i've mixed up the sdcard with system.img.ext4 etc on it with the one with just update.zip on it. it's one my list of things to check , any suggestions are welcome as to how i correctly format the card (heads,cylinders, block size etc)
ok folks, hope this helps
COPY TEXT BELOW ONLY INTO A FILE AND RUN WITH PYTHON (linux is easier, may be possible to use a vm box, i am but linux is my main os and windows is the vm)
Code:
import os
from struct import *
def mbr():
global offset, partitions
os.popen("adb shell su -c 'dd if=/dev/block/mmcblk0 of=/cache/partition0.bin bs=512 count=1'").close()
os.popen("adb shell su -c 'cp /cache/partition0.bin /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
f = open("partition0.bin", 'rb')
data = f.read()
f.close()
partitions = [ ]
n=0
while True:
buf = data[446+(16*n):446+(16*(n+1))]
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
partition['type'] = "MBR"
n += 1
partition['no'] = n
partitions.append(partition)
if partition['id'] == 5:
offset = partition['start']
break
def ebr():
global offset, partitions
n = 0
while True:
a = 0
os.popen("adb shell su -c 'dd if=/dev/block/mmcblk0 of=/cache/ebr bs=512 count=1 skip=" + str(offset+n) + "\'").close()
n += 1
os.popen("adb shell su -c 'dd if=/cache/ebr of=/cache/partition0.bin bs=512 count=1 seek=" + str(n) + "'").close()
os.popen("adb shell su -c 'cp /cache/ebr /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
f = open("partition0.bin", 'rb')
data = f.read()
f.close()
while True:
buf = data[446+16*a:446+16*(a+1)]
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
if partition['id'] == 5:
break
if partition['id'] == 0:
return
partition['type'] = "EBR"
partition['no'] = n
partition['start'] += n-1+offset
partitions.append(partition)
a += 1
if __name__ == "__main__":
mbr()
ebr()
os.popen("adb shell su -c 'cp /cache/partition0.bin /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
for part in partitions:
print "%s %2i, Boot: 0x%02X, Id: 0x%02X, Start: 0x%08X (%8i), Size: 0x%08X (%8i, %8i KB)" % (part['type'], part['no'], part['boot'],part['id'], part['start'], part['start'], part['size'], part['size'], part['size']/2)
Click to expand...
Click to collapse
beginning
thank you for your help,
I currently have the qpst version 2.7 build 373. You think is enough of download the same version of Chinese post QPST.2.7.374.rar
I will begin to download the other files required and I will be commenting my progress.
Thank you so much for your help, i really appreciate that you share you r knowledge.
Requests
While i try some theories if othe users could possibly provide me with :-
Original partition table via script above and also via adb
use
adb and run
Code:
cat /proc/partitions > /sdcard/partitions.txt
fdisk -l /dev/block/mmcblk0 > /sdcard/fdisklist.txt
mount > /sdcard/mountlist.txt
Then on the pc side using ADB again do the following
Code:
adb pull /sdcard/partitions.txt
adb pull /sdcard/fdisklist.txt
adb pull /sdcard/mountlist.txt
and post those files.
there are many posts on it so wont repeat but later will add a link.
along with some spell checks :laugh:
if you can dump the boot loaders from a original e160x too as my data started currupt.
i also need to talk to someone who can assist me in writing a program to take the pit file and turn it into this
Code:
<?xml version="1.0" ?>
<data>
<!--NOTE: Sector size is 512bytes-->
<program file_sector_offset="0" filename="" label="SMD_HDR" num_partition_sectors="65536" physical_partition_number="0" size_in_KB="32768.0" start_sector="1"/>
<program file_sector_offset="0" filename="sbl1.mbn" label="SBL1" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="65537"/>
<program file_sector_offset="0" filename="sbl2.mbn" label="SBL2" num_partition_sectors="3000" physical_partition_number="0" size_in_KB="1500.0" start_sector="66537"/>
<program file_sector_offset="0" filename="rpm.mbn" label="RPM" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="69559"/>
<program file_sector_offset="0" filename="sbl3.mbn" label="SBL3" num_partition_sectors="4096" physical_partition_number="0" size_in_KB="2048.0" start_sector="70559"/>
<program file_sector_offset="0" filename="aboot.mbn" label="ABOOT" num_partition_sectors="5000" physical_partition_number="0" size_in_KB="2500.0" start_sector="74655"/>
<program file_sector_offset="0" filename="" label="BOOT" num_partition_sectors="20480" physical_partition_number="0" size_in_KB="10240.0" start_sector="79655"/>
<program file_sector_offset="0" filename="tz.mbn" label="TZ" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="100135"/>
<program file_sector_offset="0" filename="partition0.bin" label="MBR" num_partition_sectors="1" physical_partition_number="0" size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin" label="EXT" num_partition_sectors="22" physical_partition_number="0" size_in_KB="11.0" start_sector="69537"/>
</data>
Click to expand...
Click to collapse
*edit
the partiton0.bin provided below is 8.5kb (.5kb MBR, 8kb EBR) and in raw_program0.xml bove it say 0.5kb and 11kb, making that file 11.5kb, i dont know if the A810 has larger or smaller EBR than us, it could be they pulled extra, in my reading of the dumps i've seen lots of padded 0's after files (between sbl2/ebr/rpm) anyway if you just copy paste it will throw a error, ive got it set at 0.5 and 8.
EDIT:- Do not use this file, ive uploaded newer files later on.
some of the questions i need to answer are :-
1. what is the first partition, it's dos, around 105mb and labled smd_hdr and is filled with smd_hdr.bin (or mbn)
2. what are the real sector locations of the files, above you will see the rawpartiton0.xml file, this tells QPST where in the emmc to put the data num_partiton_sectors does match data from the pit files, but i dont know the real offsets yet, (samsung or htc could put the rest of the partiton table in cpu qfuse data areas and not write it to the emmc to confuse us and write the real files to another location and use the pit file as a base+offset calculation)
start_sector is the real location on the emmc, where it starts writing the file.
at the end is partiton locations(its a generic file containing the first few byes of default partition table, patch0.xml then updates this data), i dont have our device specific figures yet, i also dont fully understand patch0.xml and the difference in figures used.
if we have a backup of each of the different version of android partitons we could just write that in replacement of partiton0.bin and we dont need patch0.xml, this file sole job to alter the generic files, oem's have the choice of changing this data.
Code:
<?xml version="1.0" ?>
<patches>
<!--NOTE: This is an ** Autogenerated file **-->
<!--NOTE: Patching is in little endian format, i.e. 0xAABBCCDD will look like DD CC BB AA in the file or on disk-->
<!--NOTE: This file is used by Trace32 - So make sure to add decimals, i.e. 0x10-10=0, *but* 0x10-10.=6.-->
<patch byte_offset="506" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
<patch byte_offset="506" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
<patch byte_offset="458" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="16" value="NUM_DISK_SECTORS-1695744." what="Update final partition with actual size."/>
<patch byte_offset="458" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="208816" value="NUM_DISK_SECTORS-1695744." what="Update final partition with actual size."/>
</patches>
Click to expand...
Click to collapse
please note that it's two lines of the same code except one is partition0.bin and the other is DISK,
Do we need both? i know if i dont add the partiton0 section used in raw_program.xml then the drive is blank in linux,
now it's my understanding that the ebr comes as the forth partiton and it point to the next one , above in patch0.xml it start at NUM_DISK_SECTORS-1695744
i am still trying to better understand these figures,
Well time to grab coffee, i guess it's a dev night in.
the file MPRG8660.HEX can be renamed EMMCBLD.HEX and it triggers QPST to always look for a QDLoad mode phone and not debug, you can place all the files you need in one folder, i advise you to keep the originals in one location and only extract what your need to your worrking folder, copy emmcswdowload.exe from the QPST folder there too, we might need to do command line work, ive read that you can pre-create images in emmcswdownload (the same way 8660_msimage.mbn was created ) that you could just drop onto a phone once it's in emmc sd-card mode, almost a one click.
More info, plus help offered
Your welcome tyllerdurdent,
I am going to be putting a few hours into the dev from now actually for if you want assistance then no problems,
I also advise the following, download ubuntu live cd, it has a lot of tools your going to need to extract data you require, if we go step by step we might be good, i did a lot of test writing before i got my first boot, and that again only happens one in 20, i dont know why.
the rawpartiton0.xml above is incorrect for our devices as it states the first partion is 32mb, (i think it's ment to be amss.mbn, or NON-HLOS.mbn , our pit file which i did extract from my emmc dump says it's 105mb. i am confused and to why rawpartiton0.xml says the first bootloader is at start_sector="65537" but fdisk shows it as start 204801, i think someone needs to show me how to convert from blocks to sectors,
in patch0.xml it says
Code:
<patch byte_offset="506" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
Click to expand...
Click to collapse
208801 is where we have our ebr start,
i also think the IROM based pbl, sbl etc use the partition types in some way, why else have so many types? can any one explain that
this is a fdisk view of what i think our partition table looks like
Code:
Device Boot Start End Blocks Id System
/dev/sdb1 1 204800 102400 c W95 FAT32 (LBA)
/dev/sdb2 * 204801 205800 500 4d QNX4.x
/dev/sdb3 205801 208800 1500 51 OnTrack DM6 Aux1
/dev/sdb4 208801 208801 0 5 Extended
/dev/sdb5 212992 213991 500 47 Unknown
/dev/sdb6 221184 225279 2048 45 Unknown
/dev/sdb7 229376 234375 2500 4c Unknown
/dev/sdb8 237568 258047 10240 48 Unknown
/dev/sdb9 262144 263143 500 46 Unknown
/dev/sdb10 270336 271335 500 5d Unknown
/dev/sdb11 278528 279527 500 91 Unknown
/dev/sdb12 286720 307199 10240 93 Amoeba
/dev/sdb13 311296 511999 100352 c W95 FAT32 (LBA)
/dev/sdb14 516096 522239 3072 4a Unknown
/dev/sdb15 524288 530431 3072 4b Unknown
/dev/sdb16 532480 538623 3072 58 Unknown
/dev/sdb17 540672 741375 100352 8f Unknown
/dev/sdb18 745472 751615 3072 59 Unknown
/dev/sdb19 753664 759807 3072 5a Unknown
/dev/sdb20 761856 29843455 14540800 5b Unknown
/dev/sdb21 770048 790527 10240 ab Darwin boot
/dev/sdb22 794624 815103 10240 60 Unknown
/dev/sdb23 819200 839679 10240 94 Amoeba BBT
/dev/sdb24 843776 3911679 1533952 a5 FreeBSD
/dev/sdb25 3915776 8114175 2099200 a6 OpenBSD
/dev/sdb26 8118272 8736767 309248 a8 Darwin UFS
/dev/sdb27 8740864 9005055 132096 a9 NetBSD
/dev/sdb28 9011200 10035199 512000 95 Unknown
/dev/sdb29 10035200 30777343 10371072 90 Unknown
Oh, download wxdhex or wimlar program, you going to need a hex editor that can load BIG files , 16gb worth
i717-GB-Modem.zip IS THE SAME AS TAR?
i717-GB-Modem.zip 21.35 MB 7 0 2012-06-30 08:45:11
I could not find the i717-gb as tar file but I find it as a zip file. but I'm not sure about thif the contents are correct. Could you check
http://d-h.st/1aP
i717-GB-Modem.zip contents
META-INF
COM
GOOGLE
ANDROID
update-binary
updater-script
TMP
amss.bin
mdm.bin
Blocks and sectors
This may explain it , the different figure in the xml files
Because sectors are logical on the drive (Logical Block Addressing = LBA) you need to convert between LBA and physical (file system) sectors. This is pretty easy to do:
First - get a table of the start and end sectors of the partition table:
Code:
[[email protected] ~]# fdisk -lu /dev/hda
Disk /dev/hda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 63 208844 104391 83 Linux
/dev/hda2 208845 4401809 2096482+ 83 Linux
/dev/hda3 4401810 8482319 2040255 82 Linux swap
/dev/hda4 8482320 234436544 112977112+ 5 Extended
/dev/hda5 8482383 29447144 10482381 83 Linux
/dev/hda6 29447208 50411969 10482381 83 Linux
/dev/hda7 50412033 52516484 1052226 83 Linux
/dev/hda8 52516548 234436544 90959998+ 83 Linux
Use this to determine what partition the bad sector is in. In this case 232962120 is inside the start and end values for /dev/hda5
NOTE: This is in partition 5 - ignore partition 4 as it is the extended partition. Any block from partitions 5 through 8 will also be in partition 4, but you want the real partition, not the extended partition.
Next, calculate the file system block using the formula:
b = (int)((L-S)*512/B)
where:
b = File System block number B = File system block size in bytes (almost always is 4096) L = LBA of bad sector S = Starting sector of partition as shown by fdisk -lu and (int) denotes the integer part.
For example:
The reported sector from the smart log above is 232962120, thus:
((14858312 - 8482383) * 512) / 4096 = 796991.125
^Bad Sec. ^Start Sec. ^Cha Ching! This is the sector!
(Use the block number from the smart test section, not from the smart error log section. They are using different methods of reporting file system vs. physical blocks.)
((BadBLock - StartPartition) * 512) / 4096
You can just paste this into Google as a template
Any fraction left indicates the problem sector is in the mid or latter part of the block (which contains a number of sectors). Ignore the fraction and just use the integer.
Next, use debugfs to locate the inode and then file associated with that sector:
Click to expand...
Click to collapse
[[email protected]]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /dev/hda5
debugfs: icheck 796991
Block Inode number
796991 <block not found>
debugfs: quit
Ah! It didn't give the inode! It if did, you could have found the file with:
[[email protected]]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /dev/hda5
debugfs: icheck 796991
Block Inode number
796991 41032
debugfs: ncheck 41032
Inode Pathname
41032 /S1/R/H/714197568-714203359/H-R-714202192-16.gwf
So what the heck? Why no inode? Well, remember how it said the sector might be bad?
Click to expand...
Click to collapse
the above copied from
http://timelordz.com/wiki/SMART_Rewriting_Bad_Sectors
i have a feeling we may need to shift our files (the basic files need to start odin are listed in rawpatch0 above, i dont know if that 100% true but it was the only files i wrote on by first sucess)
also
http://forum.xda-developers.com/showthread.php?p=31843525&postcount=13
in the above link they talk about the header of the qualcomm file
+------------+
|Dbl-preamble|
+------------+
|Dbl-header |
+------------+
|Dbl.bin |
+------------+
Click to expand...
Click to collapse
and
data_ptr = autodetectpage;
*data_ptr = sbl_header.codeword;
data_ptr++;
*data_ptr = sbl_header.magic;
data_ptr++;
*data_ptr = AUTODETECT_PAGE_SIZE_MAGIC_NUM;
Click to expand...
Click to collapse
now i used this in a way to find my bootloaders (i717 by this time, not shve-160l )
and to find the partitons
you will see in a hex editor at the start of each boot loader
something else to think about, my lack of success that last two days to produce a boot could be because my partitons are not clean , thats is to say if i write my sbl1 to 1000, and the trailing 0000 of the partition definition of my 99 block ebr/mbr ends at 999 , if i have dirt data between 999 and 1000 the cpu/pbl my interpret that as code(some of my boots is brick, some are into QDLoad, i have no pattern yet) , something i must test or confirm, or just worry about.
tyllerdurdent said:
i717-GB-Modem.zip 21.35 MB 7 0 2012-06-30 08:45:11
I could not find the i717-gb as tar file but I find it as a zip file. but I'm not sure about thif the contents are correct. Could you check
http://d-h.st/1aP
i717-GB-Modem.zip contents
META-INF
COM
GOOGLE
ANDROID
update-binary
updater-script
TMP
amss.bin
mdm.bin
Click to expand...
Click to collapse
Yes thats correct
updater script btw contains text, binary is the flashing exe i think,
Code:
run_program("/sbin/dd", "if=/tmp/mdm.bin", "of=/dev/block/mmcblk0p17");
run_program("/sbin/dd", "if=/tmp/amss.bin", "of=/dev/block/mmcblk0p13");
Click to expand...
Click to collapse
and a google of a simlar sansung product the skyrocket gives me a simlar pit layout
Device Name Size Part Name ODIN tar file Mount Point
mmcblk0boot0 512KB (empty) n/a (empty partition)
mmcblk0boot1 512KB (empty) n/a (empty partition)
mmcblk0p1 100MB SMD_HDR (partition info)
mmcblk0p2 500KB SBL1 sbl1.mbn
mmcblk0p3 1500KB SBL2 sbl2.mbn
mmcblk0p4 1KB (unnamed partition with '55 AA' MBR signature)
mmcblk0p5 500KB RPM rpm.mbn
mmcblk0p6 2MB SBL3 sbl3.mbn
mmcblk0p7 2500KB ABOOT aboot.mbn
mmcblk0p8 10MB BOOT boot.img
mmcblk0p9 500KB TZ tz.mbn
mmcblk0p10 500KB SSD n/a (empty partition)
mmcblk0p11 500KB PIT celox.pit
mmcblk0p12 10MB PARAM param.lfs
mmcblk0p13 98MB MODEM amss.bin /system/etc/firmware/misc
mmcblk0p14 3MB MSM_ST1 efs.img
mmcblk0p15 3MB MSM_ST2 n/a
mmcblk0p16 3MB MSM_FSG n/a
mmcblk0p17 98MB MDM mdm.bin /system/etc/firmware/misc_mdm
mmcblk0p18 3MB M9K_EFS1 efsclear1.bin
mmcblk0p19 3MB M9K_EFS2 efsclear2.bin
mmcblk0p20 3MB M9K_FSG n/a
mmcblk0p21 10MB DEVENC enc.img.ext4 /efs
mmcblk0p22 10MB RECOVERY recovery.img
mmcblk0p23 3MB FOTA n/a
mmcblk0p24 598MB SYSTEM system.img.ext4 /system
mmcblk0p25 2GB USERDATA userdata.img.ext4 /data
mmcblk0p26 302MB CACHE cache.img.ext4 /cache
mmcblk0p27 129MB TOMBSTONES tomb.img.ext4 /tombstones
mmcblk0p28 11.2GB UMS ums.rfs /mnt/sdcard
Click to expand...
Click to collapse
Other files
contents of the i717 boot loaders i used
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00
Code:
527K Jan 6 2012 aboot.mbn
115K Jan 6 2012 rpm.mbn
72K Jan 6 2012 sbl1.mbn
111K Jan 6 2012 sbl2.mbn
601K Jan 6 2012 sbl3.mbn
117K Jan 6 2012 tz.mbn
other files pulled from
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00 (no bootloader but all the other system files )
I tried using kingo root, both on the phone and on the computer. I am not sure where to proceed from there. The main reason I want to root is to disable the startup sound, which does not get disabled automatically when I have my phone on mute. I tried using the sound disabler app from the play store, and it seems to not be working (the startup sound still plays).
Rooting Coolpad Canvas (Cricket)
Me too having same issue as well, tried kingoroot
And king-root some got to like 30%... need help rooting it as well.. and maybe twrp would be great
But possibly could flash twrp using the coolpad's
Note 3 twrp for it, because they both have same
Resolution and screen size i believe, so for the porting shouldn't be all that hard.. any advice
Would be great..
Coolpad Canvas Root
joshglen said:
I tried using kingo root, both on the phone and on the computer. I am not sure where to proceed from there. The main reason I want to root is to disable the startup sound, which does not get disabled automatically when I have my phone on mute. I tried using the sound disabler app from the play store, and it seems to not be working (the startup sound still plays).
Click to expand...
Click to collapse
SmartPhoneDeveloper said:
Me too having same issue as well, tried kingoroot
And king-root some got to like 30%... need help rooting it as well.. and maybe twrp would be great
But possibly could flash twrp using the coolpad's
Note 3 twrp for it, because they both have same
Resolution and screen size i believe, so for the porting shouldn't be all that hard.. any advice
Would be great..
Click to expand...
Click to collapse
I just ordered a coolpad canvas its coming on Saturday. I was able to root my last phone (Alcatel Onetouch Flint) which had no official guides on how to root it (so i made a guide). I might be able to do the same thing with this phone ill let u guys know if im able to root it when it comes.
Casey Campanile said:
I just ordered a coolpad canvas its coming on Saturday. I was able to root my last phone (Alcatel Onetouch Flint) which had no official guides on how to root it (so i made a guide). I might be able to do the same thing with this phone ill let u guys know if im able to root it when it comes.
Click to expand...
Click to collapse
Awesome!.. you won't believe how good this phone is for the price it has pretty powerful specs for the price and screen size is a whopping 5.5 inch and HD, I got mine for 49.99 when it was available at walmart luckily they had 2 left in Stock the day I went and got one.. but yeah I been trying to root it with no luck , but I'm not that good at programming when it comes to phones hopefully we can get this one rooted at least if anything .. it definitely deserves it being decently powerful phone here's the specs on it.. : https://ibb.co/ehJjtQ
Guys I was able to pull over 70% of the system files from it.. but for some reason it stops at when trying to pull WCNSS_qcom_cfg.ini file for some reason-(said permission was denied)??..hmm.., I will post pic shortly..
Any luck Casey on it?.. so far nothing working for rooting it yet you may have better luck than me..
SmartPhoneDeveloper said:
Any luck Casey on it?.. so far nothing working for rooting it yet you may have better luck than me..
Click to expand...
Click to collapse
No luck yet I tried kingroot, kingo app, towelroot, framaroot and some others nothing works. Still searching for a better method
So apparently it's harder to root nougat cuz of this new security feature. I feel like one click methods not gonna work
Well I also noticed when doing command get ver all that it said secured eMMc with the little kernel bootloader I'm sure there are ways around this but its going to require some help with someone that has higher phone developing skills than of my own of course.. also try command while connected to computer "adb pull system" without the quotes it got to 72% for me before it wouldn't write no more still have the files for system if anyone needs them for rewriting or porting in the bootloader ..
---------- Post added at 03:55 AM ---------- Previous post was at 03:43 AM ----------
Casey Campanile said:
No luck yet I tried kingroot, kingo app, towelroot, framaroot and some others nothing works. Still searching for a better method
Click to expand...
Click to collapse
Same here.. hmm , well if you or you can invite someone that maybe can port in or rewrite the little kernel bootloader to be unlocked, i have 72% of the system files.. still couldn't Figure out how to or where to extract the boot.img or recovery.img from?.. or the cache.img and the other .img files as well.. some of them or the .sh file in the system folder i extracted i believe may contain the answer?.. I'm sure for the rewriting of the bootloader but it's gonna require someone with better skills than of mine because i don't know how to rewrite little kernel bootloader image, but I'm sure for some this is a breeze though lol...
Oh almost forgot , from the building prop editor, i also managed to get the recovery key ID as well of someone knows how to port or rewrite the recovery.img, i know this will be of big help for sure this is the recovery key ID for the recovery image , i will post the pic of it shortly..
SmartPhoneDeveloper said:
Same here.. hmm , well if you or you can invite someone that maybe can port in or rewrite the little kernel bootloader to be unlocked, i have 72% of the system files.. still couldn't Figure out how to or where to extract the boot.img or recovery.img from?.. or the cache.img and the other .img files as well.. some of them or the .sh file in the system folder i extracted i believe may contain the answer?.. I'm sure for the rewriting of the bootloader but it's gonna require someone with better skills than of mine because i don't know how to rewrite little kernel bootloader image, but I'm sure for some this is a breeze though lol...
Click to expand...
Click to collapse
The mount points for where to pull the .img files from can't you find them by running cat /proc/mounts? These are the locations I got:
Interesting... so with these mount points I'm assuming we should be able to do something I'm sure of it considering the zte zmax pro which also is qualcomm snapdragon processor and also utilizing same procedure of sorts and they managed to make twrp for it and also root so I'm sure same here ...which they some how put it into diagnostic mode or called **DFU mode and it allowed them to flash after mounting points was made with Linux OS
---------- Post added at 02:13 AM ---------- Previous post was at 02:11 AM ----------
Also we you could possibly use also called QPST tool for Windows allows flashing of qualcomm processors as well ...
SmartPhoneDeveloper said:
Interesting... so with these mount points I'm assuming we should be able to do something I'm sure of it considering the zte zmax pro which also is qualcomm snapdragon processor and also utilizing same procedure of sorts and they managed to make twrp for it and also root so I'm sure same here ...which they some how put it into diagnostic mode or called **DFU mode and it allowed them to flash after mounting points was made with Linux OS
---------- Post added at 02:13 AM ---------- Previous post was at 02:11 AM ----------
Also we you could possibly use also called QPST tool for Windows allows flashing of qualcomm processors as well ...
Click to expand...
Click to collapse
Managed to get exact locations of each partition by running cat /proc/partitions and then running df to convert them into the common names. Here's what I got:
cp3636a:/ $ cat /proc/partitions
major minor #blocks name
254 0 524288 zram0
179 0 15267840 mmcblk0
179 1 102400 mmcblk0p1
179 2 1 mmcblk0p2
179 3 8 mmcblk0p3
179 4 512 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 2048 mmcblk0p8
179 9 2048 mmcblk0p9
179 10 256 mmcblk0p10
179 11 256 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 2048 mmcblk0p13
179 14 2048 mmcblk0p14
179 15 32 mmcblk0p15
179 16 2048 mmcblk0p16
179 17 16 mmcblk0p17
179 18 4096 mmcblk0p18
179 19 20480 mmcblk0p19
179 20 65536 mmcblk0p20
179 21 3072 mmcblk0p21
179 22 3072 mmcblk0p22
179 23 65536 mmcblk0p23
179 24 65536 mmcblk0p24
179 25 1024 mmcblk0p25
179 26 262144 mmcblk0p26
179 27 32768 mmcblk0p27
179 28 1024 mmcblk0p28
179 29 512 mmcblk0p29
179 30 32 mmcblk0p30
179 31 65536 mmcblk0p31
259 0 32 mmcblk0p32
259 1 1024 mmcblk0p33
259 2 1024 mmcblk0p34
259 3 32768 mmcblk0p35
259 4 512 mmcblk0p36
259 5 4096 mmcblk0p37
259 6 384 mmcblk0p38
259 7 384 mmcblk0p39
259 8 384 mmcblk0p40
259 9 384 mmcblk0p41
259 10 256 mmcblk0p42
259 11 256 mmcblk0p43
259 12 256 mmcblk0p44
259 13 256 mmcblk0p45
259 14 8 mmcblk0p46
259 15 65536 mmcblk0p47
259 16 2928640 mmcblk0p48
259 17 10876911 mmcblk0p49
179 32 4096 mmcblk0rpmb
179 64 7761920 mmcblk1
179 65 16384 mmcblk1p1
179 66 7744495 mmcblk1p2
253 0 2882924 dm-0
253 1 10876895 dm-1
253 2 7744495 dm-2
cp3636a:/ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 866276 5212 861064 1% /
tmpfs 947448 616 946832 1% /dev
tmpfs 947448 0 947448 0% /mnt
/dev/block/dm-2 7622740 879764 6726592 12% /mnt/expand/ad6a771b-2b4f-4d99-8f6d-640bb1ebd212
/dev/block/dm-0 2792600 2109896 666320 76% /system
/dev/block/bootdevice/by-name/cache 253920 368 248312 1% /cache
/dev/block/bootdevice/by-name/dsp 12016 5052 6640 44% /dsp
/dev/block/bootdevice/by-name/modem 102352 69776 32576 69% /firmware
/dev/block/dm-1 10574084 4527048 6030652 43% /data
/dev/fuse 7622740 879764 6726592 12% /storage/emulated
cp3636a:/ $
---------- Post added at 04:54 PM ---------- Previous post was at 04:50 PM ----------
SmartPhoneDeveloper said:
Interesting... so with these mount points I'm assuming we should be able to do something I'm sure of it considering the zte zmax pro which also is qualcomm snapdragon processor and also utilizing same procedure of sorts and they managed to make twrp for it and also root so I'm sure same here ...which they some how put it into diagnostic mode or called **DFU mode and it allowed them to flash after mounting points was made with Linux OS
---------- Post added at 02:13 AM ---------- Previous post was at 02:11 AM ----------
Also we you could possibly use also called QPST tool for Windows allows flashing of qualcomm processors as well ...
Click to expand...
Click to collapse
So using the location I tried to use the dd command to pull system.img but it said permission denied looks like it requires root:
dd if=/dev/block/dm-0 of=/storage/emulated/0/system.img
dd: /dev/block/dm-0: Permission denied
1|cp3636a:/ $
Don't know a whole lot about development but I'm pretty comfortable with using the Android back end and I'd be willing to help any way I can if there's something I can do or provide. This is such a neat little phone and I think it has a lot of potential.
Picked a canvas up on sale at bestbuy as a back up.. I must say its a nice phone for the money...
Now I just have to wait for coolpad- cricket to release unlock codes so I can use overseas travel.
Try this root
joshglen said:
I tried using kingo root, both on the phone and on the computer. I am not sure where to proceed from there. The main reason I want to root is to disable the startup sound, which does not get disabled automatically when I have my phone on mute. I tried using the sound disabler app from the play store, and it seems to not be working (the startup sound still plays).
Click to expand...
Click to collapse
Hi bro.. Try this root.. I tried in my coolpad canvas cricket but this root is only temporary because I have not found twrp to install super us..
https://forum.xda-developers.com/android/development/guide-to-root-coolpad-note-5-flashing-t3637644
Carzacamil said:
Hi bro.. Try this root.. I tried in my coolpad canvas cricket but this root is only temporary because I have not found twrp to install super us..
https://forum.xda-developers.com/android/development/guide-to-root-coolpad-note-5-flashing-t3637644
Click to expand...
Click to collapse
Here is a link to a TWRP build for the Redmi 4a, same exact internals as our phone. I mean the phones are exact all the way across the board. The best thing to do is to fastboot boot the .img first to see if it works 100%, and being on Nougat flash su systemless root. If it boots to TWRP from fastboot and you can flash su than we should be able to permanently flash TWRP from there. https://forum.xda-developers.com/android/development/recovery-twrp-3-1-0-0-xiaomi-redmi-4a-t3576024
zMILWAUKEE said:
Here is a link to a TWRP build for the Redmi 4a, same exact internals as our phone. I mean the phones are exact all the way across the board. The best thing to do is to fastboot boot the .img first to see if it works 100%, and being on Nougat flash su systemless root. If it boots to TWRP from fastboot and you can flash su than we should be able to permanently flash TWRP from there. https://forum.xda-developers.com/android/development/recovery-twrp-3-1-0-0-xiaomi-redmi-4a-t3576024
Click to expand...
Click to collapse
i tried it but my cellphone is bootloop .. when i do fastboot it says:
Now send the package you want to apply
to the device with "adb sideload <filename>". . .
Finding update package. . .
opening update package. . .
Verifing update package. . .
E:failed to verify whole-file signature
Update package verification took 0.7 s (result 1)
E:signature verification failed
Installation aborted.
Carzacamil said:
i tried it but my cellphone is bootloop .. when i do fastboot it says:
Now send the package you want to apply
to the device with "adb sideload <filename>". . .
Finding update package. . .
opening update package. . .
Verifing update package. . .
E:failed to verify whole-file signature
Update package verification took 0.7 s (result 1)
E:signature verification failed
Installation aborted.
Click to expand...
Click to collapse
From what you're describing it sounds like you didn't do it correctly. In the bootloader it should never ask you to sideload anything. The correct steps are, with the phone on and adb debugging enabled, adb devices, should show your connected to your phone, next adb reboot bootloader, phone will restart into a download type screen, next step, on PC type fastboot devices to see if the PC and phone are communicating correctly, next is to type fastboot boot recovery.img, if it boots into the TWRP we're good, sorry but I don't have a PC up and running right now. So all I can do is suggest and hope you guys can get it running.
Anyone check into this and the comment that's on it, don't know if it will help, but just maybe.
https://mobile.twitter.com/srsroot/status/871056445315452933?lang=en
meatball702 said:
Anyone check into this and the comment that's on it, don't know if it will help, but just maybe.
https://mobile.twitter.com/srsroot/status/871056445315452933?lang=en
Click to expand...
Click to collapse
Don't do it, it's bull crap nothing but viruses. That srs spam link says they can root all phones, well if they could more devs on XDA would push it, but no it's a load of b.s.
Rooted T-Mobile varriant.
Couldn't get Boombox to load.
Realized it is not supposed to work for my phone.
Went into TWRP.
Started a format on pretty much everything I could select.
4 hours later into my exfat format, I start thinking, yeah, this is... not... this is too long. I've destroyed it. SO, just to be sure it was a paperweight, I turned it off. Mid format... of every selectable partition in TWRP.
So anyway, it boots to fastboot now, and if I try to boot it into download mode, it starts TWRP but never loads. I put TWRP on my LAF partition as the root guide for H932 recommended it. The irony.
I CAN use ADB when I attempt to get the phone into download mode. Again, it does not actually have download mode, but instead a broken TWRP that never actually loads. The CLI TWRP found in sbin also will not actually start either.
If anyone could help me repartition this back to the point where I flash normal boot.img/system.img/recovery.img etc, well that would be, a godsend.
I will do, or answer any questions.
I do not know linux, but despite behavior that warrants wearing a helmet when I leaving the house, I promise I am competent enough to fix this, with some help.
Thanks people
--Edit--
cat /proc/partitions
major minor #blocks name
1 0 8192 ram0
1 1 8192 ram1
1 2 8192 ram2
1 3 8192 ram3
1 4 8192 ram4
1 5 8192 ram5
1 6 8192 ram6
1 7 8192 ram7
1 8 8192 ram8
1 9 8192 ram9
1 10 8192 ram10
1 11 8192 ram11
1 12 8192 ram12
1 13 8192 ram13
1 14 8192 ram14
1 15 8192 ram15
8 48 8192 sdd
8 49 2048 sdd1
8 50 4 sdd2
8 51 8 sdd3
8 64 286720 sde
8 65 40960 sde1
8 66 41472 sde2
8 67 41472 sde3
8 68 2048 sde4
8 69 2048 sde5
8 70 4096 sde6
8 71 4096 sde7
8 72 512 sde8
8 73 512 sde9
8 74 512 sde10
8 75 512 sde11
8 76 512 sde12
8 77 512 sde13
8 78 128 sde14
8 79 128 sde15
259 0 112640 sde16
259 1 512 sde17
259 3 512 sde18
259 4 512 sde19
259 6 512 sde20
259 7 512 sde21
259 9 512 sde22
259 11 512 sde23
259 12 512 sde24
259 14 512 sde25
259 15 512 sde26
259 17 1024 sde27
259 18 1024 sde28
259 20 4 sde29
259 22 1024 sde30
259 23 8192 sde31
259 25 128 sde32
259 26 128 sde33
259 27 8 sde34
8 96 8192 sdg
8 97 2048 sdg1
8 98 8 sdg2
8 80 8192 sdf
8 81 2048 sdf1
8 82 2048 sdf2
8 83 512 sdf3
8 84 8 sdf4
8 0 62103552 sda
8 1 49152 sda1
8 2 49152 sda2
8 3 32768 sda3
8 4 10240 sda4
8 5 6144 sda5
8 6 1024 sda6
8 7 32768 sda7
8 8 16384 sda8
8 9 8192 sda9
8 10 40960 sda10
8 11 67584 sda11
8 12 512 sda12
8 13 512 sda13
8 14 512 sda14
8 15 512 sda15
259 2 512 sda16
259 5 32768 sda17
259 8 8192 sda18
259 10 24576 sda19
259 13 2048 sda20
259 16 6465536 sda21
259 19 1253376 sda22
259 21 54000080 sda23
259 24 4 sda24
8 16 32768 sdb
8 17 3584 sdb1
8 18 4096 sdb2
8 19 2048 sdb3
8 20 1024 sdb4
8 21 1024 sdb5
8 22 8 sdb6
8 32 8192 sdc
8 33 3584 sdc1
8 34 8 sdc2
179 0 31166976 mmcblk0
179 1 31165952 mmcblk0p1
If ADB is indeed working, have you tried reflashing twrp to the LAF n' seeing if that does anything to get you back to a working recovery?
ls -al /dev/block/platform/soc/1da4000.ufshc/by-name
send output of this with adb shell
---------- Post added at 08:29 AM ---------- Previous post was at 08:24 AM ----------
4 hours later into my exfat format, I start thinking, yeah, this is... not... this is too long. I've destroyed it. SO, just to be sure it was a paperweight, I turned it off. Mid format... of every selectable partition in TWRP.
By exfat format, what do you mean?
the easiest would be to adb dd / push the laf partition back and work with it then, means: write laf, boot into dl mode, flash kdz. should work :good:
btw: which recovery version do you use? for determining which partitions were erased.
next time: formatting *only* needed for the main partitions, which are boot (not formattable) and system. don't touch any other partition mext time pls (at least in terms of formatting)
I don't have time to post the details, but right now you can fix your phone using dd. If you wipe out what you currently have thinking download mode will save you .. it might, but it might not and then you are stuck.
Gimme a bit to type up exactly what you need to do before you make it worse.
-- Brian
Renwark-Zipper said:
So anyway, it boots to fastboot now, and if I try to boot it into download mode, it starts TWRP but never loads. I put TWRP on my LAF partition as the root guide for H932 recommended it. The irony.
Click to expand...
Click to collapse
"I put TWRP on my LAF partition as the root guide for H932 recommended it. The irony."
Yeah, the only thing that literally saved you right now......
GI, you messed up your device, then blame the dev for a suggestion that will help you.....
Sent from my LG-H932 using XDA Labs
wow, so many partitions.
anyways, the "HIDE" button or use of HIDE tags is how you create spoilers and the pound sign or CODE tags is for code:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Ends up coming out like this:
hidden text here
or for code inside of hide:
Code:
hidden text here
BROKEN1981 said:
"I put TWRP on my LAF partition as the root guide for H932 recommended it. The irony."
Yeah, the only thing that literally saved you right now......
GI, you messed up your device, then blame the dev for a suggestion that will help you.....
Sent from my LG-H932 using XDA Labs
Click to expand...
Click to collapse
Reading titles is fun. It says "I'm the big dumb" right at the top. Notice the "I'm" that stand for "I AM". Translation: I'm not blaming the dev for anything, I AM THE ONE WHO DID THIS, THE ENTIRE POST OUTLINES MY STUPIDITY. The ironic part is I flashed over the download mode. Ya know, the one that lets you plug it into the computer and simply reflash with LGUP. If download mode was on the phone, this post wouldn't exist. End of story. I fully agree with his recommendation to have it on there, which is why I did it. The FACT, that it turned out to be the thing holding me back from fixing the phone was IRONIC.
sneak310 said:
wow, so many partitions.
anyways, the "HIDE" button or use of HIDE tags is how you create spoilers and the pound sign or CODE tags is for code:
Ends up coming out like this:
hidden text here
or for code inside of hide:
Code:
hidden text here
Click to expand...
Click to collapse
You're awesome, thanks!
I reported my own thread because I did not realize I cannot simply delete it myself. Do you know how to get this post deleted? I fixed the problem, but to be honest I can not remember all of the steps I took to do so. If someone finds themselves in a similar situation it might be nice to have this thread here, but as far as I am concerned I can be removed.
seadersn said:
the easiest would be to adb dd / push the laf partition back and work with it then, means: write laf, boot into dl mode, flash kdz. should work :good:
btw: which recovery version do you use? for determining which partitions were erased.
next time: formatting *only* needed for the main partitions, which are boot (not formattable) and system. don't touch any other partition mext time pls (at least in terms of formatting)
Click to expand...
Click to collapse
This is what I did! This works!
TWRP-3.2.3-7-DataIMG.img was the exact recovery used.
JohnFawkes said:
ls -al /dev/block/platform/soc/1da4000.ufshc/by-name
send output of this with adb shell
---------- Post added at 08:29 AM ---------- Previous post was at 08:24 AM ----------
4 hours later into my exfat format, I start thinking, yeah, this is... not... this is too long. I've destroyed it. SO, just to be sure it was a paperweight, I turned it off. Mid format... of every selectable partition in TWRP.
By exfat format, what do you mean?
Click to expand...
Click to collapse
I went into the wipe tab of TWRP and thought it would be a super idea to select everything I could, then change the file system to exFAT.
I'm... not sure what in the world I was hoping to actually accomplish with this. I had it in my head that If I formatted everything to one format, then back to the original, It might be a quick fix to my never booting custom rom.
It was not quick, and it was not thought through.
BrandonB1218 said:
If ADB is indeed working, have you tried reflashing twrp to the LAF n' seeing if that does anything to get you back to a working recovery?
Click to expand...
Click to collapse
I did try that, It did not work.
What seadersn outlined in his post is route I took to repair. Quite simple actually, I just did not really know what I was doing.
Renwark-Zipper said:
You're awesome, thanks!
I reported my own thread because I did not realize I cannot simply delete it myself. Do you know how to get this post deleted? I fixed the problem, but to be honest I can not remember all of the steps I took to do so. If someone finds themselves in a similar situation it might be nice to have this thread here, but as far as I am concerned I can be removed.
Click to expand...
Click to collapse
Nope, they don't let you delete threads here.
Renwark-Zipper said:
Reading titles is fun. It says "I'm the big dumb" right at the top. Notice the "I'm" that stand for "I AM". Translation: I'm not blaming the dev for anything, I AM THE ONE WHO DID THIS, THE ENTIRE POST OUTLINES MY STUPIDITY.
The ironic part is I flashed over the download mode. Ya know, the one that lets you plug it into the computer and simply reflash with LGUP. If download mode was on the phone, this post wouldn't exist. End of story. I fully agree with his recommendation to have it on there, which is why I did it. The FACT, that it turned out to be the thing holding me back from fixing the phone was IRONIC.
Click to expand...
Click to collapse
There is nothing wrong with pointing out differences of opinion over flashing duplicate/redundant TWRP to over the partition that has download mode and thus deletes download mode. I disagree with doing that, as do some developers in this forum. Not going to bother posting quotes, as I'm not starting an argument. Has been discussed in depth in the TWRP thread. However, other respected people recommend it, and they have their reasons. Looking the history of that suggestion, it really seems to be tied to T-mobile variants for reasons I don't wish to delve into here, but which I concede may be relevant to those T-mobile models.
Regardless, in my opinion it's not needed for most people and then when you DO suddenly need download mode, it's not there. The opposite point of view is "If you have TWRP, why would you ever need download mode?" I can think of a few instances... and their response would be, "Then (if/when you need it) re-flash the partition to get download mode!"
So, it's up to the users themselves to determine the priority of their needs and what likelihood will be for disaster recovery, one way or the other -- needing extra copy of TWRP vs needing download mode. There's no right or wrong answer.
Renwark-Zipper said:
The ironic part is I flashed over the download mode. Ya know, the one that lets you plug it into the computer and simply reflash with LGUP. If download mode was on the phone, this post wouldn't exist. End of story. .
Click to expand...
Click to collapse
Congratulations on not knowing what you are talking about. I think you can STFU now.
Sent from my LG-H932 using XDA Labs
I bricked my phone (XT2041-1 "sofiar") by flashing an unnoficial build of TWRP 3.5.0 downloaded from a Telegram channel by doing:
$ fastboot flash recovery_a twrp-3.5.0-0-rav-sofia.img
$ fastboot flash recovery_b twrp-3.5.0-0-rav-sofia.img
$ fastboot reboot recovery
Since then, my phone is hard bricked - won't boot, recognized on Linux in EDL Mode only (i.e. ID 05c6:9008).
I got the latest official stock firmware, named SOFIAR_RETAIL_11_RPES31.Q4U-47-35-12_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip, from lolinet, and in its contents there's boot.img and recovery.img (among others).
I have qdl on my Arch Linux, and am wondering whether I can use it to flash the stock recovery image back to both slots and get my phone booting again.
How should I approach it?
P.s. I also got a blankflash from https://forum.xda-developers.com/t/...equest-solicitud-blankflash-g8-power.4431193/ that is supposed to get the phone working again, but am unsure whether using it will cause loss of data.
I absolutely cannot lose any data from internal storage.
Any help appreciated. Thanks in advance.
Ok, now we're rolling...
First things first. Motorola sucks because they only give you restricted Firehose loaders.
That means of the 70-odd partitions that you have you can only read/write about 1/3 of them using EDL.
If you post your Firehose loader I can tell you which ones you can read/write.
Second, are you sure that the only damage you did was by writing recovery_a and recovery_b?
And you're on Linux, *sad face*.
I was disassembling the Motorola Firehose for my Moto G (2021) and I discovered that they have more reboot options than stock.
There's reset-to-edl and reset-to-fastboot.
I've added those options to my edl.exe (in the sig) this morning. You need to download the very latest.
What may have happened is that you wrote a bad recovery which may have set the boot option in the BCB or misc.
Since the recovery is good enough to be recognized as an image but not good enough to reset this boot option you're stuck.
Your first recourse is flashing a proper recovery.
I'm not sure whether "blank flash" tries to wipe everything. In any case I wouldn't risk it.
Your first try should be to fix the broken things, not everything.
Yes, any edl client that supports ad-hoc xml should be able to get you to fastboot but I'll only answer for my code.
I've tested it.
Code:
C:\>edl /lwhatever.bin
C:\>edl /zf
C:\>fastboot flash recovery_a good_recovery.img
C:\>fastboot flash recovery_b good_recovery.img
C:\>fastboot reboot
I admit to not properly understand what a firehose loader is. :x
Second, are you sure that the only damage you did was by writing recovery_a and recovery_b?
Click to expand...
Click to collapse
Yes, 100%.
So, for now, I should try booting Windows, installing the 9008 driver and following your instructions... Will let you know how it goes.
Thanks a lot.
marc.2377 said:
I admit to not properly understand what a firehose loader is. :x
Click to expand...
Click to collapse
A Firehose loader is a replacement xbl/sbl secondary loader that has special sauce added to it to make it interactive.
It is not to be confused with a Windows driver (which, in this case is Zadig, as per the instructions on my web page).
In this case, your Firehose loader is packed in singleimage.bin in the RPE here: https://mirrors.lolinet.com/firmware/motorola/sofiar/blankflash/
I extracted it for you. I renamed it sofiar.bin
The extension name does not matter.
Code:
C:\>edl /lsofiar.bin
That's slash-ell-sofiar.bin
Edit: And yes, your Firehose loader has the reset-to-fastboot.
Right, thanks for the explanation. I figured that was programmer.elf from my files.
Ok, I got as far as:
> edl /l
Found EDL 9008
Serial: 69cccc95
HWID: 0010a0e102e80000, QC: 0010a0e1, OEM: 02e8, Model: 0000
Hash: 974359c4290cac7f-9f0dc9a802815b5e-2b376b7a7c1be92c-1e816b5287f18610
> edl /lsofiar.bin
Found EDL 9008
Resetting Sahara
Serial: 69cccc95
HWID: 0010a0e102e80000, QC: 0010a0e1, OEM: 02e8, Model: 0000
Hash: 974359c4290cac7f-9f0dc9a802815b5e-2b376b7a7c1be92c-1e816b5287f18610
Sending sofiar.bin 100% Ok
Waiting for Firehose... Ok
> edl.exe /zf
Found EDL 9008
Requesting reset to fastboot... Ok
But it doesn't boot to fastboot.
It seems to me that your tool, edl could be used to write the recovery partition directly, no?
I tried this:
> edl /w /precovery_a recovery.img
Found EDL 9008
Configuring... Ok
Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok
Requesting write recovery.img...
<log value="ERROR: range restricted: lun=0, start_sector=1591552, num_sectors=131072" />
Nope
P.s. curiously, the file I downloaded from https://raw.githubusercontent.com/b...a/0010a0e102e80000_974359c4290cac7f_fhprg.bin wasn't accepted as a valid firehose loader file.
Edit: nevermind. Had to restart the phone.
I believe that's an older loader, anyway.
How shall I proceed?
marc.2377 said:
But it doesn't boot to fastboot.
Click to expand...
Click to collapse
Hmm, the screen stays black?
Is it still in EDL mode or some other mode?
Does Windows "bong" when you pull the USB cable?
It's possible that this goes to a fastboot without a screen?
Try holding various buttons, both by long power button reset and /zf
marc.2377 said:
It seems to me that your tool, edl could be used to write the recovery partition directly, no?
Click to expand...
Click to collapse
Yes, it could if Motorola wasn't such a pain with the "range restricted".
They've really clamped down (that other file you mentioned is the same):
Code:
qcomview /r sofiar.bin
Addr LUN Start Count
------ --- -------- --------
007f10 0 0 256
007f28 0 256 78336
007f40 0 1609948 512
007f58 0 1610496 512
007f70 1 1 1
You can do this to see which partitions this means:
Code:
C:\>edl /lsofiar.bin
C:\>edl /g
I have a feeling that the Motorola "Blankflash" stuff writes something to those 3 areas that allow it to write everything.
But it probably wipes the userdata.
I'm not an expert on their tools.
Tell me what the GPT says (you only need to quote stuff in the area of that table).
Edit: It looks like in the multi GB zip there are two "instruction" files, flashfile.xml and servicefile.xml
They are mostly the same except that flashfile will wipe userdata!
Curious. The partition table is as follows:
Code:
Found EDL 9008
Configuring... Ok
Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok
# Name Start Count Type
-- ---------------- ---------- ---------- --------------------
1 xbl_a 256 9216 Inactive
2 xbl_b 9472 9216 Bootloader
3 tz_a 18688 8192 Inactive
4 tz_b 26880 8192 TrustZone
5 rpm_a 35072 1024 Inactive
6 rpm_b 36096 1024 Resource/power mgmt
7 hyp_a 37120 1024 Inactive
8 hyp_b 38144 1024 Hypervisor
9 devcfg_a 39168 256 Inactive
10 devcfg_b 39424 256 Device config
11 xbl_config_a 39680 256 Inactive
12 xbl_config_b 39936 256 Boot config
13 abl_a 40192 2048 Inactive
14 abl_b 42240 2048 Android bootloader
15 uefisecapp_a 44288 4096 Inactive
16 uefisecapp_b 48384 4096 be8a7e08
17 qupfw_a 52480 160 Inactive
18 qupfw_b 52736 160 QUP firmware
19 cmnlib_a 52992 1024 Inactive
20 cmnlib64_a 54016 1024 Inactive
21 cmnlib_b 55040 1024 Common lib
22 cmnlib64_b 56064 1024 Common lib64
23 keymaster_a 57088 1024 Inactive
24 keymaster_b 58112 1024 Key master
25 storsec_a 59136 256 Inactive
26 storsec_b 59392 256 Store secure
27 spunvm 59648 16384 Spun VM
28 uefivarstore 76032 1024 165bd6bc
29 multiimgoem_a 77056 64 Inactive
30 multiimgoem_b 77120 64 e126a436
31 multiimgqti_a 77184 64 Inactive
32 multiimgqti_b 77248 64 846c6f05
33 prov_a 77312 512 Inactive
34 prov_b 77824 512 d05e0fc0
35 modem_a 78336 368640 Inactive
36 modem_b 446976 368640 FAT32
37 fsc 815616 256 FSC
38 ssd 815872 16 Secure SW download
39 dsp_a 816128 65536 Inactive
40 dsp_b 881664 65536 DSP
41 ddr 947200 2048 DDR
42 utags 949248 1024 1dd40d18
43 utagsBackup 950272 1024 c490f39c
44 modemst1 951296 8192 Modem ST1
45 modemst2 959488 8192 Modem ST2
46 fsg_a 967680 49152 Inactive
47 fsg_b 1016832 49152 Modem storage
48 persist 1065984 65536 Persist
49 prodpersist 1131520 16384 Persist
50 frp 1147904 1024 FRP
51 cid 1148928 256 459abd04
52 carrier 1149184 32768 c63d32d8
53 metadata 1181952 32768 988a98c9
54 kpan 1214720 16384 56465e10
55 boot_a 1231104 131072 Inactive
56 boot_b 1362176 131072 Boot
57 dtbo_a 1493248 49152 Inactive
58 dtbo_b 1542400 49152 DTBO
59 recovery_a 1591552 131072 Inactive
60 recovery_b 1722624 131072 Recovery
61 misc 1853696 2048 Misc
62 logfs 1855744 16384 Log FS
63 apdp 1872128 512 APDP
64 msadp 1872640 512 MSADP
65 dpo 1873152 2 DPO
66 devinfo 1873160 8 Device info
67 bluetooth_a 1873168 9216 Inactive
68 bluetooth_b 1882384 9216 Bluetooth
69 logo_a 1891600 66848 Inactive
70 logo_b 1958448 66848 Splash
71 vbmeta_a 2025296 128 Inactive
72 vbmeta_b 2025424 128 Verified Boot meta
73 padA 2025552 6064 Empty
74 hw 2031616 16384 b2d77ec0
75 padB 2048000 16384 Empty
76 sp 2064384 16384 40aef62a
77 padC 2080768 16384 Empty
78 padD 2097152 32768 Empty
79 super 2129920 16973824 System
80 userdata 19103744 103038943 User data
Doesn't seem to match the output of qcomview.
Also, the file 0010a0e102e80000_974359c4290cac7f_fhprg.bin lists the following codenames:
Code:
QCA6390
QCS605
SA8150
SDA670
SDA845
SDA855
SDA855A
SDA865
SDC830
SDM450
SDM670
SDM830
SDM845
SDM855
SDM855A
SDM1000
SDX24
SDX24M
SDX55
SM6150
SM6150P
SM7150
SM7150P
SM_NICOBAR
While programmer.elf (same as sofiar.bin that you uploaded) lists, additionally, QCM_NICOBAR and QCS_NICOBAR.
I wonder whether this is actually the correct file for me...
Btw, before attempting any further writing strategies, I confess to being interested in pulling userdata. As I understand the real decryption key is stored in the TEE functionality of the chipset and such an image would be unreadable for me, except if I were to restore it later.
With your tool I got the "range restricted" for edl /r /puserdata parts\userdata.img /t too.
Code:
Addr LUN Start Count
------ --- -------- --------
007f10 0 0 256 - GPT
007f28 0 256 78336 - xbl_a to prov_b
007f40 0 1609948 512 - ??? random spot in recovery_a
007f58 0 1610496 512 - ??? random spot in recovery_a
007f70 1 1 1
So, basically, you have free read/write access to partions 1 to 34
Reading is always safe.
Also, you're on the B slot.
So why does reboot to fastboot fail?
It could be that it was never implemented correctly in this Firehose
It could be that this Firehose is not for your device
It could be that xbl and/or abl was damaged somehow
I'd do some checking, xbl_b and abl_b to start with.
Read 'em then compare them to the xbl and abl you have in your big packages.
Code:
C:\>edl /lsofiar.bin
C:\>edl /r /t /pxbl_b xblb.img
C:\>edl /r /t /pabl_b ablb.img
The /t will copy these ELF files only as big as they need to be (not all the blank space).
OTOH, they will enlarge to an exact number of 512 byte sector.
So they could be 511 bytes bigger than what comes out of that package.
If things are wacky, try without /t, but they'll be padded with all the zeroes in the partition.
If those files aren't in the big package, here's ones I extracted from the blankflash.
Check 'em all.
Also, it's possible that somehow the slots got switched.
While you're at it, look at xbl_a and abl_a also.
Hey, thanks for the continued efforts to help me. Sorry for absence for the past days, real life caugh in ^^
I'm glad to report that, amidst some binary checking and all that, I managed to resuscitate my phone using the blankflash strategy, after carefully revising it.
Strangely, it seems that TWRP got installed in the boot partition, such as that "normal boot" kept entering TWRP, despite I having flashed the stock recovery images to both recovery slots. I'll detail this all later.
At this point my phone is on and I backed up what I needed, and have been using it. A few strange glitches are present, i.e. battery charging is acting weird. I plan on doing a clean flashing of the stock ROM soon. Maybe I should take the opportunity to study how to make a fully working port of the latest LineageOS for this device, too.
Will get back within a few days with a detailed report of the endeavour
marc.2377 said:
Will get back within a few days with a detailed report of the endeavour
Click to expand...
Click to collapse
I'm looking forward to hearing how you got EDL mode working.
I bricked XT2041-3 Sofiar (downgrade to A10) and am stuck trying the phone to succeed at qboot blank-flash, but it hangs (on linux):
Code:
< waiting for device >
Motorola qboot utility version 3.86
[ 0.000] Opening device: /dev/ttyUSB0
[ 0.000] Detecting device
[ 0.002] ...cpu.id = 266 (0x10a)
[ 0.002] ...cpu.sn = 3773339940 (0xe0e89924)
[ 0.002] Opening singleimage
[ 0.002] Loading package
[ 0.004] ...filename = pkg.xml
[ 0.005] Loading programmer
[ 0.005] ...filename = programmer.elf
[ 0.005] Sending programmer
[ 0.178] Handling things over to programmer
[ 0.178] Identifying CPU version
[ 0.178] Waiting for firehose to get ready
With --debug=2 there can be seen some parsing errors in xmls being passed for about 13 more seconds. On Windows VM phone is recognized as a single QDLoader 9008 device, but qboot fails after half a minute with IO Errors. Is this even EDL mode?
A tried without luck Renate's edl tool. edl.exe /lsingleimage.bin:
Code:
Found EDL 9008
Could not open device
I was growing increasingly desperate, so I opened the phone and played with EDL points according to
MatiasLopezxD. No combination of vol-, power, shorting points, plugging usb seem to make a difference. I must be missing something simple.
Any help would be appreciated.
@ybea: Quick answer for now - I got into EDL mode by holding down VolDown+Power for about 8-10 seconds. Let me know if it works for you. What's your output for lsusb?
Same as yours - ID 05c6:9008 (Qualcomm, Inc. Gobi Wireless Modem (QDL mode)). It reconnects after pressing power for 9 seconds (with or without vol-), nothing new.
Try restarting it into EDL mode while it's plugged. I found that to be necessary sometimes.
Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...
marc.2377 said:
Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...
Click to expand...
Click to collapse
That was it! I didn't event try it on the metal, because Motorola driver installer and uninstaller crash for me for some reason. Should be straightforward from now.
Thank you so much. You saved the day.
ybea said:
A tried without luck Renate's edl tool. edl.exe /lsingleimage.bin
Click to expand...
Click to collapse
Sorry. edl.exe uses the generic Zadig (i.e. WinUsb) driver).
If you have the Qualcomm driver loaded it's stealing the poor WinUsb interface and forcing it into some bogus virtual com port.
Also, singleimage is Motorola's completely morally bankrupt idea of packing stuff in a file.
It is not a Firehose loader, although it contains one.
Add to all your miseries, Motorola is crap and releases only restricted Firehose loaders.
If you're still stuck, ship me the "single-and-totally-bogus.bin" and I'll extract the Firehose loader for you.
Better poke me or I won't see it.
No longer stuck. The problem for me was neither VM USB passthrough nor blankflash tools for linux did work, although both showed proper EDL mode. It seems it only works on native Windows. Thanks for your interest.