Factory Restore Tool

[Wikiwide 19]

Alright. How do I do EDL flash (with phone reporting to be in QDL mode)? Is it possible to flash partitions separately from each other? Like, flash partition A, try to boot, if it doesn't boot, flash partition B, try booting again, if it doesn't work, flash partition C?

Or, even better, check which partitions, exactly, are corrupted and require flashing, and flash those and only those partitions?

I am also quite worried whether the phone has sufficient battery left for operations such as flashing, because my laptop is ~10yo, and its USB port is not USB3 - would not deliver lots of current.

All partitions that I flashed, were reported as surprisingly small - a few MBs, maybe, but definitely not GBs. So, Sailfish OS and user files might be alright, it's "just" the boot-related partitions that suffered?

Thank you. Best wishes.

~~~~~~~~~~~~~~~~~

Per aspera ad astra...

[Gigadoc2 54]

It looks like QDL mode is EDL mode -- at least when I put my device into EDL mode it is listed as "QDL mode" in `lsusb`.

As it seems the only tool we have for EDL flashing is the one from this thread, you can't really cherry-pick partitions to flash. However, the tool offers the "Base only" option. I have not tried that, but according to tdm's page here, "base only" will keep most of the "high-level" partitions intact, so it might leave SailfishOS mostly untouched.

What you can't do in any case is checking which partitions are "corrupt", as far as I know neither EDL nor fastboot allow you to read data, it will only write it.

 

[Wikiwide 19]

Thank you! I have created the /etc/udev/rules.d/99-qcom.rules file, downloaded the programmer for Linux, checked that libjpeg.so.62 is available, and am downloading Factory Firmware - 2019-12-03 should be good, right? Will try Base Only, for start.

Thank you. Best wishes.

~~~~~~~~~~~~~~~~~

Per aspera ad astra...

[tdm 2,322]

3 hours ago, Wikiwide said:

...

 

@Wikiwide Please read my factory restore page here: http://files.nwwn.com/android/pro1/factory.html

 

This explains the function of the xbl partition, which in turn explains why you are stuck in EDL mode.  Note that EDL and QDL are pretty much interchangeable.  The device is failing to start and entering a state that allows you to restore it to a functional state.  This is marked by the USB device ID 05c6:9008 which is the definitive indication that EDL mode is active.

 

Unfortunately, Sailfish seems to be producing a steady stream of bricks and I'm afraid it won't let up until the developers somehow figure out how to disable formatting the internal partitions.

 

I have been working with two other folks who have also overwritten xbl on their devices under Sailfish.  I've updated my code to properly flash all of the partitions (including xbl) and given test copies to them.  One has successfully fixed his device and I'm waiting on the other to confirm.  I'll update my restore tool over the next day or two with the fix and I'll let you know when it's done.

 

[tdm 2,322]

@Wikiwide do not worry about the age of your laptop or the charge in your phone battery.  EDL programming is not very demanding on speed or current, and the device does not use the battery at all in EDL mode -- it does not operate on battery power nor charge the battery.  In fact, if you disassemble the device, you will find that you do not even need to have the battery connected to use EDL mode.

 

[tdm 2,322]

Hmm, so it looks like you are using Linux and you are rather anxious to get your device working.  I can't blame you.  🙂  Please try this test version of the programmer.  It is a CLI version, and it has the fix to flash xbl properly:

 

http://files.nwwn.com/android/pro1/qfpkg_cli.gz

 

And a smaller "base" version of the 20191028 package which does not flash system, vendor, userdata, etc.:

 

http://files.nwwn.com/android/pro1/QX1000_user_20191028_base.qfp

 

Please report back and let us know how it goes.  🙂

 

[tdm 2,322]

1 hour ago, Gigadoc2 said:

It looks like QDL mode is EDL mode -- at least when I put my device into EDL mode it is listed as "QDL mode" in `lsusb`.

As it seems the only tool we have for EDL flashing is the one from this thread, you can't really cherry-pick partitions to flash. However, the tool offers the "Base only" option. I have not tried that, but according to tdm's page here, "base only" will keep most of the "high-level" partitions intact, so it might leave SailfishOS mostly untouched.

What you can't do in any case is checking which partitions are "corrupt", as far as I know neither EDL nor fastboot allow you to read data, it will only write it.

 

Actually EDL can both read and write. And that means you can read the GPTs, parse them, and do all sorts of cool things. But most people only want to get their device running again and in the most foolproof way possible. So all EDL tools I've ever seen only have logic to write everything from the factory package. On the other hand, you rarely see factory packages due to security reasons.  My tool is unique in that it allows you to only flash the base data. And that it runs on many different OS's, etc.

 

 

[Polaris 423]

4 hours ago, Wikiwide said:

What is xbl partition(s)? The device(s) in question were bricked (unresponsive?) due to corrupted xbl(_a) partition(s)? Is it possible to flash only the corrupted partition, and restore the device, without having to overwrite any other partitions (with OS and personal files)? [Overwriting is an option as well, but only as last resort, if nothing else helps]

The instructions at http://files.nwwn.com/android/pro1/factory.html speak of EDL mode. My device appears to be in QDL mode - how different is that from EDL mode? I have initially thought that the phone has run out of battery to the extent that it cannot even charge anymore, but I cannot be sure if that's the cause (the phone went from 21% charged, to black-brick, within a span of few hours) without disassembling the device and checking the battery's voltage [and I would rather not disassemble the device at this point].

I didn't format any sdb devices that I know of, but I did try to use a microSD card in Fxtec-Pro1-Sailfish-OS, and saw way too many partitions here (when I would have expected the microSD card to have only one partition, based on Nokia N900's easy display of it in File Manager), with most of them requesting to be formatted (I did format two or three of the dozen(s) of partitions, so now even Nokia N900 cannot read the microSD card anymore). I do hope that neither of the partitions that were formatted in Sailfish OS GUI were internal memory of the device.

I believe QDL mode on this device is just Qualcomm EDL mode.  Thus, you are actually in EDL mode and don't have anything to worry about in this regard.  However, your problem will be that I don't THINK that @tdm has uploaded his corrected tool yet.  I know he was working with @EvilDragon to get a device unbricked and discovered that his tool (thank you again to him for creating it!) wasn't actually writing all the data it indicated it was writing.  I believe this to be the case because after he posted about it, I attempted to d/l the tool again, but it appeared to be the same version as the one with the bug(s).  Thus, I'm afraid that you are going to need to first reach out to him about your problem.  As far as I know, he's the only one that can help you at this point.

As for the formatting, I think you were actually formatting Sailfish partitions while believing to be writing external SD partitions.  I haven't attempted to load SailfishOS, but just from what I have read here in this forum, it appears as though a few people have bricked their devices by accidentally formatting, or overwriting, Sailfish partitions.  You're not alone, and I can only assume that this will be (or at least it should be) address in the future!

Good luck and reach out to @tdm for verification about his updated restore tool.

Edit: Clearly, I should have read the next page of this thread to see that @tdm has already addressed this and has a new link.  You should now be all set!  Many many thanks to @tdm for once again helping all of us keep our devices alive and running (and at a level well above typical factory support at that).  Definitely do report back with your results as he has requested.  There are many of us very interested in your issue, and wish you well with being able to recover without losing too much (hopefully the case).

Edited February 8, 2020 by Polaris

[Wikiwide 19]

1 hour ago, tdm said:

Hmm, so it looks like you are using Linux and you are rather anxious to get your device working.  I can't blame you.  🙂  Please try this test version of the programmer.  It is a CLI version, and it has the fix to flash xbl properly:

 

http://files.nwwn.com/android/pro1/qfpkg_cli.gz

 

And a smaller "base" version of the 20191028 package which does not flash system, vendor, userdata, etc.:

 

http://files.nwwn.com/android/pro1/QX1000_user_20191028_base.qfp

 

Please report back and let us know how it goes.  🙂

 

Yes! Thank you 🙂 It went beautifully. I tried with

qfpkg_cli --flash base --nodo ../QX1000_user_20191028_base.qfp

first, just to see how it goes, validates the file and verifies the package... And then

qfpkg_cli --flash base ../QX1000_user_20191028_base.qfp

which restored the device excellently; don't know what the white LED light stands for, but it booted into OS automatically (as promised).

Battery was at 3%, by now, so I plugged it into the Qualcomm charger right away.

Going by my ambience at login screen, the files and settings are intact 🙂

So, not using memory card / Storage / format-a-partition with Sailfish OS until Sailfish OS gets better at separating system/boot partitions from user partitions, or just on-phone partitions from memory-card partitions 😉

Thank you! Best wishes.

~~~~~~~~~~~~~~~~~

Per aspera ad astra...

[Gigadoc2 54]

12 hours ago, tdm said:

It is a CLI version, […]

Yass!

11 hours ago, tdm said:

Actually EDL can both read and write. And that means you can read the GPTs, parse them, and do all sorts of cool things. But most people only want to get their device running again and in the most foolproof way possible. So all EDL tools I've ever seen only have logic to write everything from the factory package. On the other hand, you rarely see factory packages due to security reasons.  My tool is unique in that it allows you to only flash the base data. And that it runs on many different OS's, etc.

Oh, that sounds very interesting!

How much is your tool dependent on the NDA stuff F(x)tec gave you? Do you think it is possible to develop something like it as open source, and add reading capabilities to it? I mean, that sounds like a prime way to fully, completely, back up your device :D

But apart from that, if you can read flash with EDL, doesn't that kind of defeat locked bootloaders? As in, now I can dump the data from the phone before I tamper with it to get the decryption key? Or is that completely mitigated by a part of the encryption key being stored in a secure element which is not dumped via EDL?

[tdm 2,322]

4 minutes ago, Gigadoc2 said:

Yass!

Oh, that sounds very interesting!

How much is your tool dependent on the NDA stuff F(x)tec gave you? Do you think it is possible to develop something like it as open source, and add reading capabilities to it? I mean, that sounds like a prime way to fully, completely, back up your device 😄

But apart from that, if you can read flash with EDL, doesn't that kind of defeat locked bootloaders? As in, now I can dump the data from the phone before I tamper with it to get the decryption key? Or is that completely mitigated by a part of the encryption key being stored in a secure element which is not dumped via EDL?

 

The device encryption/signing keys are not kept in flash, they are in a separate non-volatile storage which cannot be read outside of TEE (the walled-off "trusted" environment).  So no, it does not defeat locked bootloaders nor does it expose your userdata (because userdata is encrypted with a complicated algorithm that uses both the device encryption key and your passcode).  But it does mean that if you aren't encrypting your userdata, it can be trivially exfiltrated.  Which is one of the main reasons I won't make a build that uses unencrypted userdata.

 

I have not signed any NDA with FxTec.  They provided the factory package to developers, which contains the programmer (aka. "firehose").  That is all.

 

The code for the tools was written when I worked at cyngn.  It was intended to be used for their factory restore tool.  But that never happened because the company died.  So I was left with a bunch of nice code and nothing to do with it.  This is a perfect opportunity to use it.  🙂

 

Note that the documents describing the protocols are proprietary to Qualcomm and not publicly released.  But since Linaro has released their QDL flashing tool, they cannot realistically be considered secret anymore.

 

 

[Gigadoc2 54]

Ok, so the restore-tool sends the idealte-signed (or is it qualcomm-signed?) firehose programmer to the phone, and then communicates with said programmer over USB to send it the stuff it has to flash (or receive whatever it reads), am I getting this right?

So in theory, if one were to take the signed firehose from your tool it could be used with the Linaro tool or something similar?

And I take it that you don't have the firehose source (and if you had you couldn't sign the resulting binary), but what with the code from cyngn? I suppose you are not at liberty to release the source of it? 😇

[tdm 2,322]

1 hour ago, Gigadoc2 said:

Ok, so the restore-tool sends the idealte-signed (or is it qualcomm-signed?) firehose programmer to the phone, and then communicates with said programmer over USB to send it the stuff it has to flash (or receive whatever it reads), am I getting this right?

So in theory, if one were to take the signed firehose from your tool it could be used with the Linaro tool or something similar?

And I take it that you don't have the firehose source (and if you had you couldn't sign the resulting binary), but what with the code from cyngn? I suppose you are not at liberty to release the source of it? 😇

Yes, the device boot ROM communicates with a very simple protocol to download firehose, which is an ELF binary. After verification, it simply runs the binary not unlike running a command from a terminal.

 

I'm not sure if the OEM builds the firehose, but they do sign it. An OEM typically has a separate signing key for each device model.

 

Yes the firehose can be used with any tool.  And of course access to the firehose can be dangerous. This is one reason the qfp file is not a simple zip file.

 

No I don't have firehose source. But I could look into releasing some of my code on github.

 

[Wikiwide 19]

I am wondering how to change the boot-wallpaper. The "Fxtec Pro1 powered by Android" one. I like Fxtec Pro1 logo, yellow looks fairly good on black... But, I don't like the "powered by Android" bit. Even if there is a mini-Android running inside modem (and I am not going to look into that anytime soon), the phone itself is now running Sailfish OS, and I would appreciate a visible reflection of this.

I think the boot-wallpaper shows up when booting into OS itself, so it's probably post-ABL. In fact, I have found bootanimation.zip under /system/media/ - it contains lots of images, from "black" to "black with yellow logo" to "black with yellow logo and white text". Buuut, the white text contains only Pro1, not "powered by Android". So, it doesn't answer the question of where "powered by Android" is hiding! Could somebody please help with this? Best case, there will soon be a new thread, full of open-licence community-contributed boot-images/animations for Fxtec Pro1 😉

Thank you. Best wishes,

~~~~~~~~~~~~~~~~~

Per aspera ad astra...

P.S. Moderators, please, feel free to move this post to a different/new thread, especially if the wallpaper/"powered by Android" is not "hard-coded" inside some part of firmware.

[tdm 2,322]

11 minutes ago, Wikiwide said:

I am wondering how to change the boot-wallpaper. The "Fxtec Pro1 powered by Android" one. I like Fxtec Pro1 logo, yellow looks fairly good on black... But, I don't like the "powered by Android" bit. Even if there is a mini-Android running inside modem (and I am not going to look into that anytime soon), the phone itself is now running Sailfish OS, and I would appreciate a visible reflection of this.

I think the boot-wallpaper shows up when booting into OS itself, so it's probably post-ABL. In fact, I have found bootanimation.zip under /system/media/ - it contains lots of images, from "black" to "black with yellow logo" to "black with yellow logo and white text". Buuut, the white text contains only Pro1, not "powered by Android". So, it doesn't answer the question of where "powered by Android" is hiding! Could somebody please help with this? Best case, there will soon be a new thread, full of open-licence community-contributed boot-images/animations for Fxtec Pro1 😉

Thank you. Best wishes,

~~~~~~~~~~~~~~~~~

Per aspera ad astra...

P.S. Moderators, please, feel free to move this post to a different/new thread, especially if the wallpaper/"powered by Android" is not "hard-coded" inside some part of firmware.

This is in the splash partition. It's a BMP file with a custom header prepended. I don't know the header format off the top of my head though. Feel free to play with it, it's a rather easy customization.

 

Also please note the "powered by Android" text, including font, size and color, is mandated by Google for play store certification. There is no use requesting that FxTec change it.

 

[Craig 1,435]

24 minutes ago, Wikiwide said:

I am wondering how to change the boot-wallpaper. The "Fxtec Pro1 powered by Android" one. I like Fxtec Pro1 logo, yellow looks fairly good on black... But, I don't like the "powered by Android" bit. Even if there is a mini-Android running inside modem (and I am not going to look into that anytime soon), the phone itself is now running Sailfish OS, and I would appreciate a visible reflection of this.

I think the boot-wallpaper shows up when booting into OS itself, so it's probably post-ABL. In fact, I have found bootanimation.zip under /system/media/ - it contains lots of images, from "black" to "black with yellow logo" to "black with yellow logo and white text". Buuut, the white text contains only Pro1, not "powered by Android". So, it doesn't answer the question of where "powered by Android" is hiding! Could somebody please help with this? Best case, there will soon be a new thread, full of open-licence community-contributed boot-images/animations for Fxtec Pro1 😉

Thank you. Best wishes,

~~~~~~~~~~~~~~~~~

Per aspera ad astra...

P.S. Moderators, please, feel free to move this post to a different/new thread, especially if the wallpaper/"powered by Android" is not "hard-coded" inside some part of firmware.

Got an easy way for you to do it - there's an app on openrepos for it.

https://openrepos.net/content/coderus/splashscreen-changer

Have you looked at the links on the sailfish wiki?  The manual method is described there, along with some sample screens, including one that just changes 'powered by android' to powered by sailfishos' or whatever.  And we can do full 2160x1080 even.

https://together.jolla.com/question/220410/wiki-fxtec-pro1-sailfish-os-tips-and-tricks

And by the way, you need to figure out how to stop spamming  "Thank you. Best wishes,  ~~~~~~~~~~~~~~~~~ Per aspera ad astra..."  every friggen time you post. 

 

Edited February 12, 2020 by Craig

[Wikiwide 19]

15 minutes ago, tdm said:

This is in the splash partition. It's a BMP file with a custom header prepended. I don't know the header format off the top of my head though. Feel free to play with it, it's a rather easy customization.

 

Also please note the "powered by Android" text, including font, size and color, is mandated by Google for play store certification. There is no use requesting that FxTec change it.

 

Thank you! FxTec doesn't have to change it, but users being able to change it is a nice option to have - just like unlocking bootloader 😉

 

9 minutes ago, Craig said:

Got an easy way for you to do it - there's an app on openrepos for it.

https://openrepos.net/content/coderus/splashscreen-changer

Have you looked at the links on the sailfish wiki?  The manual method is described there, along with some sample screens, including one that just changes 'powered by android' to powered by sailfishos' or whatever.  And we can do full 2160x1080 even.

https://together.jolla.com/question/220410/wiki-fxtec-pro1-sailfish-os-tips-and-tricks

And by the way, you need to figure out how to stop spamming  "Thank you. Best wishes,  ~~~~~~~~~~~~~~~~~ Per aspera ad astra..."  every friggen time you post.

Thank you for the link! I should have searched for the app in the Storeman before asking the question, but then, I wouldn't have guessed that it's called splashscreen.

Just installed it 🙂

Sailfish wiki, is it this one? https://sailfishos.org/wiki/SailfishOS Will read up, thank you 🙂

Ah, the post ending is something I usually type manually, in lieu of signature. Sorry, didn't know it could be annoying 😕

Best wishes, anyway!

[Craig 1,435]

5 minutes ago, Wikiwide said:

Sailfish wiki, is it this one? https://sailfishos.org/wiki/SailfishOS Will read up, thank you

https://together.jolla.com/question/220410/wiki-fxtec-pro1-sailfish-os-tips-and-tricks

(it was there in the previous post too)

[tdm 2,322]

FYI... for those following this thread:

 

The Linux and Windows tools have been updated and now flash xbl properly. This has been verified with real bricked devices (no shortage of those recently!) I'll try to update the MacOS version within a day or two.

 

I asked the Sailfish developers to please remove the option to flash internal storage partitions. They had no idea so many people were doing this, and said they would fix it soon. That's great, but why didn't they know? Did nobody file a bug report or anything after bricking their device?!?

 

[Craig 1,435]

Yep, somebody did, but not after bricking their device - after noticing the odd partitions back dec 19, its common knowledge in sfos chatrooms I believe, but lotsa new ppl got devices recently.

It's on the github issue tracker...  https://github.com/sailfish-on-fxtecpro1/droid-config-t5/issues/24

 

[Gigadoc2 54]

5 hours ago, tdm said:

I asked the Sailfish developers to please remove the option to flash internal storage partitions. They had no idea so many people were doing this, and said they would fix it soon. That's great, but why didn't they know? Did nobody file a bug report or anything after bricking their device?!?

It's not an intentional option... I don't really know how the SailfishOS porting process is supposed to work, but I have a Jolla and compared some of the things we found out in the chat with the Jolla; and to me it looks like you mostly take the userland from the Jolla, add changes and put that onto the new phone.

Now, I don't know how familiar you are with desktop Linux (I have no idea if your interest is mainly Android or Linux in general), but if you are familiar: SailfishOS is very much like a desktop Linux distribution, amongst other things it is using systemd, udev and udisks2. Now it seems that dirty OEM hacks are not only a thing in Android, they seem to be in Sailfish too: Sailfish has modified the udev rules for udisks2 (in /lib/udev/rules.d/80-udisks2.rules), adding rules that automount all mountable partitions from SD cards and USB sticks (to be precise: they add a dependency for that device on an instanciated systemd service which starts after the user session is up (via a dependency) and calls udisksctl as user nemo to mount the specified device). Problem is, they just hardcoded a matching rule which only works for the Jolla itself (or similar phones): It matches every mmcblk device except mmclbk0 (internal storage on the Jolla), and every partition on every sd[a-z] device. To hide the internal partitions on the Jolla, they just hardcoded the same matching rule in the storage settings. What I probably don't need to tell you: The Pro1s storage appears to the kernel not as mmcblk0, but various sd* devices. So, the internal partitions not only show up in the storage UI, the system even tries to mount them all xD

That, btw, is also the reason why Sailfish currently can't mount the SD on the pro1, it is instead recognized as internal storage.

Now, here is where my knowledge about udev and udisks ends: On desktops, udisks is aware of which drives are internal and which are externally attached drives, but I don't know how exactly. Udisks is meant for users to mount or format their USB sticks and such without needing root rights, but then it does not allow them to do such to internal storage. Now the proper solution would be for Sailfish in general to use that facility and properly mark the internal storage. If that is also done with udev rules, there could be one rule file specific to the device, making it easy to port to different hardware. But I suppose that is something Jolla has to change, so for now the porters will have to do with somehow overwriting both the storage app and the udev rules :(

Edited February 12, 2020 by Gigadoc2

[oliviersenn6 47]

sorry to dig up an old thread, but i'm having trouble with this.
 

i used it once to do a full factory restore because i couldn't install updates and it worked fine. then after doing an update and rooting, i couldn't install any more updates (probably my fault) so I used this tool again.

now my phone can only boot to EDL or fastboot (which says it's locked, although that's not exactly a problem). if I try to flash either one of the 2 QFPs you provide, the result is the same, if I don't enter EDL the phone boots to fastboot no matter what i try.

additionnal info:

i'm using windows and have followed the instructions on your website. I am using a USB 3.0 port and the cable that came with the phone.

fastboot seems to be responding correctly but flashing a vanilla or magisk-patched boot.img doesn't appear to change my issue.

i did try to run this tool again and the result is the same.

 

thanks in advance

[VaZso 1,997]

9 minutes ago, oliviersenn6 said:

now my phone can only boot to EDL or fastboot (which says it's locked, although that's not exactly a problem). if I try to flash either one of the 2 QFPs you provide, the result is the same, if I don't enter EDL the phone boots to fastboot no matter what i try.

Just a question not related to your problem.

Can you boot to EDL using a method of pulling data line to GND (using a button for  example)?

What problem you have when you try to flash the phone? It goes through but fails to boot then?

[oliviersenn6 47]

i'm not sure what you mean, but i can enter EDL by pressing both volume buttons down and then the power button.

when i flash the phone using this tool, the flash process goes correctly but i always end up in fastboot. if I had unlocked the bootloader, it becomes locked again, so I can tell that it's doing something but it doesn't appear to work.

[oliviersenn6 47]

alright so that just fucking happened.

since my phone wasn't booting, i decided "hey you know what there can be no harm in trying to install lineageOS, worst case scenario it doesnt work and i'm back at square one."
so i flashed the boot.img for lineageos from tdm's website and the phone tries to boot into it and shows the lineage loading screen, but ultimately fails and ends up in a boot loop.

So i used this tool yet again to actually go back to square one.

and now my phone boots.

what the hell is happening i'm so confused