[TOOL] Xflasher (xperia command line flasher for pre 2017 devices)

munjeni · May 20, 2017

Before loader.sin gets uploaded tool extract information about max packet size from s1 boot (see line 25 and 26), than loader gets uploaded and gives another information (174 and 175), based on that packet was 0x80000 before loader.sin and is changed to 0x400000 after loader.sin gets uploaded. I still have no idea WTH it was not changed to 0x400000 (line 264 tells that 0x80000 instead of 0x400000)

seems something failed on pc side because I programmed it without error checking to save that info to file called max_p so tool uses information from file max_p, seems file max_p was not updated to 0x400000? Tool creates two files, one called btinf (store device specific information needed for bootbundle) and seccond one max_p (info about max packet size), seems seccond one didn't gets updated right

munjeni · May 20, 2017

Don't believe how banal bug we have

New v16 is out, this one will stop flashing if max packet size catcher din't succed and will tell about error detail and error number, let see

munjeni · May 20, 2017

Testing now my side, this is error I am getting from v16:

Code:

Proccessing cache_S1-SW-LIVE-6732-PID1-0005-MMC.sin...
File size: 0x5B0754
Sin header size: 0x624
Sin data size: 0x5B0130
ERROR: Unable to open max_p for read! failed with error code 2 as follows:
The system cannot find the file specified.


Error uploading cache_S1-SW-LIVE-6732-PID1-0005-MMC.sin!

I know whats wrong now

V17 in next 5 minutes!

munjeni · May 20, 2017

V17 is out, this one will definitelly work, or in case max packet size is not propertly detected will abandon flashing and will give error detail

shoey63 · May 20, 2017

munjeni said:
V17 is out, this one will definitelly work, or in case max packet size is not propertly detected will abandon flashing and will give error detail

Finally!

Code:

Writing crc32 for chunk part: 667
Successfully write 0x4 bytes to handle.
WRITING LAST PACKET. SETTING TIMEOUT TO 600000 (ms).
Successfully read 0xd bytes from handle.
Raw input [0xD]:

  00000000  00 00 00 06 00 00 00 01 00 00 00 00 0E           .............

Verifying crc32...
Success: device replied with 0000000600000001000000000E which mean ok.

LAST PACKET REAPLY AFTER ms: 403071.000000
Successfully read 0x4 bytes from handle.
Raw input [0x4]:

  00000000  00 00 00 00                                      ....

Finished.


[B][I][SIZE="6"][COLOR="Lime"]system.sin uploaded sucessfully.[/COLOR][/SIZE][/I][/B]

:good::good:

munjeni · May 20, 2017

Soo great!!! Finaly!! Thank you a ton for your testing this, it helped not only me but all who use xflasher! I have added you to the credits page :good:

munjeni · May 20, 2017

Did everything flashes, bootboondle, ta, etc? For me all ok! This confirms that fsc is an bul****!

shoey63 · May 20, 2017

munjeni said:
Did everything flashes, bootboondle, ta, etc? For me all ok! This confirms that fsc is an bul****!

I was reluctant to try until bugs were fixed. I will report later.

munjeni · May 20, 2017

shoey63 said:
I was reluctant to try until bugs were fixed. I will report later.

I think only that wrongly max packet size was a bug, the rest I have tested on my device, deeply tested, all working

Also some dangerous ta units tool will skip like simlock and etc

Code:

						if (memcmp(unit, "000008B2", 8) == 0 || /* unlock key */
						    memcmp(unit, "000007D3", 8) == 0 || /* dangerous */
						    memcmp(unit, "000007DA", 8) == 0 || /* sim lock */
						    memcmp(unit, "00000851", 8) == 0 || /* dangerous */
						    memcmp(unit, "000008A2", 8) == 0 || /* device name */
						    memcmp(unit, "00001324", 8) == 0 || /* device sn */
						    memcmp(unit, "0001046B", 8) == 0) { /* drm key */
							printf("Skipping unit %s\n", unit);
							continue;
						}

boot bundle is determined by btinf file which is generated by xflasher during noloader or loader processing so it will skip flashing boot bundle if didn't found perfect match for determining files

shoey63 · May 20, 2017

munjeni said:
I think only that wrongly max packet size was a bug, the rest I have tested on my device, deeply tested, all working

Also some dangerous ta units tool will skip like simlock and etc

Code:

if (memcmp(unit, "000008B2", 8) == 0 || /* unlock key */ memcmp(unit, "000007D3", 8) == 0 || /* dangerous */ memcmp(unit, "000007DA", 8) == 0 || /* sim lock */ memcmp(unit, "00000851", 8) == 0 || /* dangerous */ memcmp(unit, "000008A2", 8) == 0 || /* device name */ memcmp(unit, "00001324", 8) == 0 || /* device sn */ memcmp(unit, "0001046B", 8) == 0) { /* drm key */ printf("Skipping unit %s\n", unit); continue; }

boot bundle is determined by btinf file which is generated by xflasher during noloader or loader processing so it will skip flashing boot bundle if didn't found perfect match for determining files

Ok I tried it on the Z5, including TA stuff and bootdelivery (which returned an error)
https://pastebin.com/U5FH8VQn
Good news is, I'm not bricked! :cowboy:

munjeni · May 20, 2017

shoey63 said:
Ok I tried it on the Z5, including TA stuff and bootdelivery (which returned an error)
https://pastebin.com/U5FH8VQn
Good news is, I'm not bricked!

Its ok! TA file which failed is reset-non-secure-adb.ta , its skipped becuse xflasher can't handle ta file which contain this:

Code:

// Miscta file that resets miscta unit 2486 (hex:0x9B6)
// TA_ENABLE_NONSECURE_USB_DEBUG to empty data.
// This file is included in the fsp.zip.
// Ta files included in the fsp-zip will get automatically flashed by Emma.

// Miscta ta partition
02

// format: Unit, size, [COLOR="Red"]data[/COLOR]:
[COLOR="Blue"]000009B6 0000[/COLOR]

blue (unit, size and missing data) which contain empty data xflasher can't flash since I don't know how to send null data to device, thats nonsense for me, better lieave it as is. When I get time I will sniff usb packets on something like that.

About boot delivery, Error: boot_delivery.xml not exist in boot folder! thats because you don't have boot_delivery.xml inside boot folder, to get it working its not enought to extract ftf boot delivery since ftf format contain .sin extension like .sinb (have no idea why Androxyde renamed .sin extension in boot bundle to .sinb), but xflasher (as I mentioned need to be used with xperifirm which didn't rename .sin files and didn't archive things to .ftf, if you need to flash boot delivery you need to put boot_delivery.xml file to boot folder and make sure all files in boot folder is not .sinb it must be .sin, than xflasher will be able to flash boot delivery! If you realy need to extract ftf than you must rename all .sinb files to .sin and move boot_delivery.xml to boot folder. Better idea and most complete compatible idea is use xflasher in combination with xperifirm, no need to touch anything, just double click to xflasher.exe, modify newly generated xflasher.bat for need and done, so simple

shoey63 · May 20, 2017

munjeni said:
Its ok!...

Yep it's all good

And I agree with you about FSC script. why the need for that? All that is happening is you are flashing partitions, similar to dd command :laugh:

munjeni · May 20, 2017

shoey63 said:
Yep it's all good
And I agree with you about FSC script. why the need for that? All that is happening is you are flashing partitions, similar to dd command :laugh:

SIN can't be flashed directly using DD, it must be extracted first. About FSC, Androxide implemented that because wanted to make things identic to like flashing with emma, but I definitelly think by implementing that he totaly make "un-love" flashtool for peoples, that thing is realy no need since things worked like a charm before that fsc things. I made xflasher for educating byself and for fun, it didn't need java dependency, its just an native binary without dependencies (ofcourse gordon usb driver is need)

shoey63 · May 20, 2017

Yeah, very painful waiting for new FSC scripts. Gordon USB driver? Must be native on Windows 7 x64, or downloaded silently. Anyway, it's there.
I would test on my X but there is no FTF, due to being on concept 7.1.2 firmware. The program is EOL so no way to get back if I flash stock FTF.

munjeni · May 20, 2017

shoey63 said:
Yeah, very painful waiting for new FSC scripts. Gordon USB driver? Must be native on Windows 7 x64, or downloaded silently. Anyway, it's there.
I would test on my X but there is no FTF, due to being on concept 7.1.2 firmware. The program is EOL so no way to get back if I flash stock FTF.

You can flash cache just to see if it working

Nonloader is allready supported, somebody in this thread sucesfully flashed cache, I am prety sure the rest is the same. Old devices have s1 boot and needs loader.sin to enter into s1 loader mode, on newer devices there is no more s1 boot, s1 loader is by default when you enter into flash mode so loader.sin is no more need. Simple change first line "loader.sin" to "noloader" the rest is the same. Support for new sin format allready implemented as you can see in kernel_dump tool it is success.

munjeni · May 22, 2017

V18 is out, implemented and tested on my own device only one thing which missed https://xdaforums.com/showpost.php?p=72365505&postcount=131 , now xflasher is fully complete, enjoy!

munjeni · May 27, 2017

Now v18 for Linux, enjoy! Soon I will do one for android so we will be able to flash phone by using another phone

shoey63 · May 28, 2017

munjeni said:
Now v18 for Linux, enjoy! Soon I will do one for android so we will be able to flash phone by using another phone

Trying Linux version on Xperia X (64bit device with no loader sin and bootloader locked)
Edit: not working

Code:

shoey@Mint-Sarah-18 ~/.flashTool/firmwares/Downloads/F5121_Customized AU_1302-3011_34.2.A.0.311_R5C $ ./xflasher.i386
-------------------------------------------------------
             Xperia Command Line Flasher               
                                                       
                 by Munjeni @ 2014-2017                     
-------------------------------------------------------

Usage:
  ./xflasher.i386 LOADER  DUMP_S1?  UNLOCK_KEY  USB_VID  USB_PID FLASH_BOOT_DELIVERY? FLASH_TA_FILE?

For example:
  ./xflasher.i386 loader.sin 0 AABBCCDDEEFF1122 0FCE ADDE 0 0

For more info double click exe and see xloader batch file!

Setting permission for xflasher.sh returned: ok
xflasher.sh script is created, see it!

shoey@Mint-Sarah-18 ~/.flashTool/firmwares/Downloads/F5121_Customized AU_1302-3011_34.2.A.0.311_R5C $ ./xflasher.sh
./xflasher.sh: line 20: ./xflasher: No such file or directory
shoey@Mint-Sarah-18 ~/.flashTool/firmwares/Downloads/F5121_Customized AU_1302-3011_34.2.A.0.311_R5C $ bash xflasher.sh
xflasher.sh: line 20: ./xflasher: No such file or directory

Edit2: Windows version stuck on kernel.sin

Code:

-------------------------------------------------------
             Xperia Command Line Flasher               
                                                       
                 by Munjeni @ 2014-2017                     
-------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_adde#5&3879604a&0&5#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: Universal Serial Bus controllers
Device Instance Id: USB\VID_0FCE&PID_ADDE\5&3879604A&0&5

Proccessing kernel_S1-SW-LIVE-D553-PID1-0006-MMC.sin...
File size: 0x1258AAF
Sin header size: 0x918
Sin data size: 0x1258197
Setting max packet size to: 0x400000
Sending command...
Raw command[0xD]:

  00000000  00 00 00 05 00 00 00 03 00 00 09 18 1E           .............

Successfully write 0xd bytes to handle.
Writing sin header with size of 0x918 bytes
Successfully write 0x918 bytes to handle.
Sin header writen.
CRC32[0x4]:

  00000000  B0 64 6F F7                                      .do.

Writing crc32 for sin header...
Successfully write 0x4 bytes to handle.
Successfully read 0xd bytes from handle.
Raw input [0xD]:

  00000000  00 00 00 05 00 00 00 01 00 00 00 00 0B           .............

Verifying crc32...
success: device replied with 0000000500000001000000000B which mean ok.

Successfully read 0x4 bytes from handle.
Raw input [0x4]:

  00000000  00 00 00 00                                      ....

Sending command...
Raw command[0xD]:

  00000000  00 00 00 06 00 00 00 07 00 40 00 00 48           .........@..H

Successfully write 0xd bytes to handle.
Writing chunk part: 1 with size of 0x400000 bytes
Successfully write 0x400000 bytes to handle.
Chunk part: 1 writen.
CRC32[0x4]:

  00000000  23 E3 C8 F5                                      #...

Writing crc32 for chunk part: 1
Successfully write 0x4 bytes to handle.
Successfully read 0xd bytes from handle.
Raw input [0xD]:

  00000000  00 00 00 06 00 00 00 01 00 00 00 00 0E           .............

Verifying crc32...
Success: device replied with 0000000600000001000000000E which mean ok.

Successfully read 0x4 bytes from handle.
Raw input [0x4]:

  00000000  00 00 00 00                                      ....

Sending command...
Raw command[0xD]:

  00000000  00 00 00 06 00 00 00 07 00 40 00 00 48           .........@..H

Successfully write 0xd bytes to handle.
Writing chunk part: 2 with size of 0x400000 bytes
Successfully write 0x400000 bytes to handle.
Chunk part: 2 writen.
CRC32[0x4]:

  00000000  6E 74 98 8C                                      nt..

Writing crc32 for chunk part: 2
Successfully write 0x4 bytes to handle.
Successfully read 0xd bytes from handle.
Raw input [0xD]:

  00000000  00 00 00 06 00 00 00 01 00 00 00 00 0E           .............

Verifying crc32...
Success: device replied with 0000000600000001000000000E which mean ok.

Successfully read 0x4 bytes from handle.
Raw input [0x4]:

  00000000  00 00 00 00                                      ....

Sending command...
Raw command[0xD]:

  00000000  00 00 00 06 00 00 00 07 00 40 00 00 48           .........@..H

Successfully write 0xd bytes to handle.
Writing chunk part: 3 with size of 0x400000 bytes
Successfully write 0x400000 bytes to handle.
Chunk part: 3 writen.
CRC32[0x4]:

  00000000  31 66 3F 98                                      1f?.

Writing crc32 for chunk part: 3
Successfully write 0x4 bytes to handle.
Successfully read 0xd bytes from handle.
Raw input [0xD]:

  00000000  00 00 00 06 00 00 00 01 00 00 00 00 0E           .............

Verifying crc32...
Success: device replied with 0000000600000001000000000E which mean ok.

Successfully read 0x4 bytes from handle.
Raw input [0x4]:

  00000000  00 00 00 00                                      ....

Sending command...
Raw command[0xD]:

  00000000  00 00 00 06 00 00 00 07 00 40 00 00 48           .........@..H

Successfully write 0xd bytes to handle.
Writing chunk part: 4 with size of 0x400000 bytes
Successfully write 0x400000 bytes to handle.
Chunk part: 4 writen.
CRC32[0x4]:

  00000000  72 7D DB 02                                      r}..

Writing crc32 for chunk part: 4
Successfully write 0x4 bytes to handle.
Successfully read 0xd bytes from handle.
Raw input [0xD]:

  00000000  00 00 00 06 00 00 00 01 00 00 00 00 0E           .............

Verifying crc32...
Success: device replied with 0000000600000001000000000E which mean ok.

Successfully read 0x4 bytes from handle.
Raw input [0x4]:

  00000000  00 00 00 00                                      ....

Sending command...
Raw command[0xD]:

  00000000  00 00 00 06 00 00 00 03 00 25 81 97 3D           .........%..=

Successfully write 0xd bytes to handle.
Writing chunk part: 5 with size of 0x258197 bytes
Successfully write 0x258197 bytes to handle.
Chunk part: 5 writen.
CRC32[0x4]:

  00000000  08 09 E0 1A                                      ....

Writing crc32 for chunk part: 5
Successfully write 0x4 bytes to handle.
WRITING LAST PACKET. SETTING TIMEOUT TO 600000 (ms).
Successfully read 0xd bytes from handle.
Raw input [0xD]:

  00000000  00 00 00 06 00 00 00 00 00 00 00 00 0D           .............

Verifying crc32...
Error: device reported that crc32 for chunk part: 5 is not ok!
Error uploading kernel_S1-SW-LIVE-D553-PID1-0006-MMC.sin!

munjeni · May 28, 2017

Thanks a lot! Linux version corected (that no xflasher error is because you have used xflasher.XXX so it is no more xflasher as a name, you must rename xflasher binary to xflasher!), anyway v19 is out and you no more need to rename anything, tool will rename string in script by default to match binary name). Now I have added support for arm32 and arm64 and also linux32 and linux64 version, tested arm version on my phone and succesfully flashed seccond phone trought my main phone, screenshoot!

Can you give me flashtool debug log using the same kernel? Probably protocol need very small modification since only last packet is failed, probably that final reaply 00 00 00 06 00 00 00 00 00 00 00 00 0D is ok in case noloader version, but need to figure it first to be sure before I change tool a bit! Is your device soft bricked after that error?

shoey63 · May 28, 2017

Will get back to you later. I unlocked the bootloader again before checking for soft brick. LB is too much hard work ?
Edit: How do you unlock/ relock bootloader with xflasher?

[TOOL] Xflasher (xperia command line flasher for pre 2017 devices)

Senior Member

Senior Member

Senior Member

Senior Member

Recognized Contributor

Senior Member

Senior Member

Recognized Contributor

Senior Member

Recognized Contributor

Senior Member

Recognized Contributor

Senior Member

Recognized Contributor

Senior Member

Senior Member

Senior Member

Recognized Contributor

Senior Member

Attachments

Recognized Contributor

Similar threads

Top Liked Posts