I'm trying to use Rust's Windows WriteProcessMemory in a project of mine in order to replicate the process hollowing technique. Although I use it in nearly exactly the same way in another place in the project, I'm having trouble getting this one to work. It looks to me like the whole buffer isn't getting copied to the location I enter, and/or the u8 integers are being squished into u64s when written.
The WriteProcessMemory call returns BOOL(1), which evaluates to true, and makes me think it is running successfully. If I provide the lpnumberofbyteswritten variable, it comes back as the same size as the shellcode buffer I intended to write. But the memory doesn't look right if I read it after writing, and the shellcode doesn't run properly (whereas in the other place in my project it does). Have I made a silly mistake? If so, does anyone see where?
Thank you!
Related
I have built the DX11VideoRenderer sample (a replacement for EVR that uses DirectX11 instead of EVR's DirectX9), and it's working. Problem is, it's not working very well. It's using twice the CPU time that the EVR does for the same videos (more on this in the next question).
Since I've got the source, I decided to profile it to see what's going on. (Among other things) this led me to:
HRESULT DX11VideoRenderer::CPresenter::CheckDeviceState(BOOL* pbDeviceChanged)
I'm not much of a DirectX expert (actually, I'm not one at all), but it seems likely that window handles can invalidate as monitors get unplugged, windows get FullScreened, closed, etc so a function like this makes perfect sense to me.
However.
When I look at the code for CheckDeviceState, the first thing it does is call SetVideoMonitor, which seems odd.
SetVideoMonitor looks like the routine you call when you first initialize the presenter (or change the target window), not something you'd call repeatedly to "Check" the device state.
Indeed, SetVideoMonitor calls TerminateDisplaySystem, followed by InitializeDisplaySystem. I could see doing this once at startup, but those functions are being called once per frame. That can't be right.
I can comment out the call to SetVideoMonitor in CheckDeviceState (or actually all of CheckDeviceState), and the code continues to function correctly (it's predictably a bit faster). But then I'm not checking the device state anymore.
Trying to figure out the proper way to check for state changes in DX11 brought me here which talks about just checking the return codes for IDXGISwapChain::Present and ResizeBuffers. Is that how this should be done? Because that makes it seem like this whole routine is some leftover from DX9 (where it still would have been poorly implemented).
What's the correct way to check the device state in DX11? Is this even a thing anymore?
I am working on a program that crashes when it is run, but works just fine when debugged in GDB. I have seen this thread and removed optimizations and tried checking values of relevant local and global variables, with nothing seemingly out of place. It is not a concurrent program, so there shouldn't be issues with race conditions between threads. Windows Event Viewer logs the issue as a heap corruption (a problem with ntdll.dll), and I'm not sure what could be causing this. I am compiling with the 64-bit version of MinGW.
The program itself is rather large, and I'm not even sure which part to post. I don't really know how to proceed or what else I could check for. Any guidance if this is a known issue would be greatly appreciated, and if there is any other information I could post please let me know.
I was able to track down the issue - somewhere in the code, I was using fscanf to read in arrays of type int, but the variables that they were being stored in (i.e., the third arg to fscanf) were of type char*. Changed the argument to one of type int* and it fixed the issue.
I'm new to reverse-engineering all in all and been having real difficulty to find exactly what makes a message box appears in the application which I don't have the source code for.
I tried using the very slow search for text to see if it would find the "Error when trying to download (...)". But looks like the message text is received from the wire and, therefore, is not a const string inside the binary.
I also have absolutely no clue of where the function is because I can't "instantly break" when the message pops up, so I would like to know if is there a way to create a watch for value kind of thing?
The idea is to make IDA be prepared to break if any address has the int32 value 65000 (decimal) assigned to it.
If you want to "watch for the value 'Error when trying to download (...)'" - then you'd probably find out that it is very complicated, resource heavy, although possible. You'd have to "trace" into every opcode that the processor executes and check where ever you need (e.g - the stack) for that value (or a pointer to it), which can be done with PIN Tools. This tool allows you to efficiently execute any assembly code you wish between each opcode, function call or "block" (as represented in IDA), by manipulating surrounding opcodes so they won't get affected. It's a really interesting thing to try.
However, what you probably want to do is break on MessageBoxW or MessageBoxA. Simply navigate there (press G and write MessageBoxW and place a breakpoint). This will break when the application will call MessageBoxW, and you can then inspect the stack to see where it was called from.
Anyone knows anything about running executable from memory in OSX?
anything like this:
char *exeFile[size];
loadFromFile(exeFile, "/path/to/data");
execute(exeFile);
I want do that for security reasons. for example It is possible to encrypt exe and decrypt it before launch.
Well, yes, you can do it but its complex. I don't have access to working code right now but I do know others that are/have used it. The key is "NSCreateObjectFileImageFromMemory()", which is deprecated, but that said a few big apps like Skype reputed use it so its probably not going to disappear anytime soon (YMMV).
You have to allocate a memory buffer that's a multiple of the pagesize with vm_allocate. Copy the mach-o executable of the same architecture as the current process to there. Call NSCreateObjectFileImageFromMemory() which returns an object image. Then call successively NSLinkModule, NSLookupSymbolInModule and NSAddressOfSymbol. That last one gets you an actual function pointer to call.
This should give you most of what you need to know, and if you search you may find code that does it too. Good luck!
I'm attempting to edit a library in hex editor, insert mode. The main point is to rename a few entries in it. If I make it in "Otherwrite" mode, everything works fine, but every time I try to add a few symbols to the end of string in "Insert" mode, the library fails to load. Anything I'm missing here?
Yes, you're missing plenty. A library follows the PE/COFF format, which is quite heavy on pointers throughout the file. (Eg, towards the beginning of the file is a table which points to the locations of each section in the file).
In the case that you are editing resources, there's the potential to do it without breaking things if you make sure you correct any pointers and sizes for anything pointing to after your edits, but I doubt it'll be easy. In the case that you are editing the .text section (ie, the code), then I doubt you'll get it done, since the operands of function calls and jumps are relative locations to their position in code - you would need to update the entire code to account for edits.
One technique to overcome this is a "code cave", where you replace a piece of the existing code with an explicit JMP instruction to some empty location (You can do this at runtime, where you have the ability to create new memory) - where you define some new code which can be of arbitrary length - then you explicitly JMP back to where you called from (+5 bytes say for the JMP opcode + operand).
Are the names you're changing them to the same length as the old names? If not, then the offsets of everything is shifted. And do any of the functions call one another? That could be another problem point. It'd be easier to obtain the source code (from the project's website if it's not in-house, or from the vendor if it's closed) and change them in that, and then recompile it. I'm curious as to why you are changing the names anyway.
DLLs are a complex binary format (ie compiled code). The compiling process turns named function calls into hard-wired references to specific positions in the file ("offsets"). Therefore if you insert characters into the middle of the file, the offsets after that point will no longer match what is actually at the position they reference, meaning that the function calls in your library will run the wrong code (if they manage to run anything at all).
Basically, the bottom line is what you're doing is always going to break stuff. If you're unlucky, it might even break it really badly and cause serious damage.
Sure - a detailed knowledge of the format, and what has to change. If you're wondering why some of your edits cause loading to fail, you are missing that knowledge.
Libraries are intended to be written by the linker for the use of the linker. They follow a well-defined format that is intended to be easy for the linker to write and read. They don't need tolerance for human input like a compiler does.
Very simply, libraries aren't intended to be modified by hex editors. It may be possible to change entries by overwriting them with names of the same length, or that may screw up an index somewhere. If you change the length of anything, you're likely breaking pointers and metadata.
You don't give any reason for wanting to do this. If it's for fun, well, it's harder than you expected. If you have another reason, you're better off getting the source, or getting somebody who has the source to rename and rebuild.