Another post from the past ( 2007, wow time passes so fast :S ), a proof of concept I made to demonstrate how to grab clipboard data of a host machine from within a VMWare guest machine exploiting a backdoored hardware port the vmware team used to … well, I have no clue :D
Just a post about a small software I wrote years ago, I don’t want it to be lost.
The concept itself was quite simple, you give to it any ELF executable as input and the software will search for space to inject a shellcode of its own, which will execute a custom command.
The resulting executable will continue to work as expected, but it will spawn the command wit an execl call.
Those of you following my blog from the beginning, know that I was actively involved in the router hacking scene, mostly during the period in which I wrote the very first implementations of both Telecom Alice ( and this ) and Fastweb routers WPA key calculators and unlockers after the great reversing job performed by another italian group.
Those scripts allowed anyone to unlock hidden services in their routers ( as for the Alice scripts ) and to compute default WPA keys having just basic informations such as mac addresses, etc, demonstrating how broken the end-user security policies were.
Despite the fact I received in the past more than one intimidatory email from representatives of those two companies, I’ve never wrote or talked about that … I was smarter enough to understand that this kind of legal bullshit is better to be ignored, unless you have done something truly illegal.
Recently I was talking with one of my colleagues about computer science and the skills of those who have just taken their degree in Italy. We both agreed that the kind of knowledge you get attending the college is indeed more theoretical than practical ( and trust me, “informatic engineering” courses in Italy colleges are way much more theoretical than CS in the United States ) and most of the times this results in a lot of people with their mouths full of “big words” they don’t really understand.
It’s a while I see compiled dSploit versions pop up on Google Play Store, most of the times the actual changes are just a matter of icons, other times are merely compiled versions of one of the nightly releases.
Altough I can not ( and really don’t want to ) avoid this, I’d like to write a few lines about this kind of conduct and the ethics behind open source software.
As most of my personal projects, dSploit was released from the beginning under the GPL 3 license, this means that you can modify it at your own will, distribute it for free or even as a paid software and share it with your friends.
You are only asked to make your changes available under the same license and make references to the original authors of the software itself. That’s it, this is so simple.
Beyond the fact I find deeply unfair not putting even the smallest link to the original repository or some credits on the description of those compiled distributions, there are a few things anyone who wants to make such thing should be aware of before blindly cloning the repository and compiling the source code.
Even though it’s one of the tools I use on a daily basis, Hex-Rays IDA always fascinates me for its completeness and the huge amount of informations it is able to extract using just a “simple” static analysis approach and being myself a “make yourself the tools you need” guy a couple of weeks ago I’ve started to study it, trying to understand its internal mechanisms, algorithms and tricks.
I’ve focused on the identification and isolation of subroutines inside an executable due to the fact that this seemed to me the simplest thing to start with and because I came accross this blog post that shows how great IDA python libraries are.
I’ve just published on github libpe, a C/C++ library to parse Windows portable executables ( both PE32 and PE32+ ) written with speed and stability in mind, released under the GPL 3 license.
Currently the library is released as a Microsoft Visual Studio solution containing the library itself and an example project, I will make it cross platform in future releases.
Everyone who’s familiar with operating systems theoretical structure, whether he attented a college course or he has just read a book on this subject, knows the concept of a system call i.e. how a user space application talks with the kernel asking it to perform various jobs such as opening a file, creating a memory mapped region, etc.
While studying Windows internals for my job, I had to deepen my knowledge of executable loading process, including their memory layout, address relocations and so on.
I came accross the PEB ( process environment block ), a data structure ( mostly undocumented ) that NT systems use internally to handle many aspects of a process, including a list of loaded libraries, environment variables, command line arguments, heap informations, TLS slots and so on.
The interesting fact about the PEB is that can be inspected to obtain those informations without the use of any standard API, thus resulting in an interesting technique to detect bad written virtual machines, emulators and any sort of sandboxing that could be used by a malware analyst or an anti virus product.
Moreover you could check the PEB to detect if a DLL has been injected into your process to perform api hooking.
API hooking softwares usually hooks API such as EnumProcessModules and patch them to hide the presence of the injected module. Inspecting the PEB you will be able to perform the same task only analyzing your address space, thus avoiding API patching.