example of android_arm_license_validation result not as expected about angr-doc HOT 11 CLOSED

By the way , I found it made no change even though I commented out or open the Android NDK library path, which is very strange:

load_options = {}
#load_options['custom_ld_path'] = ['/Users/Mac/Desktop/graduate/angr/android-ndk-r14b/platforms/android-19/arch-arm/usr/lib']
b = angr.Project("./validate", load_options = load_options)

from angr-doc.

I have solevd the android phone problem . It was because the validate program is 64-bitand arm not x86, when you run it at lower than Android 5.0 , the mobile system is 32-bit,it goes wrong.

adb shell /data/local/tmp/validate JQAE6ACMABNAAIIA
Entering base32_decode
Outlen = 10
Entering check_license
Product activation passed. Congratulations!

from angr-doc.

Interesting. So it does work on the correct version?

from angr-doc.

Hi guys,

validate is a 32bit ARM binary. I just ran it on a 32bit and 64bit device trying to reproduce the issue above but no issues for me. Output is:

hero2lte:/data/local/tmp $ ./validate JQAE6ACMABNAAIIA                                                                    
(...)
Product activation passed. Congratulations!
hero2lte:/data/local/tmp $ ./validate ABGAAWQAEEAAAAAA                                                                    
{...)
Incorrect serial.

As for the incorrect result string returned by Angr, could it be related to this here?

@Fermiz, what happens when you change the offset in solve.py as follows:

addr = found.state.memory.load(found.state.regs.r11 - 0x20, endness='Iend_LE')

Does this return the correct result?

from angr-doc.

@b-mueller Thank you very much for reply. It's a pity that after I changed it into r11 - 0x20 , it is still not work, the result after base64.b32encode is ABGAATYAAAAAAAAA and the detail before base64.b32encode is:

actual: [] expect: [L]
actual: [L] expect: []
actual: [] expect: [O]
actual: [O] expect: []
actual: [] expect: [L]
actual: [] expect: []
actual: [] expect: [Z]
actual: [] expect: []
actual: [] expect: [!]
actual: [] expect: []

When go back to addr = found.state.memory.load(found.state.regs.r11 - 0x24, endness='Iend_LE'), the result is ABGAAWQAEEAAAAAA and the detail is:

actual: [] expect: [L]
actual: [L] expect: []
actual: [] expect: [O]
actual: [Z] expect: []
actual: [] expect: [L]
actual: [!] expect: []
actual: [] expect: [Z]
actual: [] expect: []
actual: [] expect: [!]
actual: [] expect: []

it is quite weird that r11 - 0x20 has LO and r11 - 0x24 has LZ!, the correct result should be like LOLZ!.

from angr-doc.

@zardus Thank you for reply, it works in the phone when I use Android 5.0, arm which is 64-bit. But stills have problem to get the correct token from Angr codes.

from angr-doc.

Just tried this with 4.4 KitKat arm emulator and it indeed does not work (it does not except any valid serial).

When switched to 5.1 Lollipop arm emulator it does work. So something is different on 4.4 and I do not know what. But perhaps add a big warning that KitKat does not work.

from angr-doc.

The problem is in the base32_decode function, it behavies differently in KitKat then in Lollipop and I expect it to be encoding issues, but it could be totally something else.

Lollipop

root@generic:/data/local/tmp # ./validate JMDRIW2BBUUHEMQT
Entering base32_decode
Outlen = 10
Entering check_license
Product activation passed. Congratulations!

KitKat

root@generic:/data/local/tmp # ./validate JMDRIW2BBUUHEMQT
Entering base32_decode
Outlen = 2
Entering check_license
Incorrect serial.

Note the Outlen being set to 2 for KitKat!

from angr-doc.

@kevinvalk Thank you for help. By the way ,did you get the JMDRIW2BBUUHEMQT token from the demo codes? I could not get the correct token, what I got is ABGAAWQAEEAAAAAA

from angr-doc.

@Fermiz NP, There are many serials that will work. The serial JMDRIW2BBUUHEMQT is one of the 255^5 different possible serials (rough math, could be off).

The symbolic execution is indeed not working anymore as you have already explained. I just did it statically without symbolic execution.

from angr-doc.

For what it's worth, it looks like this has somehow been fixed in the last 7 months:

[+] ~/angr/angr-doc/examples/android_arm_license_validation% python solve.py
JQAE6ACMABNAAIIA

from angr-doc.