That you can query this is not a good sign: *((unsigned char
*)TargetThread + 0x4a) = 1;
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, March 31, 2011 5:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to set other threads to the alertable state
Does anyone other than me think this code example doesnât belong on this
site?
I grant you, itâs a slippery slope once we start deleting posts from
people⌠I usually reserve it for only the most egregious violations. But
I donât like this âinject some code from kernel mode and change the APC
state of the target threadâ thing one bit.
If Iâm the only one who thinks this example is nasty, Iâll leave it in the
thread. If enough people agree, Iâll remove the text (and leave the post)
using my magic powers.
As opposed to the really sound ways to use code that does stuff like this:
*((unsigned char *)TargetThread + 0x4a) = 1;
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, March 31, 2011 6:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to set other threads to the alertable state
Hello,
remove the code if you want and think other people will use it in a
malicious way.
> Your service can open Explorer.exe via OpenProcess, create a chunk of code on the fly in
it using WriteProcessMemory, then SetThreadContext any thread to execute this code, and the code
will do LoadLibrary. A good old DLL injection stuff.
Actually, much easier way to do it is just to create a thread in the target process with LoadLibrary() as a function address. This trick had been described by J. Richter ages agoâŚ
But, if your software will be blocked by antivirus/security tools, you should not complain
Actually, you shouldâŚ
Windows security model is based upon the notion of a user account ( I mean kernel-object one - then it comes to sending window messages the security boundary is desktop object). Any process that runs under a given user account is allowed to do whatever it wants with the processes that run under the same user account, including creation of threads, modification of their execution context, modification of the address spaces of other processes,etc.
In order to inject a DLL into the target process you need to open a handle with the appropriate rights to it, and the rest is handled by the means of well-documented Win32 calls. Therefore, any product that tries to block it is, in fact, blocking the functionality that any program running under Windows should be allowed to have. You should realize that there are no hacks involved here whatsoever.
What the OP tries to do here is basically different trick - it is based upon undocumented KeXXXApc() calls (btw, there is nothing particularly new about this trick - it had been described on rootkit.com ages ago), so donât get surprised if you get âstrangeâ results at some pointâŚ
As opposed to the really sound ways to use code that does stuff like this:
The code â*((unsigned char *)TargetThread + 0x4a) = 1;â is the same as âTargetThread->ApcState.UserApcPending = TRUE;â but in a stupid hardcoded way.
I have never said that this code is OK!! The question in this tread was if it is possible to set the UserApcPending flag to true in a normal way (and not in a hacking or hardcoded way).
I also donât understand why this sample code is so a big problem. If a programmer can create a windows driver then this programmer has also enough skills to create malicious software. We can do nothing to prevent this. If the programmer has not enough skills, then the programmer is also not able to compile this code. You know that it is not enough to copy and past the code.
One good thing for driver writer: on the new 64Bit operating system a driver normally contains no malicious code because it must be signed. Creating malicious code in windows driver is not interesting anymore.
I have searched only a solution to load a normal dll in the windows explorer and this in the kernel mode.
If there exist a clean way to set the UserApcPending flag, then the above code maybe is not so bad to load a dll.
IIRC an explorer shell extension can be loaded by limited users. This is
normal functionality and exactly how the fancy shell menus for .zip, .pdf,
etc. files are generated.
It seems to me that the important point you have missed is that explorer
itself will quite happily load almost ANY DLL that is registered as an
extension without you having to do anything at all. This will give you the
opportunity to execute in the userâs context and capture whatever kind of
events you need. These can be communicated back to your service thru an IPC
method of your choice or sent via your driver assuming an interface with an
appropriate SD (DACL). If I have missed that mark on what you are trying to
do, I hope you will correct me.
While it is possible to spawn a process / inject a DLL from KM, it is
extremely unwise a practice as it is contrary to the OS design. In Windows,
and classic OS theory, the kernel and any drivers exist only to serve
requests from UM processes and so should never instigate work in their own
right. This doesnât preclude HW state driven changes of any kind, but
implies that the notifications exists to serve UM processes. I am not sure
what functionality your application is designed to provide, but you would be
well advised to keep these classic design principals in mind because then
your tasks will be easier
wrote in message news:xxxxx@ntdevâŚ
Hello,
Thank you very much for all the information and possible solutions.
I will check for a solution in the user mode.
But there is a reason why I wanted to load the dll from the Kernel and not
from the user mode:
It should be also possible to install the dll if the service is not running
and the user is on a restricted user account. The driver runs all the time
but the service can but must not run. So only the driver has enough
privileges to load or unload the dll.
I also donât understand why this sample code is so a big problem. If a programmer can create a windows driver then this programmer has also enough skills to create malicious software.
Oh, that is SO not true. The samples in the WDK and the approachability
of KMDF have made it quite possible for unsophisticated users to create
and play with their own drivers.
Mature individuals know enough not pull any of this kind of crap.
Dedicated antisocial malware hackers will always find a way, but there
are relatively few of those in the world. The danger of including code
like that is that it encourages copycat script kiddies in their college
dorm rooms to put together code they donât really understand, which
spreads havoc throughout the known universe.
â
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
As an admin, to the extent to which you can control the proliferation of
this, I hope that you do
wrote in message news:xxxxx@ntdevâŚ
Does anyone other than me think this code example doesnât belong on this
site?
I grant you, itâs a slippery slope once we start deleting posts from
people⌠I usually reserve it for only the most egregious violations. But
I donât like this âinject some code from kernel mode and change the APC
state of the target threadâ thing one bit.
If Iâm the only one who thinks this example is nasty, Iâll leave it in the
thread. If enough people agree, Iâll remove the text (and leave the post)
using my magic powers.
I have created and tested already some explorer shell extensions.
The shell extensions like zip, .pdf, and so on get only loaded if the user opens a menu. You can test it by killing the explorer and then check with the process explorer the loaded modules.
They don?t get loaded if windows explorer restarts or starts. I have tested it on Windows 7 64 SP1.
Sorry but at the moment I have not found a way to load a shell extension without user interaction. If someone knows an example it would be nice.
@Source code trouble
Sorry for my post. Please delete the source. I can not delete it be myself. The admin must delete it.
It was not my intension to create trouble.
When you install a driver, the INF can also install and start (in Vista+, anyway) an usermode service. Depending on the installation time (if it happens very early in the boot for a newly detected device), the INF may not be able to modify HKLM\SOFTWARE hive, but I may be wrong. If your driver is purely software and installed when Windows is fully functional, the INF can create keys in HKLM\SOFTWARE tree.
If you want a service to perform thing in the user account context, you can either have a helper application started when an user logs in, or have a service obtain the logged on session token and start a process with that token. I believe you can also use new (Vista+) task scheduler capability to inject a helper process to the user session.
Use of a helper process is a standard approach thatâs used by many other packages.
I will use the following simple code the load the DLL in the explorer.
(special thanks to @âanton bassovâ and @âMaxim S. Shatskihâ and every one else for the idea)
This code will also work on a no admin user account. I can call this from service or from a little helper app on the restricted user account.
Docs for CreateRemoteThreadEx mention that CreateRemoteThread will fail if issued for a target process in a different session. As of Vista+, the services run in a session different than logged on usersâ.
My $0.02c ⌠information, by itâs very definition, serves to âinformâ people and hiding it only serves to negate that effect. Regardless of the personal opinions of others as to the value or efficiency of the code, by posting that code (which, as others have pointed out, can easily be found going all the way back to a Dr Dobbs article about a decade ago) and then following with a discussion of why that may *not* be the best idea we serve to âinformâ future writers about this technique â the function of the list, yes?
By deleting/ hiding/ ignoring this code we do nothing to help future writers who may/ will/ likely have already discover this technique, find the Phrack/ Dr Dobbs/ [fill in other source here] discussion and without the counterbalance provided here simply believe that âif nobody said it was bad, then it *must* be good!â ⌠which again is the function of the list, yes?
Finally, there *are* valid places to use kernel level APCâs: the KeXXXApc functions are used throughout the MS codebase, arenât KiXXXApc, are linkable with a simply header definition and, like a shared memory segment between userspace and kernelland, have a role in development. The trick is to know when and where to use that technique, something we have good opportunity to do here without bashing the OP burying all evidence of any discussion âŚ
There are win32 apis to get you into the right session.
Mark Roddy
On Thu, Mar 31, 2011 at 10:33 PM, wrote: > Docs for CreateRemoteThreadEx mention that CreateRemoteThread will fail if issued for a target process in a different session. As of Vista+, the services run in a session different than logged on usersâ. > > â > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer >
Sure. But (a) we donât have to HELP them do so, and (b) we donât have to post code that totally sucks that might lead people to believe what theyâre reading is useful or recommended practice (thatâs what CodeProject is for, after all).
It may, if you happen to boot first time from different hardware path, for example AHCI
I think CriticalDeviceDatabase is used in this case instead of INF, and, if you boot this way, then later INF will still be processed (installing the boot HBA driver fully) and reboot will be requested.
wrote in message news:xxxxx@ntdev⌠⌠>> But, if your software will be blocked by antivirus/security tools, you >> should not complain > > Actually, you should⌠> > Windows security model is based upon the notion of a user account ( I mean > kernel-object one - then it comes to sending window messages the security > boundary is desktop object). Any process that runs under a given user > account is allowed to do whatever it wants with the processes that run > under the same user account, including creation of threads, modification > of their execution context, modification of the address spaces of other > processes,etc. > > > In order to inject a DLL into the target process you need to open a > handle with the appropriate rights to it, and the rest is handled by the > means of well-documented Win32 calls. Therefore, any product that tries to > block it is, in fact, blocking the functionality that any program running > under Windows should be allowed to have. You should realize that there are > no hacks involved here whatsoever.
You should complain, complain in vain. Windows secutity model was created in the past century. The very existence of all those antiviruses and âsecurity toolsâ is a proof that it is not relevant. At least for a client OS. Few examples:
1. MS believed that a PC users should be able to access all their devices, USB drives, CDs, printers, bluetooth, wi-fi. In reality: people beg to restrict USB devices, hide BT, SATA ports and so on.
2. MS believed that user can run any executable on their machine. In reality: they had to introduce âsecurity zonesâ over the API, and distinguish normal files from internet cache, downloaded files etc. Then - integrity levels.
3. ⌠No, any app cannot open userâs address book and send mails on their behalf.
4. ⌠No, any app cannot create code on stack and execute it.
5. No, any driver cannot plug into a DRMâed chain.
IT always wants more policy and locking down, so blocking or restricting another API is not something new. It may create another interop issue, so what. Users always get what their IT wants.
An approach of open environment is biting MS in the behind. Any application sees the whole registry and filesystem, and can mess with other applications. Any process can mess with other processes of the same login session. Shared components are still causing DLL hell. A compromise of any application is a compromise of the whole logon session and of all the data (including total loss or theft) of the compromised user. If such an user has admin privileges (just like a default user up to and including Windows 7). Any installed application gets equal permissions.
Microsoft needs to follow iOS example by vetting and sandboxing the apps (at least never allow administrative privileges to code without MS signature or domain signature).
From: xxxxx@lists.osr.com [mailto:bounce-447796- xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Saturday, April 02, 2011 6:09 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to set other threads to the alertable state
Microsoft needs to follow iOS example by vetting and sandboxing the apps
(at least never allow administrative privileges to code without MS signature
or domain signature).
Please donât tell such things. It is enough they totally ruined WM and made it useless, do you want the same for âbigâ Windows?
Michal
NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/
