NetBeans/Smali Debugging is Broken (SmaliDebugging Page)

[GoogleCodeExporter]

My apologies Brut.all. This is probably a NetBeans or Smali issue.

According to http://code.google.com/p/android-apktool/wiki/SmaliDebugging, 
"Specific Instructions," Step 8: "8.Set breakpoint."

One cannot set a breakpoint under NetBeans 7.2 due to lack of MIME type for 
*.smali files. Additionally, attempting to associate MIME types such as java 
and text/x-java to *.smali resulted in NetBeans parse errors.

Perhaps you could expand your explanation to Step 8 since many folks seem to be 
having problems. I don't claim to have any expertise on APKTOOLS or Smali, and 
need help from folks who know more than me.

Related topics on the NetBeans/Smali/Breakpoint issue:
* NetBeans 7.2, Breakpoint, Smali, and "Java source file is expected," 
http://groups.google.com/group/apktool/browse_thread/thread/af2047776f629010
* "Java Debugging and Console Window (APKTOOL and JPDA Protocol)," 
http://forums.netbeans.org/viewtopic.php?t=50482
* "No MIME type for *.smali," 
http://code.google.com/p/smali/issues/detail?id=135

Original issue reported on code.google.com by noloa...@gmail.com on 3 Aug 2012 at 5:18

[GoogleCodeExporter]

I used Apk-tool 1.4.1 and NetBeans 6.8, it works for me:
http://d-kovalenko.blogspot.com/2012/08/debugging-smali-code-with-apk-tool-and.h
tml

Original comment by Dm.O.Kov...@gmail.com on 27 Aug 2012 at 6:49

[GoogleCodeExporter]

Hi Dima,

Can you describe (1) your environment (Linux, x64, Mac OS X Lion, etc), and (2) 
your device (make, model, Android version, including jail break status).

I have endured lots of pain and misery from Linux/Windows/Mac OS X and NetBeans 
while attempting to re-engineer a live app and my own "crack me." So I have got 
to be missing something obvious...

Jeff

Original comment by noloa...@gmail.com on 27 Aug 2012 at 7:02

[GoogleCodeExporter]

Hi Jeff,

(1) Windows 7 x64 with the latest JDK at the moment
(2) Ainol Aurora, a very cheap tablet from China :)

If you have any questions and/or need help with AplTool+NetBeans, I'll try to 
help you :) The topic in my blog: 
http://d-kovalenko.blogspot.com/2012/08/debugging-smali-code-with-apk-tool-and.h
tml, use comments for discussion. Or just mail to  dm.o.kovalenko[die, 
spammers, die!]gmail.com

Original comment by Dm.O.Kov...@gmail.com on 28 Aug 2012 at 2:43

[GoogleCodeExporter]

> use comments for discussion. Or just mail to
> dm.o.kovalenko[die, spammers, die!]gmail.com
Got it, thanks. :)

I see two items of interest: (1) deleting build/, and (2) directly running java 
(rather than APKTOOL). I'll report back with results when I have something 
useful to add.

For what its worth, I was able to sett a breakpoint in the Smali code with 
NB6.8, but it never triggered with a debugger attached. I think I want to try 
x86 (rather than x64) if your steps don't work out for me.

Original comment by noloa...@gmail.com on 28 Aug 2012 at 2:52

[GoogleCodeExporter]

Hmmm... can't find how to edit already posted comments here. Nohow?

Ok, anyway, update for Jeff in this new comment:

(2) Ainol Aurora with Android 4.0.3, rooted. Also, it works on my HTC Winldfire 
S with Android 2.3.5, not rotted

Original comment by Dm.O.Kov...@gmail.com on 28 Aug 2012 at 2:55

[GoogleCodeExporter]

> For what its worth, I was able to sett a breakpoint in the Smali code
> with NB6.8, but it never triggered with a debugger attached.

Well, it's a well-known problem :) You need to modify an entry point in you app 
to make it waiting for debugger.

Original comment by Dm.O.Kov...@gmail.com on 28 Aug 2012 at 2:56

[GoogleCodeExporter]

> Well, it's a well-known problem :) You need to modify
> an entry point in you app to make it waiting for debugger.
Not well known to everyone ;) How does one modify an entry point? Its not 
listed in the tutorials I have seen. Naively, I though we simply set a 
breakpoint.

So we are clear on terminology: how many entry points does an application have 
(I always thought one)? For a C program, there is usually a user supplied 
`main`; but the linker actually sets it to the runtime entry point (which 
eventually calls our `main`).

I'm beginning to think Dalvik is also broken. I can't get the debugger to snap, 
Dalvik does not honor assert's in debug builds, ... What else is broken?

Original comment by noloa...@gmail.com on 28 Aug 2012 at 3:50

[GoogleCodeExporter]

> Not well known to everyone ;) How does one modify an entry point?

The problem is we can't start debugging an application from the first Smali 
instructions. We connect the debugger to an already running app, so some code 
has already been executed. Even after the debugger is connected to the app, it 
does not stop executing of the app. To stop executing and start debugging, we 
should set a breakpoint. As soon as the breakpoint is hit, execution will be 
stopped and we will be able to start debugging. But how to guess the right 
place in the code to set the breakpoint? Some code has been already executed 
and never been executed again, so if we set the breakpoint ot this code, it 
will never be hit. Some code will be executed at the very end, e.g. on 
application quit; obviously, it's a bad idea to start debugging on the 
application quit :) So we need a trick to set the right breakpoint :)

There are some such tricks. To start debugging from the very beginning of your 
(or not your :)) Android application, I'd recommend the follow the instruction 
http://d-kovalenko.blogspot.com/2012/08/debugging-smali-code-with-apk-tool-and.h
tml, but after step 2. and before step 3. do some additional things:

(2.1) In out/AndroidManifest.xml, find the activity with
<intent-filter>
    <action android:name="android.intent.action.MAIN" />
    <category android:name="android.intent.category.LAUNCHER" />
</intent-filter>

(2.2) Find the *.smali file, which implements a class for this activity. The 
class is usually a descendant of Landroid/app/Activity; and have

.method public onCreate(Landroid/os/Bundle;)V

This is some kind of "entrypoint" because it executed immediately after 
activity constructor. Actually, application logic usually start in onCreate(...)

(2.3) At the very beginning of this method, insert the following code (it 
should be Smali code, but now I have no my magic text file with corresponding 
Smali code to copy-paste it, so I'll give you the code in the Java programming 
language):

while(debugFlag) { } // an infinite loop

and add a boolean debugFlag field to the class with the default value 'true'.

As result, after you start application, the infinite while-loop is started in 
onCreate(...). You attach the debugger to the process, set a breakpoint on the 
first instruction after the loop, and then use the debugger to change debugFlag 
to 'false'. Execution run out from the infinite loop (which is not infinite 
anymore :)), you breakpoint is hit, and you can start debug your app :)

> I'm beginning to think Dalvik is also broken.

No, it's just not designed for bytecode-level debugging. So we should use a 
couple of tricks to debug bytecode :)

Original comment by Dm.O.Kov...@gmail.com on 28 Aug 2012 at 6:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Dima,

No joy. This time I followed your instructions at 
http://d-kovalenko.blogspot.com/2012/08/debugging-smali-code-with-apk-tool-and.h
tml. I did not use "while(debugFlag) { }". I instrumented 
MainActivity::onCreate (smali file) to include:

    invoke-static {}, Landroid/os/Debug;->waitForDebugger()V

The program launches, and does not paint its initial screen until I attach a 
debugger. So far, so good.

I then try to set a breakpoint in a "Button Click" handler (the program has one 
button). I've tried breaking on lines with "invoke-static", "invoke-virtual", 
"new-instance", "new-array", compares, etc. I've also tried breaking on a line 
below the annotation ".line XXX". And I tried the stuff that is not supposed to 
work (".", ":"). Everything results in "Not able to submit breakpoint 
LineBreakpoint MainActivity.smali." For what its worth, I am trying to set the 
breakpoint in a smali file located in out/smali/com/example/crackme. The file 
is MainActivity.smali.

I'm working on Mac OS X Lion (x64). Apple Java 6 and Netbeans 6.8. HTC Evo 4G, 
fully patched (non-rooted, patched with HTC patches :). I also verified the 
"breakpoint problem" with two Asus Transformer tablets (Android 3.0 Honeycomb, 
and Android 4.0 Ice Cream Sandwich). A friend also tested on a Samsung 
(personal device, not sure what model) and a Nexus One. For us, that's 5 
devices for which the published procedures do *not* work as advertised.

I feel like I must have missed something very obvious, but I have no idea what 
it is. There are a few remaining items of interest (unless I missed something):
* Need a rooted device
* APK signed with Android Debug Key (not a "production" key)
* Package (com.example.XXX) does not match Signing Key CN
* Dalvik is broken
* Eclipse and NetBeans are broken

I think I should move on and try dex2jar - it appears APKTOOLS and the 
processes surrounding it are somewhat broken. At minimum, the documentation is 
quite lacking. Anyway, thanks for all your help. And congratulations on 
accomplishing the breakpoint.

Jeff

Not able to submit breakpoint LineBreakpoint MainActivity.smali : 249, reason: 
The breakpoint is set outside of any class.
Invalid LineBreakpoint MainActivity.smali : 249
Not able to submit breakpoint LineBreakpoint MainActivity.smali : 256, reason: 
The breakpoint is set outside of any class.
Invalid LineBreakpoint MainActivity.smali : 256
Not able to submit breakpoint LineBreakpoint MainActivity.smali : 257, reason: 
The breakpoint is set outside of any class.
Invalid LineBreakpoint MainActivity.smali : 257
...

Original comment by noloa...@gmail.com on 28 Aug 2012 at 10:20

[GoogleCodeExporter]

It was something dumb and obvious: "Enhancement: Problem with Line Numbers 
(Decompile/Debug Instrument/Recompile Cycle)," 
http://code.google.com/p/smali/issues/detail?id=139.

Original comment by noloa...@gmail.com on 29 Aug 2012 at 1:37

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> I did not use "while(debugFlag) { }". I instrumented
> MainActivity::onCreate (smali file) to include:
> invoke-static {}, Landroid/os/Debug;->waitForDebugger()V

Up to you :) Sometimes it does not work for me, so I prefer to use the infinite 
while-loop. It always works.

Original comment by Dm.O.Kov...@gmail.com on 29 Aug 2012 at 7:29

[GoogleCodeExporter]

On the discussion above, about breakpoints. Here just a short summary

http://d-kovalenko.blogspot.com/2012/08/breakpoints-in-smali-code.html

I hope it will be useful for Smali/Apk-tool community.

Original comment by Dm.O.Kov...@gmail.com on 30 Aug 2012 at 2:09

[GoogleCodeExporter]

Hi Dima,

Our of curiosity, what is the output of `apktool version` (there's not really a 
version switch, but the error prints the version).

Here's mine:

C:\Users\jwalton\apktool-crackme>apktool version
Apktool v1.4.3 - a tool for reengineering Android apk files
Copyright 2010 Ryszard Wi?niewski <brut.alll@gmail.com>
Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0)

Usage: apktool [-q|--quiet OR -v|--verbose] COMMAND [...]
...

Jeff

Original comment by noloa...@gmail.com on 31 Aug 2012 at 4:57

[GoogleCodeExporter]

Here is mine:

d:\Dropbox\reverse\~tools\apktool1.4.1>java -jar apktool.jar version
Apktool v1.4.1 - a tool for reengineering Android apk files
Copyright 2010 Ryszard Wi?niewski <brut.alll@gmail.com>
Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0)
...

Jeff, if apktool still does not work for your, we can chat somehow, and I can 
try to help you with this. We can do the whole process together, step by step. 
I'm sure we will find the reason why it does not work for you :)

Original comment by Dm.O.Kov...@gmail.com on 31 Aug 2012 at 6:46

[GoogleCodeExporter]

I just tried 1.4.1 - No joy. Line numbers are (were?) still broken. Though I 
did not try it, I suspect NetBeans will not be able to submit the breakpoint.

In the copy/paste below, both the class constructor (clinit) and instance 
constructor (init) claim to have ".line 18". Additionally, ".line 18" is at 
source code lines 30 and 59.

Jeff

# direct methods
.method static constructor <clinit>()V
    .locals 1

    .prologue
    .line 18
    const-class v0, Lcom/example/crackme/FetchSecretTask;

    #v0=(Reference);
    invoke-virtual {v0}, Ljava/lang/Class;->desiredAssertionStatus()Z

    move-result v0

    #v0=(Boolean);
    if-nez v0, :cond_0

    const/4 v0, 0x1

    :goto_0
    sput-boolean v0, Lcom/example/crackme/FetchSecretTask;->$assertionsDisabled:Z

    return-void

    :cond_0
    const/4 v0, 0x0

    #v0=(Null);
    goto :goto_0
.end method

.method public constructor <init>()V
    .locals 0

    .prologue
    .line 18
    invoke-direct {p0}, Landroid/os/AsyncTask;-><init>()V

    #p0=(Reference);
    return-void
.end method

Original comment by noloa...@gmail.com on 31 Aug 2012 at 9:55

[GoogleCodeExporter]

After some talks with JesusFreke, we will aim to hopefully get this solved.

Original comment by connor.tumbleson on 16 Nov 2012 at 3:46

• Changed state: Accepted

[GoogleCodeExporter]

It'd actually be great to have support for -d back, it worked like a charm and 
it is really useful to be able to debug step by step over smali code. I'm not 
aware of any other software or technique to debug smali-code in an IDE-like 
environment, the closest thing would be AndBug. Seriously, I was one of the 
early users of this feature and got really disappointed yesterday when I found 
out that it doesn't work anymore, I actually spent some time till I figured out 
support had been discontinued, if you don't plan to support it, you could at 
least get rid of the -d switches and place a note in the SmaliDebugging wiki 
entry to clarify.

Thanks and congrats for having contributed this tool to the community, I use it 
nearly every day and I have to say the work you've done is amazing :)

Cheers,

M

Original comment by mball...@gmail.com on 29 Nov 2012 at 10:48

[GoogleCodeExporter]

We have lost the ability to print out register information. I hope this doesn't 
affect the functionality. Its just we had to make a decision

1) Force users when using -d to have the full class path available so that 
registers could be resolved correctly.

2) Just ignore registers (which doesn't require classpath).

In apktool v1.4.1, it was easy to just treat Unresolved classes extending 
java.lang.Object, which could correctly identify the branches in register v0, 
even if we didn't know its type. The problem though now, is that doesn't seem 
to be the case anymore. Using that same method in today's APKs result in 80% of 
the APK becoming unresolved, which are the errors you experience in Apktool 
v1.4.4-1.5.2.

In the current snapshot of v1.5.3, debug mode works but I cannot get 
breakpoints submitted. I believe the line numbers aren't mudged anymore, but 
I'm going to first make an extension to our smaliDecoder to write every line 
like `i++; // smali code`, thus it can be triggered as breakpoint. pxb1988 
originally had that idea way back in Nov of 2011. So gonna finally implement it.

I'm testing using Ubuntu & Netbeans 7.3. 

Original comment by connor.tumbleson on 16 Feb 2013 at 2:14

• Changed state: Started

[GoogleCodeExporter]

Issue 452 has been merged into this issue.

Original comment by connor.tumbleson on 1 May 2013 at 11:56

[GoogleCodeExporter]

This is fixed for Apktool 2.0. Though we may be approaching a different method 
when dexlib2 comes, time will tell. Wiki's will be updated as a beta approaches.

All credit goes to brut.alll for bringing this amazing feature back. 

Original comment by connor.tumbleson on 4 May 2013 at 12:35

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Apk-tool 1.4.1 and NetBeans 6.8 works for me... you definitely should try it.

Cheers
B. Oskarsson
http://www.binaraoptioner.biz/

Original comment by Borosk...@gmail.com on 1 Nov 2013 at 12:50

[GoogleCodeExporter]

I'd rather get help fixing the newest SmaliDebugging using dexlib2 and Apktool2 
isn't of bringing up 2 year old apktool versions.

The current bug is simply line numbers are mudged: 
https://code.google.com/p/android-apktool/issues/detail?id=530

Original comment by connor.tumbleson on 1 Nov 2013 at 12:53

[GoogleCodeExporter]

I agree with B. Oskarsson... Apk-tool 1.4.1 in combination with NetBeans 6.8 or 
even 6.7 works great!

Regards
Olivier Braine
http://www.optionbinairebiz.com/

Original comment by Olivbr...@gmail.com on 5 Nov 2013 at 10:09

[GoogleCodeExporter]

Issue 655 has been merged into this issue.

Original comment by connor.tumbleson on 14 Jul 2014 at 2:13