I'm proud to announce the release of Project Hijack 0.2. It's available as a shared library for easy integration with current and new projects. Libhijack 0.2 makes injecting arbitrary code incredibly easy. 32bit Linux systems are supported. 64bit Linux systems are mostly supported, with one known bug. I've been working on this version for the past few months and am excited to see this project take off. I'll be working on fixing the 64bit bug (and will probably release 0.2.1 with the fix) then move on to injecting other shared objects, rather than just shellcode.
|
|||
Well, my presentation wasn't accepted. I'm readying a release of Project Hijack 0.2 right now. I plan to release by end of this week. 64bit is mostly supported. 32bit is fully supported. Between now and Friday, I'll be cleaning up code. I'll be writing API documentation next week.
|
|||
After having a busy few weeks, Project Hijack is now 64bit compatible. Version 0.2 will ship with full 64bit compatibility. Next, I'll be working on an API to list all dynamically loaded functions and their corresponding address in memory. |
|||
I've been working on protection mechanisms to prevent Project Hijack from working. I can't detail what I've got in the works, but it involves a kernel patch and elfsh. One protection mechanism is completely done, tested, and working for 32bit linux. I'm researching a more advanced mechanism that won't rely on help from the kernel. At Defcon, I'll be releasing both Project Hijack and any protection mechanisms that are reliable.
|
|||
I've backed up and moved out the old hijack code. I've since replaced the SVN repo with a new project that integrates with libhijack. This new code is a basic, gdb-like UI. It'll mimick the old hijack UI. I'll need to complete the UI before moving back to the 64bit port. I need to be able to debug the hijacked process while it's being hijacked. I can't attach gdb while hijacking the process (linux kernel understandably only allows one process to trace a process at a given time) so I need to write a small debugging UI. The UI will be part of the Defcon release.
|
|||
I'll be giving a presentation on Project Hijack to my local OWASP chapter on 30 Apr 2009. I'm excited to talk about it and prepare for Defcon. I've got the slides mostly ready and I'll be packaging up a private release of Project Hijack for this presentation. The official 0.2 version will still be publicly released at Defcon.
|
|||
Project Hijack now has python bindings! You can now script hijacking a process. Let the mass pwnage begin. I'm pretty excited about being able to use python. I need to develop a simple UI for debugging a bug with the 64bit port and python will allow me to do that fast and easy. Providing python bindings also shows that the API is stable and functional (no guarantees made, though, until Defcon). I've been working these past few days on porting to 64bit. The underlying code works: finding a syscall entry point, allocating a new anonymous mapping, and injecting shellcode into the newly allocated memory. I'm having trouble _RUNNING_ the injected shellcode. Maybe I'm setting RIP wrong? Not sure. Support will be there eventually, hopefully before Defcon.
|
|||
I've been working on porting to 64bit. It's mostly done. I'm having trouble with one issue (I think it might be related to what was holding me up with the old 32bit code). It currently can allocate a new, anonymous memory mapping and inject shellcode into the new mapping. It cannot execute the injected shellcode at the moment. I'm researching why. I hope to have 64bit fully supported by Defcon.
|
|||
Libification of Project Hijack is now complete. I'm working now on cleaning up code and writing documentation. The API is stable and ready to use. Check out the sources here. I still plan on releasing version 0.2 at Defcon. Version 0.2 has no new features, but is much more efficient, stable, and faster.
|
|||
Currently, Project Hijack stands as a standalone program. I'm going to be working on converting the base set of functions into a shared library then writing a UI (console-based) on top of that. Doing it this way will allow for greater portability. After converting the project to a shared library, I will be working on porting to 64bit. Knowing me, it'll probably take five years to complete. ;) |
|||
