jxzhxch/hyperdbg

Automatically exported from code.google.com/p/hyperdbg

hyperdbg's Issues

Multiprocessor support

Currently, HyperDbg only puts a single logical CPU into VMX mode. HyperDbg 
will still run on a machine with multiple logical processors, but not very 
well - pressing F12 to break into HyperDbg will only break 25% of the time 
on a 4 CPU box, since the keyboard I/O is only getting intercepted on one 
CPU. 

(Note: When I say processor or CPU below, I mean a logical processor, not a 
physical one. A dual-core processor with HT enabled has 4 logical 
processors).

These changes will need to be made to HyperDbg to support multiple 
processors:

1. Each CPU needs its own vmxInitState and associated memory regions (VMXON 
region, VMCS region, VMEXIT handler stack memory, I/O bitmap, IDT, etc), 
2. VMXON needs called on each processor
3. Each CPU needs its own guest context (CPU_CONTEXT) structure, and any 
function that references the context needs to be able to get the right 
context for the CPU it's running on.
4. Any global structures that can be modified by more than one processor 
will need a lock
5. The cleanup/exit code needs to take all of this into account
6. I'm sure there are other issues 

It's possible to count the logical processors and get the ID of the current 
processor in a OS-independent way with CPUID(1). Getting code to run on a 
specific processor is something that is OS-specific though - you have to 
ask the OS to run a thread on a certain processor by setting the affinity 
mask. In Windows this can be done with ZwSetInformationThread(2). 

Since a major goal of HyperDbg is to have a platform independent core, I 
don't want to muddy up vmx.c with a bunch of Windows-specific API calls 
(although it already makes calls to the Windows kernel's Mm* functions to 
allocate memory...).

With that in mind, here's what I propose:

1. Move any code that requires Windows APIs in vmx.c to a file that 
identifies it as platform-dependent, maybe "vmx-windows.c". Most of 
VmxInitialize() and VmxFinalize() will need to implemented in a platform-
dependent way. #ifdef's can be used to call the right code for the platform 
HyperDbg is built on. Anyone who wants to implement support for other OS's 
can add a vmx-linux.c or vmx-freebsd.c or whatever.
2. Add a function that can identify the current processor and get the 
correct guest context for it. This will be needed by many functions in 
vmx.c and vmhandlers.c. This should be done platform-independently.
3. Review the code to see if there are any other issues that need taken 
into account for multiple processors.

References:

(1): Intel Processor Identification and the CPUID Instruction - 
http://www.intel.com/assets/pdf/appnote/241618.pdf
(2): Processor Affinity in a driver - 
http://www.osronline.com/showThread.cfm?link=26006

Original issue reported on code.google.com by [email protected] on 31 May 2010 at 2:17

Unloading fails when PAE is enabled

What steps will reproduce the problem?
1. Compile HyperDbg with PAE support enabled.
2. Load HyperDbg.
3. Unload HyperDbg

What is the expected behaviour? What do you see instead?
HyperDbg should be unloaded without problems. The machine crashes (triple 
fault) when tring to unload HyperDbg. 

Please provide Bochs output file and serial debug file.

Original issue reported on code.google.com by aristidefattori on 16 Jul 2010 at 1:38

Attachments:

• bochsout.txt

PAE support

HyperDbg doesn't support systems using PAE (physical address extension) 
yet. Since almost all modern OS's now operate in PAE mode by default, it's 
desirable to support it. The work done for this will also help pave the way 
towards support for 64 bit OS's.

Here's a short list of things I know need fixed:

1. For the sake of platform independence, move any Windows-specific code to 
vmx-windows.c (also see issue #1 about multiprocessor support)
2. Replace the PHYSICAL_ADDRESS members of VMX_INIT_STATE with a platform 
independent 64bit value. Maybe redefine it as LARGE_INTEGER and define 
LARGE_INTEGER in some other header file so vmx.c doesn't need to include 
ntddk.h
3. Fix VmcVmcsInitialize() in vmx.c to handle large physical addresses from 
#2 - not passing 0 as the high part of the address in calls to VmxClear, 
VmxPtrld, etc. 
4. Fix the functions in mmu.c to handle 64 bit physical addresses and deal 
with the 3 level PAE address translation. This is probably the most work... 
Right now it looks like the only functions actually used are the ones 
needed to read from a process's virtual memory space, used in winxp.c. We 
could start out by making that work and then fixing the rest of the 
functions.
5. I'm sure there are other things that will need fixed.

There is one other thing to consider: should the same driver binary work 
with or without PAE, or should HyperDbg require a compiler switch to build 
the driver for PAE mode? I think it should require a compiler switch. 
Windows has separate kernels for PAE and non-PAE mode, so it should be 
acceptable for HyperDbg to do the same. Most Windows drivers don't need 
specifically built for PAE because they use kernel API's to access memory, 
but HyperDbg doesn't have that luxury. Doing a check for PAE before each 
memory translation would be a performance hit, which isn't important now 
but may be important later.

Original issue reported on code.google.com by [email protected] on 31 May 2010 at 3:33

Unable to get debugger working

Even after i set the noPAE in boot.ini i get the following error:
  if(cr4 & 0x00000020) {
    WindowsLog("******************************", 0);
    WindowsLog("Error : PAE must be disabled.",  0);
    WindowsLog("Add the following to boot.ini:", 0);
    WindowsLog("  /noexecute=alwaysoff /nopae",  0);
    WindowsLog("******************************", 0);
    goto error;
  }

I've changed my boot.ini to use /NOPAE, no result; still the same error. So I 
commented out the error code, and it loaded the driver just fine.
But now I have no way to trigger any response from the debugger; no gui or 
anything.

I run Windows XP Service Pack 3 (english edition).

Can someone please help me?
Kind regards!

Original issue reported on code.google.com by [email protected] on 15 Mar 2011 at 6:23

Attachments:

• boot.ini

No Mac OS X Support

What steps will reproduce the problem?
1. Install Mac OS X
2. Download hyperdbg
3. Cry

What is the expected behaviour? What do you see instead?
hyperdbg running nicely saving me lots of time/an empty terminal.


Please provide any additional information below.
I would like Mac OS X support :p

Original issue reported on code.google.com by [email protected] on 4 Apr 2013 at 8:11

xpauto mode fails to compile

What steps will reproduce the problem?
1. Edit Makefile.windows to include -DXPVIDEO
2. make -f Makefile.windows

What is the expected behaviour? What do you see instead?

HyperDbg should compile correctly and automatically detect video address and 
resolution under windows.

HyperDbg doesn't compile correctly.

Original issue reported on code.google.com by aristidefattori on 26 Dec 2010 at 11:31