{"id":786,"date":"2013-11-29T00:10:10","date_gmt":"2013-11-28T23:10:10","guid":{"rendered":"http:\/\/blog.rewolf.pl\/blog\/?p=786"},"modified":"2015-05-12T07:08:17","modified_gmt":"2015-05-12T05:08:17","slug":"java-bytecode-debugging","status":"publish","type":"post","link":"http:\/\/blog.rewolf.pl\/blog\/?p=786","title":{"rendered":"Java bytecode debugging"},"content":{"rendered":"<p style=\"text-align: justify;\">Java bytecode debugging was <i>bugging<\/i> me for quite some time, however I&#8217;ve never done anything to really solve this problem once and for all. Around February I was desperately trying to solve some java bytecode riddle (yup, it was crackme ;p, but shhh&#8230;) and the only straightforward solution that would help with analysis was java bytecode debugger. If you query google for <i>java bytecode debugger<\/i> or <i>java bytecode debugging<\/i>, it will show two promising entries:<br \/><!--more--><\/p>\n<ul>\n<li>\n<p style=\"text-align: justify;\"><strong>Java ByteCode Debugger<\/strong> (<strong>JBCD<\/strong>) &#8211; <a href=\"http:\/\/sourceforge.net\/projects\/jbcd\/\" title=\"http:\/\/sourceforge.net\/projects\/jbcd\/\" target=\"_blank\">http:\/\/sourceforge.net\/projects\/jbcd\/<\/a> &#8211; very old (a.d. 2003), very limited, command line tool, actually I had problems to run it, so I can&#8217;t say anything about usability. Project is probably dead anyway <big><strong>\u2620<\/strong><\/big><\/p>\n<\/li>\n<li>\n<p style=\"text-align: justify;\"><strong>Dr. Garbage Bytecode Visualizer<\/strong> &#8211; <a href=\"http:\/\/www.drgarbage.com\/bytecode-visualizer.html\" title=\"http:\/\/www.drgarbage.com\/bytecode-visualizer.html\" target=\"_blank\">http:\/\/www.drgarbage.com\/bytecode-visualizer.html<\/a> &#8211; not that old (still in development), very promising plugin for <strong>eclipse<\/strong>. It works, but it has some problems and limitations (for example breakpoint can&#8217;t be set inside method, only method entry is supported).<\/p>\n<\/li>\n<\/ul>\n<p>I was struggling with this topic until a wild idea came to my head.<\/p>\n<h3>The idea<\/h3>\n<p style=\"text-align: justify;\">Java .class files supports various debugging attributes which are usually stripped during release compilation. One of those attributes is called <b>LineNumberTable<\/b>:<\/p>\n<pre lang=\"cpp\">    LineNumberTable_attribute {\r\n        u2 attribute_name_index;\r\n        u4 attribute_length;\r\n        u2 line_number_table_length;\r\n        {\r\n            u2 start_pc;\t     \r\n            u2 line_number;\t     \r\n        } line_number_table[line_number_table_length];\r\n    }\r\n<\/pre>\n<p style=\"text-align: justify;\"><b>LineNumberTable<\/b> should be defined for each method in the .class file, it enables debugger to match bytecode position (<i>start_pc<\/i>) with the line number inside the source file. My initial idea was pretty simple, what if generated <b>LineNumberTable<\/b> match line numbers inside the disassembled source file. Having <b>dirtyJOE<\/b> as a quite good java .class editor (modesty!) I could easily add such functionality and test how it works. Quick prove of concept shown that this method is really working. I was testing it with <b>JDB<\/b> and <b><a href=\"https:\/\/code.google.com\/p\/jswat\/\" title=\"https:\/\/code.google.com\/p\/jswat\/\" target=\"_blank\">JSwat<\/a><\/b> debuggers:<\/p>\n<p><b>JDB:<\/b><\/p>\n<pre lang=\"\"><b>c:\\Java\\jdk\\bin>jdb -classpath e:\\_JPCApplication\\ org.jpc.j2se.JPCApplication<\/b>\r\nInitializing jdb ...\r\n> <span style=\"color: #008000;\">stop in org.jpc.j2se.JPCApplication.main<\/span>\r\nDeferring breakpoint org.jpc.j2se.JPCApplication.main.\r\nIt will be set after the class is loaded.\r\n> <span style=\"color: #008000;\">run<\/span>\r\nrun org.jpc.j2se.JPCApplication\r\nSet uncaught java.lang.Throwable\r\nSet deferred uncaught java.lang.Throwable\r\nVM Started: Set deferred breakpoint org.jpc.j2se.JPCApplication.main\r\n\r\nBreakpoint hit: \"thread=main\", org.jpc.j2se.JPCApplication.main(), line=931 bci=0\r\n<span style=\"color: yellow;\">931    00000000:        invokestatic        java.lang.String javax.swing.UIManager.getSystemLookAndFeelClassName()<\/span>\r\n\r\nmain[1] <span style=\"color: #008000;\">step<\/span>\r\nStep completed: \"thread=main\", org.jpc.j2se.JPCApplication.main(), line=932 bci=3\r\n<span style=\"color: yellow;\">932    00000003:        invokestatic        void javax.swing.UIManager.setLookAndFeel(java.lang.String)<\/span>\r\n\r\nmain[1] <span style=\"color: #008000;\">step<\/span>\r\nStep completed: \"thread=main\", org.jpc.j2se.JPCApplication.main(), line=933 bci=6\r\n<span style=\"color: yellow;\">933    00000006:        goto                pos.00000016<\/span>\r\n\r\nmain[1] <span style=\"color: #008000;\">step<\/span>\r\nStep completed: \"thread=main\", org.jpc.j2se.JPCApplication.main(), line=941 bci=22\r\n<span style=\"color: yellow;\">941    00000016:        aload_0<\/span>\r\n<\/pre>\n<p><b>JSwat:<\/b><br \/>\n<a href=\"http:\/\/blog.rewolf.pl\/blog\/wp-content\/uploads\/2013\/11\/jswat.png\" target=\"_blank\"><img decoding=\"async\" loading=\"lazy\" src=\"http:\/\/blog.rewolf.pl\/blog\/wp-content\/uploads\/2013\/11\/jswat-1024x672.png\" alt=\"jswat\" width=\"586\" height=\"384\" class=\"aligncenter size-large wp-image-816\" srcset=\"http:\/\/blog.rewolf.pl\/blog\/wp-content\/uploads\/2013\/11\/jswat-1024x672.png 1024w, http:\/\/blog.rewolf.pl\/blog\/wp-content\/uploads\/2013\/11\/jswat-300x196.png 300w, http:\/\/blog.rewolf.pl\/blog\/wp-content\/uploads\/2013\/11\/jswat.png 1196w\" sizes=\"(max-width: 586px) 100vw, 586px\" \/><\/a><\/p>\n<p style=\"text-align: justify;\">After playing a bit with <b>JSwat<\/b>, I&#8217;ve realized that I&#8217;m still missing some information. This little missing thing is called <b>LocalVariableTable<\/b> and it is another <i>debug<\/i> attribute that should be defined for every method in the .class file:<\/p>\n<pre lang=\"cpp\">    LocalVariableTable_attribute {\r\n        u2 attribute_name_index;\r\n        u4 attribute_length;\r\n        u2 local_variable_table_length;\r\n        {\r\n            u2 start_pc;\r\n            u2 length;\r\n            u2 name_index;\r\n            u2 descriptor_index;\r\n            u2 index;\r\n        } local_variable_table[local_variable_table_length];\r\n    }\r\n<\/pre>\n<p style=\"text-align: justify;\">Restoring this one is tricky, as it would require building function graph to correctly assign local variable scope (<i>start_pc, length<\/i> fields). I&#8217;ve decided to simplify it a bit. I&#8217;m using information about branch instructions and exception handlers to partition function into small chunks (I&#8217;ll not call them basic blocks, but they&#8217;re similar to basic blocks). Each chunk is scanned for opcodes that are operating on local variables ( a\/f\/d\/i\/l-store\/load_&lt;n&gt;, iinc) so I can determine the type of a specific variable. All those information are merged and put together into <b>LocalVariableTable<\/b> attribute. Described mechanism isn&#8217;t perfect, but it should be sufficient in most cases (and currently it&#8217;s probably the best (only?) solution to this problem).<\/p>\n<p style=\"text-align: justify;\">This is the end of my idea, but it isn&#8217;t the end of that topic. Java VM is a stack based virtual machine, which means that most of all opcodes operates on the operand stack. Having information about values pushed onto the stack sometimes can be crucial to understand what is really going on. Unfortunately neither <b>JDB<\/b> nor <b>JSwat<\/b> supports previewing of jvm operand stack. This is an unresolved problem for now.<\/p>\n<h3>dirtyJOE<\/h3>\n<p style=\"text-align: justify;\">Above ideas are implemented in <b><a href=\"http:\/\/dirty-joe.com\" title=\"http:\/\/dirty-joe.com\" target=\"_blank\">dirtyJOE v1.6<\/a><\/b>, they&#8217;re called <b>Restore Debug Info<\/b> and are accessible from GUI as well as from a command line. There is also <b>LocalVariableTable<\/b> editor, so if anyone feel that automatically generated <b>LocalVariableTable<\/b> isn&#8217;t enough, one can freely edit all aspects of the local variable (e.g. name, type). Command line support was introduced to help with restoring debug info in multiple files. Below command will restore debug information for all files in the current directory and all subdirectories (.joe files will be placed in the same subdirectories as input .class files):<\/p>\n<pre>for \/R %c in (*.class) do start \/WAIT dirtyJOE.exe \/rdi \"%c\"<\/pre>\n<p style=\"text-align: justify;\"><i>start \/WAIT<\/i> is crucial if you don&#8217;t want to mess the console, as <b>dirtyJOE<\/b> isn&#8217;t a console application so without this command it will run asynchronously. Most debuggers should automatically pick up generated disassembled source files (.joe), just set the proper <i>sourcpath<\/i> in the debugger settings. <b>JSwat<\/b> is even able to load source files from the .jar file, so disassembled .joe files can be repackaged into the original .jar file.<\/p>\n<p style=\"text-align: justify;\">That&#8217;s all for now.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Java bytecode debugging was bugging me for quite some time, however I&#8217;ve never done anything to really solve this problem once and for all. Around February I was desperately trying to solve some java bytecode riddle (yup, it was crackme ;p, but shhh&#8230;) and the only straightforward solution that would help with analysis was java [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[9,7,4],"tags":[],"_links":{"self":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/786"}],"collection":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=786"}],"version-history":[{"count":59,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/786\/revisions"}],"predecessor-version":[{"id":1075,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/786\/revisions\/1075"}],"wp:attachment":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=786"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=786"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=786"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}