Finding Undocumented Intel Atom MSR's in the Viliv S5 Pt 2: Software RE

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

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.

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.

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.

- Elias Augusto