Repository navigation
Default the device-id chain to unknown, and resolve it in one place - #316
Merged
Merged
Conversation
JingMatrix
force-pushed
the
fix/harvest-fallback-attestation-ids
branch
from
October 19, 2026 11:33
4adbc9f to
bd53dfd
Compare
JingMatrix
changed the title
Owner
Author
|
@lvyin555 Thanks for the complete log in #306 — it turned out to be our bug: with no working TEE the harvest recorded |
|
TEESimulator-report-v4.0-74-604dfb0-release-20261019-213754.zip |
|
In addition, the integrity of the equipment has not been restored. |
JingMatrix
force-pushed
the
fix/harvest-fallback-attestation-ids
branch
from
October 19, 2026 13:42
bd53dfd to
07fd0c3
Compare
JingMatrix
changed the title
JingMatrix
force-pushed
the
fix/harvest-fallback-attestation-ids
branch
from
October 19, 2026 14:45
07fd0c3 to
651dd89
Compare
JingMatrix
changed the title
Owner
Author
|
@lvyin555 Thank for feedback, please test https://github.com/JingMatrix/TEESimulator/actions/runs/39271858356 now. |
JingMatrix
changed the title
JingMatrix
force-pushed
the
fix/harvest-fallback-attestation-ids
branch
from
October 19, 2026 15:29
651dd89 to
3c98a5f
Compare
|
TEESimulator-report-v4.0-74-88c4ab6-release-20261020-001901.zip |
|
I contacted deepseek, and they said the problem isn't with the TEES, but with the ROM; perhaps the issue has been resolved. |
devicePropId followed the framework's property chain but not its defaults: Build.getString falls back to "unknown", ours fell back to blank and then collapsed a read "unknown" to blank as well. A chain unset the whole way down therefore recorded nothing, while the provider -- which adds all five ATTESTATION_ID_* tags whenever device properties are included, and omits none -- asked us to attest the literal "unknown". The TA compared "" against it and refused with CANNOT_ATTEST_IDS. The #313 and #279 device resolves its product id that way. #258 resolved those five ids through devicePropId, but the no-TEE fallback record filled them itself from the plain property, so that path's "already set" guard skipped its own resolution and the chain was spelled out twice with only one copy following the framework. The record now leaves them blank, like the telephony ids beside it, so one site resolves all nine. buildId goes with it. devicePropId's comment credited keystore with filling ATTESTATION_ID_*; it is the framework's provider, in the caller's process, and Build backs only two of the three legs.
JingMatrix
changed the title
JingMatrix
force-pushed
the
fix/harvest-fallback-attestation-ids
branch
from
October 19, 2026 16:35
3c98a5f to
6f3b538
Compare
Owner
Author
|
Try my PlayIntegrityFix fork here: https://github.com/JingMatrix/PlayIntegrityFix. Flash its latest CI build. |
JingMatrix
added a commit
that referenced
this pull request
Oct 19, 2026
…316) devicePropId followed the framework's property chain but not its defaults: Build.getString falls back to "unknown", ours fell back to blank and collapsed a read "unknown" to blank as well. A chain unset the whole way down recorded nothing, while the provider -- which adds all five ATTESTATION_ID_* tags and omits none -- asked us to attest the literal "unknown", so the TA compared "" against it and refused with CANNOT_ATTEST_IDS. The no-TEE fallback filled those ids itself too, defeating #258's resolution; it now leaves them blank so one site resolves all nine. buildId goes with it.
Draft
6 tasks
Zhanfg
added a commit
to Zhanfg/TEESimulator
that referenced
this pull request
Oct 22, 2026
Adapt 2fda3b1 to existing OnePlus/StrongBox Harvester without overwriting fork logic.
This was referenced Oct 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
devicePropId followed the framework's property chain but not its defaults: Build.getString falls back to "unknown", ours fell back to blank and then collapsed a read "unknown" to blank as well. A chain unset the whole way down therefore recorded nothing, while the provider -- which adds all five ATTESTATION_ID_* tags whenever device properties are included, and omits none -- asked us to attest the literal "unknown". The TA compared "" against it and refused with CANNOT_ATTEST_IDS. The #313 and #279 device resolves its product id that way.
#258 resolved those five ids through devicePropId, but the no-TEE fallback record filled them itself from the plain property, so that path's "already set" guard skipped its own resolution and the chain was spelled out twice with only one copy following the framework. The record now leaves them blank, like the telephony ids beside it, so one site resolves all nine. buildId goes with it.
devicePropId's comment credited keystore with filling ATTESTATION_ID_*; it is the framework's provider, in the caller's process, and Build backs only two of the three legs.