I just built Python wheels for the latest version of SQLAlchemy (1.05 at the time I wrote this). This should make it a whole lot easier to install on Windows since no compiling is required. They’re only available for the latest versions of Python (2.7.10 and 2.6.6) since it appears to be impossible to make multiple minor versions of Python coexist. I did manage to install both 32 and 64 bit versions though. On Cygwin, only Python 2.7.10 is available (I don’t think it’s possible to install Python 2.6 there, at least not using the package manager), but at least I could produce builds for 32 and 64 bits as well.

I skipped Python 2.5 entirely since pip doesn’t work there, so I assume it’s not meant to be possible. If you happen to know how to make Python wheels work on it, let me know!

I also skipped Python 3.x, but that’s just because I hate it. I don’t even know if SQLAlchemy works there and quite frankly I don’t care.

Enjoy!

Download

SQLAlchemy 1.0.5 for Python 2.6 (Windows 32 bits)

SQLAlchemy 1.0.5 for Python 2.6 (Windows 64 bits)

SQLAlchemy 1.0.5 for Python 2.7 (Windows 32 bits)

SQLAlchemy 1.0.5 for Python 2.7 (Windows 64 bits)

SQLAlchemy 1.0.5 for Python 2.7 (Cygwin 32 bits)

SQLAlchemy 1.0.5 for Python 2.7 (Cygwin 64 bits)

The WinAppDbg python module allows developers to quickly code instrumentation scripts in Python under a Windows environment.

It uses ctypes to wrap many Win32 API calls related to debugging, and provides an object-oriented abstraction layer to manipulate threads, libraries and processes, attach your script as a debugger, trace execution, hook API calls, handle events in your debugee and set breakpoints of different kinds (code, hardware and memory). Additionally it has no native code at all, making it easier to maintain or modify than other debuggers on Windows.

The intended audience are QA engineers and software security auditors wishing to test / fuzz Windows applications with quickly coded Python scripts. Several ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86/x64 native code, debugging multiple processes simultaneously and produce a detailed log of application crashes, useful for fuzzing and automated testing.

What’s new in this version?

In a nutshell…

• full 64-bit support (including function hooks!)
• added support for Windows Vista and above.
• database code migrated to SQLAlchemy, tested on:
  • MySQL
  • SQLite 3
  • Microsoft SQL Server

  should work on other servers too (let me know if it doesn’t!)

• added integration with more disassemblers:
  • BeaEngine: http://www.beaengine.org/
  • Capstone: http://capstone-engine.org/
  • Libdisassemble: http://www.immunitysec.com/resources-freesoftware.shtml
  • PyDasm: https://code.google.com/p/libdasm/
• added support for postmortem (just-in-time) debugging
• added support for deferred breakpoints
• now fully supports manipulating and debugging system services
• the interactive command-line debugger is now launchable from your scripts (thanks Zen One for the idea!)
• more UAC-friendly, only requests the privileges it needs before any action
• added functions to work with UAC and different privilege levels, so it’s now possible to run debugees with lower privileges than the debugger
• added memory search and registry search support
• added string extraction functionality
• added functions to work with DEP settings
• added a new event handler, EventSift, that can greatly simplify coding a debugger script to run multiple targets at the same time
• added new utility functions to work with colored console output
• several improvements to the Crash Logger tool
• integration with already open debugging sessions from other libraries is now possible
• improvements to the Process and GUI instrumentation functionality
• implemented more anti-antidebug tricks
• more tools and code examples, and improvements to the existing ones
• more Win32 API wrappers
• lots of miscellaneous improvements, more documentation and bugfixes as usual!

Where can I find WinAppDbg?

Project homepage:

• http://winappdbg.sourceforge.net/

Download links:

• Windows installer (32 bits)
• Windows installer (64 bits)
• Source code

Documentation:

Online

• Tutorial
• Reference

Windows Help

• Tutorial
• Reference

HTML format (offline)

• Tutorial
• Reference

PDF format (suitable for printing)

• Tutorial
• Reference

Acknowledgements

Acknowledgements go to Arthur Gerkis, Chris Dietrich, Felipe Manzano, Francisco Falcon, @Ivanlef0u, Jean Sigwald, John Hernandez, Jun Koi, Michael Hale Ligh, Nahuel Riva, Peter Van Eeckhoutte, Randall Walls, Thierry Franzetti, Thomas Caplin, and many others I’m probably forgetting, who helped find and fix bugs in the almost eternal beta of WinAppDbg 1.5!

Enjoy!

Edited 6-May-2013: updated Impacket to version 0.9.10
Edited 18-Feb-2014: updated Impacket to version 0.9.11

Download Impacket 0.9.11

impacket-0.9.11.win32.msi

impacket-0.9.11.win-amd64.msi

Download Pcapy 0.10.5

pcapy-0.10.5.win32-py2.5-winpcap4.1.2.msi

pcapy-0.10.5.win32-py2.6-winpcap4.1.2.exe

pcapy-0.10.5.win32-py2.7-winpcap4.1.2.exe

pcapy-0.10.5.win-amd64-py2.6-winpcap4.1.2.exe

pcapy-0.10.5.win-amd64-py2.7-winpcap4.1.2.exe

Download Pcapy 0.10.4

pcapy-0.10.4.win32-py2.5-winpcap4.1.2.msi

pcapy-0.10.4.win32-py2.6-winpcap4.1.2.exe

pcapy-0.10.4.win32-py2.7-winpcap4.1.2.exe

pcapy-0.10.4.win-amd64-py2.6-winpcap4.1.2.exe

pcapy-0.10.4.win-amd64-py2.7-winpcap4.1.2.exe

Download Pcapy 0.10.3

pcapy-0.10.3.win32-py2.5-winpcap4.1.2.msi

pcapy-0.10.3.win32-py2.6-winpcap4.1.2.exe

pcapy-0.10.3.win32-py2.7-winpcap4.1.2.exe

pcapy-0.10.3.win-amd64-py2.6-winpcap4.1.2.exe

pcapy-0.10.3.win-amd64-py2.7-winpcap4.1.2.exe

Download Pcapy 0.10.2

pcapy-0.10.2.win32-py2.5-winpcap4.1.2.msi

pcapy-0.10.2.win32-py2.6-winpcap4.1.2.exe

pcapy-0.10.2.win32-py2.7-winpcap4.1.2.exe

pcapy-0.10.2.win-amd64-py2.6-winpcap4.1.2.exe

pcapy-0.10.2.win-amd64-py2.7-winpcap4.1.2.exe

Anyway. After a conversation on Twitter about how it’s becoming increasingly harder to find the venerable WIN32.HLP file – and how it was becoming ever more outdated, I came to realize I didn’t know of any OllyDbg plugin to use the more modern and up to date MSDN documentation. I asked around and no one else seems to have written such a plugin, so I wrote my own.

It’s sort of a dirty hack – in general there’s no easy way of overriding existing features in Olly, the plugin API is rather meant to add new functionality. So after messing about with it for a while I came up with an easy hack – the plugin just hooks the WinHelp() API call to detect when WIN32.HLP is about to be opened, and launches the default web browser instead. Any other help file is launched normally.

The next step would be to search the MSDN looking for the API call the user requested. Then again, a quick hack came to the rescue since instead of figuring out how to perform MSDN searches it was much easier to just use a Google search with the “I Feel Lucky” button. You can find out more here about the unofficial Google Search API.

The plugin is also compatible with the newer Immunity Debugger which is based in OllyDbg, and was tested on both.

To install, just copy the DLL file in the plugins folder (by default is the same where the main EXE lives). You do need to have set the win32.hlp file in the configuration at some point (so Olly actually tries to open it, otherwise the plugin never finds out). It doesn’t need to be the real file though, any file named “win32.hlp” will do the trick, even if it’s 0 bytes long.

Enjoy!

Download

OllyMSDN.zip

I’ve packaged the BeaEngine Disassembler along with its Python bindings into a no-frills Windows installer. Certainly easier than manual install, and it really helps me when installing it on virtual machines.

Enjoy!

Update: Just added another disassembler package, Pymsasid.

Update: Added precompiled Windows binaries for PyDasm on Python 2.6 and 2.7.

Update: My installers were added to the Python Arsenal for RE.

Update: The Pymsasid package was updated with a small change, so the importation works just the same as loading the .py files from the current directory (it’s just an “import *” in __init__.py)

Update: Added a simple setup script for Libdisassemble 2.0. Since I had to put the sources inside a package the import statement in your scripts will have to be adjusted if using this version. With a simple try/except block you can make scripts compatible with both versions as well, if you need to.

Downloads

BeaEngine win32 installer: BeaEnginePython-3.1.0.win32.exe

BeaEngine win64 installer: BeaEnginePython-3.1.0.win-amd64.exe

BeaEngine source installer: BeaEnginePython-3.1.0.zip (run “python setup.py install”)

Libdisassemble 2.0 win32 installer: libdisassemble-2.0.win32.msi

Libdisassemble 2.0 win64 installer: libdisassemble-2.0.win-amd64.msi

Libdisassemble 2.0 source installer: libdisassemble-2.0.zip (run “python setup.py install”)

PyDasm precompiled binaries: PyDasm-1.5-precompiled.zip (run “python setup.py install”)

Pymsasid source installer: pymsasid-0.3.1.zip (run “python setup.py install”)

In case you missed it, Aníbal Sacco released a new tool called Heappie! to analyze heap sprays in multiple platforms. It uses PyGame and PythonCard for the GUI and Kenshoto’s VTrace as the backend. It’s really cool, check it out

Now, I never get tired of saying how great VTrace is. It’s written in Python, supports multiple platforms and quite comfortable to develop with. But alas, I tend to prefer my own debugger (call me biased if you wish!). So today I went ahead and added WinAppDbg support to Heappie!. When WinAppDbg is installed, it’s chosen automatically as the backend. If not found, it falls back to VTrace. That way we don’t lose support for other platforms, since WinAppDbg naturally only works on Windows.

This patch also adds support for 64 bit versions of Windows, in case you were thinking this was just an exercise in self indulgence. Well, it is that, but not just that. Ahem.

TL;DR

Just download the file above, go to Aníbal’s blog to learn how to use it, and exploit all the bugs!

Download

Heappie-WinAppDbg.zip

Java hash functions are implemented as a MessageDigest object, which you can’t instance directly but rather get an instance through the MessageDigest.getInstance() static method. It takes as it’s only argument a string with the name of the algorithm – but I couldn’t find an easy way to enumerate all available algorithms.

After a little googling I found this code example at Example Depot to do it programatically. Since results may vary from one installation of Java to the next, a command line tool would have been more useful to me, but I don’t know of any. (If you do, let me know!)

Anyway, I wrapped the code in a very simple Main function and compiled it using Eclipse. I called this little tool “ListServices” because I didn’t feel like thinking of a catchy name.

By default this tool lists all available cryptographic providers, but you can specify just the ones you need (in the example below, we type MessageDigest to get just the hashing algorithms):

        $ java -jar ListServices.jar
        KeyFactory:
                1.2.840.113549.1.3.1
                OID.1.2.840.113549.1.1
                1.2.840.113549.1.1
                OID.1.2.840.113549.1.3.1
                1.3.14.3.2.12
                DSA
                DiffieHellman
                RSA
                DH
                1.2.840.10040.4.1

        TransformService:
                INCLUSIVE_WITH_COMMENTS
                ENVELOPED
                (... output omitted for brevity ...)

        $ java -jar ListProviders.jar MessageDigest
        MessageDigest:
                SHA-256
                SHA-512
                SHA
                SHA-384
                SHA1
                MD5
                SHA-1
                MD2

        $

Enjoy!

Update: Added source code to Github.

Downloads

Executable JAR

Source code + Eclipse project

Most of you probably know it already, but just in case, here goes the explanation. You can connect two computers and simulate what would happen if you had two monitors instead: when the mouse leaves the screen in one computer, it “enters” the other computer on the opposite side of the screen. For example, if you have two laptops on your table and you move the mouse to the right, after reaching the border of the screen you see it coming out on the left side of the other computer.

The magic is done by using a remote desktop protocol like VNC, which lets you send keystrokes and mouse events, but discarding the framebuffer updates. That is, a program that connects to the remote desktop, but instead of showing you the remote screen, it monitors mouse movements locally and when the mouse reaches the screen limits, it captures the mouse and starts sending mouse events to the remote system. Similarly, when the mouse reaches the opposite limit on the remote system, it stops capturing the mouse so you can use it on the local system.

Since I use Linux my choice was x2vnc, the Linux cousin of the more famous Win2VNC, also by the same author. But unlike Win2VNC which is now actively maintained at SourceForge, x2vnc seems to have been abandoned.

x2vnc supports SSH tunneling, which is just perfect since VNC is a plaintext-only protocol and insecure by design. However there’s no easy way to tell x2vnc to which port to connect or which username to login as – it defaults always to the current local user and port 22.

I also had a problem with my other laptop, which had Windows 7. When the mouse cursor leaves the screen, it is “parked” to a corner of the screen so it doesn’t show (it’d be confusing to see two mouse cursors as you wouldn’t know which one is active). But the corner chosen by x2vnc is always the lower right corner, causing Windows 7 to hide all active windows… very annoying.

So I did what any other geek would do in my situation – branch it!

The patched code is now at Google Code Github. The new command line switches I added were:

-sshuser: Log in to the SSH tunnel using the given username.

-sshport: Connect to the given TCP port number instead of the SSH default (22).

-restingx and -restingy: Tell x2vnc where to park the mouse cursor. A value of 0 means left or top, a value of -1 means right or bottom. Then for example, -restingx 0 -restingy -1 means the top right corner of the screen.

Enjoy!

Download

Source code: https://github.com/MarioVilas/x2vnc/archive/master.zip

The WinAppDbg python module allows developers to quickly code instrumentation scripts in Python under a Windows environment.

It uses ctypes to wrap many Win32 API calls related to debugging, and provides an object-oriented abstraction layer to manipulate threads, libraries and processes, attach your script as a debugger, trace execution, hook API calls, handle events in your debugee and set breakpoints of different kinds (code, hardware and memory). Additionally it has no native code at all, making it easier to maintain or modify than other debuggers on Windows.

The intended audience are QA engineers and software security auditors wishing to test / fuzz Windows applications with quickly coded Python scripts. Several ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86 native code (using the open source diStorm project, see http://ragestorm.net/distorm/), debugging multiple processes simultaneously and produce a detailed log of application crashes, useful for fuzzing and automated testing.

What’s new in this version?

In a nutshell…

• fully supports Python 2.4 through 2.7
• fully supports Windows XP through Windows 7, 32 and 64 bit editions
• crash report tool now supports MSSQL (requires pyodbc)
• now supports downloading debugging symbols from Microsoft (thanks Neitsa!)
• new tool: sehtest.py (Windows SEH buffer overflow jump address bruteforcer, inspired by the same tool by Nicolas Economou)
• the tutorial is now available in chm and pdf formats
• now with only one MSI installer for all supported Python versions
• added support for diStorm 3 (falls back to the old version if not found)
• now using cerealizer instead of pickle whenever possible
• added new command to the command line debugger to show the exception handlers
• a few more anti-anti-debug tricks were added, still more to go!
• several improvements to the Window instrumentation classes
• more code examples
• more Win32 API wrappers
• lots of miscellaneous improvements, more documentation and bugfixes as usual!

Entire changelog for all versions (slow!):

• http://p.sf.net/winappdbg/changelog

Where can I find WinAppDbg?

Project homepage

• http://tinyurl.com/winappdbg

Windows installer (32 bits)

• winappdbg-1.4.win32.msi
• winappdbg-1.4.win32.exe

Windows installer (64 bits)

• winappdbg-1.4.win-amd64.msi
• winappdbg-1.4.win-amd64.exe

Source code

• winappdbg-1.4.zip
• winappdbg-1.4.tar.bz2

Online documentation

• Programming Guide
• Reference documentation

Offline documentation

• winappdbg-tutorial-1.4.chm
• winappdbg-tutorial-1.4.pdf
• winappdbg-reference-1.4.chm
• winappdbg-reference-1.4.pdf

Hi everyone. Today I’ll be showing you a quick script I wrote to make Google searches from Python. There are previous projects doing the same thing -actually, doing it better-, namely Googolplex by Sebastian Wain and xgoogle by Peteris Krumins, but unfortunately they’re no longer working. Maybe the lack of complexity of this script will keep it working a little longer…

The interface is extremely simple, the module exports only one function called search().

        # Get the first 20 hits for: "Breaking Code" WordPress blog
        from googlesearch import search
        for url in search('"Breaking Code" WordPress blog', stop=20):
            print(url)

You can control which one of the Google Search pages to use, which language to search in, how many results per page, which page to start searching from and when to stop, and how long to wait between queries – however the only mandatory argument is the query string, everything else has a default value.

        # Get the first 20 hits for "Mariposa botnet" in Google Spain
        from googlesearch import search
        for url in search('Mariposa botnet', tld='es', lang='es', stop=20):
            print(url)

A word of caution, though: if you wait too little between requests or make too many of them, Google may block your IP for a while. This is especially annoying when you’re behind a corporate proxy – I won’t be made responsible when your coworkers suddenly develop an urge to kill you!

EDIT (Jan 2017): Wow, this little code has expanded a lot since its creation. Now it’s an installable package and had contributions from many people. Thanks everyone!

Source code

Get the source code from GitHub: https://github.com/MarioVilas/googlesearch