Sandsifter logs were a bust, was unable to get the summarize started so I decided to try other
means of finding MSR's. I decided to go with the strategy of analyzing device specific driver
software.I downloaded several windows drivers related to the Atom processor including the
software that lets it access the embedded IO chip, the Chipset driver, and a BIOS F-Log patch.
These can be found here: https://vilivdrivers.weebly.com/downloads-viliv-s5.html
means of finding MSR's. I decided to go with the strategy of analyzing device specific driver
software.I downloaded several windows drivers related to the Atom processor including the
software that lets it access the embedded IO chip, the Chipset driver, and a BIOS F-Log patch.
These can be found here: https://vilivdrivers.weebly.com/downloads-viliv-s5.html
I picked the BIOS F-LOG patch to get started with my analysis. I opened the executable in Radare2
and analyzed it. Radare was unable to recognize any functions, but when I searched "/a rdmsr", I
found two hits! They were at the addresses 0x00425eb3 and 0x00426685. There was no need to
dump as I could manually seek and view them using the "s [address]" tool.
...Unfortunately they were doing enough funky stuff with ecx in both instances that I didn't bother
following program flow. (I'm supposed to be doing work training right now anyway). I moved on to
Atom_Control.dll. Wow, a lot of fun functions here. I decided to put them and all strings to a text file
for analysis later. Unfortunately no msr's, so no relevance to the current project.
I moved on to ATOM_CTL.sys, which I hoped would bear fruit. It had a whole lot of fun functions
however, and I may have to do some reverse engineering on it later.
My next file was atom_io_control.sys. Very parred down, only 2 functions. No msr's referenced.
The last file I tried out was the chipset device driver. I was sure that there would be some MSR's
here. I was correct. I ran "/a rdmsr" and "/a wrmsr", and got 25 and 29 hits respectively. Almost as
many as the actual bios. This became the main focus of my analysis. I decided against dumping to a
file and instead resolved to hit every address manually, as that had given me better results the last
time.
Intel Atom Z515 MSR's I found through analysis (including their relative addresses for easier later
analysis):
Note: For program flow analysis reasons (read: laziness and the fact that this isn't my only activity
tonight), I am discounting a whole lot of msr calls. For a lot of these it seemed almost like they were
attempting some sort of obfuscation technique. Instead of just assigning a value to ecx there were a
lot of increments, decrements, adc's, shifting of values, shifting of bytes from ch and cl, it was weird.
Note 2: This is feeling more and more like intentional obfuscation by the minute, or maybe just some
wild form of optimization. Very odd. I'm a lot less sure about a lot of these because of program flow,
so apologies for any errors.
Name Addr
wrmsr
0xaa 0x0055e6b0 - medium confidence
0xa34a96dc 0x00560dd6 - medium confidence
0xff77 0x00569cae - low confidence, result of some sketch math
0x6fff6a83 0x0060c065 - high confidence, unobfuscated
rdmsr
0xadd9004a 0x005d7d1f - medium confidence - unobfuscated - tested and got no response
0xd8 0x00613cld - low confidence - tested and got no response
Their Functions? Well, once again, we know that the Atom Z515 is based on the Silverthorne
architecture, so let's load up the Intel 32 bit and 64 bit architecture developer manual and search up
some of these mysterious MSR's
Documented MSR's in the Intel Developer's Manual:
Zero of these were documented. High error rate is definitely a factor here, but I have very
high confidence on at least one instruction, 0x6fff6a83.
Anything else we can find for the MSR's Intel won't tell us about? The RE community is a great
resource. I attempted to find some info using github searches, google searches, and
searches on the Reverse Engineering Stackexchange.
searches on the Reverse Engineering Stackexchange.
Undocumented MSR's known to the RE community:
Search turned up nothing. High error rate still a factor, but again, I have high
confidence in 0x6fff6a83.
confidence in 0x6fff6a83.
After that information was found, here is what was left.
Undocumented MSR's unknown to the community:
Name Addr
wrmsr
0xaa 0x0055e6b0 - medium confidence
0xa34a96dc 0x00560dd6 - medium confidence
0xff77 0x00569cae - low confidence, result of some sketch math
0x6fff6a83 0x0060c065 - high confidence, unobfuscated
rdmsr
0xadd9004a 0x005d7d1f - medium confidence - unobfuscated - tested and got no response
0xd8 0x00613cld - low confidence - tested and got no response
This was just a cursory look for fun and to improve my reverse engineering skills while I study up for
my GREM attempt, but if anyone wants to do some serious analysis, the files are in the intro. If
anyone has any info regarding 0x6fff6a83 or wishes to tell me about an error I made, please reach
out in the comments. In a future post, I may use ollydbg on the chipset executable to set breakpoints
at the wrmsr's and find the value of ecx at these points.
out in the comments. In a future post, I may use ollydbg on the chipset executable to set breakpoints
at the wrmsr's and find the value of ecx at these points.
- Elias Augusto