| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two results now sit side by side: a mechanically verified count underflow that is not
reachable in the shipping build because its front half needs a larger payload than any
application delivers, and the absence of version enforcement, which lets an attacker choose
which build runs.
Unreachability is a property of one build's gates, so the question becomes precise: in
either older build, is the front half open? If it is, rollback plus the existing defect is
an exercisable primitive rather than a documented but unreachable one.
Both older bodies are plaintext by entropy so they are directly analyzable, and both are
committed with hashes in the manifest.
It is recorded as a lead rather than a result, with caveats stated: the defect shape exists
in every build so the back half is only presumably open and must be confirmed per image, a
string diff shows no added error messages so there is no cheap signal that a bounds fix
landed in the window, and each detector must rediscover a known defect in that specific
image before any negative from it is trusted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
misread as empty
The opcode recovery was taking the first stack store in each thunk, which is a
neighbouring field rather than req[0]. XGMI stores 2 to var_78 before storing the
real opcode 0x1067 to var_7C, so every XGMI, AUC and FP opcode came out as 0x2 and
their privilege reach looked empty. The rule is now the immediate stored at [SP],
the store whose var_ offset equals the frame size.
Re-ran all twelve TAs. AUC and FP each reach twelve SYS_DRV opcodes, XGMI thirteen
including the 0x104x and 0x106x families, OC ten. GCP's ASD set is unchanged, so
the 0x202 finding is unaffected.
That also retracts my own claim from two commits ago that AUC, FP and XGMI use a
different kernel ABI whose reach is not enumerable. They use the same svc 0xF2
ABI; my rule was misreading it. The SVC 0xF3 stub is real but is a lazy import
resolver -- XGMI's sub_403CA0 caches a resolved pointer in a global and tail-calls
it, and its callers build an ordinary request struct with the opcode at offset 0 --
so it is another route to the same service RPC rather than a separate privilege
channel.
This supersedes both earlier SVC tables in the document.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reopened every database and read back what is actually stored rather than
trusting the write reports: note lines, renamed command handlers, renamed RPC
thunks and entry points for all twelve TAs. Distinct handler counts are lower
than command-id counts wherever ids share a handler, as with RAP's seven ids
funnelling into one and OPM's 6 and 7 sharing one through a goto.
Noted that multi-line function comments are stored fine and only the listing view
renders the first line inline, while pseudocode shows all; checking the listing
alone briefly looked like truncation.
Also recorded the operational cause of a real failure: tmz spawned once and then
failed on every later attempt, with the pane present in the registry but absent
from slosh and readiness never arriving. TMZ is the stub with no real entry
function, and idatui documents that such a binary can land in the symbol palette
on startup, so the saved database restores that modal and the readiness probe
never completes. Deleting the .i64 and reopening works immediately. Worth
recording because the symptom looks like a spawn bug rather than restored state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types
Ran the download/extract/carve/delete loop over every Adrenalin package for this
card, 22.12.1 through 26.7.1, 53 of 53 processed with no failures.
Recording a silent failure mode that nearly cost 30 packages: the first run
reported "NO amdkmdag.sys" for every version from 23.7.1 onward. The cause is
that 22.x-23.5.x are NSIS self-extractors while 23.7.1 and later are PE32+
7-Zip SFX with the archive embedded around 0x1b3e00, and 7z -tnsis exits cleanly
while extracting nothing from those. The harvester now tries both formats and
retries versions previously recorded as failed.
Dedup needed correcting too. The Windows sys_drv 0.49.0.51 differs from the
linux-firmware build of the same version in exactly 256 contiguous bytes at the
end of the body, which is the RSA-2048 signature -- identical code, different
signature, as expected for randomised PSS. Counting on content excluding that
trailing block gives 114 distinct contents from 117 Windows files, 4 overlapping
the existing corpus, so 110 genuinely new firmware images rather than the naive
count. Two groups inside the Windows set differ only by signature, including
three copies of RAS 27.0.0.22, so AMD ships the same image re-signed; that is a
useful data point for the rollback finding since multiple valid signatures exist
over identical content.
The corpus now spans 17 component types and 142 unique bodies, including CSU and
OC which only appear in later drivers, so the TA inventory grows across the
train.
Also corrects the apu tag decode from the first pass, which was byte-reversed:
the tags are NV31, NV33, NV24 and MI20. Seven sys_drv builds carry NV31, our
exact silicon, and six of them are versions linux-firmware never shipped
(0.49.0.35/.38/.40/.42/.46/.53), interleaving with the Linux set to give a
near-contiguous .35 to .54 range for version diffing. No sOS images appear in
Windows packages.
Bodies, full signed containers, per-driver records and manifest hashes are all
stashed.
|
| |
|
|
|
| |
The DMUB images (including the historical 7.0.38/7.0.42 pair used to prove
rollback) and the gfx11 MES/PFP/ME blobs, verified with sha256sum -c.
|
|
|
Split out of a tinygrad working tree, where all of this lived untracked.
tinygrad remains a dependency for hardware-facing scripts only.
Contents:
psp_emu/ Unicorn-based PSP emulator that boots the real signed firmware from
the ARM reset vector: sOS -> SYS_DRV -> HDCP/DTM/RAS TAs, with a CCP
crypto device model faithful enough to run the firmware's own
drivers (RSA-PSS/SHA-256 container verification passes 5/5 with
5/5 negatives rejected). A simulated host drives the real
mailbox/ring path through to TA_InvokeCommandEntryPoint.
psp_out/ Static analysis: six PSP modules fully named (asd 1562, sys_drv
1141, sos 527, ras 119, hdcp 109, dtm 14) plus SMU 1033, a
cross-version diffing pipeline over 34+ builds, per-handler
annotated analysis and ~125 findings documents.
Deliberately not tracked: AMD firmware images, the Hex-Rays decompilation
derived from them, and IDA databases. data/MANIFEST.sha256 pins the SHA-256 of
all 301 blobs results were derived from, so findings remain traceable to their
inputs without redistributing AMD code. 6 MB tracked instead of 315 MB.
Verified from the new location: test_smoke 5/5, ccp_selftest 11/11,
verify_real_image 5/5 + 5/5 negatives, fuzz_ta_invoke controls passing and
host-driven TA invoke working (0.73s per invoke).
|
