ryanmiao / hyperdbg Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/hyperdbg
Automatically exported from code.google.com/p/hyperdbg
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:
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:
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
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.