Skip to content
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

Partial Recompilation #728

Open
Amejonah1200 opened this issue Sep 24, 2023 · 0 comments
Open

Partial Recompilation #728

Amejonah1200 opened this issue Sep 24, 2023 · 0 comments

Comments

@Amejonah1200
Copy link
Contributor

Amejonah1200 commented Sep 24, 2023

<insert first idea draft here>

Potential Problems with this approach:

  1. Decompiler API Requirement & Challenges:
    • To enable this feature, the decompiler must have an API for obtaining an Abstract Syntax Tree (AST) from input code.
    • Not all decompilers readily support obtaining the AST, potentially necessitating forking of the decompiler codebase.
    • Implementing this feature across different decompilers would require creating abstractions, which can be complex.
  2. Alignment Issue:
    • Even if partial recompilation is achieved, it works effectively only for the initial pass.
    • Editing decompiled code can lead to misalignment between the AST and the edited code.
  3. Generic Code Handling:
    • A generic code handling system is necessary to support editable code, addressing the issue of code alignment after user edits.
  4. Obfuscation Challenge:
    • The challenge lies in handling obfuscated code, as most Java code parsers expect valid Java source code.
    • Some parsers, like JavaParser (2x/3x), hard fail in cases involving obfuscation, whereas OpenRewrite (4x) can provide partial AST from obfuscated code in certain cases.
  5. Refactoring Requirements:
    • Implementing this feature would necessitate significant refactoring in terms of managing decompilation, displaying decompiled code, handling syntax styling, and context analysis.
  6. Edge Cases and Abuse Considerations:
    • The feature is subject to potential edge cases, particularly concerning obfuscation.
    • Careful consideration is needed to prevent misuse and abuse of this approach to display data.

The initial feature request would involve significant refactoring in four key areas:

  1. Decompilation Management: Restructuring how decompilation is handled.
  2. Display of Decompiled Code: Adapting code display methods.
  3. Syntax Styling: Updating the approach to syntax styling.
  4. Context Analysis: Enhancing the system's context analysis capabilities.

A new idea is being proposed:

Action: Right-click on a method to access the "edit method separately" option.
Functionality: Opens a new window/tab with the following features:

  • Handling of Inner Classes, Fields, and Methods:
    • Obfuscated fields are replaced with fieldX aliases, and these aliases cannot be changed.
    • Inner classes are mocked, and if they have illegal names, aliases are provided.
    • Other methods, including lambdas, are mocked.
    • If they have illegal names, aliases are used.
    • Comments are included for reference.
  • Method Body Editing:
    • The method itself is presented in a text field, allowing users to edit and save the method body.
  • Additional Features (Nice to Have):
    • Method and Parameter Renaming: Consider allowing users to rename method names and parameter names.
    • Changing Types: Explore the possibility of changing data types, potentially using a miniature JASM field.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants