Have you ever openly mused to yourself, “I wish that Impact could _________?” What if I told you that it’s actually pretty straight-forward to build new functionality into Core Impact? Oh, so now you’re interested? Awesome. Over the next couple of blogs, I’m going to show you how you can extend Core Impact with custom modules to leverage novel exploits and integrate with third-party tools. However, before I get there, I’m going to have to give you a brief history lesson.
When Core Security was founded in 1996, we were one of the first penetration testing companies. All of the tools that we used were built in-house because there weren’t commercial tools available for what we were trying to achieve. As our process matured, we began seeing the value in automating repetitive tasks in order to free up valuable pen-tester time. Since we were automating things, we thought we might as well build a framework so that tools can be built consistently and with the ability to maximize modularization and code reuse. What do you know? Our in-house framework became the product that is available today as Core Impact. All framework is accessible to you as a user if you know what to do.
That’s what I’m going to show you over the next couple of weeks. We’ll start today with setting up your development environment and discussing the architecture of how Impact modules work. In the next blog, we’ll actually start building a useful integration module, and learn as we go.
The Development Environment
First, you’ll want to make sure that your copy of Core Impact is installed, properly activated and up to date.
There are a couple of preparatory steps that I strongly suggest that you do; unless you like doing the deactivate, uninstall, reinstall, reactivate dance with Impact a lot. You *really* want to use a tool like Git to create a version-controlled repository of your Impact modules folder. This will allow you to maintain a history of your changes, but also to revert your modules to a known good state if you accidentally mess something up. Trust me, it will happen.
The next thing to consider is what type of development environment you want to use. Much like programmers, security folks tend to have strong opinions about what development environment should be used. Members of our own Impact development team and our Exploit Writing team have the flexibility to choose the development environment they like. I’ve seen them using everything from Eclipse, to Notepad++, to Visual Studio, to PyCharm. They aren’t writing this blog, so I’m going to strongly suggest to you that you use PyCharm. There’s a free Community Edition, but it’s really worth it to spring for the Professional edition for $8.90 a month, or $89 per year. Autocomplete is more than worth the price. You will also need to install a copy of Python 2.7.x on the machine. This is mostly to make PyCharm happy.
Impact has it’s own Python interpreter embedded into the product. Our most recent release ships Python 2.7.11. This has a couple of implications that you need to be aware of. Impact’s Python Interpreter will ignore modules that are installed on the system outside of the Impact directory hierarchy. That’s intentional behavior, so that we don’t break existing Python bits, and that those outside bits don’t break us. It’s for the best, really— since my hair isn’t long enough to pull when I’m troubleshooting broken version dependencies. Impact’s python also recurses slightly differently through our module folders than the standard for Python, so we’re going to have to make a couple of minor tweaks in PyCharm to make sure that we get autocomplete and similar features up and working.
Inside of Impact, click on the Modules menu. Then, New Module.
Fill out a name for the module, select Network for now, and select a Category where you’d like it to appear in the Impact UI, then click Next.
The next screen in the wizard builds the Module Parameters. We’ll leave it blank for now, and explore it later. Click Next, then click Finish.
Navigate to the file. It’ll be in %APPDATA%/Impact/UserModules.
Right click on the file, go to Open With, and find PyCharm.
You should see something like this:
This next step is very important for making PyCharm autocomplete the Impact internal class structures.
Expand the AppData folder, then Roaming, then IMPACT
We want to take two of the folders under this tree and mark them as “Resource Root” by right clicking, selecting Mark Directory As… Resource Root
%APPDATA%\Roaming\IMPACT\Components\Site-Packages and %APPDATA%\Roaming\IMPACT\Components\Modules should be marked thusly.
Now, let’s do the traditional thing and create a simple “Hello World” style module that will just print something to the module log so that we know it’s working.
Let’s first take a look at the autogenerated module code.
You’ll see five different function stubs. Initialize() and finalize() are run once per module execution, so you’ll put your target independent setup and teardown code here. Impact supports passing multiple targets into a module, so targetSetup(), targetRun(), and targetFinish() will be executed for EACH target passed into the module.
Impact has a number of helper functions for logging, depending on how verbose you want Impact to be. Impact defaults to a Medium verbosity, so we’ll use the .LogMed() function.
Then we can save it and run it from Impact. Look in the Module Log for the output.
And just like that, we’ve written a custom, albeit utterly useless Impact module. Next week, we’ll actually start building something useful. Stay tuned.