Q. What is SwiPE? A. SwiPE is a full-fledged (mature) Microsoft® Windows® Operating System (OS) DLL un/injection package and is not your "run-of-the-mill" everyday, common DLL injection solution. The basic premise of SwiPE is to provide maximum stability, be performance driven and always reliable. SwiPE offers a "wait-free" target implementation and does not "leak" memory in the "injected" process atop of not needing to use relocatable assembly code in order to force the target process to load a library, unlike other DLL injection packages which are crash prone. With this in mind, it's been tried and proven within the security community circuit spanning many years as a complete commercial/enterprise solution and is currently implemented in several large security company's flagship products. Furthermore, SwiPE additionally offers a vast array of other useful functionality aside from un/injection. Read More Q. What do I receive when I purchase SwiPE? A. I only sell source code to SwiPE, not .DCU's, external libs (.DLLs) etc. You get the x86 and x64 versions of SwiPE.pas (Delphi code) and the c source code to the newly created process injection driver Q. How much does SwiPE cost? A. Please email me about current pricing plans. Purchasing from me includes free lifetime source code updates. I don't believe in re-charging customers who have already purchased source code from me so updates will always remain free be it a bug fix, new Windows OS support, extended APIs etc. Q. Do you offer support? A. Yes, you can contact me directly at bindshell@gmail.com In the event of a critical support request and you are an existing customer, you can directly submit a support ticket. I also intend to create a support forum that the public can freely use as a professional courtesy to my existing and potential new customers Q. Does SwiPE work on 32-bit and 64-bit operating systems? A. Yes, 32-bit and x64 (64-bit) Microsoft® Windows® Operating Systems (Microsoft® Windows® XP - Microsoft® Windows® 10) Q. What is SwiPE's current stable/production release version? A. v3.0.0.0 Q. Does SwiPE rely on service packs for supported operating systems? A. No, SwiPE is completely service pack independent and doesn't need to rely on any external help that Microsoft® provides Q. Does SwiPE require any special framework such as NET framework or any additional redistributable packages? A. No, it requires nothing that Microsoft® Windows® doesn't already provide out-of-the box Q. Where can I get a list of exposed APIs? A. Please see the Available API List Q. Where I can download and try an un/injection demo binary for x86 or x64 Windows? A. You can email me bindshell@gmail.com for a 32-bit and 64-bit Demo Last virus scan date August 07, 2015. Detection ratio 0/55 according to VirusTotal.com. Secure analysis results can be found Here or feel free to scan the binaries yourself Q. How is DLL injection useful? A. Debugging, subclassing windows in remote processes, code hooking... the list goes on Q. What is SwiPE's source code written in? A. The usermode code portion is written in Delphi while the kernel mode driver, only responsible for injecting into newly created processes when injecting system-wide, is written in c. The driver is 100% PREfast static code analysis compliant with 0 issues/defects. It is also 100% Windows Driver Verifier (Verifier.exe) compliant (ALL settings enabled) which performs various run-time code analysis stress tests Q. Am I able to inject a DLL into more than a single process? A. Yes, you can inject into any process that links with "kernel32.dll" provided that you have sufficient rights required for the requested operation(s) to succeed. This depends on OS security permissions and your user account privileges Q. Does SwiPE use code hooking or anything similar in order to realize DLL injection? A. No, SwiPE does not need to hook any API in kernel mode or usermode. Doing so looks suspicious and mimics malware behavior, which I find unacceptable Q. On x64 can SwiPE inject a 32-bit DLL into a 64-bit process and vice versa? A. 32-bit processes can only load 32-bit DLLs and 64-bit processes can only load 64-bit DLLs as per x64 Microsoft® Windows® OS design. SwiPE handles the internal bitness matching for you internally Q. How can I get SwiPE to work with other programming languages? A. SwiPE can be statically or dynamically linked to as a compiled DLL which can be utilized by any language that is capable of loading a Windows DLL and calling exported functions. For those of you who do not like external file dependencies come compilation time, I am currently porting the Delphi source code to c but I currently do not have an ETC Q. Is SwiPE a usermode or kernel mode injection package? A. Technically speaking, it's a hybrid (both). To clarify, SwiPE uses 100% usermode code in order to un/inject into 32/64-bit processes respectfully, however, newly spawned processes are injected by a small c-written kernel mode driver, this way you are guaranteed that your injected DLL(s) is/are loaded and initialized before the process runs its entry-point routine. This is extremely important if you plan to use hooking code inside your DLLs since you do not want to miss function calls that may take place right at the entry-point, or near there Q. Is process session isolation a problem for SwiPE? kernel32.dll!CreateRemoteThread() has issues with this... A. No, with many technical details aside... SwiPE doesn't need to concern itself with said "Process Session Isolation Restrictions" or Terminal Services logic imposed by the underlying OS when it comes to running remote code outside of your current session. All will succeed from usermode provided you have sufficient process handle rights to the target process. SwiPE also offers a far superior CreateRemoteThread() implementation since it allows up to [3] "optional" thread start parameters that can be directly passed to the newly created remote thread, complete session barrier penetration, as well as full Win32 subsystem compliance (CSRSS on XP and 2K3 needed to be manually informed of newly created threads outside of the current caller process' session, otherwise the new remote thread was not "properly" linked to the Win32 environment and Win32 API calls to kernel32.dll!CreateThread(), kernel32.dll!CreateProcessA/W() etc. would fail!) Unfortunately to date, I have yet to witness any other package, be it commercial or freeware, handle this situation properly let alone at all while the majority leave this situation entirely unaddressed. Anyhow, this is absolutely no problem for SwiPE since it fully supports legacy operating systems correctly as well as the latest Windows 10. Please refer to CreateRemoteThread3() Q. My DLL is not loaded into Modern UI / Metro Apps on Windows 8+. Why? A. These Windows apps are special processes and you will need your to-be-injected DLL to have the group ALL APPLICATION PACKAGES added to your DLL's file permissions. Moreover, your DLL should also not be linked with any manifest whatsoever. It would also not be a bad idea to digitally sign your DLL if you have a code signing certificate, not required but never a bad idea. This is simply a new requirement for loading a DLL into Modern UI apps instituted by newer Windows OS versions and has nothing to do with my package Q. Is Address Space Layout Randomization (ASLR) and/or Data Execution Prevention (DEP) an issue for SwiPE? A. No. SwiPE is ASLR aware and DEP friendly Q. On x64 Windows do I need to sign the driver for injecting into newly created processes? A. Yes, SwiPE requires you to sign the driver for system-wide injection. This way, I am not responsible for any abuse if it were to transpire using my own personal code signing certificate. After a quick x64 kernel mode driver signing, everything is ready to go for you! Q. Need freelancing work/custom programming solutions implemented at a fairly quoted price? A. I'm available for contract programming and consultancy services. Email me to discuss any project(s) and request my CV/resume.