mirror of
https://github.com/jehna/humanify.git
synced 2026-04-27 17:45:58 +03:00
[GH-ISSUE #285] Unexpected reserved word 'await' #66
Labels
No labels
bug
enhancement
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/humanify#66
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TheGreyRaven on GitHub (Jan 21, 2025).
Original GitHub issue: https://github.com/jehna/humanify/issues/285
I have a quite heavily obfuscated file that fails with the following error shown above.
Not sure what you might need to debug this further, let me know and I can assist with both the file that I'm trying to deobfuscate.
I had a few other files that also contained some awaits and such and those files successfully deobfuscated, so not sure what might be the issue.
Also I'm running the local 2b to deobfuscate.
@0xdevalias commented on GitHub (Jan 22, 2025):
@TheGreyRaven I would probably start by seeing if bumping to the latest version of @j4k0xb 's
webcrackresolves the issue:If it does, then the version in
humanifyneeds to be updated.If not and the issue is still present there, then it's probably worth opening an upstream issue and providing an ideally minimal example of the code to reproduce the error:
If not, but it works upstream, then providing an ideally minimal example of the code to reproduce the error here would make the most sense I think.
@TheGreyRaven commented on GitHub (Jan 22, 2025):
Ah I see, I tested pasting the obfuscated code into their online ide and there it deobuscated most of the code just fine.
Perhaps a version update would be a good idea!
@0xdevalias commented on GitHub (Jan 23, 2025):
This project currently seems to be using
2.13.0:github.com/jehna/humanify@f6a2190bc5/package.json (L62)Latest
webcrackseems to be2.15.0:@TheGreyRaven If you feel like doing a little more digging, it would be useful to know if you get the same error running
webcrackdirectly on version2.13.0, and which newer version seems to fix it. That would help provide relevant context for this bug report.@j4k0xb commented on GitHub (Jan 23, 2025):
I remember a similar discussion regarding the version in this repo
It should already use the latest version due to the
^?Since it works fine the first time I assume the generated code get's corrupted at some point.
Remember that the babel parser is used by humanify itself, webcrack, and prettier.
@brianjenkins94 commented on GitHub (Jan 23, 2025):
You can use
overridesfor quick testing:https://github.com/jehna/humanify/issues/67#issuecomment-2422990106
@VivaLaPanda commented on GitHub (Jan 31, 2025):
With overriding to latest webcrack, I still see this
@0xdevalias commented on GitHub (Feb 6, 2025):
@VivaLaPanda Thanks for checking.
@TheGreyRaven / @VivaLaPanda Since it sounds like the issue is in
humanifyrather thanwebcrack, it would be useful to have an (ideally minimal, but any is better than none) example code that triggers this error; to help narrow down exactly where it's being caused.@fosteman commented on GitHub (Feb 7, 2025):
this seems to fix it:
https://github.com/jehna/humanify/compare/main...fosteman:humanify:main
although, i am skipping the problem instead of dealing with it.
@0xdevalias commented on GitHub (Feb 7, 2025):
This seems to create a plugin that logs a
console.error, and then skips the entireProgram:Which is then added at the end of
transformWithPlugins.@fosteman Can you explain how this fixes the issue? From my quick / naive read.. this looks like it would just skip running any processing against the code at all; so while yes, it would technically skip the issue, I believe it would also skip doing anything at all wouldn't it?
Do you have a code sample where this issue was natively occurring? I would like someone to be able to provide a real-world sample so we can actually debug this issue properly and see exactly where/why it's occurring.
Edit: Resurrecting the stack trace from your edit:
Stack Trace
We can see this part of the error, showing the code that caused it:
Putting the whole stack trace into ChatGPT 4o gave the following suggestion about the root cause of the error:
@0xdevalias commented on GitHub (Feb 7, 2025):
@TheGreyRaven The surrounding context in your error is less clear than what I discovered above in https://github.com/jehna/humanify/issues/285#issuecomment-2641827428, but I suspect it's the same root cause, that there is an
awaitkeyword in your code, but the function isn't marked withasync. If you still have the code sample available, are you able to check if that is true please?While I haven't yet explored this deeper, my potential guesses for areas to look deeper would be:
asyncbefore usingawaitinternallyhumanifyis removing theasynckeywordhumanifyis choosing a name that includesasyncas a prefix (despite that being an invalid name)@j4k0xb commented on GitHub (Feb 15, 2025):
Forgot to mention that it's configured to have laxer parsing rules (
errorRecovery: true), which also allows await in non-async functions.And thanks to @0xdevalias I found the root cause why your fork got rid of the error: the bug is in
babel-plugin-transform-beautifier, which removes the async keyword.There are also many similar transforms that exist in humanify, webcrack and this plugin at the same time, might be a good idea to review which ones are needed.
@0xdevalias commented on GitHub (Feb 16, 2025):
Imported here:
github.com/jehna/humanify@88b51bc689/src/plugins/babel/babel.ts (L4-L4)Used here:
github.com/jehna/humanify@88b51bc689/src/plugins/babel/babel.ts (L72-L78)Upstream bug issue:
@jehna Is there any reason we need to keep
babel-plugin-transform-beautifierinhumanifyat all? I've generally found thatwebcrack/wakaru(#3) do a pretty good job of beautifying the code; and if there are any edge cases where it could be better; my personal thought would be that upstreaming those (if relevant) might make more sense than trying to fix them here after the fact.The other internal plugins defined here:
convertVoidToUndefinedgithub.com/jehna/humanify@88b51bc689/src/plugins/babel/babel.ts (L6-L21)webcrack:github.com/j4k0xb/webcrack@302bd93e99/packages/webcrack/src/unminify/transforms/void-to-undefined.tsgithub.com/j4k0xb/webcrack@302bd93e99/packages/webcrack/src/unminify/test/void-to-undefined.test.tsflipComparisonsTheRightWayAroundgithub.com/jehna/humanify@88b51bc689/src/plugins/babel/babel.ts (L23-L53)webcrack:github.com/j4k0xb/webcrack@302bd93e99/packages/webcrack/src/unminify/transforms/invert-boolean-logic.tsgithub.com/j4k0xb/webcrack@302bd93e99/packages/webcrack/src/unminify/transforms/yoda.tsmakeNumbersLongergithub.com/jehna/humanify@88b51bc689/src/plugins/babel/babel.ts (L55-L70)webcrack@j4k0xb commented on GitHub (Feb 16, 2025):
github.com/j4k0xb/webcrack@302bd93e99/packages/webcrack/src/unminify/transforms/raw-literals.ts (L13-L18)normalizes any number formatting like 5e3 or 0x2b20@0xdevalias commented on GitHub (Feb 16, 2025):
Edit: PR to bump the dependency: