I am trying to disable S0ix sleep on Windows (As there's no way to force Windows to use S3 sleep, after the "CsEnabled" registry no longer works) and allow S0ix on Linux (S3 Sleep seems to be not working on Chromium OS). But I couldn't find a reliable way to tell what OS I am running in ACPI and patch in OpenCore. Something like doing the reverse of the following piece of code for disabling S3...
// AOAC
// Name (_S3, ......
// In config ACPI, _S3 to XS3
// Find: 5F53335F
// Replace: 5853335F
//
DefinitionBlock("", "SSDT", 2, "OCLT", "S3-Fix", 0)
{
External (XS3, IntObj)
If (_OSI ("Darwin"))
{
//
}
Else
{
Method (_S3, 0, NotSerialized)
{
Return(XS3)
}
}
}
//EOF
Of course there're _OS, _OSI and _REV methods in ACPI standard, but according to Linux kernel documentation, the Linux kernel is mocking itself up as Windows/Darwin. Though currently I could tell I am loading a Linux kernel, as Linux would return TRUE when querying if _OSI is Darwin. But what if I install Hackintosh in the future?
you might enter BIOS setup menu to take a look
Related
Hi i'm relativly new to kernel programming (i've got a lot of c++ development experience though) and have a goal that i want to achieve:
Detecting and conditionally blocking attempts from userland programs to write or read to specific memory addresses located in my own userland process. This has to be done from a driver.
I've setup a development enviorment (virtual machine running the latest windows 10 + virtualkd + windbg) and already successfully deployed a small kmdf test driver via the visual studio integration (over lan).
So my question is now:
How do i detect/intercept Read/WriteProcessMemory calls to my ring3 application? Simply blocking handles isn't enough here.
It would be nice if some one could point me into the right direction either by linking (a non outdated) example or just by telling me how to do this.
Update:
Read a lot about filter drivers and hooking Windows Apis from kernel mode, but i really dont want to mess with Patchguard and dont really know how to filter RPM calls from userland. Its not important to protect my program from drivers, only from ring3 applications.
Thank you :)
This code from here should do the trick.
OB_PREOP_CALLBACK_STATUS PreCallback(PVOID RegistrationContext,
POB_PRE_OPERATION_INFORMATION OperationInformation)
{
UNREFERENCED_PARAMETER(RegistrationContext);
PEPROCESS OpenedProcess = (PEPROCESS)OperationInformation->Object,
CurrentProcess = PsGetCurrentProcess();
PsLookupProcessByProcessId(ProtectedProcess, &ProtectedProcessProcess); // Getting the PEPROCESS using the PID
PsLookupProcessByProcessId(Lsass, &LsassProcess); // Getting the PEPROCESS using the PID
PsLookupProcessByProcessId(Csrss1, &Csrss1Process); // Getting the PEPROCESS using the PID
PsLookupProcessByProcessId(Csrss2, &Csrss2Process); // Getting the PEPROCESS using the PID
if (OpenedProcess == Csrss1Process) // Making sure to not strip csrss's Handle, will cause BSOD
return OB_PREOP_SUCCESS;
if (OpenedProcess == Csrss2Process) // Making sure to not strip csrss's Handle, will cause BSOD
return OB_PREOP_SUCCESS;
if (OpenedProcess == CurrentProcess) // make sure the driver isnt getting stripped ( even though we have a second check )
return OB_PREOP_SUCCESS;
if (OpenedProcess == ProtectedProcess) // Making sure that the game can open a process handle to itself
return OB_PREOP_SUCCESS;
if (OperationInformation->KernelHandle) // allow drivers to get a handle
return OB_PREOP_SUCCESS;
// PsGetProcessId((PEPROCESS)OperationInformation->Object) equals to the created handle's PID, so if the created Handle equals to the protected process's PID, strip
if (PsGetProcessId((PEPROCESS)OperationInformation->Object) == ProtectedProcess)
{
if (OperationInformation->Operation == OB_OPERATION_HANDLE_CREATE) // striping handle
{
OperationInformation->Parameters->CreateHandleInformation.DesiredAccess = (SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION);
}
else
{
OperationInformation->Parameters->DuplicateHandleInformation.DesiredAccess = (SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION);
}
return OB_PREOP_SUCCESS;
}
}
This code, once registered with ObRegisterCallback, will detect when a new handle is created to your protected process and will kill it if it's not coming from Lsass, Csrss, or itself. This is to prevent blue screens from critical process being denied a handle to
your application.
I want to know how erlang's VM preempts the running code and contexts the stack. How it can be done in a language such as c?
The trick is that the Erlang runtime has control over the VM, so it can - entirely in userspace - keep track of how many VM instructions it's already executed (or, better yet, an estimate or representation of the actual physical computation required for those instructions - a.k.a. "reductions" in Erlang VM parlance) and - if that number exceeds some threshold - immediately swap around process pointers/structs/whatever and resume the execution loop.
Think of it something like this (in kind of a pseudo-C that may or may not actually be C, but I wouldn't know because I ain't a C programmer, but you asked how you'd go about it in C so I'll try my darndest):
void proc_execute(Proc* proc)
{
/* I don't recall if Erlang's VM supports different
reduction limits for different processes, but if it
did, it'd be a rather intuitive way to define process
priorities, i.e. making sure higher-priority processes
get more reductions to spend */
int rds = proc->max_reductions;
for (; rds > 0; rds--) {
/* Different virtual instructions might execute different numbers of
physical instructions, so vm_execute_next_instruction will return
however many reductions are left after executing that virtual
instruction. */
rds = vm_execute_next_instruction(proc, rds);
if (proc->exited) break;
}
}
void vm_loop(Scheduler* sched)
{
Proc *proc;
for (;;) {
proc = sched_next_in_queue(sched);
/* we'll assume that the proc will be null if the
scheduler doesn't have any processes left in its
list */
if (!proc) break;
proc_execute(proc);
}
}
Proc* sched_next_in_queue(Scheduler* sched)
{
if (!sched->current_proc->exited) {
/* If the process hasn't exited yet, readd it to the
end of the queue so we can resume running it
later */
shift(sched->queue, sched->current_proc);
}
sched->current_proc = pop(sched->queue);
return sched->current_proc;
}
This is obviously quite simplified (notably excluding/eliding a lot of important stuff like how VM instructions are implemented and how messages get passed), but hopefully it illustrates how (if I'm understanding right, at least) Erlang's preemptive scheduler and process model works on a basic level.
All code of Erlang will compile to operation code of Erlang's VM. Erlang's VM execute Erlang's operation code by OS's threads which are created at startup of Erlang's VM.
Erlang's code run on Virtual CPUs which are controlled by Erlang's VM. And Erlang's VM consider IO as interrupt of Virtual CPUs. So Erlang's VM implements a machine and a scheduler like an OS. Because of operation code and non-blocking IO, we can implements preempts in Erlang's VM using C languange.
I am developing a Firefox add on, I pretend my add on to be able to run in both desktop and mobile devices. I think more or less everything is compatible with both environments, however there are pieces of code that I would like to run depending on whether the current device is mobile or desktop, so the question is if there is something like system.isMobile() that can be used in the following way:
var system = require("sdk/system");
if(system.isMobile())
console.log("firefox for android");
else
console.log("normal firefox");
As you can find at the system api documentation, there is a variable telling the operating system.
code:
var system = require("sdk/system");
console.log("system platform = " + system.platform);
output:
system platform = linux
disclaimer: I didn't tested on mobile environment.
You can use the System High-Level API. system.platform will contain the information on the type of OS the user is running.
You can use it like so:
var system = require("sdk/system");
var platform = system.platform // Will contain platform, i.e. Windows, Linux, etc.
// You can log this data to the console
console.log("System Platform = " + platform);
When you call system.platform, it will usually return one of the values listed on this page, converted to lowercase
I manually install my driver using an .inf file. Until now, I deleted the oem.inf and .pnf files from the inf folder to uninstall. Whenever I install a new driver I delete/uninstall the old inf and pnf files.
In my old uninstalls (by deleting .inf and .pnf files), I didn't modify or delete any registry settings.
In this case do I want to change or remove any settings from the registry (for example: devnode)?
You should use the SetupUninstallOEMInf function to uninstall the .INF (and subsequently .PNF) files. This will take care of the details. pnputil (on Vista and higher) should do the equivalent thing from the command line. However, this function will not delete drivers that are currently installed (e.g. associated with a devnode).
Why are you uninstalling the old driver first? The user might already installed your driver for at least one devnode. Why not use a Microsoft-sanctioned solution such as DpInst? It will do the work required to update the driver.
Passing SUOI_FORCEDELETE to SetupUninstallOEMInf wouldn't be a good idea, cause you'd end up with lingering .INF references in your devnodes (in the registry).
At work I wrote a utility I called DriverUninstaller that deletes the devnodes and then deleted the INFs. I only use this utility for uninstallations. Upgrades are handled by DpInst, as they should be. The flow is roughly:
Enumerate them with SetupAPI (e.g. by device class if your device class is unique)
For each devnode, call SetupDiCallClassInstaller(DIF_REMOVE, ...)
Call SetupDiBuildDriverInfoList to find all .INF files for my device
For each INF, call SetupUninstallOEMInf
If there'll be interest in this utility, I might be able to persuade my employer to open-source it :-)
As the other answer points out the API to remove drivers on Windows is the SetupUninstallOEMInf method but I figured I'd add a few important notes here:
the INF path parameter must be the file name only (must not include the full path!)
this API requires Administrator privileges (this is not much of a surprise)
on 64-bit systems, the method only works when executed in the context of a 64-bit process (ie. WOW64 doesn't work)
The SetupDiGetDriverInfoDetail API can be used to query information about the relevant INF file(s) to remove for a particular device. And the SetupDiEnumDriverInfo/SetupDiBuildDriverInfoList APIs can be used to enumerate all drivers for a particular device.
// given infFilePath - full path to inf as returned by a query using SetupDiGetDriverInfoDetail
TCHAR* infFileName = GetFileNamePart(infFilePath);
if(SetupUninstallOEMInf(pInf, SUOI_FORCEDELETE, NULL))
{
// success
}else
{
DWORD errCode = GetLastError();
if(errCode == 0x02)
{
// means that the driver INF file was not found
// most likely it was already uninstalled
}else if(errCode == 0x05)
{
// must run as administrator
}else
{
// some other error code.. handle appropriately
}
}
I've open-sourced the code for a tool I wrote to perform driver uninstalls for USB and Media/Image devices. Details here: http://mdinescu.com/software-development/30-driver-hunter-programatically-uninstall-drivers-in-windows
I'm stumped trying to get etherOutputHookAdd() to work. Its counterpart, etherInputHookAdd(), seems to work fine. The OS version in question is VxWorks 5.4 .
The hook code looks like so (the code I intend to actually run is more complicated, but this serves for an example.)
int anCounter;
STATUS etherHook(struct ifnet *pif, char *buf, int size)
{
anCounter += 1;
return FALSE;
}
I can hook up etherInputHookAdd from the vxworks shell like so
etherInputHookAdd etherHook,"fei",0
This returns 0 (STATUS OK), after which examination of the 'anCounter' variable will indicate activity as expected. However, no such luck with the output direction. I've tried both of these command lines
etherOutputHookAdd etherHook,"fei",0
etherOutputHookAdd etherHook
Both of these return OK, but the hook routine doesn't seem to be getting called at all. My best hypotheses are (1) I'm missing an initialization step, or calling it wrong, (2) the etherOutputHookAdd implementation is just a stub, (3) you just can't call it from the shell, or (4) maybe my nic driver implementation is buggy.
Any ideas that solve the central problem - how do I see what's being sent off my board - are welcome.
The following VxWorks network drivers support both the input-hook and output-hook routines:
if_cpm - Motorola MC68EN360 QUICC network interface driver
if_eex - Intel EtherExpress 16
if_ei - Intel 82596 ethernet driver
if_elc - SMC 8013WC Ethernet driver
if_elt - 3Com 3C509 Ethernet driver
if_ene - Novell/Eagle NE2000 network driver
if_fn - Fujitsu MB86960 NICE Ethernet driver
if_ln - Advanced Micro Devices Am7990 LANCE Ethernet driver
if_sm - shared memory backplane network interface driver
if_sn - National Semiconductor DP83932B SONIC Ethernet driver
if_ultra - SMC Elite Ultra Ethernet network interface driver
if_gn - generic MUX interface layer
The following drivers support only the input-hook routines:
if_nic - National Semiconductor SNIC Chip (for HKV30)
if_sl - Serial Line IP (SLIP) network interface driver
The following drivers support only the output-hook routines:
if_ulip - network interface driver for User Level IP (VxSim)
The following drivers do not support either the input-hook or output-hook routines:
if_loop - software loopback network interface driver
To those few who might stumble this way .. It was the horrible 'hypothesis 4'!
It turns out that in order for etherOutputHookAdd() to work correctly, it is incumbent on the NIC device driver writer to include a call to the function pointed to by etherOutputHookRtn. All etherOutputHookAdd() does is add your proffered packet handler to a list, so that when a NIC driver calls etherOutputHookRtn, you get a copy of what's being transmitted. Sadly, there are many drivers where for whatever reason, this was simply not done.
So in cases such as this one, there are only two courses of action.
find a patch for your driver, or patch it yourself
change tactics entirely, e.g., try using etherInputHookAdd() on the other side.
In case you migrate to a newer version (>6.x) of VxWorks , etherLib is no longer supported. Instead, one can use muxLib for a similar purpose.
Hook inbound traffic: Use muxBind with MUX_PROTO_PROMISC or MUX_PROTO_OUTPUT.
Hook outbound traffic: Use muxBind with MUX_PROTO_OUTPUT.
You should provide a callback routine in both cases.