NetBeans/Smali Debugging is Broken (SmaliDebugging Page)
GoogleCodeExporter opened this issue · comments
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
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
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
> 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
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
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
> 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
> 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
> 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
[deleted comment]
[deleted comment]
[deleted comment]
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
> 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
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
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
[deleted comment]
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
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
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
Issue 452 has been merged into this issue.
Original comment by connor.tumbleson on 1 May 2013 at 11:56
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
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
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
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
[deleted comment]
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
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
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
Issue 655 has been merged into this issue.
Original comment by connor.tumbleson on 14 Jul 2014 at 2:13