pro1x Pro1X - Stock Android OS (Build Number: v2.1.2_20220707)

[mattock 8]

Thanks @mosen

Reflashed (edl on linux) stock android, edl reset, and used edl to flash stock persist.

I now have landscape rotation, keyboard backlight, but still no main camera.

I guess my backup persist partition has become useless somehow. I'll investigate by mounting it on loopback when I have time.

[sspiff 29]

1 minute ago, mattock said:

I guess my backup persist partition has become useless somehow. I'll investigate by mounting it on loopback when I have time.

Before you do, can you try flashing it back (it will break the sensors again), and try if device attestation still works for you? I backed up my persist partition when device attestation still worked (but rotation etc did not), and reflashing the original backup did not restore attestation. I'm just curious if this is just me having messed up somewhere, or if there is more going on here.

[ducksoup 110]

4 hours ago, sspiff said:

Before you do, can you try flashing it back (it will break the sensors again), and try if device attestation still works for you? I backed up my persist partition when device attestation still worked (but rotation etc did not), and reflashing the original backup did not restore attestation. I'm just curious if this is just me having messed up somewhere, or if there is more going on here.

Same situation here.  I had broken sensors, but working attestation, but then when I reflashed my persist backup, which ostensibly valid keys, I lost attestation.

[EskeRahn 5,471]

7 minutes ago, ducksoup said:

Same situation here.  I had broken sensors, but working attestation, but then when I reflashed my persist backup, which ostensibly valid keys, I lost attestation.

So does this mean that you have proved that restoring a saved persist image is NOT enough to keep key-attestation, as we thought?

[ducksoup 110]

Just now, EskeRahn said:

So does this mean that you have proved that restoring a saved persist image is NOT enough to keep key-attestation, as we thought?

I wouldn't claim to have proven anything, since I don't claim to know much about attestation (this is my first device that even supports it).  Just reporting what I did and what I got.  🙂 

[EskeRahn 5,471]

So we better tag @Casey here as this means some extra tests are needed, that only sensibly can be made by someone that can easily add new key-attestation when lost, and I guess that means internally at FxTec.

[EskeRahn 5,471]

Ah well 'proved' was a very hard word. 'suggested' might be better 😉

Just to be sure, did you restore on top of a freshly reflashed stock image (following casey's guide) - before booting it? Or did you do something else?

[sspiff 29]

2 hours ago, ducksoup said:

Same situation here.  I had broken sensors, but working attestation, but then when I reflashed my persist backup, which ostensibly valid keys, I lost attestation.

I'm sorry for your loss. But it seems like there is more going on than we currently understand with the attestation keys. Thank you for confirming this.

[sspiff 29]

2 hours ago, EskeRahn said:

So does this mean that you have proved that restoring a saved persist image is NOT enough to keep key-attestation, as we thought?

That does seem to be the case here 😞

[ducksoup 110]

13 hours ago, EskeRahn said:

Just to be sure, did you restore on top of a freshly reflashed stock image (following casey's guide) - before booting it? Or did you do something else?

I have freshly reflashed using QFIL in Windows just be sure, then flashed my persist backup on top, and it does not pass key attestation.

I know this persist "should" be good, because I backed it up a while ago, before successfully testing key attestation.  In my earlier testing, after seeing successful key attestation, I flashed stock persist on top in order to fix my sensors (which worked), then flashed my backup persist back on top of that, expecting to lose sensors and regain attestation, and I did not regain attestation (but did lose sensors as anticipated).

11 hours ago, sspiff said:

I'm sorry for your loss. But it seems like there is more going on than we currently understand with the attestation keys. Thank you for confirming this.

Hehe, no worries, this device won't be running Android in the long run anyway, so I don't mind taking one for the team as it were.  😉 

[sspiff 29]

32 minutes ago, ducksoup said:

I know this persist "should" be good, because I backed it up a while ago, before successfully testing key attestation.  In my earlier testing, after seeing successful key attestation, I flashed stock persist on top in order to fix my sensors (which worked), then flashed my backup persist back on top of that, expecting to lose sensors and regain attestation, and I did not regain attestation (but did lose sensors as anticipated).

This is the same thing I observed with my device.

[EskeRahn 5,471]

1 hour ago, ducksoup said:

I have freshly reflashed using QFIL in Windows just be sure, then flashed my persist backup on top, and it does not pass key attestation.

I know this persist "should" be good, because I backed it up a while ago, before successfully testing key attestation.  In my earlier testing, after seeing successful key attestation, I flashed stock persist on top in order to fix my sensors (which worked), then flashed my backup persist back on top of that, expecting to lose sensors and regain attestation, and I did not regain attestation (but did lose sensors as anticipated).

Hehe, no worries, this device won't be running Android in the long run anyway, so I don't mind taking one for the team as it were.  😉 

Thanks so we now know that it is important but NOT sufficient to backup the persist partition, so now the big question is what ALSO should be backed up?

(And without the ability to add key-attestation, it is hard for us to test, unless we initially backup EVERYTHING from a device that still got the keys....)

[matf-kabouik 414]

@mosen said he has successfully restored a backed up persist and passed attestation test, so it would be great to have his view on it and know exactly what he did before concluding on that matter.

Edited August 18, 2022 by matf-kabouik

[EskeRahn 5,471]

27 minutes ago, matf-kabouik said:

@mosen said he has successfully restored a backed up persist and passed attestation test, so it would be great to have his view on it and know exactly what he did before concluding on that matter.

Indeed and maybe also what he did not *LOL*
That is more precisely narrow down the difference between what @ducksoup and @mosen did.

Since restoring the Persist helped Mosen, we can conclude that it is needed

But since it did not for Docksoup, we can also conclude that restoring it is not enough.

• Maybe it is HOW they did the backup and/or the restore that was different? e.g. file rights,
• Maybe what Ducksoup did 'damaged' more than what Mosen did?
• Maybe Mosen restored something else, that also matters?

  It will require more thorough tests to say for sure what is sufficient.

[matf-kabouik 414]

Mosen definitely backed fsc, fsg, modemst1, modemst2 and persist (which I advise to do as well, they're only taking up 40MB of storage space on your disk), but I don't know if he restored them all.

[EskeRahn 5,471]

If no one else find a solution before that, I plan to try to backup everything from the retail unit that I hope to get soon, as well as the early unit in the state it is, and then see If I can wipe the early unit completely with Casey's guide, and attempt to transfer the keys. It might not work as the 'serial numbers' (imei, mac etc) could be saved somewhere completely different, and they just might have to match the attestation keys... I do not know.

https://forum.xda-developers.com/t/info-android-device-partitions-and-filesystems.3586565/
 

Quote

PERSIST - contains data which shouldn't be changed after the device is shipped, e.g. DRM related files, sensor reg file (sns.reg) and calibration data of chips; wifi, bluetooth, camera etc.
Some package installers such as OpenGapps also make use of this partition to read configuration file.

EFS, MODEMST1, MODEMST2, FSG, BACKUP
These all are related to IMEI; a unique number used by GSM networks to identify and trace a mobile phone.
EFS may contain hardware info like configuration files, WiFi/BlueTooth MAC’s, IMEI (or ESN for a CDMA based device) etc.
EFS and MODEMST1 may be a single partition on some phones.
FSG (FileSystem Golden copy) and BACKUP are backups of MODEMST1 and MODEMST2 respectively. If MODEMST1 or MODEMST2 are erased (by wrong factory flashing say) and phone notices an invalid partition, FSG and BACKUP will be restored.
MODEMST1 and MODEMST2 also contains modem firmware files.
PARAM - stores a number of parameters, variables and settings of the hardware. It contains info whether MODEMST partitions are backed up or not. Also debug settings, custom ROMs flash count, current stage boot process etc.
 

 

[ducksoup 110]

48 minutes ago, EskeRahn said:

Maybe what Ducksoup did 'damaged' more than what Mosen did?

FWIW, I did not back up persist until after it was "damaged" to break the sensors.  However, when I flashed back everything stock except persist, using the edl Python tool and the process described here (I edited the xml to skip persist), I did still pass attestation in Android.

Then, I used fastboot to flash the stock persist.img, thus fixing sensors and breaking attestation.  Finally, I used fastboot to flash back my saved persist, and did not regain attestation.

I performed additional tests using QFIL to flash full stock image back, and then fastboot to replace persist with my backup, which again does not regain attestation.

One thing I did notice when testing with QFIL is that if I have broken sensors before a QFIL flash, I also have broken sensors after it, so I suspect QFIL is not messing with a persist partition if it already exists.  I have just noticed this once, however, and have not verified.

One thing I have not tried is using edl to flash my persist backup.  I can give that a try later today.

[matf-kabouik 414]

57 minutes ago, EskeRahn said:

If no one else find a solution before that, I plan to try to backup everything from the retail unit that I hope to get soon, as well as the early unit in the state it is, and then see If I can wipe the early unit completely with Casey's guide, and attempt to transfer the keys. It might not work as the 'serial numbers' (imei, mac etc) could be saved somewhere completely different, and they just might have to match the attestation keys... I do not know.

https://forum.xda-developers.com/t/info-android-device-partitions-and-filesystems.3586565/
 

 

As far as I understand, IMEI and whatnot should be in fsc, fsg, or more likely modemst1 and modemst2. Don't quote me on that though.

[mosen 202]

Sorry, still traveling.
Quick clarification, i did back up all mentioned partitions since i was advised so by someone that all of those are device specific and might help in the future.

For now, i only played with restoring persist.
That one always restored fine. I flashed like 20x back and fourth testing several broken states that lead into non-boot situations.
But was always able to get back to the backup state.

[ducksoup 110]

19 minutes ago, mosen said:

For now, i only played with restoring persist.
That one always restored fine.

Where you using fastboot or edl to flash it?

[mosen 202]

Strictly EDL on the Pro¹-X. Its very convenient not having to unlock the bootloader to flash imo. Having much experience with fastboot from doing user support over at AsteroidOS. I am using and debugging Fastboot a lot and i really appreciate to now learn about EDL more.

In AOS, we don't have rooting problems 😛 We even got our very own universal community bootloader with integrated adb server. So debugging a WearOS smartwatch and prepare it for porting is as easy as "fastboot --cmdline debug-ramdisk boot aos-bootimage.fastboot" to boot into the bootloader and have full adb. Where is the magician building such for the Pro¹-X 😅 But i guess thats reinventing TWRP when it comes to phones.

Edited August 18, 2022 by mosen

[ducksoup 110]

21 hours ago, ducksoup said:

One thing I have not tried is using edl to flash my persist backup.

Okay, I've now tried this, with no luck.  I QFIL flashed the whole device to stock Android, then used the edl Python script to write out my persist backup, and I've got the same place as I get with fastboot, i.e. broken sensors and no attestation.

Bit of a mystery.  Would be good to get more data from others, in case I've somehow just broken the keys in my persist backup and don't know it.

[mosen 202]

8 hours ago, ducksoup said:

Okay, I've now tried this, with no luck.  I QFIL flashed the whole device to stock Android, then used the edl Python script to write out my persist backup, and I've got the same place as I get with fastboot, i.e. broken sensors and no attestation.

Bit of a mystery.  Would be good to get more data from others, in case I've somehow just broken the keys in my persist backup and don't know it.

I must admit to not having full understood. Imo your case is isolated due to the instructions having been unclear over the last days. And you where possibly lead into some action i can not really follow.
First of all, it has never happened to me that flashing a persist that actually contained keys, did lead to the Key Attestation demo app to not show/use them.
There is a fix for the sensors folder now (updated in the backup, restore and repair partitions guide). Hopefully this will help everyone with broken sensors only.
To debug your case, lets start all over. I would first of all make sure you still have any keys remaining, after what ever happened.
The keys are visible in a mounted persist partition. 

For the one that is currently flashed, look into /mnt/vendor/persist/data after rooting the Pro¹-X using magisk.
For the hopefully many copies of your backup persist you took at any point in time:
Mount the local persist.img. In linux its just `mount persist.img <folder to mount to>`. For windows there are programs that can mount ext4 partition images, like DiskInternals Linux Reader.
When you explore the mounted partition, it looks like so when your keys are fine



If there is only two folders, sensors and a lost+found present, we are looking at a stock persist image without device specific data.
In case you got that data folder filled in any of your backups. But flashing it result in no visible keys for the Key Attestation demo app. I would try to apply the sensor fix method also to this folder, just by chance.

[sspiff 29]

3 hours ago, mosen said:

In case you got that data folder filled in any of your backups. But flashing it result in no visible keys for the Key Attestation demo app. I would try to apply the sensor fix method also to this folder, just by chance.

This is my situation, I have two backups of my persist partition, from when the phone had broken sensors but working attestation keys. They contain a data folder (with files similar to yours) and have only been copied (so I could modify the copy) or mounted read-only (to copy files from). restoring any of my persist backups with the data folder does not restore the attestation. I'm not at my PC until tomorrow night, but I will try out the restorecon method on the data folder when I get back.

[mosen 202]

Thanks already for the confirmation that you found your keys. That's cool and you can pat yourself on the shoulder for not deleting them by chance 😄
However, i understand correctly that you did alterations to all of your backups by copying into all of them at some point?
Then it would make much sense that restorecon can also fix all other folders.
When you have your device rooted and moved to /mnt/vendor/. Just try the

restorecon -nvRF persist

on the whole persist. The verbose output will show every file restorecon can relabel and thus put back to context.
The -n option is to not do changes. If you like what the command offers, remove the -n and execute it with -vRF

Edited August 19, 2022 by mosen