Sunday, February 20, 2011

smali syntax highlighting for notepad++

update 10/8/2013:
thanks to Ádám Tóth for creating a dark themed version. i've linked to it next to the main version.

update: 11/10/2011:
thanks to Jho for pointing out how to get code folding to work. i updated the syntax file and made a few other tweaks. the link and picture have been updated and here are the instructions for installing (tested with v5.9.6.1):
View -> User-Defined Dialogue...


Click Import


Select smali_npp.xml
       no picture here, use imagination

There will be a message box that says "Import successful."
Any new files you open should have syntax highlighting.



several people have asked for smali highlighting for notepad++. thanks to furrelkt for having already sent me an example. here's what i've come up with: https://sites.google.com/site/lohanplus/files/smali_npp.xml
for dark backgrounds, try this:  https://sites.google.com/site/lohanplus/files/smali_npp_darkbg.xml


there are many limitations for notepad++'s user defined language. i could not get many tokens to highlight correctly, or as well as ultraedit or the highlighter used on this blog. perhaps a full lexer plugin could handle it. if you write one or make improvements to this xml, let me know.

Saturday, February 19, 2011

more smali syntax and running smali files

there are some examples of smali syntax written by the author of smali/baksmali JesusFreke here: http://code.google.com/p/smali/source/browse/trunk/examples/. most are rather technical, but still illuminating.

here's one that i modified slightly that shows a basic hello world app with a standard main method. also, in the comments you will see a way to quickly compile and run a smali file. this is sometimes quite useful in testing your code:
.class public LHelloWorld;

# Ye olde hello world application
# To assemble and run this on a phone or emulator:
#
# java -jar smali.jar -o classes.dex HelloWorld.smali
# zip HelloWorld.zip classes.dex
# adb push HelloWorld.zip /data/local
# adb shell dalvikvm -cp /data/local/HelloWorld.zip HelloWorld
#
# if you get out of memory type errors when running smali.jar
# give java more memory with -Xmx512m, like this:
# java -Xmx512m -jar smali.jar HelloWorld.smali

.super Ljava/lang/Object;

.method public static main([Ljava/lang/String;)V
    .registers 2

    sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;

    const-string v1, "hello,world!"

    # combine executing with adb shell commands and console output
    # and you have a very quick way to test code
    invoke-virtual {v0, v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V

    return-void
.end method

writing large amounts of smali

for the android reverser and more-so for one wishing to modify an apk, it is sometimes necessary to write large amounts of smali code. by large i mean over 10 lines, with a lot of control flow and api calls. keeping track of all those gotos, catches, switches, etc. is cumbersome unless you want to be some kind of smali wizard.

i wrote a class for antilvl to handle function hooks (really just replacements), and there is a lot of scary logic in there to have written manually. i've found it's best to create an android project in eclipse, write the code in java and decompile it into smali. the setup is easy. just download eclipse and install the ADT android plugin.

i recommend creating an android project just to prototype code. also, with the android plugin, when you run code it can either execute on your phone or start up an emulator. this has saved me tons of time while exploring various under-documented android api calls or digging around system settings or just trying to get a large bit of smali working.

writing code in java and then seeing it as smali will aid in understanding smali since you'll already be familiar with the functionality of the code. you can also automate the process of getting the smali file out by writing a shell script or batch file. here's an example batch file:
@ECHO OFF
SET CLASSES_PATH=%USERPROFILE%\workspace\ProjectName\bin\classes.dex
SET SMALI_OUT_PATH=\where\you\want\it
SET DUMP_DIR=out
SET SMALI_FILE=%DUMP_DIR%\Package\Name\Smali_File.smali
SET BAKSMALI_PATH=baksmali.jar
SET BAKSMALI_OPTS=--use-locals --sequential-labels

ECHO Decompiling ...
java -jar "%BAKSMALI_PATH%" "%CLASSES_PATH%" -output "%DUMP_DIR%"
ECHO Finishing up ...
COPY "%SMALI_FILE%" "%SMALI_OUT_PATH%"
RMDIR /s /q "%DUMP_DIR%"
PAUSE

Sunday, February 13, 2011

antilvl 1.1.3

just put up antilvl 1.1.3. a few small but annoying bugs fixed and some improvements with the hooks. pick it up from the usual spot: http://androidcracking.blogspot.com/p/antilvl_01.html

also had to do some major refactoring so people could make use of the source once it's released, and i think i got most of the kinks out.

while working on this, i noticed a few more apps that were using string encryption. maybe it will start to get popular? i wrote a proof of concept decryptor just to see how feasible it would be to convert dex to java .class files and run the apk's own methods to decrypt the strings. it worked but i want to make something more general. here's my idea:

  • start with an apk and disassemble
  • chose to decode literal strings (ex: const-string "some-encoded-string") or assume strings are the result of a function call (ex: invoke-static LStringHolder;->getString(v0)).
  • show all lines that match the above selection and allow for regex filtering. this way, if you pick literal strings and not all strings are encoded, you can filter for just the ones that are
  • decode strings by one of several methods: run the function, in the case of function-call encryption, built-in stuff like base 64, etc. or by using reflection on the classes of the apk. this way if every literal string in the apk is decoded through some function, i could use dex2jar to get the java class, dynamically load that and run each string through it.
the goal is to make the tool generic enough so that it's useful in the most situations. shouldn't be too hard. half of the work will be making my patching and apk libraries more generic and useful, so it wont be a total waste of time.

Monday, February 7, 2011

antilvl's source

several have asked for antilvl's source to use it in ways i could not have imagined. it seems it's true purpose is more of a general semi-automated apk patcher, which is fine. i'm thinking i should rename it and make it more general purpose, while still including the lvl-patching and anticracking-patching information.

i'm also getting a lot of fun out of this little shell extension for windows to get explorer to replace an apk's icon with the actual icon for the app inside: http://code.google.com/p/apkshellext/

Sunday, February 6, 2011

antilvl 1.1.2

antilvl 1.1.2 is finished. thanks for the bug reports from anonymous, sage and others. changes and download links are here: http://androidcracking.blogspot.com/p/antilvl_01.html

Friday, February 4, 2011

updated lesson 1

for lesson 2 i'm using html and javascript to make things more readable. to test the template i rewrote and updated lesson 1 of way of the android cracker to include stuff on threads, stack dumps and using jdb with android apps. it's also in html now and the code looks much prettier. i'll rewrite lesson 0 if i ever get around to it.