[GH-ISSUE #414] Idea from @neoOpus: Evolve HumanifyJS into an AI-Powered, Integrated Reverse Engineering & Code Transformation Assistant #81

New issue

Open

opened 2026-03-03 13:52:50 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 13:52:50 +03:00

Owner

Originally created by @0xdevalias on GitHub (Apr 23, 2025).
Original GitHub issue: https://github.com/jehna/humanify/issues/414

@neoOpus shared the following in an unrelated issue thread, bringing it to it's own issue for better visibility/discussion/etc.

(Note: The issue title was auto-generated by gemini-2.5-pro-preview-03-25, but if you have a more relevant suggestion to use, let me know and I can update it.)

The original comment:

HumanifyJS has tremendous potential as a tool, and the foundation laid so far is commendable. However, there are opportunities to enhance its functionality and usability. Right now, it requires a lot of manual effort and maintenance, which can be challenging even for small projects.

To unlock its full potential, it would be exciting to explore a reworked version that focuses on reliability, automation, and seamless integration with development environments. Imagine a tool that could handle its own limitations, leverage AI for intelligent task management, and work effortlessly within the context of a project.

Some ideas for improvement could include:

Building AI-driven features to automate deobfuscation and monitoring, similar to what Manus does but specific to the reverse-engineering task.

Enhancing its ability to integrate smoothly with IDEs for a more streamlined experience.

Developing a project-aware system that adapts to the needs of each workflow, allowing refactoring of the code and making it possible to create something different out of it and keep updating it with minimal to no effort, while leveraging the state-of the art coding knowledge and development expertise, allowing to create better versions of what is already there (obfuscated or not).

With these enhancements, HumanifyJS could become an indispensable tool for developers. It’s a great opportunity for collaboration to bring this vision to life and create something truly impactful.

Let’s build on the existing foundation and take it to the next level!

Originally posted by @neoOpus in https://github.com/jehna/humanify/issues/405#issuecomment-2813514414

For context, my followup comment was:

@neoOpus From a quick skim through your comment, it seems like it might be better positioned in a new issue, since it sounds more 'standalone'; rather than on this one that is focussed on the OpenAI Batch API specifically.

My quick /2c is that while I agree there's a lot of potential within Humanify (or another tool like it), I think there is also a lot of benefit in knowing where to draw the boundaries around what a tool will/won't handle (eg. unix philosophy); while making it easier for other tools/projects to make use of it in the process (eg. the same way humanify builds upon webcrack).

Some of what you mention above sounds interesting to me, but some of it sounds like things I would personally probably never need/use; and at least at face value, feel like they may stray a bit from what I believe the core functionality of humanify probably is/should be.

But yeah.. probably better if you create a new issue with that comment and can discuss thoughts there more as appropriate.

Originally posted by @0xdevalias in https://github.com/jehna/humanify/issues/405#issuecomment-2814559067

Originally created by @0xdevalias on GitHub (Apr 23, 2025). Original GitHub issue: https://github.com/jehna/humanify/issues/414 @neoOpus shared the following in an unrelated issue thread, bringing it to it's own issue for better visibility/discussion/etc. (Note: The issue title was auto-generated by `gemini-2.5-pro-preview-03-25`, but if you have a more relevant suggestion to use, let me know and I can update it.) The original comment: > HumanifyJS has tremendous potential as a tool, and the foundation laid so far is commendable. However, there are opportunities to enhance its functionality and usability. Right now, it requires a lot of manual effort and maintenance, which can be challenging even for small projects. > > To unlock its full potential, it would be exciting to explore a reworked version that focuses on reliability, automation, and seamless integration with development environments. Imagine a tool that could handle its own limitations, leverage AI for intelligent task management, and work effortlessly within the context of a project. > > Some ideas for improvement could include: > - Building AI-driven features to automate deobfuscation and monitoring, similar to what Manus does but specific to the reverse-engineering task. > - Enhancing its ability to integrate smoothly with IDEs for a more streamlined experience. > - Developing a project-aware system that adapts to the needs of each workflow, allowing refactoring of the code and making it possible to create something different out of it and keep updating it with minimal to no effort, while leveraging the state-of the art coding knowledge and development expertise, allowing to create better versions of what is already there (obfuscated or not). > > With these enhancements, HumanifyJS could become an indispensable tool for developers. It’s a great opportunity for collaboration to bring this vision to life and create something truly impactful. > > Let’s build on the existing foundation and take it to the next level! > > _Originally posted by @neoOpus in https://github.com/jehna/humanify/issues/405#issuecomment-2813514414_ For context, my followup comment was: > @neoOpus From a quick skim through your comment, it seems like it might be better positioned in a new issue, since it sounds more 'standalone'; rather than on this one that is focussed on the OpenAI Batch API specifically. > > My quick /2c is that while I agree there's a lot of potential within Humanify (or another tool like it), I think there is also a lot of benefit in knowing where to draw the boundaries around what a tool will/won't handle (eg. [unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy#Origin)); while making it easier for other tools/projects to make use of it in the process (eg. the same way `humanify` builds upon `webcrack`). > > Some of what you mention above sounds interesting to me, but some of it sounds like things I would personally probably never need/use; and at least at face value, feel like they may stray a bit from what I believe the core functionality of `humanify` probably is/should be. > > But yeah.. probably better if you create a new issue with that comment and can discuss thoughts there more as appropriate. > > _Originally posted by @0xdevalias in https://github.com/jehna/humanify/issues/405#issuecomment-2814559067_ ## See Also - https://github.com/jehna/humanify/issues/84 - https://github.com/jehna/humanify/issues/400 - https://github.com/jehna/humanify/issues/481 - https://github.com/jehna/humanify/issues/503 - https://github.com/jehna/humanify/issues/636

kerem commented

2026-03-03 13:52:50 +03:00

Author

Owner

@0xdevalias commented on GitHub (Apr 23, 2025):

Thank you for your kindness @0xdevalias. I considered taking action yesterday, as you suggested, but I was too tired and unsure if it was within scope as you remarked. I'm now reorganizing to see if I can make it work, but if anyone else is confident, please don't hesitate to take the initiative.

I'm also open to collaboration and exploring product launch opportunities, given the significant potential. Friendship as well.

Originally posted by @neoOpus in https://github.com/jehna/humanify/issues/405#issuecomment-2823128749

@neoOpus I figured I would copy this over and respond here to keep from de-railing the other thread too much with this.

(As a sidenote, would you mind marking your comments in https://github.com/jehna/humanify/issues/405#issuecomment-2813514414 as 'off topic' just so they don't draw as much focus on that thread? I would do it myself, but I'm not an official maintainer on this repo)

Totally understandable RE: being too tired. As far as in scope; while this isn't my repo, my general personal view is that in a grey area like that, at the very least it can be raised in an issue (or a discussion if the repo uses those instead); and then if it's out of scope or not relevant, then the issue can be closed with comments saying as much. Then even if it's decided to not be relevant, the context is captured in it's own thread for future knowledge.

I'm now reorganizing to see if I can make it work

@neoOpus Curious what you mean by 'reorganizing' in this instance?

I'm also open to collaboration and exploring product launch opportunities, given the significant potential.

@neoOpus I'm not sure how much capacity I have for extra side projects at this stage, but definitely happy to hear more about what your thoughts are; and if you end up setting up a new repo/similar, definitely let me know where it is and I'll see whether it's something I am interested in; even if that's just in a more casual 'providing feedback'/similar sort of way.

Friendship as well.

Feel free to drop me a message on Twitter DM's or similar if there's anything more specific you wanted to chat about in regards to things too.

@0xdevalias commented on GitHub (Apr 23, 2025): > Thank you for your kindness @0xdevalias. I considered taking action yesterday, as you suggested, but I was too tired and unsure if it was within scope as you remarked. I'm now reorganizing to see if I can make it work, but if anyone else is confident, please don't hesitate to take the initiative. > > I'm also open to collaboration and exploring product launch opportunities, given the significant potential. Friendship as well. > > _Originally posted by @neoOpus in https://github.com/jehna/humanify/issues/405#issuecomment-2823128749_ @neoOpus I figured I would copy this over and respond here to keep from de-railing the other thread too much with this. (As a sidenote, would you mind marking your comments in https://github.com/jehna/humanify/issues/405#issuecomment-2813514414 as 'off topic' just so they don't draw as much focus on that thread? I would do it myself, but I'm not an official maintainer on this repo) Totally understandable RE: being too tired. As far as in scope; while this isn't my repo, my general personal view is that in a grey area like that, at the very least it can be raised in an issue (or a discussion if the repo uses those instead); and then if it's out of scope or not relevant, then the issue can be closed with comments saying as much. Then even if it's decided to not be relevant, the context is captured in it's own thread for future knowledge. --- > I'm now reorganizing to see if I can make it work @neoOpus Curious what you mean by 'reorganizing' in this instance? --- > I'm also open to collaboration and exploring product launch opportunities, given the significant potential. @neoOpus I'm not sure how much capacity I have for extra side projects at this stage, but definitely happy to hear more about what your thoughts are; and if you end up setting up a new repo/similar, definitely let me know where it is and I'll see whether it's something I am interested in; even if that's just in a more casual 'providing feedback'/similar sort of way. > Friendship as well. Feel free to drop me a message on Twitter DM's or similar if there's anything more specific you wanted to chat about in regards to things too.

kerem commented

2026-03-03 13:52:51 +03:00

Author

Owner

@0xdevalias commented on GitHub (Jun 30, 2025):

Some words I wrote recently that feel relevant to this issue also:

which could serve as the backbone for this project—eliminating the need for APIs and transforming this mode from mere JSON request-response exchanges into a comprehensive system capable of managing files and the entire project. This innovation could revolutionize the script’s ability to autonomously maintain projects and perform minimal-input reverse engineering—a set-and-forget solution that downloads obfuscated files, extracts them if packaged (e.g., .crx), processes them, and generates references and supporting files to ensure version consistency.

@neoOpus This sounds quite similar to the following issue, and may stretch the scope of humanify beyond its current intent:

https://github.com/jehna/humanify/issues/414

I hope this project adopts this approach instead of relying on the current, limited API method.

@neoOpus While I haven't thought about this too deeply (and humanify technically isn't my project to guide the direction of (see also: #358)), I don't personally feel like the current API method is necessarily 'limited'; but more that what you're proposing feels like it could be an entirely different tool/scope than what humanify is looking to solve.

Like, off the top of my head, it could be that humanify ends up being just one of many tools in some new project that fulfills those 'larger scope' aspects you're talking about; in the same way that humanify leverages webcrack as a tool itself.

I kind of think about this in terms of the 'unix tool philosophy':

https://en.wikipedia.org/wiki/Unix_philosophy

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

Write programs that do one thing and do it well.

Write programs to work together.

Assuming those thoughts do tend out to be a good approach, then the sorts of changes that I think would be relevant within humanify itself could be adding the ability for it to act like a tool via Model Context Protocol (MCP) or similar, so that it could be more easily integrated into other tools via a standardised interface.

https://www.anthropic.com/news/model-context-protocol

Introducing the Model Context Protocol

https://modelcontextprotocol.io/

Model Context Protocol (MCP)

Another protocol that could be relevant in this space is the Agent2Agent protocol:

https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

Announcing the Agent2Agent Protocol (A2A)

Originally posted by @0xdevalias in https://github.com/jehna/humanify/issues/503#issuecomment-3017673075

@0xdevalias commented on GitHub (Jun 30, 2025): Some words I wrote recently that feel relevant to this issue also: > > which could serve as the backbone for this project—eliminating the need for APIs and transforming this mode from mere JSON request-response exchanges into a comprehensive system capable of managing files and the entire project. This innovation could revolutionize the script’s ability to autonomously maintain projects and perform minimal-input reverse engineering—a set-and-forget solution that downloads obfuscated files, extracts them if packaged (e.g., .crx), processes them, and generates references and supporting files to ensure version consistency. > > @neoOpus This sounds quite similar to the following issue, and may stretch the scope of `humanify` beyond its current intent: > > - https://github.com/jehna/humanify/issues/414 > > --- > > > I hope this project adopts this approach instead of relying on the current, limited API method. > > @neoOpus While I haven't thought about this too deeply (and `humanify` technically isn't my project to guide the direction of (see also: #358)), I don't personally feel like the current API method is necessarily 'limited'; but more that what you're proposing feels like it could be an entirely different tool/scope than what `humanify` is looking to solve. > > Like, off the top of my head, it could be that `humanify` ends up being just one of many tools in some new project that fulfills those 'larger scope' aspects you're talking about; in the same way that `humanify` leverages `webcrack` as a tool itself. > > I kind of think about this in terms of the 'unix tool philosophy': > > - https://en.wikipedia.org/wiki/Unix_philosophy > - > Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". > - > Write programs that do one thing and do it well. > - > Write programs to work together. > > Assuming those thoughts do tend out to be a good approach, then the sorts of changes that I think would be relevant within `humanify` itself could be adding the ability for it to act like a tool via Model Context Protocol (MCP) or similar, so that it could be more easily integrated into other tools via a standardised interface. > > - https://www.anthropic.com/news/model-context-protocol > - > Introducing the Model Context Protocol > - https://modelcontextprotocol.io/ > - > Model Context Protocol (MCP) > > Another protocol that could be relevant in this space is the Agent2Agent protocol: > > - https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ > - > Announcing the Agent2Agent Protocol (A2A) > > _Originally posted by @0xdevalias in https://github.com/jehna/humanify/issues/503#issuecomment-3017673075_