Hello and happy new year.
I need a little guide through process of loading a XML DOM from disk to memory with C++, on windows.
Microsoft provide this example, but it doesn't cover the actual process of what ntKernel Functions are being used to do this, and it doesn't explain what process is behind the actual load .
Does the main process make a call to kernel function to load xml from disk to mem?
VariantFromString(L"stocks.xml", varFileName);
pXMLDom->load(varFileName, &varStatus);
Or there is global process that handle request's to load, and then after it load xml via Kernel Functions, it make's a link to DOM Object, and return it to the process were it was asking.
I want to know what Kernel Function does the job for loading .xml file from disk ?
Thanks !
There is no kernel function for 'loading XML' (at least not one used by the DOMDocument60 coclass.
Instead it simply uses generic file reading calls (in the kernel this is ZwReadFile), the DOMDocument60 code then parses the file content into whatever internal representation it uses.
The only context switch involved will be between user and kernel mode not between one process, kernel mode and another process (unless perhaps some kind of user-mode file system is involved but if it were you likely wouldn't need to be asking this question).
Related
I am a novice security researcher trying to learn about PE injection using droppers/stagers, very much like a cryptolocker would operate.
We are setting up a fire drill for our blue team that handles our QRadar SIEM and we would like to launch some custom malware on it.
So now, for my question :). I understand the general concept op PE injection, but almost all tutorials I have found inject the current EXE (so usually by invoking GetModuleHandle(NULL))
I was wondering how you would go about injecting an EXE from a remote resource (e.g. a HTTP download).
Basically my goal is this:
STAGER file downloads EXE in memory
STAGER file inject EXE using PE method in process X
I do not expect a full answer here, but if you could point me in the right direction, that would be great :).
Note that this code will not be used for malicious purposes.
Best regards!
Very simple actually. All you need to do is download the remote EXE/DLL into a buffer, (i.e. from memory), from this point you have a few options.
You originally need to check for MZ signature, and that it is a valid PE file. You can do this with PIMAGE_NT_HEADERS, checking against Optional.Signature (if valid PE file), and e_magic in PIMAGE_DOS_HEADER (MZ signature)
Now the question is if you wish to inject a dll, load it from memory, search its export table for a given function, get the code and execute i in remote process, or execute EXE from memory.
Assuming you just want to get the ImageBase of the image, as you said you read some tutorials online which talked about it via GetModuleHandle, you first need to map the downloaded buffer.
You can do this via
CreateFileW (for reading), CreateFileMapping (pass handle from createfile), MapViewOfFile (pass returned handle from createfilemapping).
After this you will obtain base image address from MapViewOfFile. You can now do many things with the file, you can inject it from memory, or execute it from memory.
You will need to look into PE fixups (export, and import address table functions), and base relocation via the direct image directory, RVA -> base.
Take note, if you are executing the image in a remote process after mapping the file, use ZwQueueApcThread injection method instead of the more dull ones like RtlCreateUserThread/CreateRemoteThread.
If you are executing the code from memory. After fixing the offsets through relocations, make sure to execute the code via VirtualProtectEx, optionally ZwAllocateVirtualMemory (passing PAGE_WRITECOPY instead of PAGE_EXECUTE_READWRITE) instead of ZwWriteVirtualMemory - WriteProcessMemory as it is much stealthier!
Also, I'm sure you can figure out some other approaches, this is just from the top of my head.
till today when i was starting up a child program in my application (distributed computing) i used execv and as an argument i was passing a filename which has a payload stored.
So i had two files:
1) child-program.binary (+x)
2) child-program.payload (+r)
When child-program.binary executed it knew that it has to load child-program.payload on startup, then the computing took place and the new payload was stored into child-program.payload file.
i would like to change that and instead of storing payload on the hard drive, i would love to run the binary and pass the payload the different way, maybe via pipes?
Also, do i have to store the binary on the hard disk to be able to run it?
Isn't there any other memory like option to execute something?
What are the possible options?
Thanks all !
The advantage of your file-approach is that it is non-volatile and the data can be easily distributed around the globe as file.
Based on your thought about pipes, I assume your "distributed computing" is on the same node. You could also use shared memory see: shm_open and pass the name of the "file" name of your shared memory to the child.
BTW. Pipes or FIFOs let you easily synchornize using poll/select. AFAIK you need a bit more infrastructure to synchronize access to Shared Memory.
I have written a code in C++ to open a file in its default application like .doc in MS-Word now I want to calculate time to open a file into its application.
For that I need to know percentage of file loaded into that application. But from last 7 days I couldn't find any suitable solution. So can any one help me in solving this problem?
If i am using windows then can windows task manager help me to do this?
What you're trying to do is not only impossible, it doesn't even make sense.
When you play an MP3 in WMP, it doesn't load the whole file into memory. Instead, it maps a little bit of the file at a time into memory so it can decode the MP3 on the fly as it's playing. (I suppose if you play the song all the way through, without stopping or skipping or fast forwarding or rewinding, it will eventually read every byte of the file, probably finishing a few seconds before the song is over, but I doubt that's what you're looking for.)
Likewise, Word doesn't read any entire .doc file into memory (unless it's very small). That's how it's able to edit gigantic files without using huge amounts of memory. (Again, if you page through the whole file, it will probably eventually read every byte—for that matter, it may eventually copy enough of the file into an autosave backup file that it no longer needs to look at the original—but again, I doubt that's what you're looking for.)
If you only care about certain specific applications, and those applications have a COM Automation interface (as both WMP and Word do), they may have methods or events that will tell you when they're done "loading" a file (meaning they've read enough of it to start playing/displaying/etc.), or when they've "finished" with a file (meaning moved on to the next track, or whatever), but there's no generic answer to that; different applications will have different Automation interfaces. (And, as a side note, you really don't want to do COM Automation from C++ unless you really have to; it's much easier from jscript, vbscript, or your favorite .NET language…)
If the third party process does not signal that it has loaded something, e.g., through some output stream, one way will be to view the file handles being opened and closed by the processes. I presume this will be similar to how "task managers" like Process Explorer are able to view file handles of processes. However, if the process does not close the file handle once it is done "loading", then, you will not get an accurate time. Furthermore, you won't be able to get a "live" percentage of how much data has been loaded.
How do I read data from another window's application?
The other application has a TG70.ApexGridOleDB32 according to Spy++. It has 3 columns and a few rows. I need to read this data from another application I am writing. Can someone help me?
I am writing the code in MFC/C++
Operating systems donot allow directly reading data from different applications/processes. In case your "application" is a sub-process of main application, you can use shared objects to pass data to and fro.
However, in your case, it seems like the most appropriate would be to dump your data on disk. Suppose you have applications A and B. So B can generate the data and push this data onto a regular file or a database. Then A can access the file/database to proceed. Note that this will be a very costly implementation because of sheer number of I/Os performed.
So if your application is generating a lot of data, making both the applications as threads would be the way to go.
I am building an "Application Virtualization" product. I use XML file as a virtual registry.
Virtual applications generated from my software accesses the virtual registry Xml.
It runs , however runs very slow.
I load and unload the XML on every Registry API calls, because multiple process threaded from the parent access a same registry file. This may cause the application to run slow.
Can any one let me know the alternative for XML...
You could use a database instead. It would be faster. Sqlite is lightweight and powerful.
If you load it into memory and operate on it from there then your problem isn't XML.
Profile your application to find out where it's spending most of it's time.
I think you will probably find it's spending most of it's time searching for the item you want to access.
Its text to tree transformation time.
I managed this in my code by Loadaing and Parsing the XML in all processes, only after a write has occured in any one of the process.
Well, you could of course always use the real registry, which is thread-safe and fast...
Otherwise, you'd have to create a separate process that manages your virtual XML registry, keeping the XML structure in memory so it doesn't have to read/write it all the time. Then the processes that need to access it can use IPC to communicate with the registry process.
Another idea, if the multiple processes are not likely to update the registry all the time: keep your virtual XML registry in memory, and write it to disk when changed, but asynchronously via a background thread. When accessing the registry, first check whether the file has been changed; if not, you don't need to reload it.