Extending the IDA Script Language A First Stab	Our tools
27 January 1997	by Quine
	Courtesy of Fravia's page of reverse engineering
	This present essay by Quine is -once more- the kind of work anyone is expecting from us: ameliorating and exstending the functionalities of our targets... just reversing protected proggies is getting dull, if we don't add anything. Life is development, and development is progress (based on history and sound knowledge of the past... else it would be frills instead of progress :-) and progress is building for free on each others shoulders, out of the commercial dead ends where "they" want to push us. You'll find here an ADDITION to the already incredible IDA disassembler (and if you are still just cracking with wdasm -believe me- you don't know what you are loosing) addition that will work immediatly if you have IDA's 'Quined' version, will require some fumbling if you -instead- have stolen the full regged one from the Web. Which suites us, since we want you to reverse engineer targets, not to steal them... man, it should be obvious! So, let's hope you 1)have cracked ('quined') IDA demo 2) Have used it and got a little 'feeling' 3) Know how its 'internal' language works, at least a little. Else leave this stuff and go play elsewhere. Hope Pierre and his Russian Genius notice that we don't only take, we give too... Pierre, if you commercialize this, the minimum you can do is send a copy of your new IDA to Quine :-)	Also in: Advanced Crippled Related: Programmers
	There is a crack, a crack in everything That's how the light gets in
Rating	( )Beginner ( )Intermediate (x)Advanced ( )Expert	NO beginners

Well, quite a long time ago I promised that I would write some extensions to IDA. Well, here's the first. mammon, who, by the way, knows a lot about IDA and has some great info on his web page, mentioned to me that he was looking for a way to display bitmap resources and the like from within IDA. This was in connection with his resource parser (written in IDC) for IDA. This, in turn, reminded me of an IDC extension I had wanted to do. The goal, then, is to add a command to IDC which lets you run another program. This would solve mammon's problem because IDC gives you the resources to create a bitmap file out of the resource data, but no way to run a viewer app. I want to add a command of the following form:

This will simply execute the command line as a separate process. Since it's not possible as far as I know to implement this as a straightforward IDC function, we're going to have to hack ida.wll. I am in this essay assuming that you have the demo version with the load and file size cracks I have outlined previously on this site. Cracking the full version would just be a matter of recomputing some offsets. I'll leave that as an exercise to those who have the full version. Ok, here goes.

Please see my first two IDA essays:
quine1.htm
quine_21.htm

If you look at address 48BDF4 in ida.wll you'll see an array of structures that starts out like this:

dd offset aSegbyname

dd offset sub_40E914

dd offset unk_48CBD8

Let's have a look in the IDA SDK and see if we can find the declaration for this structure (even though it's pretty easy to figure out). You'll find it in expr.h:

typedef struct {		/* Element of functions table */

  const char near *name;	/* Name of function */

  error_t (*fp)(value_t *argv,value_t *res); /* Pointer to the Function */

  const char near *args;	/* Type of arguments. Terminated with 0 */

				/* VT_WILD means a function with arbitrary

				   number of arguments. Actual number of

				   arguments will be passed in res->num */

} extfun_t;

Now we need to find out what value_t is:

typedef struct {	/* Result of expression */

  char vtype;		/* Type			*/

#define  VT_STR		1

#define  VT_LONG	2

#define  VT_FLOAT	3

#define  VT_WILD	4	// used only in function arg type declarations

  union {

    char *str;		/* T_str  	*/

    long num;		/* T_long 	*/

    ushort e[6];	/* T_flt	*/

  };

} value_t;

Ok, so the structure specifies first, a pointer to the IDC command name, second, a pointer to the function that implements the command, and third, a pointer to information about how many what type of arguments the command takes. What we want to do is hijack one of the IDC commands and use it for own purposes. However, doing so would seem to be a problem because any other IDC script that uses the command we hijack will not work. I at first thought that I would just take one that wasn't used that often, but then I had a better idea. We just need to pass Exec one argument, the command line, but what if we take over a command that takes two arguments? For example,

success MakeName        (long ea,char name);

Now, an ea (Effective Address) that will pretty much never be passed to this function is FFFFFFFE (FFFFFFFF probably will be passed by buggy scripts because it is the value of BADADDR). So, for Exec, we'll take over MakeName and pass it FFFFFFFE as the first argument and the command line as the second. To do so, we'll re-route the function pointer in the array of extfun_t's to point to a function we'll add to the end of the code section. Our new function will first check to see if FFFFFFFE is passed as the first argument and if it isn't it'll immediately jump to the real MakeName function. So, now all we have to do is write our new function.

To run another process, the Win32 API provides the CreateProcess function. It takes 9 arguments, two of which are pointers to structures for which the caller has to allocate the memory. This is annoying because it means there's more we have to deal with. I thought about using the Borland run-time library function system, which takes only a command line. Unfortunately, system doesn't return until the new process terminates, so IDA is left hanging while our viewer or whatever is up. Further, when it does return, IDA won't recognize the mouse anymore. Fuck that. CreateProcess it is. I trust that everyone has got some sort of Win32 API reference (you can find them everywhere), so I won't go over CreateProcess, STARTUPINFO, or PROCESS_INFORMATION (these are the two structures we're going to have to create) in detail.

Alright, let's first work out how to get the parameters that are passed to the IDC function. Remember, according to the function definition in extfun_t, each idc function takes two pointers to value_t structures. The first pointer is actually a pointer to an array of value_t structures which has as many elements as there are arguments for the particular command. The second pointer is a pointer to a single value_t struct which will contain the result of the IDC command. Take a look at the real MakeName function.

idc_MakeName    proc near

                push    ebx

                mov     ebx, eax ; eax points to arg. value_t array

                push    esi

                mov     esi, edx ; edx points to result value_t

                mov     edx, [ebx+0Eh] ; the second argument

                mov     eax, [ebx+1] ; the first argument

                call    @set_name$qqrulpxc ; set_name(ulong,char *)

                mov     [esi+1], eax ; the result

                xor     eax, eax

                pop     esi

                pop     ebx

                retn

idc_MakeName    endp

This should be fairly straightforward. The only quirky thing is that every function (just about) in ida.wll uses the fastcall convention (see my first IDA essay) so the first three arguments always come in through registers rather than through the stack. One other thing I should mention is that the length of a value_t object is 13d bytes. One byte for the first member, and then 12d bytes for the union. A union is always as long as its longest member, which in this case is the 6 element array of words used for floating point arguments. That's why the second IDC argument is at offset 0Eh. Ok, the last thing to worry about is the call to CreateProcess. Most of the arguments to it can just be null because we don't want it to do anything fancy. All we're going to do is pass it the command line and two creation flags, CREATE_NEW_PROCESS_GROUP and CREATE_NEW_CONSOLE. The second flag will enable us to run separate console apps. However, we've got to allocate 10h byte for the PROCESS_INFORMATION structure and 44h bytes for the STARTUPINFO struct. This will be done on the stack which is infinitely easier than allocating from the free store. Furthermore, we'll zero out both of them with a call to memset and then all we need to fill in is the length of STARTUPINFO in the first dword of STARTUPINFO. The rest of the members can safely be left at zero. So, here's our code:

; is it a call to Exec or MakeName?

cmp [eax+1], 0fffffffeh ; 81 7c 20 01 fe ff ff ff

je exec                 ; 74 05

jmp MakeName            ; e9 d3 60 f8 ff

exec:

; set up stack and reserve 54h bytes for our structs

push ebp                ; 55

mov ebp, esp            ; 8b ec

sub esp, 54h            ; 81 c4 ac ff ff ff

; save esi and ebx

push esi                ; 56

push ebx                ; 53

; ebx = *res

mov ebx, edx            ; 89 d3

; esi = *CommandLine

mov esi, [eax+0eh]      ; 8b 70 0e

; zero out the structs

push 54h                ; 6a 54

push 0                  ; 6a 00

lea eax, [ebp-54h]      ; 8d 85 ac ff ff ff

push eax                ; 50

call _memset            ; e8 73 34 fa ff

; clean stack after memset

add esp, 0ch            ; 83 c4 0c

; move size of STARTUPINFO into struct

mov [ebp-44h], 44h      ; c7 85 bc ff ff ff 44 00 00 00

; this is where we start pushing the args to CreateProcess

; ptr to PROCESS_INFORMATION

lea eax, [ebp-54h]      ; 8d 85 ac ff ff ff

push eax                ; 50

; ptr to STARTUPINFO

add eax, 10h            ; 83 c0 10

push eax                ; 50

; unused

push 0                  ; 6a 00

push 0                  ; 6a 00

; our creation flags

push 210h               ; 68 10 02 00 00

; unused

push 0                  ; 6a 00

push 0                  ; 6a 00

push 0                  ; 6a 00

; ptr to CommandLine

push esi                ; 56

; unused

push 0                  ; 6a 00

call j_CreateProcess    ; e8 11 fe ff ff

; stick the return value into res.num

mov [ebx+1], eax        ; 89 43 01

; eax = 0 means function was successful

xor eax, eax            ; 33 c0

; clean up stack and that's it

pop ebx                 ; 5b

pop esi                 ; 5e

mov esp, ebp            ; 8b e5

pop ebp                 ; 5d

ret                     ; c3

The relative references are set up assuming that the code starts at VA 488886h, which is file offset 87E86h, which is right after the code I inserted for the load crack. If you want to put it somewhere else or you want to patch the full version, make sure to correct the one relative jump to MakeName and the calls to memset and CreateProcess.

The last thing to do is to patch the extfun_t array. The pointer to the real MakeName function is at 48BE1C, so put 00488886 into that location (in big endian order, of course).

Now, typing MakeName (0xfffffffe, "notepad.exe") each time we want to use Exec in a script is annoying and makes the code less readable. So, let's use a preprocessor define to fix it up:

#define Exec(x) MakeName(0xfffffffe, x)

Put this into idc.idc somewhere and you can use Exec as I originally wanted:

Exec("notepad.exe");

So, let's test it. Create the following IDC script and run it:

#include <idc.idc>

#define Exec(x) MakeName(0xfffffffe, x)



static main () {

Exec("notepad.exe");

}

Look! There's the Notepad. It works. That's it.

One more thing. You can pass whatever you want on the command line, but remember to escape special characters (quotes, backslashes, etc.) with a backslash.

Our tools homepage links anonymity +ORC students' essays academy database
tools Javascript wars cocktails antismut CGI-scripts search_forms mail_fravia+
Is reverse engineering legal?