I want to read the "TSTR"-register (Thermal Sensor Thermometer Read Register) of my Intel Chipset.
I have found that the __readmsr function is what I need.
I have also setup a kernel driver since the function is only available in kernel mode.
But I have no clue how to access the register...
In the datasheet of the chipset it is stated on page 857 that the offset adress of the register is TBARB+03h.
How can I use this adress? Are there tutorials out there that could help me?
Thanks!
As far as I have figured out, trying to do the exact same thing, __readmsr is indeed the right command for accessing registers:
http://msdn.microsoft.com/en-us/library/y55zyfdx%28v=VS.100%29.aspx
however I am working on an i5, and Intel's documentation
http://www.intel.com/content/www/us/en/intelligent-systems/piketon/core-i7-800-i5-700-desktop-datasheet-vol-2.html
suggests that things like MC_RANK_VIRTUAL_TEMP entries are registers, so it ought to work, so you are on the right track probably.. the particular register is on page 272. So technically this is indeed the answer, __readmsr(1568) in my case.
However I am struggling to convince visual studio 2010 to build this in kernel mode, which it seems reluctant to do, I keep getting the Priviledged Instruction error.. When I get this out of the way and the whole program working I'll write a tutorial on the general process, but until then I only dare give a theoretical answer. If your compiler tends to listen to what you say, just add the /kernel compiler option, since you are only reading and not editing the registers it should be safe.
Edit:
There is also this article, the answer more or less suggests what I'm trying to do, though not much more than I have so far, but take a look anyway:
How to access CPU's heat sensors?
"This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) will be generated."
http://faydoc.tripod.com/cpu/rdmsr.htm
Related
I'm a first year grad student trying to write an Operating System from scratch as a side project. I've read the Linux Programming Interface, Modern Operating Systems 4th edition, a bunch of articles on OSdev wiki's, and anything I can find on Google, but I'm having a tough time finding what I should be doing next after writing a simple bootloader, and a kernel that can take user input and display it back onto the screen.
I have a feeling that I need to create some drivers that interact with the file system and memory, but I'm not entirely sure. I'm trying to work my way up with just physical memory and one process running "kernel" for right now. I'll worry about virtual memory (pagging) and multi-processes later. If anyone can give me some kind of direction or better understanding of what happens when the kernel is finally put into memory, that would be great.
Thanks.
I would like to point a resource that will be of great help for you to understand this stuff in real details. One of the great and evolving resource that is being maintained on git.
https://github.com/0xAX/linux-insides/tree/master/Booting
The section 5.4 of SICP develops an evaluator written in an assembly, but I can't figure out why they call it explicit-control evaluator.
Up until this point we were writing interpreters that run over the underlying machine's architecture with its own registers and operations. In a way, we don't truly have control of what's happening down there.
Now, we're going to build a virtual machine in which we'll have explicit control over the registers, operations, jumps, etc. - sure, this virtual machine will also be running on top of the physical machine, but you'll be able to see how things work at a very low level ;)
The latest Intel's XEON processors have 30MB of L3 memory which is enough to fit a thin type 1 Hypervisor.
I'm interested in understanding how to keep such an Hypervisor within the CPU, i.e. prevented from being flushed to RAM or, at least, encrypt data before being sent to memory/disk.
Assumes we are running on bare metal and we can bootstrap this using DRTM (Late Launch), e.g. we load from untrusted memory/disk but we can only load the real operating system if we can unseal() a secret which is used to decrypt the Operating System and which take place after having set the proper rules to make sure anything sent to RAM is encrypted.
p.s. I know TXT's ACEA aka ACRAM (Authenticated Code Execution Area aka Authentication Code RAM) is said to have such guarantee (i.e. it is restrain to the CPU cache) so I wonder if some trickery could be done around this.
p.p.s. It seems like this is beyond current research so I'm actually not quite sure an answer is possible to this point.
Your question is a bit vague, but it seems to broil down to whether you can put cache lines in lockdown on a Xeon. The answer appears to be no because there's no mention of such a feature in Intel docs for Intel 64 or IA-32... at least for the publicly available models. If you can throw a few million $ at Intel, you can probably get a customized Xeon with such a feature. Intel is into the customized processors business now.
Cache lockdown is typically available on embedded processors. The Intel XScale does have this feature, as do many ARM processors etc.
Do note however that cache lockdown does not mean that the cached data/instructions are never found in RAM. What you seem to want is a form of secure private memory (not cache), possibly at the microcode level. But that is not a cache, because it contradicts the definition of cache... As you probably know, every Intel CPU made in the past decade has updatable microcode, which is stored fairly securely inside the cpu, but you need to have the right cryptographic signing keys to produce code that is accepted by the cpu (via microcode update). What you seem want is the equivalent of that, but at x86/x64 instruction level rather than at microcode level. If this is your goal, then licensing an x86/x64-compatible IP core and adding crypto-protected EEPROM to that is the way to go.
The future Intel Software Guard Extensions (SGX), which you mention in your further comments (after your question, via the Invisible Things Lab link), does not solve the issue of your hypervisor code never being stored in clear in RAM. And that is by design in SGX, so the code can be scanned for viruses etc. before being enclaved.
Finally, I cannot really comment on privatecore's tech because I can't find a real technological description of what they do. Twitter comments and news articles on start-up oriented sites don't provide that and neither does their site. Their business model comes down to "trust us, we know what we do" right now. We might see a real security description/analysis of their stuff some day, but I can't find it now. Their claims of being "PRISM proof" are probably making someone inside the NSA chuckle...
Important update: it's apparently possible to actually disable the (whole) cache from writing back to RAM in the x86 world. These are officially undocumented modes known as "cache-as-RAM mode" in AMD land an "no-fill mode" in Intel's. More at https://www.youtube.com/watch?v=EHkUaiomxfE Being undocumented stuff, Intel (at least) reserves the right to break that "feature" in strange ways as discussed at https://software.intel.com/en-us/forums/topic/392495 for example.
Update 2: A 2011 Lenovo patent http://www.google.com/patents/US8037292 discusses using the newer (?) No-Eviction mode (NEM) on Intel CPUs for loading the BIOS in the CPU's cache. The method can probably be used for other type of code, including supervisors. There's a big caveat though. Code other than the already cached stuff will run very slowly, so I don't see this as really usable outside the boot procedure. There's some coreboot code showing how to enable NEM (https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/84defb44fabf2e81498c689d1b0713a479162fae/src/soc/intel/baytrail/romstage/cache_as_ram.inc)
I have a very old application which I bought about 15-years ago, it consists of 5 .exe files used for storing patients' profiles and information. The problem is that this application was programmed to work on a specific computer.
And because I have little knowledge about cracking, I tried to disassemble it using win32dasm but there was no information about string references, tried Hiew to replace JE by JNE and after many, many tries one of the executables worked, but I failed to patch the other files.
Is there any way I can find the exact jump and patch it?
thanks ;)
Yes, there is a way, there's always a way. If you can run the code, you can get at it to modify it.
However, if it was licensed to work on a specific computer, you may not actually have the legal right to use it on another computer. The first thing you should do is figure out is the legality of what you're trying.
Having said that, I've used OllyDbg in the past to do this sort of work. It wasn't nefarious, it's just that the code failed on machines with lots of memory - turns out it used a signed comparison instruction rather than an unsigned one.
The basic idea would be to record the string output when you run it on a failing machine, then locate that string in memory and watch for any piece of code referencing it. You should then be able to backtrack from there to find the conditional jump which brought you there and patch it so that it doesn't (eg, replace the entire jCC instruction with nop bytes.
But, and I stress this, it will require some investigation, this isn't something you can do just by pressing a button and letting the computer work it out. You may well have to dig deep into the assembly to understand how it's working.
I am trying to implement some basic anti debugging functionality in my application. One area that I wanted to focus on in particular, is attempting to prevent people from easily taking a usable memory dump from my application. I read the article at:
http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx
and that gave me a lot of tips for how to detect if a debugger is present, as well as some information on how I might prevent memory dumps. But the author notes that one should be careful about using these techniques, such as removing the executable header in memory. He mentions that there might be times when the OS or other programs may want to use this information, but I cannot see for what purpose.
Has anyone got some other tips as to how I could stop reverse engineers from dumping my program?
I am on Windows.
Kind regards,
Philip Bennefall
There is no reasonable way to prevent someone from capturing a memory dump of your process. For example, I could attach a kernel debugger to the system, break all execution, and extract your process' dump from the debugger. Therefore, I would focus on making analysis more difficult.
Here are some ideas:
Obfuscate and encrypt your executable code. Decrypt in-memory only, and do not keep decrypted code around for longer than you need it.
Do not store sensitive information in memory for longer than necessary. Use RtlZeroMemory or a similar API to clear out buffers that you are no longer using. This also applies to the stack (local variables and parameters).