how can I hide a device driver from the service controller? - c

I am writing a game hack and want to run cheat engine while the game is running, the anti hack currently detects both the user mode and kernel mode components and terminates the game. I wrote a device driver to hook ZwQuerySystemInformation to hide the process. I would also like to hide the device driver since it is currently still detected.i know i could do this with DKOM but id prefer to use a SSDT hook, does anyone know what api i should hook to filter the list of services/drivers?

You can follow this article from the beginning to the start and use its supplied code and customize it to fit your own needs: http://www.codeproject.com/Articles/46670/Service-Hiding
Word of advice, if you don't know what you are doing, its best to not play with such stuff.
On a side note, they tend to over complicate their architecture and compilation process so expect some hiccups as its not going to be straightforward solution. But, this should address and solves your question and needs.
EDIT:
You would need to hook the services API that is responsible for showing you what services are running currently on your computer. An example for this is "services.exe" this is where all the data structure(s) you would need to modifiy/alter to properly hide your driver. In specific the SERVICE_RECORD structure and the following members needs to be modified as well: Prev, Next and ServiceName. Once you have found such structure inside services.exe its back to basic algorithm 101. Which is to drop the required driver that you want to hide from those doubly-linked list. The following image is courtesy of the article mentioned before.
This is the basic or general rule behind hiding the service.

Related

CRUD in embedded web server

I'm implementing a RESTful web API in an embedded stack which provides a webserver without the REST feature. To be precise, the embedded stack is RTCS which runs on top of the MQX RT operating system, the microcontroller is a Kinetis K60 from Freescale. I'm able to distinguish GET/POST/DELETE/PUT requests and to get the url with the parameters (let's say /this/firstValue/that/secondValue/...).
I use strtok to separate the different elements of the url and take decisions. But my code is just ugly because it's full of strcmp functions and if statements. I also need to check bounds for firstValue and secondValue (which I could do in set/get functions, but 2 functions for each parameter will be repetitve). Moreover I'd like to be able to add parameters without messing around with the decision tree.
I have two questions:
How would you make the code nice and dry?
Do you think a REST webservice is appropriate to control my microcontroller over the network? Do you have examples of such things? I'm using a REST webservice because it provides authentication (no secrecy however because I can't setup SSL sockets yet) and I think it's an elegant solution.
I evaluated some other solutions:
SNMP (snmpset/snmpget): it worked but setting up the MIBs was a real pain, and since it's SNMPv2 there is still no secrecy.
telnet server (I have no SSH solution yet): I don't see any advantage/drawback aside that REST will probably be easier to control from the outside, I'm testing it with curl :)
SOAP Remote Procedure Call (I just don't like it)
Any other idea ? I need something simple and scalable since there could be multiple targets to control. I have limited resources :s. I would need secrecy at some point, and I expect to have it when CyaSSL (an embedded ssl implemetation) is ported to MQX. They said it's happening next month so secrecy won't be an issue anymore but if you have other ideas...
--
Emilien
REST is an architectual pattern, So i guess you mean your server provides HTTP.
A resource is 'any data that can be named'. e.g. an LED on your embedded device could be a URI of '/leds/led3' You could change the data it holds (its state, rgb led? etc) with the standard PUT request, and GET should return its current state.
As for coding it, a generic tree structure maybe wise if memory permits to make path finding as simple as possible. With the data and function pointers (emulating objects) at the leafs

What are the difficulties of writing core os components in managed code?

I know that some of the Microsoft employees are members of StackOverflow like the famous Raymond Chen to Larry Osterman (enginner of the Vista's audio stack and per-application sound controlling mechanism) and we know Jeff Atwood is here too. So maybe we can learn some lessons about managed code in core Windows componenets straight from the horse's mouth.
I have downloaded all leaked Windows Longhorn builds (from the "obvious" sources) and poked around to find managed code with tools like "dotPeek" and ".net OR not". I found that managed code was declining in every build after the august 2004 "longhorn reset". But i even find "windows movie maker" written in managed code.
So, here is the question: What are the diffuculties of writing core os components in managed code?
I'm sure there's other considerations, but this is a reasonably obvious one that springs to mind:
Managed code components require a specific version of the managed runtime, and, IIRC, a process can have only one instance of the managed runtime in it. Right off the bat, this rules out using managed code for shared components - since an app and one or more of its components could require different versions of the runtime, and limits its use to application-style components.
Also keep in mind that more parts of Windows are actually 'shared components' than might be immediately obvious. While you might think of Explorer as a form of application, as soon as an app opens a File/Open common dialog, it's now got a bunch of Explorer components within it, listing the available files and directories.

Need a kernel mode API that will find the base address of user mode Win32 Dll

I am new to device driver programming. I've followed the available tutorials on the web which has provided helpful information to get started. However now I have embarked on a new project where the exclusive goal is to search for functions which have been hooked by malware or keyloggers. So I think I have sorted out what I need to accomplish this though I still need to be able to locate the load address of the system dll's (i.e. kernel32.dll, user32.dll and the like) that are already loaded in memory. I need the load address so that I can parse their PE to get to the export and import sections. Furthermore adding the load address to the file size will give me a address range to cross reference the addresses of the export functions no ? Cross referencing the the IMPORT address will be a little more involved but it can be done according to my estimates. I thought that building a kernel mode driver would be the right way to go since accessing memory outside the kernel driver's address range would not be an issue for the driver as opposed to a user mode app. How else will I be able to access the addresses located in the EAT and IAT of the target dll ? I know there exist a user mode API that can provide the load address mainly being GetModuleHandle but I would like to find the equivalent in kernel mode. I could write a user mode application that could relay this information to the driver but prefer that this all be done in kernel mode if possible. Any suggestions or comments would be most welcome.
Thanks in advance
Victor
p.s This post has been edited for more clarity. Hopefully it will make it more clear as what I am trying to accomplish.
This is probably not a very good idea to do in kernel mode. When are you going to actually do this and guarantee the process is in a state where you could walk the IAT?
What if the process is in the middle of loading a DLL? If you're executing in-thread (i.e. from a syscall or device IOCTL), what if other threads are executing too? Doing this when you're not the OS is a very difficult proposition to correctly do, and it's very easy to destabilize your customers' machines (hell, it's reasonably hard to do even if you are the OS)
Take a look at LdrGetProcedureAddress and the rest of the gang.
Edit:
MmGetSystemRoutineAddress might also be helpful.
Just wanted to thank everyone for their contribution. I did manage to some further research and discovered that there is a kernel mode API called PsLoadImageNotifyCallback that is able to find the base addresss of any process.

Remote Desktop Project in C

I want to make project for my final year in college.
So someone suggested me to make Remote Desktop in C.
Now I know basic socket functions for windows in C i.e. I know how to make
echo server in C.
But I don't know what to do next. I searched on internet but couldn't find
something informative.
Could someone suggest me how to approach from this point..any tutorial...or any source ?
I think this is do-able. For a college project, you don't need to have something as complex and as full-featured as VNC. Even demonstrating simple keyboard and mouse control and screen feedback would be enough, in my opinion, and that's well within reach.
If you're doing everything from scratch and using Win32, you can get the remote screen using the regular "printscreen" example all around the internet.
http://www.codeproject.com/KB/cpp/Screen_Capture__Win32_.aspx has it, for one. You can then compress the image with a third-party library, or just send it raw; this wouldn't be very efficient but it would still be a viable demonstration.
Apart from capturing the screen data remotely and showing it in the local window, you'll need to listen for local window messages for mouse and keyboard events, send them to the remote host, and then play them back. http://msdn.microsoft.com/en-us/library/ms646310%28VS.85%29.aspx will probably do that for you.
Check tightvnc TightVNC is a free remote control software package. The source code is also available.
For sending the image of the screen I would probably use rtp. The JRTPLIB is really handy for that.
And yes, as KevinDTimm says, an echo server is the very easiest part.
KevinDTimm may well be right, writing an RDP client would a fairly significant undertaking. To give you some idea, the current spec, available at the top of this page, is 419 pages long and includes references to several additional documents for specific aspects of RDP like Audio Redirection and Clipboards.

Writing an API to communicate with a device connected on Serial port

I am afraid that several terminologies in my question are wrong. Please bear with me and correct me wherever I am wrong.
I have to write a library/program that will provide set of function to operate a card reader attached at Serial Port. Like to eject card that was inserted in it, user will simply have to call in his code, for example,
cardEject(); // or
track2Data( response); // to read data of track 2 of magnetic stripe.
cardEject() and other functions will themselves take care of opening serial port, writing data to it, checking the acknowledgement, checking error code, resending command in case of failure, etc. I am pretty clear about communicating with devices on serial port.
My question is, after writing all these functions and testing them, how should I provide them to the user.
Should I give him a header file (.h) and an object file (.o)? So that he can link to the object while compiling his actual program.
Should I provide a static library (.a)?
Which one is a better idea?
Is it a good idea that each function open serial port and then close it? Or a initCardReader() opens it, sets its properties and closeCardReader() should close it? All other functions can only be called after initCardReader()?
Now a silly but real question :-) what is the terminology used for such programs? Is it a driver or library or device interface? What is the correct label for such projects?
Thanks for your time.
Edit
Thanks to all of you for guiding me. Really appreciated.
This API has to become part of a larger project. In fact, I will be working on that project too. But there is a strong possibility that this API will be used in other projects with or without me. I think, considering the possible use in other projects, library makes more sense. Kindly correct me if I am wrong.
I'll go with the answer from Anders K. you are writing a API for your card reader.
My two cents about the more general questions:
Your question about open/close connection, there are two aspects that you have to keep in mind. Lets assume you proceed the way in which you leave it up to the user to open and close the connection. What if he forgets to close it after he finished, what when multiple processes access the card-reader? In those scenarios you may want to free the port to the other processes after each write/read. In the end it depends on the operations that will be done, the process using your API will usually always call your read method multiple times you might want to leave it open or you could implement a read multiple records in your API again avoiding the possibility that a connection gets left open.
I would make a library if it is mainly used in other projects. It also puts you into the position of changing the lib at one place for everyone to implement. Again depending on where you will implement it, there are numerous scenarios when adding your code is the better option.
I think you should do it as simple as possible, a static library and a header file should be a good start.
One way is to treat the card reader in the same way any other resource like a file, meaning you open/init the card reader and return some handle that identifies the card reader. Then subsequently use that in all functions when accessing the card reader.
My two cents:
I think how you provide the output depends on the user. Is this person working closely with you in the same company / project, or is this going to an external source?
If its going external definitely make it a library...it may be easier to create a library in the other case as well, since it would mean less things for this other user to worry about.
Is your code going to be integrated into a larger project? If so, you should just build your code into a subfolder in this project and provide him with the required functions that are needed. I think this portion is more subjective than anything.
Regarding opening/closing the ports, again it depends how it will work. If you are simply providing the API for other programmers to use (and don't know how it will work), I would say abstract it into an initCardReader/closeCardReader function call. That way, if the user wants to do multiple transactions he doesn't need to worry about wasting processing time with each call he makes...he can simply open/close at his discretion.
And it sounds to me like you are writing API calls for a card-reader device driver ;)
You can put this set of functions in the shared lib (like: libCardReader.so) and give away with the Header file to the programmer to reference and use it in his/her code. The following link provide very good intro about building the SO file (http://www.network-theory.co.uk/docs/gccintro/)

Resources