I need some clarification on the below. After reading the below, I was wondering how a device driver sys file can be embedded in another file, since we need the driver to be signed in order to load on the OS. When the sys file content is extracted and written to a new file, how this file supposed to have the signing?
“BattlEye is using kernel driver to protect their games.
The process BEService.exe has their driver, called “BEDaisy” embedded in the .exe, as a byte array.
On game launch, BEService.exe drops BEDaisy to your disk with CreateFile & WriteFile functions, loads the driver and deletes it. This is done very fast, so you never see the file on your disk.”
When they create a new file for the driver, OS verify the certification of this file.
Not true. If you’re trying to understand the process, then you must speak precisely. There is no verification when you create a file. The signature check happens when the driver is loaded. The system doesn’t know how the file got there.
This is a very common technique. Almost all of the SysInternals tools do this. DebugView, for example, copies a driver called dbgv.sys from its resources. When you run it, it copies the file into place and loads it.
Sounds almost correct …until we recall that that one needs to give some interpretation to this bytestream…
You somehow believe there is a difference between a file’s content and a byte array.
Of course there is the one…
When we speak about the file data, what we actually mean is not only the byte array per se, but also the particular way the target data is structured. For example, an executable image may look like a total piece of nonsense to a text editor, but the system loader is going to realise that it is, actually, a perfectly valid file.
Therefore, the OP’s question is perfectly reasonable. What he had actually asked us about is how to embed a signed .sys file into an executable image without turning the latter into a piece of a plain gibberish from the system loader’s perspective.
and you preserve this semantic meaning to other components that understand it better than you do by preserving the exact sequence of bytes that comprise it - just like the files system does. NTFS after all does not know what a valid .sys file consists of either. if you want to rename one to .txt the shell may warn you that it’s not a good idea but the file system won’t care. and then when you open it in notepad, you get what you get.
but none of that seems relevant to the question from the OP. His question has a simple answer - which is to take an exact stream of bytes that represent a .sys file, embed them into his exe as a binary resource (using one of the standard techniques). and then on the target system extract that exact sequence of bytes and write them to disk. as long as they are exactly preserved along the way, it is an elaborate kind of file copy and the target system gets an exact copy of the original file.
Typically next comes the zero trust game - which i will not describe
NTFS after all does not know what a valid .sys file consists of either
Well, it is (hopefully) obvious the very distinction between a “valid” file and the “invalid” one may make sense only
if you look at the whole thing from the perspective of the application that is actually meant to work with it, and not from the one of the OS, FSD, or any other component. I DO admit that Mr. Berkan’s statement would be perfectly reasonable if we looked at the whole thing from the FSD’s or OS’s perspective, but looking at this from this angle simply would not really make any sense, in the first place.
if you want to rename one to .txt the shell may warn you that it’s not a good idea but the file system won’t care.
IIRC, file extension is a 100% Explorer thing - neither FSD nor the system loader care about it. In fact, I don’t really think that the app that is actually meant to work with the target file is going to care about it either. It is more than likely to decide upon the target file’s validity judging from its actual data (for example,by means of examining the headers that is expects to encounter),rather than from the file extension. More on it below
and then when you open it in notepad, you get what you get.
Actually, there is a good chance that Notepad will crash right on the spot. This is exactly what happened on my machine with Notepad running under Wine as recently as an hour ago when I tried to open a binary file (namely, a file describing an initialised tensor specified in NNEF format) with it. GEDIT politely refused to open the target file because it did not recognize it as a valid text one, so that I tried Notepad instead.
but none of that seems relevant to the question from the OP.
Of course it is. If you try to embed the data in the file in a way that the target app (in this context, the system loader) does not recognize,
it will decide that the target file is invalid. Try to embed some external data in a PE file in some way other than presenting the target data as an embedded resource, and see what happens. Therefore, what the OP asks us about is how to do it properly…