Log in

View Full Version : RDPMC & RDTSC problem


Neitsa
May 26th, 2005, 16:49
Hello,

I'm currently working on a little tool to disable the use RDTSC for CPL3 process (and enabling RDPMC for CPL3 also).

Some strange behaviours appear :

From the intel manual it is stated that :

1) Bit 2 of CR4 (know as TSD), when Set, will disable RDTSC for ring3 apps
2) Bit 8 of CR4 (known as PCE), when set, will enable RDPMC for ring3 apps

First of all, as stated in the intel manual, I've checked the presence of the TSD field by using :

Code:

mov eax,1
CPUID


and testing bit 4 of EDX. It was here !

I made a little driver for the purpose of enabling/disabling those bits, but when setting only the TSD (for RDTSC) it doesn't work at all... RDTSC doesn't raise a privilegied instruction fault.

While testing again, I decided to enable both bits of CR4 (2 & 8) and it worked, at least for RDTSC, but not for RDPMC => RDTSC while raise a privilegied instruction fault, while RDPMC is NOT enabled for ring3 apps...

I'm wondering what i'm doing wrong, or what I've missed.

Attached is a control program and its driver. The control program will display hex values of Control registers (and also Debug registers).

It is clearly shown that those 2 bits are set (CR4 = 0x6D9 before and 0x7DD after modification), but why the hell I have to enable both bits, and why RDPMC isn't ok for CPL3 process ?

WARNING: Enabling RDTSC as a privilegied instruction will cause crash for some apps (for me it crashed only the microsoft update process) so be carefull ! When Leaving the app, bits are restored to there previous known state, so for testing purpose, leave the app alive if you want to try RDTSC and RDPMC.

Thank you very much,
Regards, Neitsa.

Neitsa
May 26th, 2005, 17:24
problem with RDPMC is solved... Reading the intel manual (well acrobat reader was down 'cause it uses rdtsc also) i should have done :

Code:

xor ecx,ecx
rdpmc


before using it, or it will rise a fault... (possibility of mov ecx,1, there is 2 counter performance).

It remains the other problem,I don't understand why i should enable both bits of CR4 to be able to restrict the use of RDTSC...

Sorry for posting and answering with myself

Woodmann
May 26th, 2005, 21:32
Howdy,

That code is redundant, it means nothing that I can see.

I hope someone can explain this.

Woodmann

Kayaker
May 26th, 2005, 21:35
Quote:
[Originally Posted by Neitsa]It remains the other problem,I don't understand why i should enable both bits of CR4 to be able to restrict the use of RDTSC...

Hi Neitsa,

I took your code snippets and set up a test on Win2K. If only the CR4.TSD bit 2 is set (CR4 = 6D1 before -> 6D5 after), it correctly gives the proper "privileged instruction" error message when RDTSC is used at CPL3. I didn't have the problem of having to set both bits 2 and 8.

Btw, it seems the VC6 compiler doesn't recognize the "cr4" instruction in inline asm. I had to hardcode the opcodes when used, such as:

// mov eax, cr4
_emit 0x0F
_emit 0x20
_emit 0xE0

Regards,
Kayaker

Kayaker
May 26th, 2005, 21:40
You mean in the RDPMC instruction?
Probably from this:


RDPMC {
IF (CPL != 0) && (CR4.PCE == 0) {
#GP(0);
}
IF (ECX = 0) {
EDX:EAX = Performance_Counter0;
} ELSE IF (ECX = 1) {
EDX:EAX = Performance_Counter1;
} ELSE #GP(0);
}

http://www.x86.org/secrets/opcodes/rdpmc.htm

Neitsa
May 27th, 2005, 07:36
Hello,

sorry for lack of explanation... As kayaker stated RDPMC should have an 'xor ecx,ecx' or 'mov ecx,1' before it could be used otherwise it will raise a protection fault.

Indeed, I don't know what has been changed since yesterday but my code is working perfectly even if only the bit 2 of CR4 is changed, restricting the use of RDTSC to ring0. So problem seems to be solved in a mysterious way...

BTW, many thanks for taking time to see what was the problem !

This mini-driver was coded for a crackme wich use a lot of layers (many thousand, which make it untracable by hand) and many RDTSC beetween them.
With a debugger/tracer that i've coded, restricting the use of RDTSC will raise a privilegied instruction fault that catch my debugger. Reading the opcodes at current EIP, if it's an RDTSC instruction I increment EIP by 2, bypassing the instruction (and tweaking EAX to a another value if desired). Therefore the program couldn't see it is debugged/traced with the RDTSC trick.

Attached is source code of control program and driver (both in asm [MASM]) and their binaries . You'll probably need KMDKIT from four-f, and maybe Radasm (an IDE for asm) if you want to compile them again.
Some path to files are hardcoded, you'll probably need to change them. The driver code is self-compilable (in a .bat file).

Maybe it will help someone

Regards, Neitsa.

andrewg
June 19th, 2005, 10:34
Quote:
[Originally Posted by Neitsa]Hello,

This mini-driver was coded for a crackme wich use a lot of layers (many thousand, which make it untracable by hand) and many RDTSC beetween them.
With a debugger/tracer that i've coded, restricting the use of RDTSC will raise a privilegied instruction fault that catch my debugger. Reading the opcodes at current EIP, if it's an RDTSC instruction I increment EIP by 2, bypassing the instruction (and tweaking EAX to a another value if desired). Therefore the program couldn't see it is debugged/traced with the RDTSC trick.



Did the crackme check if tick count was lesser than an amount, and greater than the amount of code?

Kinda means that you'd need to analyse the code and work out and check if the code needs more than x ticks counts, or less than. Makes things a bit harder (hmm, not sure if this is used in any protection system at the moment; if not, wonder how long it will take when they have checks for both ways

</two cents>