You really need to read up on public-key cryptography, methinks.
The scheme - if properly (i.e. securely) implemented - could work somewhat like this:
generate a public/private key pair on the infected/affected machine. NOTE: this means each key pair is specific to the machine and there is no single private key that could be used to decrypt everything ...
Is there any way to detect from the driver that this process is protected ?
Disclaimer: This following procedure depends on undocmented data structure which is extracted from PDB symbol of combase.dll file. As usual this may not work in future Windows OS version.
This is the sample C code to detect protected process. The program accepts a valid process ID ...
Following cites, answering your first question come from Windows Internals Sixth Edition Part 1, page 225:
Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution
of 32-bit x86 applications on 64-bit Windows. It is implemented as a set of user-mode DLLs, with
some support from the kernel for creating 32-bit versions ...
which debugger are you using ?
most debuggers will decipher the handle on the spot
that is you can find out the handle info when you have broken on the WriteProcessMemory() Call itself
here is how you can do it with windbg
i am debugging ollydbg and olllydbg ais debugging calc.exe
ollydbg is setting a breakpoint in calc.exe (uses WriteProcessMemory() )
It is also easy using x64dbg. When you break on the WriteProcessMemory the handle will be at [esp+0x4] in the memory.
After you write down the handle (in this case 0xDC) you may go to the Handles tab in the x64dbg main window, then Right click -> Refresh. All the handles associated with your debugged process will be listed. Now you need to find the ...
This technique is equivalent to the Structured Exception Handler for Windows.
The application registers an exception handler, then forces an exception to occur, thereby transferring control to the exception handler. However, when a debugger is present, it will generally intercept the exception to allow user interaction. If your debugger allows you to pass ...
Yea, it's not completely automatic like IDA Pro.
Although the NSA dev team is very active on the project. And any US citizen should be able to add such a feature (via Java) and make a pull request to add it.
I found what you do is simply add the module to your Ghidra project.
When you click on the module/executable it will ask "...Would you like to analyze ...
without any supporting context the -c will be treated as 0xc and it will be subtracted from the address
resolved by win32k!impPsIsThreadTerminating+0xe4
be aware the 0xe4 is will be properly relevant most of the times only if you have an unoptimized build.
because after optimization functions can and will be divided into chunks
by the compiler
My guess is that ppMalloc is a pointer to an instance of the IMalloc COM interface (e.g. it was initialized by a call to CoGetMalloc), which means the the first pointer in it (loaded by the les instruction) is the VTable which has the following methods.
First three are inherited from IUnknown, the parent of all COM objects:
We cannot deduce it from the fragment of code you have provided (unless we are @Igor Skochinsky of course). However, we can notice a few things:
ppMalloc contains the address of dynamically allocated array of function pointers
the function called by call [bx+0Ch] takes three arguments passed by stack: 0, 34h (offset?) and a pointer to the address of that ...
Pretty much, they will all eventually read the PEPROCESS object directory.
Maybe not, depends on what you're trying to hide from. If it's just some basic usermode process iteration then you're probably fine. There's quite a few ways to iterate the process object directory though, such as ZwGetNextProcess.
Your best bet would probably be ObRegisterCallbacks ...
When does the PE loader fill in the IAT?
The IAT is updated at load time by the PE Loader , this is called Load-time dynamic linking, as opposed to Run-time dynamic linking, where LoadLibrary/GetProcAddress are necessary.
Hooking an API not included in Import Address Table
There are several ways to do that actually, and Export Address Table hooking is ...
This is normally not possible. The icon is part of the resource section (.rsrc) which is covered by the signature so any modification will invalidate it and the binary needs to be re-signed.
There may be some parts of the executable you can change without invalidating the signature, but the resource section is not one of them.
Searching for RVA as bytes works for x86 code since RVA is encoded directly in the instruction. However, as you noticed, it does not work on x64 where you instead have a RIP-relative offset which obviously changes depending on the address of the instruction.
I don't see any tricks you could use here but I think that unless your binary is multi-gigabyte, a ...
int 1 is not a part of the SEH setup, that's done by the third instruction. However, int is intercepted by Windows and is translated into an exception which is then dispatched to the handler that has been set up by the previous instructions. So basically here it serves as a sort of "invoke handler" macro.
In practice, any privileged instruction (e.g. hlt ...
Look for the writes to the qword_18009FBD0 to see where it's initialized.
Apparently it's a part of an array called __encodedKERNEL32Functions where various pointers to kernel32 functions are stored after being XORed with __security_cookie. You can rename the pointer to the kernel32 function's name to better see what is happening:
There are many steps to patch an executable, but here is I think the easiest one. The highlighted one is the EntryPoint, you can patch the highlighted one and redirect it to your control, in my sample, I added a new executable section but remember, you have to return the control to the original program, or else it will not run properly.
You understanding is correct:
PE's IAT is resolved by the system loader and can be made read-only afterwards.
ELF's GOT entries initially point to PLT stubs and are overwritten with the final address on the first call.. meaning GOT needs to remain writable.
Writable GOT is indeed a known source of vulnerabilities which is why mitigations like RELRO have ...
It is possible. Take a minute to read the output from analyze. There's a few fields that will tell you what driver faulted like "FAULTING_MODULE", "IMAGE_NAME", and "MODULE_NAME".
It will give you the state of the registers as well and specifically what instruction that caused the crash so you'll see something like
driver + offset:
not sure what methodology you are looking for if the said gui is under some debugger
you can simply detour a patch
or if you are under the wndproc Thread of the gui You can use apis
(for example for checking the menu wordwrap in notepad use CheckMenuItem(); )
or use the oldest trick SendMessage From an external App a demo and src of the third method ...
Sounds like you want to reproduce a system modal dialog box on a more modern Windows OS. It looks like someone took the steps to reproduce this behavior as closely as possible. Not sure about keyboard accelerators, etc though.
To work this out you need to understand how resources are loaded via Windows APIs. A number of APIs in kernel32.dll are commonly used such as:
A number of APIs in Kernel32.dll are used for example:
And for dialogs/windows additional APIs are ...
Depending on the calling convention, the indirect call you NOPped out might end in "RET nn". IIRC this is in fact the case in Microsoft's variant of the x86 thiscall convention. If you NOP the call out, ESP is wrong after the call. This is harmless if ESP is no longer used in that function, and it ends in a standard epilog that uses LEAVE or MOV ESP, EBP, ...
Many programs, especially malware, start a suspended child process (CreateProcess variants), overwrite its code with their own (WriteProcessMemory with or without VirtualAllocEx) and resume the main thread (ResumeThread).
Also look for ReadProcessMemory, it is possible that the call to OpenProcess that you see is actually the same process reading from its ...
There are ways to do it without resorting to hooking or drivers.
For example alternate data streams (ADS), or creating files with "illegal", i.e. reserved, names (NUL, CON ... trailing ., alternative casing to an existing file). Yep, that's right a trailing dot in a file name is illegal in Win32, but the most frequently used file system (NTFS) has no ...
just modified your source a bit to print Rip prior and post in handler
added another exception and eliminated a warning (empty handler block)
and tested with +1,+2,+3 +4 +5 on the handler Hardware breaks doesn't get hit
I haven't checked by single stepping inside RtlpExecuteHandlerForxxx calls
here is a modified src
Shortly after posting the question I took a closer look at my code for parsing the exports and came to the realization, that I made an incorrect assumption.
In the export directory entries, if a function entry point to the export section, you can find a string there, which depicts the forwarder export name. An example of that is visible in the last ...
It is possible that the program is employing mittigations against DLL sideloading and won't load the DLL from current directory. Check Secure loading of libraries to prevent DLL preloading attacks.
You can check what paths the program is actually trying to use with Process Monitor (see Using Process Monitor to dynamically detect nonsecure loads in the ...
using windbg you can set an sxe ld:Modname event break
assuming you are running this which will pop up a help gui for printers
rundll32.exe printui.dll PrintUIEntry /?
if you want to Break on this printUI.dll's CrtMain or AddressOfEntryPoint you can do it like this
C:\WINDOWS\system32>cdb rundll32.exe printui.dll PrintUIEntry /?
Microsoft (R) ...