Tag:

assembler

Total:
Show all posts

Posts with the given tag:
  • "The tale of Syndicate Wars Port";
  • "Syndicate Wars Port - a reverse-engineering tale";
  • "GDT and LDT in Windows kernel vulnerability exploitation";
  • "DR6 may or may not be useful for bochs/VirtualPC detection";
  • "BSWAP + 66h prefix";
  • "Windows Win32k syscall table";
  • "Automagical function list in C++";
  • "LOOP vs. default Mac OS X assembler";
  • "Freedom for everything - total annihilation of process memory";
  • "Naked functions in gcc/g++";

  • All posts with the given tag are shown below.
    2010-01-27:

    The tale of Syndicate Wars Port

    hard:reverse engineering:re:assembler:games:gamedev:x86:asm:windows:linux:macosx:c:syndicate wars
    As promised, It's time to reveal the technical story behind the Syndicate Wars Port. The story is divided into two parts - the first, and the second attempt to port this game. Comments are welcomed!

    Read more...
    2010-01-26:

    Syndicate Wars Port - a reverse-engineering tale

    reverse engineering:re:assembler:games:gamedev:x86:asm:windows:linux:macosx:c:syndicate wars
    Syndicate Wars is a game published in 1996, created by Bullfrog. The game was written in C (Watcom) for the DOS4GW DOS extender. And of course it has stopped working natively (i.e. without emulators like DOSBox) when the modern operating systems, like GNU/Linux or Windows NT series, emerged. A few years ago my friend, Unavowed, told me about proposition of a project to create a port of Sydicate Word for modern OS'es like the two previous one I've mentioned. The port was to be done by decompiling the original executable file, locating all the functions from the standard C library, locating the DOS4GW and I/O (sound, keyboard, gfx, mouse, etc) dependencies, replacing them with modern native libc function call and libSDL/OpenAL libraries (sometimes using simple wrappers, other times by creating converters), and finally, recompiling it all to form native executables for the modern systems. Yesterday, we've (it was Unavowed who was the clear leader of this project) finished this project, and we've published executables, not only for GNU/Linux and Windows, but also for Mac OSX :)

    Read more...
    2010-01-17:

    GDT and LDT in Windows kernel vulnerability exploitation

    medium:x86:assembler:windows:win32:exploit:security
    A few weeks ago j00ru has visited me, and, as one can figure out, some more or less interesting ideas came to be. One of such ideas was to use the Call-Gate mechanism in kernel/driver exploit development on Windows, or, to be more precise, to use a write-what-where condition to convert a custom LDT entry into a Call-Gate (this can be done by modifying just one byte), and using the Call-Gate to elevate the code privilege from user-land to ring0. The idea was turned into some PoC exploits, and finally, into the paper presented below.

    Read more...
    2010-01-05:

    DR6 may or may not be useful for bochs/VirtualPC detection

    medium:x86:assembler:bochs:virtualpc
    This post will be similar to the previous one, and will be about small, but interesting, details of x86 architecture, that might be (and sometimes are) easily overlooked by creators of emulators and virtual machines. The hero of today's post is the DR6 debug register, or, to be more precise, the four least significant bits of this register - B0 to B3 (breakpoint condition detected flags). Please read the whole post before jumping into any conclusions :)

    Read more...
    2009-12-29:

    BSWAP + 66h prefix

    x86:assembler:bochs:qemu:medium
    In the last few days I've been playing with osdev again (last time I've coded something more than a boot menu (sorry, PL), was in 2003), so expect a few posts about assembler, x86 emulators and similar institutions. Today's post will be about the bswap reg16 instruction, running in protected mode - which, as one will find out, can be used, for example, to detect bochs or QEMU.

    Read more...
    2009-11-13:

    Windows Win32k syscall table

    easy:windows:re:assembler
    Just a quick info. j00ru has published on his blog a syscall number/name table for the Win32k syscall shadow table (user32.dll, gdi32.dll and DirectX use it) - http://j00ru.vexillium.org/win32k_syscalls/ (it's very similar to the Metasploit one, however the one on the Metasploit page contains only kernel syscalls, and this one contains only win32k syscalls). If you like digging in the low level stuff, this is definitely something worth checking out!

    Read more...
    2009-03-10:

    Automagical function list in C++

    c++:medium:assembler:windows:linux:macosx
    The story starts as usual. I've been writing a certain application, that generates some test files. The files were very similar in structure, so I took the common factor out, and created a function that creates the common base of the file, and then, made a few functions that make modification to this base, and then the file is written (file shared, only in GF 15200 GTX! ;>). Of course, every modification function that I made, I had to add to a list of function in another part of the source file. And I've added each 'shader' function I created to that list. After 38th function I've grew tired of this...

    Read more...
    2008-12-07:

    LOOP vs. default Mac OS X assembler

    assembler:macosx:easy
    The guys at Apple seem to like old tools. Last night we worked with Unavowed on some project (I'll write about it another time) - to be more accurate, we tried to to port the project to Mac OS X - and we've stumble on an obstacle. The obstacle told us it was called Apple Inc version cctools-698.1~1, GNU assembler version 1.38. And yes, that is the default assembler (as) used on the current Mac OS X, and I certainly hope that 1.38 is just a different version naming schema, since the current version (according to wiki) is 2.19, my MinGW says it uses 2.18.50, in the year 2000 version 2.11 was released, and in the current project changelog the oldest entry tells about version 1.93.01 - that would make 1.38 reaaaally old.

    Read more...
    2008-11-27:

    Freedom for everything - total annihilation of process memory

    c++:assembler:windows:winapi:medium
    Sitting in my hotel room at the Polish edition of PyCON, I started to think what would happen, if a normal Windows process wipes out (almost) all of it's memory. By "wipe out" I mean to free/unmap what is possible (VirtualFree and UnmapViewOfFile), and overwrite with zeroes the rest. I've started to experiment with this, wanting to know how will the system, and other applications, react to this uncommon process condition. Below I describe the creation of a test application (I've found a few interesting (imho) problems), and a funny thing OllyDbg does while attaching to such a process.

    Read more...
    2008-08-18:

    Naked functions in gcc/g++

    c:c++:assembler
    Recently I was creating in C++ (MinGW g++) a small library for runtime-patching. A need came to create an assembler-only functions, without any additions from the compiler - a "naked" function. However, even if compilers from Redmond support __declspec(naked) attribute for the x86 [Visual C++ Language Reference - naked (C++)], GNU compilers don't - they only support "naked" in ports for ARM, AVR, IP2K and SPU [Using the GNU Compiler Collection (For GCC version 4.3.0) - Function Attributes]. The problem had several possible solutions:

    Read more...