-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different results each boot dumping spi #14
Comments
This could happen because of the non-volatile region. That said, there are 2 ways of extracting the flash: the memory mapped way or via spi-controller commands. The version that is in the CLI uses the memory mapped approach. There are examples in the PoCs on how to do it via spi-controller commands that you can use to double check. |
Oooh im on it. I wasnt sure why it would very so much in time to rip the
spi flash, and had a foolish idea that maybe other processes where somehow
causing issues. So i made a bare initrd with the kernel module and userland
app. And even after a reboot i was able to get identical files. This of
course proves nothing and requires more testing, but i like your suggestion
much better. Off topic but any resources on the PSB/PSP fuses you would
suggest? My machine has firmware anti rollback enabled.The very little i
can find where its mentioned, makes it seem if i set a PSB fuse(offset
0x10994,bit 25) and enable PSB (bit 24) i can have it ignore the FAR
protection. But im unsure because its all mentioned in passing and
sometimes using double negatives. With only one chance to get it right, its
nerve wrecking. Also the disable secure debug ive seen with double
negatives wondering if it makes secure debug available or locks it up.
Sorry for the off topic banter. Just resources are so slim.
…On Sat, Aug 24, 2024, 4:07 PM Enrique Elias Nissim ***@***.***> wrote:
This could happen because of the non-volatile region. That said, there are
2 ways of extracting the flash: the memory mapped way or via spi-controller
commands. The version that is in the CLI uses the memory mapped approach.
There are examples in the PoCs on how to do it via spi-controller commands
that you can use to double check.
—
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADAWMPZ4PU5QWNV22DYDUFTZTDRZDAVCNFSM6AAAAABNBSPIQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGUZDGMRZGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If i dump the spi and reboot dump spi again i get different results in files. Seems usually ill have large segments of all f's. In the few files i have it seems random so far so ill dump more and look for a pattern. Not sure if it applies or not but the machine does use recoveryAB and so my 32mb bios is dumped as 64mb file. If i split the files the two parts are always identical. Not sure if this all happens because of some security thing, or a glitch in the app. Oh one more piece, if i dont reboot i so far will get the exact same dump, and a warm reset seems to produce less f filled segments. Thank you for writing this software and the blog posts! Very helpful.
The text was updated successfully, but these errors were encountered: