Automotive Night Vision (civilian version of FLIR?)

When you read this: http://en.wikipedia.org/wiki/Automotive_night_vision. Every single one of the implementation reads like a Forward Looking Infra-Red (FLIR: http://en.wikipedia.org/wiki/Forward_looking_infrared) to me. To be more precise, read this line from GM implementation of the automotive night vision: "This system was developed with Raytheon and worked by using an infrared sensing camera mounted behind the vehicle's grille".

Now, why would Raytheon is in there? if it's not for FLIR tech, then I'd be surprised. The question is: what kind of FLIR sensor is being used? I think it must've been the  long-wave infrared (LWIR) cameras because it doesn't need Cryogenic cooling which is almost impossible in the target vehicle, given the required size and energy requirement.

Another question is will this technology be adopted en-masse? Time will tell. But, to be sure this is a dual use tech.

Our Distorted View of The Ancient World

We, who live in 21st century tends to view the ancient past as less advanced civilization. The long held view of superiority of present technology compared to ancient times, for example ancient Egypt or ancient Greek is now challenged by the discovery of several remnants from the old times.
The Antikythera Mechanism (http://www.antikythera-mechanism.gr/) is one of them. The precision of this instrument is a silent proof of the ingenuity of our "ancient" predecessors. Perhaps we shouldn't call whoever invent the machine as "ancient" but rather as advanced predecessors.
Perhaps, reinvention is a feature of any advanced civilization, be it human or not. Maybe, very far in the future when a global catasthrope happens and then reinvention happens let's say to our present day radio technology, human living in that time would call us the ancient as well :-).

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).

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. 
• If the number of propositional variable is less than or equal to four, Karnaugh Maps (K-Map) is enough. See http://en.wikipedia.org/wiki/Karnaugh_map
• If the number of propositional variable is more than four but less than ten, then Quine-McCluskey algorithm ( http://en.wikipedia.org/wiki/Quine%E2%80%93McCluskey_algorithm ) is attractive because the processing time is "bearable" and could help finding the most simplified form precisely. Unfortunately, due to the exponential run-tim nature of the  Quine-McCluskey, any values above ten probably requires unpractical amount of time.
• If the number of propositional variable is equal-to or more than ten, then the most attractive option is the Espresso heuristic (http://en.wikipedia.org/wiki/Espresso_heuristic_logic_minimizer ).

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.