It's not only possible but has been done already, and not just once. Here's three I know about, and there may be more.
Kivlad by Cody Brocious
DAD by Zost (Androguard project):
JEB by Nicolas Falliere (commercial)
Then there ...
this is not entirely true. Dalvik bytecode will also be verified on the device, but this happens during installation time, not runtime. A verified and optimized version of the dex file will be stored on the system, protected by file system permission (you cannot change it afterwards unless you have rooted your device).
The trick that was used in the blog ...
There is no similar feature for Java byte code.
When you compile a C program, and statically link it to a standard library, the library code will be present, more or less unmodified, within the binary (except for addresses which will change), but there won't be any hint that a particular function had a particular name before being compiled (unless debugging ...
Android also contains bytecode verification but this step is moved from class loading on the device to the dex compiler (as it is similarily done in J2ME).
Alter dexing your class files (and before packaging to an .apk file) you can modify the files and introduce the referenced obfuscation.
So at loading time no further verifcation is done.
You just need to search online.
Anyways here are some python 2.4 decompilers worth trying,
decompyle - http://murphey.org/code/decompyle-2.4.tgz
pycdc - https://github.com/zrax/pycdc
depython - http://depython.com/
decompyle service - http://www.crazy-compilers.com/decompyle/
Python-Decompiler - https://gitorious.org/python-decompiler
Note : Easy Python ...
Some tools you can use. However note that none of them has the ability to recompile classes, i.e you cannot decompile a single class to source, modify it, and then recompile back. It may be possible using Reflection API but then you need to do a lot of modification on the decompiled source itself. Other ways may be to decompile the entire bunch of classes ...
If your application is compiled to a binary you might still be able to use normal debuggers like IDA. However, Lua has its own tools for decompiling from machine code and byte code. These links should be kept up to date by the Lua community.
Lua Wiki: LuaTools
If you need support for Lua 5.2 LuaAssemblyTools is the first to support that.
I think it should be possible even with current Java decompilers, by patching their code. They have at least one big difference - while JVM is stack-based, Dalvik is register-based. This difference could be handled with not so much code. Second difference - bytecode format. So you need use code, which is able to disassemble Dalvik bytecode format.
If the control flow graph has not been obfuscated then you could use those to match methods. The biggest hurdle to this is building up the database of library signatures.
Control flow graphs are the structure that the basic blocks make when viewed as a directed graph.  These represent the possible paths of execution in a method. They are relatively easy ...
JPEXS Free Flash Decompiler appears to have this functionality.
From http://www.free-decompiler.com/flash/features.html --
Displaying ActionScript code on the left, p-code on the right
Clicking AS item hilights position in p-code and vice-versa
Here are some thoughts on the fundamental problem and a possible solution; even if the full system goes way beyond your dev budget, some key ideas might still be useful for fashioning your own solution.
Crypto is of little use if you don't have the leverage that makes the crypto algorithm itself the weakest link in the system, just like a ten-inch steel ...
You can try using javasnoop (https://code.google.com/p/javasnoop/) to accomplish something similar.
Here's a tutorial for using it -
The issue is that constant pool entry 67 (the one for your List.get()) method has the type Method, rather than InterfaceMethod, even though you are trying to invoke it as an interface method. When using invokeinterface, the corresponding constant pool entries need to be InterfaceMethod.
Assuming you didn't specify the type itself, this is likely a bug in ...
Your file seems to go like:
52A0 = 20:02:36
53A0 = 20:02:38 in dos time
If its dos time it would make sense why every pattern(51A0, 52A0) is shown 2 times since dos time doesnt accept odd numbers as seconds.
I dont think anything natural such as sound would go DA,5A,DA,5A,DA,5A,DA,5A,DA,5A.
So I assume that DA ...
This question is a little too broad to answer without more information but I'll cover some general points about what I think you're looking for. I'm also going to assume x86 calling convention on Windows for simplicity's sake.
The only thing that really determines what a function "looks like" in assembly is its calling convention, but there's no restriction ...
IMHO, in general, order of difficulty:
My reasoning is such:
Object code is easiest because it will usually contain lots of symbol or debug information. Even when it doesn't you have a bit of extra knowledge, since you know that all the code in that file relates to one compile object. That's pretty useful to know, and ...
I found out that there is no specification of what the PHP bytecode should look like, so vendors implement it differently. So technically there is no such thing as "php bytecode", it only exists when talking about a particular engine, e.g. "zend bytecode".
Soot can give you a Jimple IR of an apk and inject instrumentation into it. It's not dynamic though, although I don't see why it couldn't be used for data dependency analysis. Unless your target app does weird things with reflection or JNI you should still be able to perform the analysis you want.
There's a tutorial on using Soot with Dalvik executables ...
There is virtually no difference between the bytecode emitted by loadfile and luac.
The only possible reason for the error you are getting is that you are opening the file stringdumped.txt in text mode. Try the following code and see if there are any errors
f = io.open("stringdumped.txt", "wb") --Note that file is opened in binary mode
Firstly, I would mention that instead of using a general purpose hex editor, a dedicated class editor would be much better. There are plenty of them.
You tried editing the class file and to your surprise the changes you made were not reflected. At that point you should be pretty much sure that there must be some other tricks such as generating the strings ...
There are a number of ways to do this. Some people new to signature scanning use MD5 hashes of the entire file. This is VERY flawed, due to the switching of registers or even just the timestamp of the file would change the entire signature.
Another method often used is YARA ( http://plusvic.github.io/yara/ ).
A good example from their webpage:
There is no JMP-64bit-OFFSET instruction in AMD64 (don't ask me, normaly they are not stingy with new opcodes).
Quote from x86asm.net about JMPF:
AMD64 Architecture Programmer's Manual Volume 3: If the operand-size
is 32 or 64 bits, the operand is a 16-bit selector followed by a
32-bit offset. (On AMD64 architecture, 64-bit offset is not supported)
Stack maps were a feature added in Java 6 (corresponding to version 50), but were not made mandatory until Java 7 (version 51) in order to ease the transition. Stack maps make classloading slightly faster at the expense of making bytecode generation significantly more painful.
If you are manually editing bytecode, then it is a big hassle to write the stack ...
Regarding your comment (Would respond as a comment, but don't have the 50 rep yet):
I added links to the class file before and after modification. Is there any other better tool around?
I develop the bytecode editor Recaf. I reimplemented your code and it worked just fine. However lets say you forgot the isInterface flag on your INVOKEINTERFACE ...
I develop Recaf, a free Java bytecode editor. Recaf currently supports most of what you're looking for in the current release (Decompile via CFR, class/member renaming, a verbose search feature, and contextual actions on the decompiled code). Right now it's going through a rewrite which will include even more of the features you're looking for.
If you have ...