Android smali question

Question

I'm currently doing some research on smali/"code obfuscator" and I'm trying to get familar with the decompiled source codes at the moment. For this I created a simple app and decompiled it by smali.

I'm trying to understand the decompiled source code now to improve and compare the security (against decompiling) after using a code obfuscator later. While most of the smali source code is not that difficult, I'm still having sometimes problems with the format conversion of figures.

May you explain to me e.g. the following line. I guess it should have a value of five, but I'm not sure, which kind of binary format this is. How to calculate it 0x4014 = 5 ???

const-wide/high16 v0, 0x4014       // 100000000010100        (5 = 101)

Attached are the full java and smali code sources of this test function :

Java source:

 boolean test(int a, double d) {
        if (a < 5 && d < 5)
            return true;
        else 
            return false;
    }

Smali source:

.method test(ID)Z
    .locals 2
    .parameter "a"
    .parameter "d"

    .prologue
    .line 28
    const/4 v0, 0x5

    if-ge p1, v0, :cond_0

    const-wide/high16 v0, 0x4014

    cmpg-double v0, p2, v0

    if-gez v0, :cond_0

    .line 29
    const/4 v0, 0x1

    .line 31
    :goto_0
    return v0

    :cond_0
    const/4 v0, 0x0

    goto :goto_0
.end method

Answer 1

Unfortunately, dalvik bytecode makes no distinction between integral types (short/integer/long/etc.), and floating point types (float/double). So baksmali can't know whether to show a constant like that as a floating point or integer, so it just defaults to integer.

This is further complicated by the existance of instructions like that one that you mentioned. From the dalvik-bytecode page from the dalvik documentation:

"Move the given literal value (right-zero-extended to 64 bits) into the specified register-pair.".

So that instruction will actually load the value 0x4014000000000000 into the v0 and v1 registers. This is a standard 64bit IEEE-754 floating point representation. The first (most significant) bit is the sign bit, the next 11 bits are the exponent (base 2), and the last 52 bits are the mantissa. In this case, we have a binary representation of

0100000000010100000000000000000000000000000000000000000000000000
SEEEEEEEEEEEMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

For the sign bit, 0 is positive and 1 is negative.

For the exponent, you take the integer value of the 11 bits (in this case, 1025), and subtract 1023, for an exponent of 2.

And for the mantissa, there is an implied "1" at the front, in the 2^0 place, with the following digits being the usual 2^-1, 2^-2, etc. So in this case, we have the binary number 1.01, or 1*2^0 + 1*2^-2, or 1.25.

The general form of the calculation used for the value is

-1^(2+S) * M * 2^E

Where S, M and E are the sign, mantissa and exponent.

In this case, we have -1^(2+0) * 1.25 * 2^2 = 1 * 1.25 * 4 = 5

If you don't want to do this calculation manually every time, there are various online calculators that can do it for you. http://babbage.cs.qc.edu/IEEE-754/64bit.html seems to be one of the better ones.

Answer 2

I'm doing this from memory, but as far as I remember, floating point numbers are generally stored like this:

100000000010100
smmmmmmmmmmmmee

s = sign, m = mantissa, e = exponent. So in your case, the sign must be 1 or positive, the mantissa is 5, and the exponent is zero:

+5 x 2^0 = 5

See the Wikipedia article on floating point for more information. Apparently your encoding uses 15 bits which is not a lot for a floating point number, especially with only 2 bits for the exponent, so it might be something else entirely. This is just my educated guess. You might try putting in other numbers and examining the decompiled code to learn more.

Answer 3

It's apparently the appropriate binary encoding of "5" as a double, for comparison against your second parameter of that floating-point type.