
                                           R D B G v0.1b
                                           - - - - - - -

History/Features
====================
  Tuesday, March 11, 2003  -   Release 0.1b
                               This release has only been tested w/ exe files.
                               Server successfully ran under WinME, NT4, W2K, XP; Client was only tested on W2k.

Intro
========
  When I first received IDA win32 debugger, I commented:
  "hmm, the debugger is nice...I sure wish you implement remote debugging because I hate to debug viruses on my local machine..."
  I kept the idea in mind for a while....then one sunday I started to code.
  I have no idea how existing remote debuggers work, so the current solution is an implementation of my own ideas and experience.
  The only approach that came to mind is Simple API transporting.
  I started the project not knowing whether it will yield success or failure...
  I had to learn a lot in order to make this possible: winsock, extensive win32 debug api research, misc...
  Hope you enjoy using it.
          //lallous <lallousx86_at_yahoo.com>

How it works
===============
  rdbg.plw (debug client) is an IDA plugin; Being in IDA's debugger process (win32_user.plw) memory, 
  it can easily patch its import table and
  replace its imported functions especially the ones related to debugging.

  Having located and replaced the imports, I had to make a remote version of every function I hooked...

  Here's the API transport flow:

  Client side: IDA Dbg->rdbg.plw->[cache engine|network->server]
  Server side: Server->network->rdbg.plw->IDA Dbg

How to use it
===============
  Client configuration:
  -----------------------
     1)open a database
     2)Debugger/Process Options
     3)Set the application=InputFile=Remote program path=Local file path
     4)connect to client
     5)enable remoting
     6)hit F9 and enjoy!

     A simpler sequence: alt+1, alt+3 then F9 !

  From the client side you need only the input file to be in the same path structure as in the remote location.
  No need to have the program installed on both ends! The server must have the full program installed, but the client only the EXE file.

  Example:
    if you want to remotely debug c:\temp\notepad.exe, you must also have in the client c:\temp\notepad.exe ...
    if you want to remotely debug MS Word for example...simply copy winword.exe to your client machine (where IDA reside) into same path structure as it exists on the server. example: c:\program files\office\winword.exe

  Notes:
    * You do not need to have same OS on both machines, although it is more preferable
    * OS can be installed on different drives, say client has w2k @ c:\winnt and server has winNT4 @ d:\winnt4
    * On the client side you do not need the DLL or other dependencies...again only the .exe file

  Server configuration:
  ------------------------
    Simply run the server by specifying the *IP address* and the port number (the default port is 1001).
    If you use localhost address, then only client at localhost can connect to you...

The distribution
==================
server-dbg.exe      Debug version of the debug server, you need run logwindow.exe
                    on the same machine if you want to see debug messages.
                    It will be a little bit slower though.

server-rel.exe      This is the release version of the debug server. It is faster
                    and does not output debug messages, but only displays connection info.

Logwindow.exe       A simple program that receives messages and dumps them into its text
                    box. You can enable or disable messages reception w/o closing LogWindow.
                    Look at Settings/Enabled.

rdbg.*              This is the remote debug client plugin. Place it in path_to_ida\plugin\
plugins.cfg         A sample configuration of plugins.cfg

plugins.cfg
--------------
I will briefly explain each verb I put inside the plugins.cfg file

;
;      command name     plugin           hotkey          argument
;
       start_client     rdbg.plw         Alt-1           1
       end_client       rdbg.plw         Alt-2           2
       enable_client    rdbg.plw         Alt-3           3
       disable_client   rdbg.plw         Alt-4           4
       restart_server   rdbg.plw         Alt-5           5
       clear_cache_data rdbg.plw         Alt-6           6

You may map the shortcut keys as you like, but *do* keep the argument.

rdbg.ini
-----------
contains the following:
  [connection]
  server=192.168.0.100
  port=1001


start_client:
---------------
You press it to connect to the debug server.

end_client:
-------------
Disconnects from debug server.

enable_client:
-----------------
makes IDA's debugger a remote debugger.
Do not use this feature if you're not connected.
I haven't added checks if connected or not before proceeding...

disable_client:
----------------
makes IDA's debugger a local debugger. (original behaviour)

restart_server:
----------------
exits and re-spawns the debug server. After this command the client/server connection is lost.
It is better to start_client again!
Restart server is also useful to allow the OS to close all unclosed handles and clean memory leaks if any...

clear_cache_data:
------------------
The remote debug client by default intelligently cache some requests instead of re-sending them over the network.
This is to speed up the remote debugging process and to make it more convenient.
Use this command to clear all cached data and allow debugger client to fetch data from server again.


FAQ
======
 Q: Can I remote debug two processes same time by launching two IDA instances and connect to the same server?
 A: My current server code design easily allow me to make the server multithreading which will enable it
    to server multiple clients at the same time.
    But...I didn't implement that yet.
    You can still debug two processes use two different servers running on two different ports...

 Q: Any precautions when using the server?
 A: Yes!!! Do not be connected to the internet! The protocol can be easily exploited and then used by hackers to build
    requests and launch remote processes on your machine.

 Q: are dlls supported?
 A: probably yes, probably no..didn't test them yet