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

Finding Undocumented Intel Atom MSR's in the Viliv S5 Through BIOS Reverse Engineering

 I put "Verified" in the title because while I have run a Sandsifter on this project, I have not had time to analyze these opcodes.

Rough overview for those not familiar with my other posts, the Viliv S5 is an Ultra Mobile PC with an Intel Atom Z515 IA-32 Processor. I recently replaced the native Windows XP 2003 with Kali linux.


I wanted to find msr's, both documented and undocumented on this machine, and I figured that the best way to start would be looking into the BIOS version. Analysis using the "dmidecode" command determined that it was running an AMI SMBIOS 2.5 Version 080015.

Knowing this, I knew that it would be compatible with flashrom. I went to work capturing the BIOS. I used the "flashrom -r" command to write the bios to the file "bios.rom".

After capturing the BIOS, I wanted to know how many machine specific registers were being utilized by the BIOS. For my purposes this was a good enough indicator of how many MSR's were usable on this particular system. I analyzed the bios with Radare2 and used the "/a wrmsr" and "/a rdmsr" commands to find all of the points where msr's would be.

I may do a deeper analysis with the sandsifter results later, but for now, 31 hits on WRMSR and 29 hits on RDMSR! I was very excited by these findings. I decided to dump the addresses of these hits to separate files and the disassembled rom to a text file for further analysis.

First, however. I need to run "afl" to find the address of the first function, in order to ensure I'm not analyzing an endless row of invalid opcodes.

I have my starting point, "fcn.000f0000", and it's address, "f000:0000". I can now dump my file from this point to the end of the file using "wtf biosdump $s @ 0x000f0000" to dump the valid binary output to a the file "biosdump" and reopen that file in radare2.

I then verified to ensure that all MSR's were still present, and disassembled to a file using "pd $s >biosdis.asm".

Intel Atom Z515 MSR's I found through analysis:
0x17
0x1b
0x79
0xcd
0xee
0x194
0x198
0x199
0x1a0
0x200
0x201
0x250
0x258
0x259
0x268
0x269
0x26a
0x26b
0x26c
0x26d
0x26f
0x2ff
0xf42
0x107e7

Their Functions? Well, 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:
 17h - MSR_PLATFORM_ID - The platform ID

1bh - I32_APIC_BASE - APIC status

79h - IA32_BIOS_UPDT_TRIGGER - Triggers bios update

cdh - MSR_FSB_FREQ - Indicated intended bus frequency

eeh - UNKNOWN - I thought this was a normal one based on how often I saw it, but it's function is 
not documented - Interesting attributes - Always read, never written to

194h - MSR_MCG_R12 - Machine state checking

198h - IA32_PERF_STATUS - Intel Speedstep Status

199h - IA32_PERF_CTL - Intel Speedstep Control

0x1a0 - IA32_MISC_ENABLE - Enable miscellaneous processor functions - Interesting one

200h - IA32_MTRR_PHYSBASE0 - MTRR function

201h - IA32_MTRR_PHYSMASK0 - MTRR function

250h, 258h, 259h, 269h, 26ah, 26bh, 26dh, 26eh, 26fh - IA32_MTRR_FIX[x]K_[x]0000 - All associated with MTRR range

2ffh - IA32_MTRR_DEF_TYPE - Memory types (default)

f42 - MSR_C8_PMON_BOX_OVF_CTRL

107e7h - UNKNOWN - I knew this one was going to be interesting when I found it. As expected, it did not show up in the manual. Written to, never read.
Context:
and al, 0xf0
cmp eax, 0x106d0
jne 0x148c ;eventually gets to jump down below after a few other checks 
;address 0x000f1476
mov ecx, 0x107e7 ;no modifications to ecx in this section, ecx is never cleared, not an addr
mov edx, 0x320505
mov eax, 0x101
wrmsr
jmp ...
;at jump
mov ecx, 0x17 ; returns platform ID, as we have already established.
;I'm guessing al also contains id related info that is checked.
rdmsr

Opcode: 66b9e7070100





When I try to read it using msr-tools, however, I get nothing. May not have an inherent value?

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:

0xee - IA32_EXT_CONFIG - From what I could figure out on github it was some sort of control that would determine whether to sleep or not

 107e7h - UNKNOWN - None of my searches could dredge up anything on this one. Wow, must be really specific and rarely used.

After that information was found, here is what was left. Hopefully I'll eventually be able to find out the purpose of these registers.
Undocumented MSR's unknown to the community:

 107e7h - UNKNOWN - A truly undocumented MSR (to my knowledge). Anyone with information relevant to this opcode willing to get in touch? Is this a simple error I'm making and not an MSR? Reach out in the comments to let me know!
- Elias Augusto 

 Update: Want my bios file to mess around with? Here you go: http://tinyurl.com/yxweccsv

Getting Malware onto a Finicky VM

This is going to be a quick one. I just had a bit of an issue with a finicky windows 7 VM that refused to allow USB drives because of some sort of driver error. I found a tool called WinCDEmu that will allow me to create drives from folders and use those to transfer malware to the VM. Here it is, if you are having similar issues:
http://wincdemu.sysprogs.org/

Reverse Engineering the FOR610

 I don't have $7,000, but what I do have is a (non-comprehensive) list of tools and course targets graciously provided by the SANS institute, as well as access to a library of Malware Analysis resources and a few video courses within my reach. Here's what I've come up with.
Tools and Targets of FOR610
https://www.sans.org/course/reverse-engineering-malware-malware-analysis-tools-techniques/course/asc/ - Targets
Tools:
Malware Analysis Fundementals:
*pestr
*peframe
*PeStudio
*Process Hacker
*Process Monitor
*Regshot
*ProcDOT
*x64dbg
*API Monitor
*INetSim

Reverseing Malicious Code:
*IDA Pro

Malicious Web and Document Files:
*Fiddler
*SpiderMonkey
*box-js
*base64dump.py
*pdf-parser.py
*peepdf.py
*scdbg
*olevba.py
*oledump.py
*rtfdump.py
*jmp2it

In Depth Malware Analysis (Packers, Debugging, API Hooks, Memory Forensics):
*Detect It Easy
*Exeinfo Pe
*Bytehist
*CFF Explorer
*Scylla
*OllyDumpEx
*Volatility

Self Defending Malware (Antidebugging, unconventional packing):
*FLOSS
*bbcrack.py
*ScyllaHide
*pe_unmapper

My Plan and Resources for GIAC GREM Prep

A lot has happened to me as of late. I accepted a role on a DoD DTS contract and got accepted into the UMCP Honors college. But the year is not over for me yet. Before I rest on my laurels, I still need to do something I've been meaning to do for a long time, and get my GIAC Reverse Engineering of Malware (GREM) certification. I need to start getting roles on some higher value bigger contracts, and I want to get a SECRET clearance or better before the end of my freshman year of college. Been working on learning x86/x64 MASM for Windows and messing with Fireye's FLARE VM and IDA Freeware, but I think it's time to take it up a notch. Compiled a list of books recommended by current GREM holders:

• The Malware Analyst's Cookbook  (Mainly for material relevant to learning, skipping OSINT and VM automation, will come back to them in future)
• Practical Malware Analysis (Mainly material not covered by the Cookbook)
• The IDA Pro Book
• Practical Reverse Engineering - Will be my assembly refresher book
• The Art of Memory Forensics
• Reversing

Currently following along with both Modern x86 assembly and The Malware Analyst's Cookbook because they appear to cover a lot of the concepts in Practical Malware Analysis and use modern tools. After them I'll be moving on to Practical Malware Analysis and Practical Reverse Engineering before my exam.

Going to deviate a bit from the lab setups in the books. Here's what I have planned:
Linux Box:
- Kali-linux-full install (includes forensics tools and yara)
- Clamav
- Tools provided by the Malware Analyst's Cookbook CD

Windows Box:
- Windows 7 x64 SP1
- FLARE VM - Great malware analysis toolkit - https://github.com/fireeye/flare-vm
- Bindiff
- IDA Freeware 7.0 (Flare VM only comes with 5.0)
- OWASP ZAP - My primay traffic proxy
- Tools provided by the Malware Analyst's Cookbook CD
- This old trick I learned to cut any Virtualbox off from the net while still allowing fakenet to operate (No adapter but attach the adapter)

Currently brushing up on my x86 ASM using this tutorial: https://0xax.github.io/asm_3/
Learning how to index GIAC style and do writeups may be trouble, but luckily I have some resources at my disposal:

https://digitalforensicstips.com/2012/11/sans-index-how-to-guide-with-pictures/  

https://www.giac.org/media/exams/prep-guide.pdf  

https://tisiphone.net/2015/08/18/giac-testing/

  I also want to try my hand at some malware analyses and post some formal write-ups here and some yara/clamav rules to my github (coming soon) just for extra prep. Resources I'm using for that:
 https://zeltser.com/malware-analysis-report/

I might post some progress before I finish prep for the exam. Until then! - Elias Augusto

Update: The Malware Analyst's Cookbook feels like a very superficial guide filled with many tools that do not even exist anymore and confusing elements. Moving on to practical malware analysis.

Kali Linux on the Viliv S5 Update 2

In the middle of my exploration into running Kali on the Viliv S5.
Turned off the wifi chip to find alternative driver because libertas was freezing the system hard by default. Unfortunately made the bluetooth stop working.
Working on getting the touchscreen working still,  working with original publisher of driver to get sources for psmouse.ko.
Working on a fun project, mapping all of the hidden machine instructions on the Viliv's Intel Atom processor. Maybe I'll find something fun.


Here are some notes I have so far. These are unorganized, random, and may only make sense to me, but I hope they will be helpful to some.
Known glitches:
Freezes at random, possibly due to low memory, but I made sure to give it at least 2gb of swap space, so...?
Sometimes doesn't recognize the hardware clock
GPS stops working at random
Don't hard shut it off, it'll do an fsck on boot

VILIV SERVICE
reinstall install.sh - done
recompile viliv-ec - done
local-fs.target - done
change mac address - unnecessary for now, standard mac, only change in real attack scenario
install build-essential, you forgot  - done
install qemu - done
change DNS to 1.1.1.1 and 9.9.9.9 in /etc/dhcp/dhclient.conf
turn on ufw - ufw enable - done
change default desktop environment to lxde - update-alternatives –config x-session-manager - you want startlxde - after installing lxde - done
ndiswrapper - don't write about it, but insert it - done
torghost - from github - git clone https://github.com/susmithHCK/torghost.git && cd torghost && sh install.sh - done
rerun apt upgrade at this point
turn systemctl graphical back oCoand change clipit history to 100 - systemctl set-default graphical.target
PS-2 Mouse driver is what is stopping your touchscreen from being recognized as touchscreen (psmouse.ko) - recognized as mouse
event0
Change to lubuntu background (because no sysadmin wants to see kali on their system) pcmanfm --set-wallpaper="/your/background/file"
Change lockscreen wallpaper - https://null-byte.wonderhowto.com/forum/kali2-0-change-boot-and-login-background-image-0164443/

Install
Retdec - solid decompiler - https://github.com/avast-tl/retdec

Change clipit history

add xfce4-power-manager as a default application
add Ctrl-t as keybinding to gnome-terminal to lxde-rc.xml

Fix exim4
apt-get --purge remove exim4 exim4-base exim4-config exim4-daemon-heavy
apt-get install exim4-daemon-heavy

GPS:
cat /dev/tty reveals a string of coordinates
/etc/basic/gpsd - write your options
Gpsd service temporarily disabled for testing, reboot

Wifi:
Purge firmware-libertas
Wifi and bluetooth confirmed same chip, both stop working if you do this, sd8686

Package installs:

apt-get update
apt-get upgrade -y
Lxde
florence
qemu
gpsd-clients
gpsd
wine
watch
build-essential
alien
kali-linux-all
python3-pip
python-pip
inspectrum
gnuradio
bluetooth
blueman
bless
ndiswrapper
bluez-cups
arduino
putty
falkon - Firefox is too heavy for most tasks - No good for video viewing, great for web browsing and downloading
filezilla
firezilla-common
htop
nethogs
gdebi
remmina
virtualbox
tree
xfce4-power-manager


apt-get update && apt-get upgrade -y && apt autoremove && apt-get clean

torghost - from github

openvas setup

Verify event handlers are still the same

Create scripts that turn on and off the touchscreen by modprobe -r and modprobe loading the psmouse module - done - one of them is in the startup service (offtouch)

Bluetooth:
enables - viliv-ec -e 3
installs - bluetooth blueman bluez-cups
services - systemctl enable bluetooth
bluetooth.service bluetoothd --noplugin=sap

Uninstall: Midori and epiphany-browser

Emergency Driver to Try: DebEm
- Instructions: https://forum.xda-developers.com/showthread.php?t=1598207


Things to Remember:
-Ensure wifi is enabled at boot time, as with other SDIO
-Jaunty is the ubuntu os, meaning 3D graphics is supported
-If all else fails try ubuntu