-
Notifications
You must be signed in to change notification settings - Fork 994
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arbitrary code concealment #25
Comments
I'm concerned about the exploit and who uses what tools however as Luyten only displays what Procyon spits out, I can't and wouldn't implement a change from within Luyten. |
Fair enough. I did fork Luyten and implement an incredibly hackish JavaP bytecode mode, but the code is pretty horrible. In principle though, what would your thoughts be on expanding Luyten to encompass other disassembly tools? |
I did see your fork, as I hate executing external applications within code, it is functional. With that in mind I have always been willing to utilize other tools (Luyten's predecessor used fernflower), hell, I've thought about going as far as to make comparable diffs between decompilers however time... time is always of the essences. |
Time sucks |
I say this, but I do have a lot of time on my hands... |
As a result of the incorrect disassembly of a JVM instruction by Procyon, it is possible to hide arbitrary code in such a way that it is undetectable by Procyon/Luyten.
Incomprehensively, the concealment isn't even visible in the disassembled bytecode produced by Procyon, so if Luyten is being used to audit potentially malicious binaries, code concealed in such a manner is completely invisible to it. The constant pool has the potential to betray the presence of malicious code unless care is taken to avoid using (obviously malicious) literals.
For now, in regards to Luyten, there's little that can be done, unless you want to patch Procyon yourself, or use another disassembler (for bytecode disassembly, Krakatau is effective, although it's written in python).
Issue as described on Procyon bugtracker:
https://bitbucket.org/mstrobel/procyon/issue/216/goto_w-instruction-handled-improperly
The text was updated successfully, but these errors were encountered: