Tuesday, April 10, 2012

Using Custom Function Calling Convention in IDA Pro

It's possible to "define" custom calling convention in IDA Pro disassembly database (at least in version 6.1). For example, the following function uses ax register and the stack to pass parameters.

assignI16toI64a proc near

 pDstI64= word ptr  4

 push    bp
 mov     bp, sp
 mov     bx, [bp+pDstI64]
 mov     [bx+I64.mWords.mWord0], ax ; <-- this is one of the parameter
 mov     [bx+I64.mWords.mWord1], 0
 mov     [bx+I64.mDwords.mDword1], 0
 mov     ax, bx
 leave
 retn    2
assignI16toI64a endp

How do we "inform" IDA Pro about the calling convention? Look at this hint from IDA Pro help.
IDA supports the user-defined calling convention. In this calling convention, the user can explicitly specify the locations of arguments and the return value. For example:

        int __usercall func<ebx>(int x, int y<esi>);
denotes a function with 2 arguments: the first argument is passed on the stack and the second argument is passed in the ESI register and the return value is stored in the EBX register.
Let's put this knowledge to the function above. Go to the "Set Function Type"  command (the default is "y" keyboard button). Set the function type as follows:

I64* __usercall assignI16toI64a<ax>(short Src<ax>, I64 *pDstI64)

Now, we have the custom function declaration. Let's see how the "auto commenting" works in the call to this function:

     push    ax                              ; pDstI64
     xor     ax, ax                          ; Src
     call    assignI16toI64a
As you can see, the function parameter "auto commenting" works as expected, marking the ax register as one of the parameter (as intended).

Friday, March 2, 2012

Simplifying Complex Expression in Reverse Code Engineering

Some parts of a software system that you reverse engineer may contain complex expressions. The first question is whether you need to simplify those complex expressions? In many cases, you need to, because the basic notion of reverse engineering is to understand what's going on, not to make it even slightly more complex. Now, the second question is: how to deal with  such complex expression?

There are several avenues to deal with the complexity. I found these steps to be useable:

  1. "Translate" the expressions into propositional variables. Just to make it more readable. For example: the (i < sizeof(MY_DATA)) expression could be "translated" as propositional variable A,  and so on.
  2. Once you have the propositions in place. You now have several options to minimize the present expressions. 
Anyway, I think that it's a very seldom case to encounter software code that uses closes to ten propositional variables in a single expression unless the programmer who wrote the code is a very unskilled or do so intentionally. 

Sunday, January 29, 2012

Opting Out Google Ad Tracking

If you've been following the new Google Privacy policy, you must have known about the Ad Tracking. That is, Google will "track" your browsing habits and present you with personalized result on various Google services that you use. If you think that you don't want to be tracked, you can opt-out. These are the steps:
  1. Go to Google Dashboard (https://www.google.com/dashboard/)
  2. Sign in to your account
  3. Go to Google Ads Preferences Manager (http://www.google.com/ads/preferences/?hl=en)
  4. Choose opt-out in the services you wished not to be tracked (or all of Google services that you use)
If you're using Google Chrome browser and want this setting to be applied permanently, you can use the Keep My Opt-Outs Chrome browser plugin.

Monday, January 16, 2012

How to Recognize The Documentation That You Wrote Has Gone Too Deply Nested?

One of the way to recognize that you have gone too far "nesting" your documentation section. For example, if you have gone to make section v.w.x.y, that means you're now four levels deep. Four levels are already too deep because human brain are not naturally able to remember something with "nesting-level" more than that.

When your nesting has gone too deep, consider creating a new "chapter" and provide a smooth transition into that new "chapter". That way, people will understand what your're trying to say. Monstrous "chapter" is not good or it's better to say that it's a bad writing habit.

Be aware of it next tome you write documentation