Related
I try to use the new version of Heimdall but when starting to flash I had the following error:
Code:
Heimdall v1.3.0, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
Initialising connection...
Detecting device...
ERROR: Failed to access device. libusb error: -3
Is there anybody that could explain the problem ?
However my SGS-2 is detect in the utilities tab.
Thanks for your answers.
Django313 said:
I try to use the new version of Heimdall but when starting to flash I had the following error:
Code:
Heimdall v1.3.0, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
Initialising connection...
Detecting device...
ERROR: Failed to access device. libusb error: -3
Is there anybody that could explain the problem ?
However my SGS-2 is detect in the utilities tab.
Thanks for your answers.
Click to expand...
Click to collapse
Heimdall is flashing software? Why not use Odin?
As far as I understand Heimdall is for use on Galaxy S, not S2.
theo80 said:
Heimdall is flashing software? Why not use Odin?
As far as I understand Heimdall is for use on Galaxy S, not S2.
Click to expand...
Click to collapse
Because Heimdall is stable, reliable, open-source, cross-platform, allows for a large degree of flashing freedom and is guaranteed to be legal. None of these are true for Odin. Although not necessarily overly important Heimdall also flashes substantially faster.
Also as of 1.3.0 Heimdall Frontend now supports Heimdall Firmware Packages, which are by far a superior than attempting to flash several description-less tar archives with Odin.
EDIT: Heimdall works with all Galaxy S devices, except the Droid Charge, which we've had difficulties with. Which is another advantage over Odin; one version of Heimdall works with all devices so there's less confusion about versions.
Django313 said:
I try to use the new version of Heimdall but when starting to flash I had the following error:
Code:
Heimdall v1.3.0, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
Initialising connection...
Detecting device...
ERROR: Failed to access device. libusb error: -3
Is there anybody that could explain the problem ?
However my SGS-2 is detect in the utilities tab.
Thanks for your answers.
Click to expand...
Click to collapse
What OS are you running? If it's Windows make sure you follow the README and install the drivers.
@Benjamin Dobell
Yes, I use heimdall 1.3.0 on Kubuntu 11.04.
I read your e-mail and I try to launch Heimdall with sudo and it works !
but it's finished bad, resulting in a "half-bricked" SGS-2.
the flash of the datafs partition, when reaching 100% freeze and heimdall sent the error that it couldn't load datafs. ending the session...
I try twice flashing my phone:
- one with my own built heimdall-firmware-packages
- the other was custom flashing.
both failed.
The third flashing I made with odin in a virtualbox, and succeeded.
here is the results when launching Heimdall in a terminal :
Code:
[email protected]:~$ sudo heimdall-frontend
[sudo] password for didier:
Error: "/var/tmp/kdecache-didier" is owned by uid 1000 instead of uid 0.
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Aucun fichier ou dossier de ce type
QFileSystemWatcher: failed to add paths: /home/didier/.config/ibus/bus
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work
Error: "/tmp/kde-didier" is owned by uid 1000 instead of uid 0.
Error: "/tmp/ksocket-didier" is owned by uid 1000 instead of uid 0.
kdeinit4: Shutting down running client.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
Error: "/tmp/ksocket-didier" is owned by uid 1000 instead of uid 0.
Error: "/tmp/kde-didier" is owned by uid 1000 instead of uid 0.
Error: "/var/tmp/kdecache-didier" is owned by uid 1000 instead of uid 0.
kbuildsycoca4 running...
Error: "/var/tmp/kdecache-didier" is owned by uid 1000 instead of uid 0.
Error: "/var/tmp/kdecache-didier" is owned by uid 1000 instead of uid 0.
Error: "/var/tmp/kdecache-didier" is owned by uid 1000 instead of uid 0.
Error: "/tmp/ksocket-didier" is owned by uid 1000 instead of uid 0.
Error: "/var/tmp/kdecache-didier" is owned by uid 1000 instead of uid 0.
[email protected]:~$
Django313 said:
@Benjamin Dobell
Yes, I use heimdall 1.3.0 on Kubuntu 11.04.
I read your e-mail and I try to launch Heimdall with sudo and it works !
but it's finished bad, resulting in a "half-bricked" SGS-2.
the flash of the datafs partition, when reaching 100% freeze and heimdall sent the error that it couldn't load datafs. ending the session...
I try twice flashing my phone:
- one with my own built heimdall-firmware-packages
- the other was custom flashing.
both failed.
Click to expand...
Click to collapse
In regards to sudo permissions being required, I just did a bit of searching and I found some information (although it may have been old) that Kubuntu's udev rules are in a different location to Ubuntu's. I also found separate information indicating that Kubuntu is using an outdated udev rules specification. Either of these two things would cause the -3 permissions error without running Heimdall as a super user.
Do you know exactly what the error was you received from Heimdall when flashing failed? The output from Heimdall Frontend only contains the permissions errors and aren't related to the flashing process. When you use Heimdall Frontend, Heimdall's output is displayed in "Status" section of the "Flash" tab so that it can easily be copy and paste.
By the way if your phone gets stuck in a "half-bricked" state again then it can usually be fixed by going to the "Utilities" tab and running the "Close PC Screen" action. This doesn't repair any corrupted files on device (if there are any). This literally just tells the phone that it should at least try boot up, instead of displaying the phone <--> PC screen.
Help please
trying to run heimdall 1.3.0 on Mac OS 10.5.8, I have qt/xcode installed, still doesn't seem to work. everytime i run frontend and try to detect my device (samsung captivate)or save my .pit file I get "FRONTEND ERROR Heimdall crash"
Any suggestions ?
ERROR: Failed to access device. libusb error: -12
Win7 x64
Installed drivers:
Heimdall v1.3.0, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna http://www.glassechidna.com.au
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...
Beginning session...
Handshaking with Loke...
Uploading PITERROR: Failed to send end session packet!
ERROR: Failed to send file part packet!
PIT upload failed!
Ending session...
Odin works, back to odin.
Problem with heimdall on mac 0s 10.5.8
Crappyvate said:
trying to run heimdall 1.3.0 on Mac OS 10.5.8, I have qt/xcode installed, still doesn't seem to work. everytime i run frontend and try to detect my device (samsung captivate)or save my .pit file I get "FRONTEND ERROR Heimdall crash"
Any suggestions ?
Click to expand...
Click to collapse
@benjamin
Problem solved after updating to osx 10.6
there seem to be issues between Heimdall 1.3 on Leopard 10.5 and certain binaries. Heimdall command line does not execute and just crashes.
I'm getting a similar error on Arch Linux running Heimdall v1.3.0 with my Fascinate:
Code:
Initialising connection...
Detecting device...
ERROR: Failed to access device. libusb error: 4
I do have the proper udev rules in place:
Code:
$ lsusb | grep Samsung
Bus 002 Device 068: ID 04e8:6601 Samsung Electronics Co., Ltd Mobile Phone
I couldn't get Heimdall to even detect the device on my MacBook Pro running 10.6.8. I don't have access to a Windows machine to do further testing, and have had a lot of issues trying to update pretty much anything on my phone after I rooted and put a Superclean ROM on a few months ago. Here's my current setup: pastie.org/2358372
Today I tried to flash my SGS-II with heimdall 1.3.0 on Linux Kubuntu 11.04.
I used the latest firmware XXKH3 and it failed as it did with the firmware XXKG6 few weeks ago. Just after it downloaded the file "datafs" it freeze resulting in a half-bricked phone.
Certainly there is a bug in heimdall at this point because all the others files are correctly downloaded.
the question is : why ?
I'm on Mac OsX 10.6.8, and after tried to flash my firmware using the downloaded PIT from my device, Heimdall told me that there were an error with libusb while it was trying to upload the PIT.
My SGS got semi-bricked, and after putting it to download mode again and unchecking Repartition in Heimdall, everything was fine with the flashing.
So, the question is... is there a bug with repartitioning? is it possible to use my device's PIT to repartition?
Need new bootloader for EPIC? How do I tell?
All, I picked up an EPIC from someone and they put DK28 on it which is a bit of a dead end. All searches turned up needing Odin and I don't have a Windows box. I then found Heimdall and then this thread here:
http://forum.xda-developers.com/showthread.php?t=1353310
This all looks promising but then I've read where I need to update the bootloader if I'm using a Mac. My question is, with an EPIC of somewhat unknown past, how do I know if I have the right bootloader on it? DK28 is the leaked Froyo that never got OTA'd. I want to get this EPIC back onto the OTA track so it can get Gingerbread. I've found CWM flashable images but the modem seems to be the biggest struggle. Of course, if Heimdall works, the thread above looks like it will get me all that I want.
So if anyone can help and tell me how to figure out if I've got the right bootloader and won't get the black screen problem, that would be cool.
thanks peterb
Need some help please
My device got messed up and I know nothing about using Linux or fixing partitions with ADB, I have the partition tables I need to fix it but I have no clue and no one in our community knows how to change the "head" sectors from four to ONE. Please this is my partition list from heimdal
Entry Count: 14
Unknown 1: 15718400
Unknown 2: 1
Unknown 3: 0
Unknown 4: 0
Unknown 5: 7703
Unknown 6: 237
Unknown 7: 62704
Unknown 8: 18
--- Entry #0 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 1
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 1
Unknown 2: 0
Unknown 3: 0
Partition Name: IBL+PBL
Filename: boot.bin
--- Entry #1 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 2
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 1
Unknown 2: 0
Unknown 3: 0
Partition Name: PIT
Filename: YPG70_8G-0304.pit
--- Entry #2 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 3
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 5
Unknown 2: 0
Unknown 3: 0
Partition Name: SBL
Filename: Sbl.bin
--- Entry #3 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 4
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 5
Unknown 2: 6226025
Unknown 3: 7143533
Partition Name: SBL2
Filename: Sbl.bin
--- Entry #4 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 5
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 20
Unknown 2: 0
Unknown 3: 0
Partition Name: PARAM
Filename: param.lfs
--- Entry #5 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 6
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 40
Unknown 2: 39021280
Unknown 3: 7143533
Partition Name: EFS
Filename: efs.rfs
--- Entry #6 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 7
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 30
Unknown 2: 36662408
Unknown 3: 0
Partition Name: KERNEL
Filename: zImage
--- Entry #7 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 8
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 30
Unknown 2: 6684793
Unknown 3: 3014771
Partition Name: RECOVERY
Filename: zImage
--- Entry #8 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 9
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 1160
Unknown 2: 0
Unknown 3: 0
Partition Name: FACTORYFS
Filename: factoryfs.rfs
--- Entry #9 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 10
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 536
Unknown 2: 6684780
Unknown 3: 115
Partition Name: DBDATAFS
Filename: dbdata.rfs
--- Entry #10 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 11
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 256
Unknown 2: 115
Unknown 3: 115
Partition Name: CACHE
Filename: cache.rfs
--- Entry #11 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 12
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 7696
Unknown 2: 0
Unknown 3: 0
Partition Name: DATAFS
Filename: datafs.rfs
--- Entry #12 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 13
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 20516
Unknown 2: 0
Unknown 3: 0
Partition Name: USERFS
Filename: userfs_8G.rfs
--- Entry #13 ---
Unused: No
Chip Identifier: 2 (Unused: %
s
)
Partition Identifier: 0
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 0
Partition Block Count: 0
Unknown 2: 0
Unknown 3: 0
Partition Name: GANG
Filename: inand_8G.bin
Ending session...
Rebooting device...
Heyo guys, idk if this can be seen as somehow relate to this topic, cuz its a diff problem with heimdall than originally mentioned in this thread, but my problem is that while trying to flash twrp, my sm-a750fn got half-bricked, and odin didnt want to flash the phones stock ROM, beeing stuck at establishing a connection, so i went and tried to flash it via heimdall-frontend, without sudo cuz else id have issues with the pit not beeing recognised, and everytime i try to flash smth, no matter what .img, be it recovery, boot, misc, etc, heimdall gets stuck at 93% and later gets a fail msg:
"Heimdall v1.4.1
Copyright (c) 2010-2014 Benjamin Dobell, Glass Echidna
Glass Echidna
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
Donate | Glass Echidna
Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...
Initialising protocol...
Protocol initialisation successful.
Beginning session...
Some devices may take up to 2 minutes to respond.
Please be patient!
Session begun.
Downloading device's PIT file...
PIT file download successful.
Uploading BOOT
0%
1%
2%
3%
4%
5%
[...]
80%
81%
82%
83%
84%
85%
86%
87%
88%
89%
90%
91%
92%
93%
ERROR: Failed to confirm end of file transfer sequence!
ERROR: BOOT upload failed!
Ending session...
ERROR: Failed to send end session packet!
Releasing device interface..."
The phone also shows like bout 45% of progress:
{
"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"
}
Qualcomm based chipset phones are fixed through QPST tool. One of the software provided QPST is eMMC software download which helps to fix corrupt bootloader and emmc partitions. BUT SOMETIMES THE BOOTLOADER REPAIR IS NOT SUCCESSFUL.
The PURPOSE OF THIS THREAD is to know what is causing the errors and provide solutions.
The eMMC software creates log files like Dload_COMxx.dbg which can be found under C:\ProgramData\Qualcomm\QPST in Windows 7 PC.
I am encoutring "Image Download Failed. Cookie (if present) not received" error in eMMC download. Here is the log file:
2013/07/03 14:15:55.095 Restart timeout set to 10 seconds
2013/07/03 14:15:55.095 StartSB2Download
2013/07/03 14:15:55.095 Begin SB2.0 Software Download
2013/07/03 14:15:55.095 Skip Reset: 1
2013/07/03 14:15:55.095 Lock phone
2013/07/03 14:15:55.095 Examine phone mode
2013/07/03 14:15:55.111 Get partition file name
2013/07/03 14:15:55.111 User specified flash programmer:
2013/07/03 14:15:55.111 Flash Programmer file:
2013/07/03 14:15:55.126 Examine phone mode
2013/07/03 14:15:55.126 Mobile not in download mode!
2013/07/03 14:15:55.126 SynchronizeConnection starting...
2013/07/03 14:15:55.126 Sending Hello to flash programmer...
2013/07/03 14:15:55.126 Disabling automatic polling.
2013/07/03 14:15:55.189 Try Hello with polling disabled...
2013/07/03 14:15:55.189 Try Hello with polling disabled...
2013/07/03 14:15:55.189 Try Hello with polling disabled...
2013/07/03 14:15:55.189 SynchronizeConnection succeeded.
2013/07/03 14:15:55.189 Sending Hello Packet
2013/07/03 14:15:55.204 Version info = 5 2
2013/07/03 14:15:55.204 Block size = 400
2013/07/03 14:15:55.204 Flash base = 0
2013/07/03 14:15:55.204 Device Name=eMMC:
2013/07/03 14:15:55.204 Flash ID size= 4
2013/07/03 14:15:55.204 Sectors = 128
2013/07/03 14:15:55.204 Feature mask = 0x09
2013/07/03 14:15:55.204 Sending Close 0
2013/07/03 14:15:55.204 Log: Cannot close when not previously opened
2013/07/03 14:15:55.204 ARMPRG error: 15, text: Cannot close when not previously opened
2013/07/03 14:15:55.204 CloseDownloader error
2013/07/03 14:15:55.204 Sending Security Mode 1
2013/07/03 14:15:55.204 eMMC user image present - skipping partition table
2013/07/03 14:15:55.220 eMMC user image: C:\flare repair files\8X25_msimage.mbn
2013/07/03 14:15:55.220 Opening eMMC USER file
2013/07/03 14:15:55.220 Opening eMMC USER mode
2013/07/03 14:15:55.220 Sending MI Open mode 33 size 0
2013/07/03 14:15:55.579 Log: Open multi failed, unknown error
2013/07/03 14:15:55.579 ARMPRG error: 7, text: Open multi failed, unknown error
2013/07/03 14:15:55.579 Download end, status 103, error 852
2013/07/03 14:15:55.579 Exit SB 2.0 download with status 0x00000000
a have a htc one m8s where do i get the xml file and the patch please
To load raw images to a device you will likely need a signature. Even low level tools like QFIL, for example, require MBN files which are essentially keys to the device.
Hello all ,
I linked a serial cable to my allwinner a20 based Android Tv box.
It can not pass after the boot logo and next is all what it display in serial console.
Somebody pelase help i need to reisntall linux on it ,if you knwo any u boot keys that i have to press on the uboot serial consoel pelase help.I tryed to press ransom keys but i see nothin.
Here is all i see when it start:
====================================
HELLO! BOOT0 is starting!
boot0 version : 3.0.0
dram size =512
sum=0x9c3bd8cf
src_sum=0x9c3bd8cf
Ready to disable icache.
Jump to secend Boot.
[ 0.133]
U-Boot 2011.09-rc1-dirty (Nov 08 2013 - 11:06:32) Allwinner Technology
[ 0.141]version: 1.1.0
[ 0.144]pmbus: ready
axp read error
probe axp20x failed
axp_probe error
boot_clock = 912
dcdc2_vol = 1400
axp set dcdc2_vol to 1400 failed
dcdc3_vol = 1250
ldo2_vol = 3000
ldo3_vol = 2800
ldo4_vol = 2800
power_start = 0
storage_type = -1
usb_recovery = 0
find power_sply to end
fel key old mode
run key detect
no key found
no key input
dram_para_set start
dram_para_set end
[ 0.293]DRAM: 512 MiB
relocation Offset is: 15b27000
user_gpio config
user_gpio ok
DRV_DISP_Init: opened
[ 0.560]boot_disp.output_type=2
[ 0.563]boot_disp.output_mode=5
[ 0.567]boot_disp.auto_hpd=1
workmode = 0
[ 1.871]NAND: NAND_UbootInit
NB1 : enter NAND_LogicInit
nand : get id_number_ctl from script, 3
not burn nand partition table!
NB1 : nftl num: 3
init nftl: 0
NB1 : NAND_LogicInit ok, result = 0x0
[ 2.381]sunxi flash init ok
In: serial
Out: serial
Err: serial
--------fastboot partitions--------
-total partitions:12-
-name- -start- -size-
bootloader : 1000000 1000000
env : 2000000 1000000
boot : 3000000 1000000
system : 4000000 20000000
recovery : 24000000 2000000
databk : 26000000 2000000
misc : 28000000 1000000
private : 29000000 1000000
sysrecovery : 2a000000 21000000
data : 4b000000 40000000
cache : 8b000000 17000000
UDISK : a2000000 0
-----------------------------------
base bootcmd=run setargs_nand boot_normal
bootcmd set setargs_nand
key 0
recovery key high 6, low 4
cant find fstbt value
Fastboot detected, will boot fastboot
to be run cmd=run setargs_nand boot_fastboot
the user data'magic is bad
WORK_MODE_BOOT
board_status_probe
sunxi_bmp_display
WORK_MODE_BOOT
[ 2.509]Hit any key to stop autoboot: 0
run usb fastboot
sunxi_fastboot_init
recv addr 0x41000000
send addr 0x582580a8
delay time 0
usb init ok
------------------------------------------------------------------
After this nothing .Please help me
After searching all google and reading documantation ,I contacted the box seller and he gied me the files i neeeded.
I used a image file named sun7i_A20v2.0_android_sugar-ref001_2014.09.04_TakenYBSJ.img and a windwos software to flash it via usb named PhoenixPacketV333
To flash teh device you muist hava a serial console to the box (veru easy to do if you have the cable ) ,and keep pushed the key 2
on serial consle (putty) while powering the device ,so it enter in fel mode ( something like recovery mode ,it accept usb connection) .Then oyu need a usb male to male cable to conect the android tv box usb port to the windows usb port ,and start flasing using the PhoenixPacketV333 software.
If somebody needs more help or files just write here I check daily .
have a nice day all!
hey guys..
i have a module which called bus multimedia.. i need root or read full backup of this device.. but there is no usb socket only exist RX TX pinout and i cannot connect it to pc over putty.. is anyone help me to read backup.?
t-mobile_mda said:
hey guys..
i have a module which called bus multimedia.. i need root or read full backup of this device.. but there is no usb socket only exist RX TX pinout and i cannot connect it to pc over putty.. is anyone help me to read backup.?
Click to expand...
Click to collapse
hey.. i removed the emmc and info..do u think that this device is android based..?
HiPower mode is On
Setting Interface to EasyJtag1/ISP_HiPower
Setting IO Levels to 3.3V
Setting Frequence to 21 Mhz
Setting BusWidth to 1 Bit
CMD Pullup Level: 2134 mV
CMD Active Level: 2609 mV
Setting HS Timing to Enabled
EMMC Device Information :
EMMC CID: 7001004D3732383038801500009374CA
EMMC CSD: D04F01320F5903FFFFFFFFEF8A400060
Manufacturer: KINGSTONE , NAME: M72808 , HEX: 4D3732383038 , S/N: 15000093 , Rev: 80
Manufacturer ID: 70 , OEM ID: 00 , Device Type: BGA (Discrete embedded) , Date: 7/2017
EMMC ROM 1 (Main User Data) Capacity: 7296 MB (0x0001C8000000)
EMMC ROM 2/3 (Boot Partition 1/2) Capacity: 4096 KB (0x000000400000)
EMMC RPMB Capacity: 4096 KB (0x000000400000) , Counter: 0 , Response: Clean
Extended CSD Information :
Extended CSD rev: 1.8 (MMC 5.1)
Boot configuration [PARTITION_CONFIG]: 0x00 , Device not boot enabled
Boot Bus Config: 0x00 , x1 (sdr) or x4 (ddr) bus width in boot operation mode
H/W Reset Function [RST_N_FUNCTION]: 0x00 , RST_n signal is temporarily disabled
Supported partition features [PARTITIONING_SUPPORT]: 0x07
Device supports partitioning features
Device can have enhanced technological features in partitions and user data area
Device can have extended partitions attribute
Partition settings [PARTITION_SETTING_COMPLETED]: 0x00
EMMC Init completed
Backup saved: M72808_15000093_20220611_141710.extcsd (new backup)
Connected successfully
Operation: Scan PartitionTable from Source (Vendor: Binary Read/Write)
Scanning soft partitions from ROM2
GPT header is not found
Scanning soft partitions from ROM3
GPT header is not found
Scanning soft partitions from ROM1
GPT header is not found
MBR header is not found
You need a usb to uart device to get started on that board. You can find one online for about 3 dollars.
The Qualcomm XBL (SBL1) and Firehose loader images are packed somewhat reasonably.
They are ELF images (32 or 64 bit) with no sections but 3 or more programs:
Code:
E:\>elfview xbl /p
# Type Flags Size Offset Address
-- ------- ----- ------- ------ --------
0 null 960 000000 00000000 // this is the standard ELF header
1 null 6952 001000 9fdb6000 // this is the signing
2 load RX 350012 003000 14015000 // these are various things that actually get loaded
3 load RWZ 0 058740 14077000
4 load RW 31844 058740 1407a000
5 load RWZ 0 0603B0 14084800
6 load RWZ 0 0603B0 85e00000
7 load RX 11824 0603B0 146ae000
8 load RW 2916 0631E0 146b1000
9 load RWX 107032 063D50 14098000
10 load RWZ 0 07DF70 146b2000
11 load RWX 1792000 07DF70 9fc00000
12 load RX 78208 233770 14699000
13 load RX 171536 2468F0 85e35000
14 load RW 6409 270700 85ea8000
15 load RWZ 0 272010 85e97000
That is to say:
Code:
32 bit ELF file
Program table
Signing
Header
Hashes // one for each program, the 2nd is zeroes as you can't hash the hash!*
Signature
Certificate chain
Payload // multiple programs
So the XBL loads the next one, usually abl which is the Android bootloader which also implements the fastboot protocol.
Now we get a bit deep in the gumbo:
Code:
E:\>elfview abl /p
# Type Flags Size Offset Address
-- ------- ----- ------- ------ --------
0 null 148 000000 00000000 // this is the standard ELF header
1 null 6536 001000 9fa22000 // this is the signing
2 load RWX 139264 003000 9fa00000
Code:
32 bit ELF file
Program table
Signing
Header
Hashes
Signature
Certificate chain
LZMA archive
MZ Windows executable
PE Portable executable
64 bit ARM code
This is all (U)EFI compatibility so it has sworn fealty to Intel/Microsoft.
So, accepting all the idiocy of this, my question remains:
7-Zip can extract the structure of what is the #2 (i.e. the third) program:
Code:
C:\>7zip ablefi
Type = UEFIf
ERRORS:
Headers Error
Physical Size = 139264
Method = LZMA
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
D.... 9E21FD93
D.... 9E21FD93\EE4E5898
..... 0 9E21FD93\EE4E5898\0.raw
D.... 9E21FD93\EE4E5898\VOLUME
..... 20 9E21FD93\EE4E5898\VOLUME\FFFFFFFF
..... 376832 9E21FD93\EE4E5898\VOLUME\LinuxLoader.efi
------------------- ----- ------------ ------------ ------------------------
376852 139264 3 files, 3 folders
Errors: 1
The "program" itself starts with 16 bytes 0x00.
If I remove these 16 bytes then 7-Zip can't decypher the file.
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
*Please note that although you can't hash the hash, you can Can the Can
@Appreciative
Sorry, I don't have anything technical documents on this at all except for Qualcomm stuff at the level of a PowerPoint.
All that stuff from booting onward is non-disclosure aggreement restricted.
I think that SecureBoot is in a OTP (one time programmable) fuse, but I don't know.
I can monitor the hardware console while booting the Firehose loader:
Code:
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.4-00246-S660LZB-1
S - IMAGE_VARIANT_STRING=Sdm660LA
S - OEM_IMAGE_VERSION_STRING=cibuild
S - Boot Interface: Unknown
S - Secure Boot: Off
S - Boot Config @ 0x00786070 = 0x000001c1
S - JTAG ID @ 0x00786130 = 0x000cc0e1
S - OEM ID @ 0x00786138 = 0x00000000
S - Serial Number @ 0x12345678 = 0x12345678
S - OEM Config Row 0 @ 0x00784188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00784190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x007841a0 = 0x007030000b580100
S - Feature Config Row 1 @ 0x007841a8 = 0x00000000000000c0
S - Core 0 Frequency, 3715 MHz
S - PBL Patch Ver: 5
S - I-cache: On
S - D-cache: On
B - 0 - PBL, Start
B - 7024 - bootable_media_detect_entry, Start
B - 141363 - bootable_media_detect_success, Start
B - 141369 - elf_loader_entry, Start
B - 19372540 - auth_hash_seg_entry, Start
B - 19372841 - auth_hash_seg_exit, Start
B - 19481121 - elf_segs_hash_verify_entry, Start
B - 19534026 - elf_segs_hash_verify_exit, Start
B - 19534831 - auth_xbl_sec_hash_seg_entry, Start
B - 19563960 - auth_xbl_sec_hash_seg_exit, Start
B - 19563963 - xbl_sec_segs_hash_verify_entry, Start
B - 19570674 - xbl_sec_segs_hash_verify_exit, Start
B - 19570719 - PBL, End
B - 0 - SBL1, Start
I've also pieced together some addresses from logs and dumping the DTB:
Code:
00780000 msm-core
00780350 secure_boot
00784138 serial_number
00784188 oem_config0
00784190 oem_config1
007841a0 feature_config0
007841a8 feature_config1
00786040 jtagfuse
00786070 boot_config
00786130 jtag_id
00786138 oem_id
Nice work. This saved me days of hard work.
Renate said:
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
Click to expand...
Click to collapse
Did you ever find a solution to this re-pack problem? I'd like to do something similar for the bootloader on my tablet.
Yahoo Mike said:
Did you ever find a solution to this re-pack problem? I'd like to do something similar for the bootloader on my tablet.
Click to expand...
Click to collapse
Nope, I havn't gotten back to this yet.
I guess it's just a question of biting the bullet and diving into this swamp of stupid packing.
Renate said:
...
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
Click to expand...
Click to collapse
After a bit of research, I can answer that question.
It starts with nulls because it's not an LZMA header. It's a UEFI Firmware Volume (FV) header, in which the first 16 bytes are always zero.
I looked at a few UEFI FV editing tools, but none of them do quite what we want. So I've started on my own. I'll keep you posted on progress.
Here's a summary of my research:
Code:
The layout of a UEFI Firmware Volume
====================================
see: UEFI Platform Initialization Specification, Vol. 3 (https://uefi.org/specifications)
see also: https://sudonull.com/post/125061-UEFI-BIOS-file-device-part-two-UEFI-Firmware-Volume-and-its-contents
+----------------+----------------+
| | FV Header |
| |================|--------------------+-------------------+
| | | | FF Header |
| | | |===================|---------------+
| | | | | FS Header |
| | | | FF Section (FS) |===============|
| | | | #1 | data |
| | | Firmware File (FF) | | |
| | | #1 |-------------------|---------------+
| | | | . . . | . . .
| | | |-------------------|
| | | | FF Section (FS) |
| UEFI | Firmware | | #N |
| Firmware | File |--------------------|-------------------+
| Volume (FV) | System (FFS) | | . . .
| | | . . . |
| | | |
| | |--------------------|
| | | |
| | | Firmware File (FF) |
| | | #N |
| | | |
+----------------+----------------+--------------------+
To implement this, an object model might look like this:
* a FirmwareVolume object has 1 FirmwareFileSystem
* a FirmwareFileSystem has 0..n FirmwareFile objects
* a FirmwareFile object has 0..n FirmwareFileSection objects
Just to make life interesting, one type of FF Section is the EFI_SECTION_FIRMWARE_VOLUME_IMAGE.
It has a UEFI Firmware Volume as its data. So there can be FVs nested in other FVs ad infinitum.
FF Sections can also be encrypted, compressed or encoded by an OEM.
Once decrypted/decompressed/decoded, these sections contain further FF sections.
And in accordance with Murphy's Law, the file we want (LinuxLoader.efi) is in one of those nested firmware volumes. ...And you guessed it - the nested FV is compressed using LZMA. Presumably that's deliberate - so you can't directly edit the bootloader in the abl.elf.
So I plan for my tool to do two things:
extract the LinuxLoader.efi file from the abl.elf file
repack a modified LinuxLoader.efi back into the ELF file.
I don't know if a repack will work. There are some checksums in the EFi headers. And the whole ABL.ELF might be signed by a private RSA key and the SoC will refuse to load it without the correct signature. We'll see..
Yahoo Mike said:
After a bit of research, I can answer that question.
It starts with nulls because it's not an LZMA header. It's a UEFI Firmware Volume (FV) header, in which the first 16 bytes are always zero.
Click to expand...
Click to collapse
Well, that's very clever of them. Most standards use "magic" values in the header.
These guys have taken a bold stand: "When you see 16 0x00 it's an unambiguous sign that you've found our UEFI FV!"
<rant>
I've dealt with kernels that were uncompressed, compressed with gzip or compressed and a decompressor stub.
So, imagine my surprise when I ungzipped a kernel from a boot image recently and found that it starts with "MZ".
"OMG, did Bill Gates buy Android? Is this the MS-DOS compatibilty layer?"
No, it's just the MS-DOS header stuck on a Windows PE header stuck on a kernel.
Code:
00000000 t _head
00000000 T _text
00000040 t pe_header
00000044 t coff_header
00000058 t optional_header
00000070 t extra_header_fields
000000f8 t section_table
00001000 T do_undefinstr
00001000 t efi_header_end
00001000 T _stext
</rant>
Renate said:
Well, that's very clever of them. Most standards use "magic" values in the header.
These guys have taken a bold stand: "When you see 16 0x00 it's an unambiguous sign that you've found our UEFI FV!"
<rant>
I've dealt with kernels that were uncompressed, compressed with gzip or compressed and a decompressor stub.
So, imagine my surprise when I ungzipped a kernel from a boot image recently and found that it starts with "MZ".
"OMG, did Bill Gates buy Android? Is this the MS-DOS compatibilty layer?"
No, it's just the MS-DOS header stuck on a Windows PE header stuck on a kernel.
Code:
00000000 t _head
00000000 T _text
00000040 t pe_header
00000044 t coff_header
00000058 t optional_header
00000070 t extra_header_fields
000000f8 t section_table
00001000 T do_undefinstr
00001000 t efi_header_end
00001000 T _stext
</rant>
Click to expand...
Click to collapse
Yes, very clever. But there is method in their madness. According to the spec: "The first 16 bytes are reserved to allow for the reset vector of processors whose reset vector is at address 0."
There is a bit of magic at byte 0x28 in the FV header. It's always "_FVH". That's how you identify a UEFI FV. But I guess the first 16 nulls are always a big hint.
...and it's great to see that the ghost of MS-DOS lives on. It reminds me of what we used to say in my early programming days: "DOS is boss".
I've been looking into this hashing business.
I know that I'm basically on the right track.
I can take a Firehose loader (basically a custom xbl) make a trivial spelling change somewhere and it will refuse to load.
I can recalculate the SHA256, replace it and it will load correctly.
I have a WIP that checks the hashes on xbl/abl/firehose loaders (all basically the same).
I see tons of files that check out 100%.
Code:
C:\>qcomview /h poke3.bin
64 bit ELF, SHA256
0 00000000 00000318 a117dbc5 e643e404 361bfe30 45fbda01 4c153842 59a4cbe8 09b7da55 a2dd413e OK
1 00001000 00001ac8
2 00003000 0005709c 7b833734 f2763b9e 35f3310c f6fb22a9 a514eac0 3eddbe46 b5ff339b 3c7b045c OK
3 0005a0a0 00000000
4 0005a0a0 00009f00 6296c006 31852f79 b99691c3 e8d598f2 9d323e9a ba0358aa b742901f 506709d5 OK
5 00063fa0 00009908 41176495 3e07ad84 8923398e ce854131 91066dca 43f253fa c027c4f4 a3c21483 OK
6 0006d8b0 00000000
7 0006d8b0 00001e7c fe77c473 b02e4a71 d3f287e4 cf85ccbe b5a43326 53930bd8 d68e4e40 6e71a0b8 OK
8 0006f730 00000000
9 0006f730 000188d8 1bfef74c ed467a22 8616419d e71ab1ea 22a717e5 4874c704 541793ed f5d5c5e5 OK
10 00088010 00000000
11 00088010 00000000
12 00088010 00012dc0 b72cb77e 81026632 446c3462 cc6c83fc d7904333 cb8807cc 27d6e4c9 189c7ca4 OK
I see a bunch of files that don't check out at all.
I can SHA256 a program chunk and the SHA256 appears nowhere in the entire file.
Are they salting the SHA256 or using a different hash?
Edit: Oh, it looks like SHA512. Er, maybe SHA3 512?
Edit: Ok, big deal, so I can't count. It's SHA(2)-384. WIP can be found http://www.temblast.com/qcomview.htm
The SHA256 displays the calculated and verifies.
The SHA384 displays the file content and does not verify (yet). calculated and verifies.
There is also an option to dump an ASN1 listing of the certificate chain.
Renate said:
WIP can be found http://www.temblast.com/qcomview.htm
Click to expand...
Click to collapse
qcomview works great. Thanks.
With @Renate 's invaluable guidance, I put together a tool to extract the LinuxLoader from the abl.elf file, and to repack a modified LinuxLoader back into the abl.elf file. But it comes with a warning: don't try to run a modified abl.elf on a device with SecureBoot on - if you do, you will probably brick your device. Of course, if SecureBoot is off, this tool should work for you.
If you want to try it, the tool source is available at: github.com/Yahoo-Mike/lltool. It's still in beta. It was only tested on a limited number of ELF files and it might need some fine-tuning for different OEMs. So feel free to report issues or send pull requests. If it doesn't work on your ELF file, send me a link to the file and I'll see what I can do.
Yahoo Mike said:
If you want to try it, the tool source is available at...
Click to expand...
Click to collapse
Nice work! (And a bunch of it.)
I just got around to modding my abl. I just did it manually.
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
It made a world of difference. I got rid of the 30 second delay for being Orange. It seems I waste half a day with that 30 seconds.
Have you got a SecureBoot=off device?
I'm sure many people are getting sick of all the restrictions.
Renate said:
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
Click to expand...
Click to collapse
Spot on!
Renate said:
Have you got a SecureBoot=off device?
Click to expand...
Click to collapse
No, unfortunately. That's why I'm still hunting around for other options. I'm currently thinking about self-signing the modded abl.elf. Maybe I'll get lucky and the OEM allows that on my device...
BTW, I don't suppose you know the answer to this question: How to find "hw_soc_version" for a QCom SOC?
Usually the SHA256 of the root CA corresponds to the "Hash" burned into the chip.
I see that's true for about 80% of the loaders in the repository.
There may be a newish wrinkle where there is an encryption step or something.
But if you're SecureBoot, everything has to match all the way down.
Some trivia from our favorite loader repository:
Code:
Older style, not an ELF [ 89]
32 bit ELF, Version 3, SHA256 [460]
32 bit ELF, Version 3, SHA384 [ 8]
64 bit ELF, Version 3, SHA256 [ 31]
64 bit ELF, Version 5, SHA256 [ 65]
32 bit ELF, Version 6, SHA384 [ 4]
64 bit ELF, Version 6, SHA384 [ 54]
Of course a bunch of these are duplicated and put in different directories.
Renate said:
I just got around to modding my abl. I just did it manually.
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
Click to expand...
Click to collapse
I've got it down to 100% automatic now. It uses a makefile and a few of my "glue" utilities.
Code:
hexcalc size(ablmod)-3000 > hexcalc.tmp
My Xperia XZ2 got turned off secure boot after unlocking bootloader, is this actually off? I don't trust secure:no in fastboot getvar secure
I'm wondering if my phone will brick if flashing abl mod
cuynu said:
I'm wondering if my phone will brick if flashing abl mod
Click to expand...
Click to collapse
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.
Renate said:
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.
Click to expand...
Click to collapse
Unfortunately, there is no firehose loader for Xperia XZ2 nor sony phones
Renate said:
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.
Click to expand...
Click to collapse
I can get to EDL by short testpoint in the mainboard, but the PID not 9008, it is PID:ADE5
cuynu said:
I can get to EDL by short testpoint in the mainboard, but the PID not 9008, it is PID:ADE5
Click to expand...
Click to collapse
Mmm, that seems strange.
Because the VID/PID comes out of the ROM PBL and I've never seen any override on 05c6/9008.
OTOH fastboot often has wacky VID/PIDs.
Look at the manufacturer/product strings and see if it's Qualcomm CDMA Technologies MSM and QUSB__BULK.
https://www.ftdichip.com/Support/Utilities.htm#MicrosoftUSBView