[ Sneak Preview ] Wifi eSpy

Wifi-eSpy is a tool for Windows (vista onwards at this point) to facilitate in the detection, planning and surveying of wifi networks. Whilst certainly not the only tool available, wifi eSpy is designed to incorporate aspects of other tools. Wifi-eSpy includes the ability to:

-Detect and list networks in chronological order, or as “active” stations.
-Communicate over USB with most garmin GPS devices.
-Present a user with a moving map, either street, satellite or hybrid views – courtesy of Google (internet connection required).
-Or allow the user to import a custom map (i.e. office interior map)
-Represent network coverage as image overlay on Map image (find dead zones in your coverage)
-Roughly triangulate, and estimate as to the location of detected access points (AP’s).
-Provide chronological log-file support (i.e. the ability to save a scan).
-Multiple, simultaneous wifi adapter support. (great for directional antennae).

My question to everyone out there is what additional features, if any, would you like to see on such an application?

Requirements:
Direct-x 9.0c or greater
Windows Vista or greater (XP will be supported later on)

Earlier development screenshot:

Later development screenshot:

[ 3D Game ] Project space shooter

A few weeks ago I began writing what will be a space-shooter game, perhaps. It will incorporate a rich 3d environment, an efficient particle system that handles everything from asteroid fields, through explosions to space-gas and clouds. I will continue to update it now and again in my free time. The game will be open-source once I’ve gotten a little further in it and fully developed the framework.

Written in straight C, utilizing the directx sdk.

[ C ] Reverse Shell

Allows a remote shell connection to be made. Pipes data between the spawned shell and the remote connection via winsock.
[ Code - C ]Reverse Shell Server

In the screenshot below you can see that I’ve got the Reverse-shell server running on my Windows 7 machine, internal address 10.0.0.2 on port 2221, which I connect to using a backtrack VM telnet session. On successful connection one is presented with the target machines command prompt:

The most obvious usage of course is during a hack, to take complete control of your victims PC.

Yet another tale of the EPROCESS and windows SYSCALLS offsets.

Firstly, I would like to say Hello to everyone after my hiatus. I will be updating my site again with new ideas and concepts. 

However, back to the point of this post. As many of my readers have become aware (and this is one of the topics that brings most the traffic to my blog) that the offsets and structures are no longer the same size and the offsets have been changed.

Included below is a list of both EPROCESS and syscalls offsets, just like the title says.

[ Link ] New EPROCESS offsets for windows 7
[ Link ] List of current windows syscalls

Lack of activity

Well its been quite a while now since I’ve last updated my blog, yet its just passed 42,600 hits! Anyway, my time is now predominantly taken up by a new activity, with minimal time spent behind a computer, and even less time spent programming. I’ve taken up flying.

[ General Problem ] EPROCESS-ImageFileName + NtOpenProcessHook

Ok well a few of my pieces of code here rely upon the ImageFileName element within the EPROCESS structure (which you can find in the ntifs_6001.h) header I’ve uploaded. Again, in 7600 it seems to be missing. Weird.
Anyway, the problem was that ImageFileName was returning nothing. Blank. So evidently the offset has changed. I wrote a peice of code to enumerate the base addresses of each EPROCESS structure and then looked at them in Win Dbg, have a look:

That image should pretty much give you an idea of what to do. Count the bytes. Find the new offset.
Previously the offset for ImageFileName was +0×154 now all of a sudden its +0×174. To implement search for this offset programmatically, search the memory from each EPROCESS base for the string “system”. As it will ALWAYS be there, makes for an easy way to determine the correct offset.

Original NtOpenProcess Screenshot

I have attached an updated version of my NtOpenProcessHook below with the fix.
The hack (this is too crude to be a fix!) lies in the RetrievePID() function. So have a look there for comparison.

A revised list of both sys calls and EPROCESS offsets are included below too.

[ Link ] My Old NtOpenProcessHook post
[ C - Source ] New NtOpenProcessHook Driver
[ C - Source ] Old NtOpenProcessHook Driver
[ C - Header ] ntifs_6001.h
[ Link ] New EPROCESS offsets for windows 7
[ Link ] List of current windows syscalls

[ C ] Entry Point Hook

This was an idea that I used in the Rootkit idea below, when I was thinking of ways of executing a hidden application at start-up and this is what I came up with:

[ .rar ] Project files
[ C - Source ] PEInfect

This works by finding null space within the program that is of sufficient size for our payload code.
It then copies the payload into this space, locates the PE structure, saves the entry point address and changes this address
to the base address of our code. A “jmp” instruction in our payload code is then placed at the end to return to the normal program entry point. Our payload simply contains crude (0×00) shellcode which calls WinExec() for us.
Any version specific API address’s, and WinExec() arguments are also inserted in the ModifyPayload() function.
As the victim file is mapped with write flags, changes made to victim files are permanent.

Unmodified program shown in PE Explorer.

Unmodified programs entry point shown in ollydbg

Our payload:

Modified program shown in PE Explorer:

Modified programs entry point shown in ollydbg: