yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
So having the fake setup for the android attest key, I've tried factory reset - result is that android attest key looks still provisioned, still having there the 5 fake empty files - they were not touched.

But factory reset changed content of the other files under fidocrypto and tzattest.

Then tried to flash the persist_X-FLASH-ALL-C93B.sin file alone with newflasher, it went ok.

Booted the phone, security screen shows those two somc keys as provisioned and android attest one not provisioned.

But the strange thing - when temprooted - I can see that the files were not re-created. There was only the wv subdirectory with the keybox.dat which content was changed.

Any action on the phone, like entering the security screen or configuring fingerprint for unlock or starting camera did not create the other directories with files.

So I did another factory reset, which finally re-created everything, but again, content in the files was different.

So I guess flashing the persist.sin might not be that safe (after all it is marked in the update.xml as FACTORY_ONLY, not sure what that means or who provides this xml in the fw).

And one more interesting point: if I bind mount an empty directory onto the keymaster64 dir which had those 5 fake files, provisioning state changes to not provisioned from provisioned with re-open of the security screen.

But in case of those two SEMC keys, the provisioning state is always provisioned regardless there are or not are any files in fidocrypto and tzattest directories, bind mounting empty dir on them has no effect and not having those dirs after flash of persist still had no effect, the keys were all the time provisioned (on my still locked xz1c).

I've found a good info about the versioning and the attest key here:

https://source.android.com/security/keystore/version-binding

From there it seems this is tied to device, most likely stored in TrustZone and those files in /persist are just derived from keys in TZ.

Most likely if sony implemented it right, we could not save the attest key for other devices.

It might be possible to save the attest key (or recover it) for a device which would not need downgrade for the exploit, but only in case unlock would not erase it from TZ.
[Sony Xperia XZ1 Compact Questions & Answers] Yurienu:
Would it be possible to downgrade without flashing that persist.sin file?

In that case, it might be possible to backup it up with the exploit after downgrading?
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
Just tested downgrade without flashing persist.sin - the attest key bad been lost before the downgrade already, so this test just shows, that persist.sin is optional when flashing (the flashing went fine, phone booted ok).

There is a difference though: when persist.sin is flashed, device is factory reset _completely_.

If it is not flashed, it seems to remember, that it was used and keeps asking to go online on first boot in order to setup google account (and check for updates).

When persist.sin is flashed, then that's not needed, phone can be first booted skipping all requests to go online via wifi or whatever and skipping setting accounts up for later.

Anybody with attest key present (with fw newer than 47.1.A.8.49): could you please downgrade without flashing persist.sin to see if attest key would be removed or not?

Another interesting test may be when attest key is present to flash just the persist.sin to see if that removes the attest key or not.
[Sony Xperia XZ1 Compact Questions & Answers] Yurienu:
I can but I will need G8441_1310-8853_47.1.A.8.49-R9B_Customized_FR.ftf firmware. In case I loose the attest key by downgrading without persist.sin, we will be sure this is not due to country variant changing ;)

It used to be available on XperiCheck but it is now removed and link found in Google cache is indeed dead: https://alfafile.net/file/npVQ
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
I am not sure about the connection of customization change and loosing the android attest key.

I have at least one prove that it did not happen - [MENTION=5677791]tramtrist[/MENTION] bought his xz1c with Japan customization and switched to UK. And he still had the attest key present with his UK fw as screenshots sent to me prove.

Not saying that any change of customization is safe, but it seems that the opposite is not the case either.

Maybe you can switch to CE1 keeping the same fw version (or possibly upgrading) and hopefully the attest key stays and then you can do the test?
[Sony Xperia XZ1 Compact Questions & Answers] pbarrette:
The customization variant is set by the

oem_X-FLASH-ALL-C93B.sin

file.

If you don't want to change your country, don't flash the OEM SIN file.
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
So it seems we can confirm that flashing the persist.sin from a fw package causes loss of Android Attest Key - as tested by [MENTION=8010702]tanapoom1234[/MENTION], not flashing persist.sin allows downgrade with android attest key still provisioned - see his post#212 in the exploit thread.

[MENTION=4120742]munjeni[/MENTION], could you please add a check for the persist.sin in your newflasher to avoid flashing it (maybe allow only if explicitly requested) - that file seams to be the cause of losing the Android Attest Key. Thanks.
[Sony Xperia XZ1 Compact Questions & Answers] pbarrette:
Um.. I don't think that's what's going on.

Instead, I think there is a startup process that is making a TrustZone call, then spitting its results out to

/persist/

.

With the bootloader unlocked, further TrustZone attestation calls fail, so if the files aren't already there, they don't get re-created.

The question is: Is anything actually using those files other than the debug menu check?

I mean, if you're an app and want to verify attestation, do you read those files in the persist partition, or do you make your own TrustZone calls?

If the apps are doing the former, then by preserving

/persist

, you've gained an advantage. But if apps are doing the latter, preserving

/persist

is just giving you a warm fuzzy in the debug menu, but apps aren't fooled.
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
That could be like that. Still flashing nearly empty persist.sin, effectively erasing the persist partition does not seem like a good option.

As [MENTION=4403504]tonsofquestions[/MENTION] pointed out to me in pm:
[Sony Xperia XZ1 Compact Questions & Answers] Blu-eyes:
The android attest key is loosed even with only costumization change, when i chnged my phone costumization i hve upgraded to new version, but i have flashed all file from downloader from xperifirm except all .ta(the phone where not wiped), the phone booted fine with all my data, but all key where lost, the camera wouldn't focus and took green pics, after a full wipe the key were stillnot provision, and suntury blob give me error, i hanen't tookany screenshot, but after a restore with xperia Companion, the key came back, suntury blob is ready,safety net is ok, android pay work, OTA Update works like a charm(OS ond apps), the only key not provision, were, obisiulsy, the attest key.

So probably the fido key...., Blobs, Widewine... not rely only on bootloader status, but rely on a some signature, version matching, that is checked by some of the Trust Zone....

#OT

have anyone opened his xz1/xz1c and looked for some test pad/jtag/swd(single wire debug) or some serial port.., i know that for other model on the sony unlock page there is also the location of the testpad/serialport.

Sorry for my long post and probably bad wroten post
[Sony Xperia XZ1 Compact Questions & Answers] HandyMenny:
This is my case. I passed the security test

Note that I slightly edited the app to make it compatible with xz1 g8341, I'll ask the developer to add g8341 in the compatibility list as it has the same fingerprint of g8342 and g8441.
[Sony Xperia XZ1 Compact Questions & Answers] tonsofquestions:
Long time lurker, first time poster here.

This work and success encouraged me to take the plunge and get an XZ1C, and I've been chatting with j4nn over PM and helping with some tests, as well. I've achieved root a few times on different firmwares, but haven't unlocked (yet).

One experiment (early on) was to downgrade (I started on 47.1.A.16.20) without flashing persist.sin - and I also confirm that the attest key still shows as provisioned.

I downloaded the github version of the Auditor app, and tested it out. It didn't verify on the 7.0 phone (as expected; it's not supported). My initial attempt to verify on the XZ1 failed with some strange error, and when reading it, I realized that it was a timestamp issue - I'd never set the time on my phone properly (no need while exploiting), so it was in 2017, and dates were invalid. When I reran it after setting the time, I got a single line: "OS patch level too old".

At the time, I was on 47.1.A.2.324 (I'd started on , and it was encouraging, it made me think the keys were there, and functioning, just considered invalid by the OS since they ratchet up to patch levels (as documented).

So I re-upgraded to the original 47.1.A.16.20, and ran the Auditor again. The XZ1C read the second-phone's QR code successfully (where it previously errored), but then it displayed a giant QR code the second phone was mean to read back, but I was completely unable to get the other phone to register it. Bright light, low light, different screen brightnesses, nothing. I even tried taking a screenshot and and displaying that on my computer, but still no luck reading it. The auditing phone just keeps focusing in and out, trying to grab the QR code, but failing to register it. I sadly don't have another (non-downgraded) phone to test with, to see if the behavior is different, but I suspect it would be the same.

(Note: it's also not clear to me what kind of internet access (or account setup) is necessary, if any, for this auditing step. Nether of the phones were connected initially, but I did try adding both. Neither were connected with Google accounts.

So it's a mixed data point, but shows promise. I'd love to get it working before I unlock (I'm also still trying to do a proper full-phone backup when in temp root, but it keeps failing kicking me off strangely).

It also fits our rough understanding of the keys and how they would be stored/work. If they're in the persist partition, then it certainly seems like that shouldn't be flashed. Flashtool didn't do it by default. And it makes sense that downgrading wouldn't destroy them completely, just make them unusable until you re-upgrade.
[Sony Xperia XZ1 Compact Questions & Answers] Kayant:
Hi i was wondering if you could help me in doing the same as your changes hasn't been pushed upstream with an updated apk.

Haven't had any luck with the methods I searched for around modifying/compiling apks. I also have the same xz1 variant and wanted to provide

data point.
[Sony Xperia XZ1 Compact Questions & Answers] HandyMenny:
I compiled a signed release apk with android studio. I had to replace the signature with my own signature: https://github.com/HandyMenny/Auditor/commit/41a48fa7ff89207b98c1e5ab76d0c0c3d6285608 and edit the list of supported devices: https://github.com/HandyMenny/Auditor/commit/14ff88d4aac599892fe6bb815d37c97f46902bbd
[Sony Xperia XZ1 Compact Questions & Answers] Kayant:
Thanks a bunch I only just noticed that and was wondering how to get past that barrier :D
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
[MENTION=5400898]HandyMenny[/MENTION], just wondering - am I right that you need to do the same verification process twice in order to get that green screen with "strong paired verification"?

I helped [MENTION=6329152]flashcart[/MENTION] and [MENTION=4503201]blue-spiderfire[/MENTION] to try a test on their unlocked (and TA restored) devices and after many modifications we got a yellow screen with "basic initial verification".
[Sony Xperia XZ1 Compact Questions & Answers] HandyMenny:
Yes, you need to do the verification twice in order to get green screen.
[Sony Xperia XZ1 Compact Questions & Answers] Kayant:
[MENTION=4418980]j4nn[/MENTION]

Here are the results from an Xperia XZ1 g8341 on the latest 47.1.A.16.20 firmware. Let me know if there is anything else I can test before I attempt temp root without flashing the persist.sin file.
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
[MENTION=4173406]Kayant[/MENTION], could you please capture logcat from both devices when you run the test?

And after you unlock, try to run it with Auditor build attached here installed on both devices, again capturing logcat from both devices?

And after you restore your TA, run it for the third time, again capturing logcat?

Each testrun twice to try to get the green screen?

If you could then send me the results, it would be great.

I am wondering if the attest key could be used even when a phone has been unlocked, that hopefully could be seen from the logs.

Thanks.

https://mega.nz/#!XLBW0SKa!mmhEyyQ1wt4tbSd3FZTwdZmo4BcCHK0HPjUrU_B3J2Q
[Sony Xperia XZ1 Compact Questions & Answers] HandyMenny:
[MENTION=4418980]j4nn[/MENTION] According to this pdf, the attest keys are not unique, an attest key must be used by at least 10k devices. So maybe if you copy the keymaster64 dir of another xz1, the key attestation will return to work. Have you ever tried this? The only risk is that these keys could be revoked. If you want to try I can send you my persist partition
[Sony Xperia XZ1 Compact Questions & Answers] russel5:
I'm already flash persist from another locked phone and my android attest key is provisioned. First two not
[Sony Xperia XZ1 Compact Questions & Answers] Unbounded:
Well, first of all I downgraded firmware version to 47.1.A.2.324_CE1 (I deleted all the .ta files and also deleted persist_X-FLASH-ALL before flashing via newflasher)

As result All of my keys which are SOMC, FIDO and Android Assets show as PROVISIONED.

After that got the temp root and Backed Up my TA.

After that I unlocked the bootloader and rebooted the phone.

But, unlike before it is now showing the warning that "Your device software can't be checked for corruption. Please lock the bootloader" and after this message my phone booted.

Well, this time all the keys are gone, means they all are showing their status as NOT PROVISIONED.

No, problem. After that I restored my backed up TA and rebooted.

And still the above warning popped up first and then my phone booted.

Checked the status of my keys again. While this time I had Android Assets shown as PROVISIONED, while SOMC and FIDO are shown as NOT PROVISIONED.

After that I flashed the latest TWRP.

After that via TWRP, I flashed the latest magisk followed by flashing of secd-ignore-unlock.zip and then rebooted my phone to system.

(That unlocked bootloader warning popped up again)

And once again I checked the status of the keys and PRAISE THE GOD!!!!!!!!!!

All my keys are back to PROVISIONED.

And then to check if we can get official system updates from sony I setup the internet connection.

And Yes, I did get the official system update from sony. So, I downloaded the next firmware update provided by the sony and hit the "Install".

The phone rebooted for the update (well, still that warning shows up) and then the display was showing the official android animation proceeding for update and phone rebooted again.

The update was not installed.

[MENTION=4418980]j4nn[/MENTION], I hope that I have answered the previous questions like if we still get the official system update from sony or not.

The answer is Yes. Because, after TA restore and flashing of secd-ignore-unlock.zip, all keys are PROVISIONED. Well, we do get the official system update but we can not install the update.

Although all of the keys shows PROVISIONED and the functions like camera is working properly and safetynet check also passes successfully (Even OEM unlocking in Developer options is as the stock one, like the device was never unlocked ), every time when I reboot my phone, the warning message of "Your device software can't be checked for corruption. Please lock the bootloader" that popes up.

It just popes up every time.

Can we infer that according to above warning, Even though the TA is restored, somehow the phone still knows that the bootloader is Unlocked and that that is why it doesn't let the update to be installed on the phone???

I am not sure that if I am the only one who is getting that warning message or everyone who has unlocked their bootloader gets this message.
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
[MENTION=5400898]HandyMenny[/MENTION], interesting pdf. I had tried to restore just the keymaster64 few days ago, got the attest key provisioned.

But I think the key did not work - I get an exception from Auditor right on the first qr code scan.

So I assume it's not possible to use keymaster64 content from another device.

[MENTION=4688377]russel5[/MENTION], you may check the Auditor app to see if the android attest key is accessible. But don't expect the original auditor to run with unlocked bootloader. I needed to workaround all those checks to make it do something (posted a patched version above). Still need to analyze the logs provided by guys here.

[MENTION=9540710]Unbounded[/MENTION], the warning on boot is normal I guess (I've read about it, we can't get rid of it I am afraid, but there is no harm).

That is great result with the system update coming in.

I am wondering if it was not installed due to unlocked bootloader or because the vendor partition got modified with the patched secd.

Maybe we could check it having not modified stock firmware, replacing secd via temp root on runtime via bind mount and secd process restart.

Still, the result would not really help - if it is due to unlocked bootloader, we cannot force the ota update (when rebooted to perform it) to think that it is still locked.

If it did not update due to change in vendor partition, it would be useless also as that would mean no root or any other change in order to be able to receive ota updates.

So I guess we can just forget about it.

Or allow only application updates, not update of system which requires reboot.
[Sony Xperia XZ1 Compact Questions & Answers] Unbounded:
Thanks for the clarification.
[Sony Xperia XZ1 Compact Questions & Answers] S1gma:
If someone more needed for testing: I've XZ1C with locked bootloader, android attest key = not provisioned after debranding done year ago :) DRM Keys are in place.

It's "production" phone, so I cannot test downgrade/drm restore, but I can do some testing on recovering attest key with locked bootloader (if this is possible).
[Sony Xperia XZ1 Compact Questions & Answers] mirhl:
Just for the records, I'm not sure this isn't

really

just XZ2-specific..

But *for some reason* it seems like they decided not to have rollback protection on at least some phone/firmware/sku combination.

Could this help explaining all this random mess? (or did I miss the fact we already have a coherent and widely accepted theory?)
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
[MENTION=4900593]mirhl[/MENTION], that is interesting. I am not sure I understand it right - does it mean that if there is a fw downgrade in case of XZ2, the attestation would be lost (rollbackResistant == false)?

While all the other xperia devices have rollbackResistant == true meaning they all can downgrade without losing attestation?

So that XZ2 would be the first device allowing attestation only if there never has been any downgrade (a first device from sony testing this path)?
[Sony Xperia XZ1 Compact Questions & Answers] mirhl:
Not saying they are testing anything, and not saying anybody in here may or may not have had something similar.

I just wanted to point out there's this dangling variable that could quite skew many simple assumptions.
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
[MENTION=4900593]mirhl[/MENTION], just wanted to confirm, if my understanding is similar to yours or if the meaning should be opposite?

I am afraid it would not be about testing but rather about behaviour of the keys with upgrades, that is defined by google and the implementation is possibly common in android.
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
[MENTION=4403504]tonsofquestions[/MENTION], could you please test one more time the Auditor app - I've added there a log of the signed data received from TEE and it seems interesting:

- this is from a virgin locked xz1c device, downgraded from 47.1.A.12.179 (which was not booted - went straight into flash mode to find out) to 47.1.A.8.49, flashing only adspso, bluetooth, fotakernel, fsmetadata, kernel, modem, system, vendor and userdata (this one to resolve bootloop on the first try without it) .sin files:

AttestationProtocol: teeEnforced = {
AttestationProtocol: Algorithm: ECDSA
AttestationProtocol: KeySize: 256
AttestationProtocol: Purposes: [SIGN, VERIFY]
AttestationProtocol: Digests: [SHA256]
AttestationProtocol: EC Curve: secp256r1
AttestationProtocol: Origin: Generated
AttestationProtocol: Rollback resistant: true
AttestationProtocol: Root of Trust:
AttestationProtocol:
AttestationProtocol: Verified boot Key: 54A9F21E9CFAD3A2D028517EF333A658302417DB7FB75E0A109A019646CC5F39
AttestationProtocol: Device locked: true
AttestationProtocol: Verified boot state: Verified
AttestationProtocol: OS Version: 80000
AttestationProtocol: OS Patchlevel: 201712}

Attached you can find a patch of the Auditor source to allow run with older oreo versions also ignoring unlocked state and a built debug apk with those changes.

You can find the above output in adb logcat, when you scan the first qr code from an auditor device with xz1c being audited.

I wonder if an unlocked device where attest key was not lost provides similar signed data only with state reflecting the unlock.
[Sony Xperia XZ1 Compact Questions & Answers] HandyMenny:
IMHO rollback resistant is related to this: https://source.android.com/security/keystore/tags#rollback_resistant

As shown here too: https://developer.android.com/train...estation#certificate_schema_authorizationlist
[Sony Xperia XZ1 Compact Questions & Answers] messenja:
There is no SOMC Attest key anymore in Android Pie. So seems like oneway ticket for Oreo->Pie that ive already done. My question is: whats the purpose of SOMC Attest key in Oreo, because i want to downgrade to Oreo and i want to know what have i lost with that key.
[Sony Xperia XZ1 Compact Questions & Answers] j4nn:
[MENTION=6214713]messenja[/MENTION], it only seems that pie does not list the SOMC Attest key in it's security screen. If you downgrade back to oreo, it will appear again, still provisioned - tried that myself.

Just skip flashing persist sin file - that removes the Android Attest key (but the other two SOMC keys are ok even after persist flashed).
[Sony Xperia XZ1 Compact Questions & Answers] Enyime:
So after I read this thread, I am still not secure about, if I downgrade from Pie to a temp rootable Oreo build (many Thanks to you j4nn!) Flashed by NewFlasher (and also many Thanks to munjeni too!)

without flashing persist.sin and *.ta, will my AndroidAttestation Key still be provisioned or not.

I am willing to install Magisk on my XZ1 (G8341), but only if all of my keys will be provisioned after all of this.

Thanky you for your help!
[Sony Xperia XZ1 Compact Questions & Answers] mad0701:
Good questions : in Android 9 only the SOMC Key was visible ; back to Orego SOMC Attest key was visible too.

An AndroidAttestation Key I haven't seen any time on my phone. OTA works... Does the key will be visible, if I downgrade to Nougat? Phone is still locked

Oh, I forgot : my phone is a XZP
[Sony Xperia XZ1 Compact Questions & Answers] gilvanio:
hello, I made the procedure and changed from UK to USA, my device is a XZ2P. Keys NOT PROVISIONED. After a downgrade to android 8.0 , keys still not provisioned. Update to 9 again and still not provisioned. So, didn't work.