January 26th, 2008, 09:13 PM
[Tool] The Syringe - DLL Injector
My latest project:
The Syringe can be downloaded here.
The Syringe is a command line tool which allows you to inject a DLL into a running process.
This program allows you to use 2 different techniques to inject your own code through a DLL into a running process.
This can be useful during penetration tests to run code under the credentials of the running process.
The two techniques available are:
# Using the CreateRemoteThread API
# By Hijacking the main thread of the target process
Both techniques have their own advantages and disadvantages. Read the README in the download for more information.
January 29th, 2008, 01:26 AM
January 29th, 2008, 05:03 PM
Neat and small - i like it. I haven't still look at it in detail,
but for hijacking, is it related to have the thread in suspended
state and overwriting the entry point resp SetThreadContext/EIP?
You may consider writing a technical tutorial (unlike  ) if you
find the time...
If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 1908-70)
January 29th, 2008, 05:26 PM
Originally Posted by oofki
@Scorpion: You should take oofki's comment as constructive criticism. You're showing us another wheel. If I need another wheel I know where to get one. But, if you can make me believe that your wheel is bigger, better and sexier and that I couldn't live another second without it's new and exciting bells and whistles, I just may ditch my wheel and pick up one of yours...
January 30th, 2008, 08:35 PM
You're right, the 2nd method is suspending the thread and changing the EIP to the get code written to memory executed.
I don't think writing a tutorial will be useful since on codeguru.com there already is a nice tutorial about 3 different ways to inject dll's and they use C/C++ code to explain. For most people that would be much better then my tutorial in assembly
@xiphias360, you know, I don't need to persuade anyone to use this program instead of any other.
I wrote it myself since the CreateRemoteThread method is the easiest one but also the easiest to detect. So I wanted a program which could load any dll in an undetected way.
The main reason I used both methods is that suspending the thread might cause a delay before the dll is executed, If the thread itself isn't active at the time of injecting then you'll have to wait until its active again.
Sometimes this might not be a result you want to have, hence the 2nd method.
There's of course a 3rd method as well, by using a hook, but I didn't see any advantages by using that method that the other 2 methods don't already have.
To make a long story short, I decided to write this program since I feel it can be of use to me. The fact that I'm sharing it is merely so that others don't need to reinvent the wheel. It's up to them to make the choice which one to use, I'm not selling it so I don't have any advantages if someone uses this or another program.
The reason I've distributed it packed and without source is simple, I've seen several programs over the years of which I'm sure that they contain parts of my code while the author claims it's his code. That's the risk of sharing sources but by providing the source on request I hope to prevent these actions since I can control who has the source.
The only disadvantage of this approach is that the original program is ~10kb in size while the packed version is much bigger
January 31st, 2008, 03:22 AM
One thing I've learned in sharing programs is that there's never a way to fully control who has your source. During my military tour, I wrote a program that automated several network security tasks that were extremely time consuming, but had to be done. Everyone else across the states who were in my position had to do the same and it was an important part of the job but felt like watching paint dry. So I made this program that did all the work for me and alerted me whenever there was something important I needed to take action on. Well, I gave it to a single person, who traveled to several commands doing similar but different work in the IT field. Jeebus-christ, it spread like a virus. I had one guy offer me my own program once, lol.
January 31st, 2008, 07:27 AM
I can see what you mean. Directly after my previous post I decided it's not worth having a program of 1.2MB instead of 10KB just for the sake of software protection.
So I reuploaded it unpacked.
I figured, if someone is smart enough to understand and use the disassembled code in his own program, then he's also smart enough to write it on it's own
By Spyrus in forum Miscellaneous Security Discussions
Last Post: October 19th, 2005, 07:28 PM