Consider using pionxzh/wakaru instead of/alongside webcrack

[0xdevalias]

I only came across webcrack, wakaru, and this project today; but in some basic tests I was doing between webpack and wakaru, I found that the latter seemed to produce much nicer output by default when used on webpacked files:

• https://github.com/pionxzh/wakaru

  • Javascript decompiler, unpacker and unminify toolkit

I wonder if it would make a good addition to this humanify tool?

[jehna]

That's a great addition, thanks! I was searching for similar tools like webcrack, but I think I've missed wakaru. I'll definitely give it a try!

[jehna]

It seems that wakaru does not yet have a (functioning) npm package, which makes usage harder. I'll add an issue to their repo about it. I think I can come up with a PoC without a package too, but for official support it would be better to have a sane way to have it as a dependency 😅

[0xdevalias]

That's a great addition, thanks! I was searching for similar tools like webcrack, but I think I've missed wakaru

@jehna No worries :) Yeah, I was looking pretty deep in this space only like 4 months ago and didn't come across webcrack or wakaru (or humanify 😜), so was exciting to be able to update my gist with a bunch of new resources today!

I think I can come up with a PoC without a package too, but for official support it would be better to have a sane way to have it as a dependency

@jehna Yeah, definitely agree.

[0xdevalias]

NPM package has been released. You can check the README for more information.

Originally posted by @pionxzh in pionxzh/wakaru#39 (comment)

---

https://github.com/pionxzh/wakaru#-using-the-api

📦 Using the API

npm install @wakaru/unpacker @wakaru/unminify
# or
pnpm install @wakaru/unpacker @wakaru/unminify
# or
yarn add @wakaru/unpacker @wakaru/unminify

@wakaru/unpacker

import { unpack } from '@wakaru/unpacker';

const { modules, moduleIdMapping } = await unpack(sourceCode);
for (const mod of modules) {
  const filename = moduleIdMapping[mod.id] ?? `module-${mod.id}.js`;
  fs.writeFileSync(outputPath, mod.code, 'utf-8');
}

@wakaru/unminify

import { runDefaultTransformation, runTransformations } from '@wakaru/unminify';

const file = {
  source: '...', // source code
  path: '...',   // path to the file, used for advanced usecases. Can be empty.
}
// This function will apply all rules that are enabled by default.
const { code } = await runDefaultTransformation(file);

// You can also specify the rules to apply. Order matters.
const rules = [
  'un-esm',
  ...
]
const { code } = await runTransformations(file, rules);

You can check all the rules at /unminify/src/transformations/index.ts.

Please aware that this project is still in early development. The API might change in the future.

And the bundle size of these packages are huge. It might be reduced in the future. Use with caution on the browser (Yes, like the playground, it can run on the browser).

[Acters]

Even though I ran into an issue with pionxzh/wakaru#134 , I found a simple bandaid fix to try to test it on some packages.
This package seems to not work as well or even have noticeable effectiveness in improving readability.(no difference in my bandaid fix and the online playground to see if the fix caused any issues)
wakaru certainly didn't help de obfuscating code.
webcrack seems to do be the better performer to the point that using wakaru on the webcrack output didn't seem necessary.
I say we wait for the wakaru package to mature before implementing it.

[0xdevalias]

wakaru certainly didn't help de obfuscating code.

@Acters Wakaru is specifically not a de-obfuscator. It's an un-minimiser.

I say we wait for the wakaru package to mature before implementing it.

@Acters I would personally suggest running both against non-obfuscated code and comparing/contrasting their output. I haven't checked for a while now, but at the time I made this suggestion, wakaru's output on non-obfuscated code was drastically better. I know there has been a bunch of improvement in webcrack since then; but given I believe this lib is pinned to an old version anyway, i'm not sure those improvements would even be seen here currently.

[Acters]

wakaru certainly didn't help de obfuscating code.

@Acters Wakaru is specifically not a de-obfuscator. It's an un-minimiser.

I say we wait for the wakaru package to mature before implementing it.

@Acters I would personally suggest running both against non-obfuscated code and comparing/contrasting their output. I haven't checked for a while now, but at the time I made this suggestion, wakaru's output on non-obfuscated code was drastically better. I know there has been a bunch of improvement in webcrack since then; but given I believe this lib is pinned to an old version anyway, i'm not sure those improvements would even be seen here currently.

I apologize, I mispoke. There are nuances here and fumbled the spoken language.
If I run an obfuscated script through webcrack then wakaru(both unpack and unminify) the output was similar without meaningful changes.

It seems like that the samples I have are more geared towards testing deobfuscators, as the output from webcrack does a better job than Restringer, or common online deobfuscators.

As for using Wakaru after a deobfuscator like webcrack, Wakaru will sometimes make it harder to look at the code because I find the aggressive "unrolling" of brackets/function calls to spread them over multiple lines has reduced my ability to get a overview of the code. Especially when there is code that is repeated in an ugly fashion that was obvious to be a developer choice and not the fault of tools.
This example shows that while Humanify did make a similar mistake, it was not present throughout the entire code and some portions are better unrolled because I will be able to see patterns in the code than the unrolled version Wakaru presented. Even for extremely short params/elements in a list or object were unrolled quite aggressively, such as just a list of ints or simple function calls. Something I didnt like as scrolling through the code was a heavier burden from the simple reason of needing to expend some effort into keeping track of where the bracket/parenthesis started and where it stops when there are repeated lines that are better seen as single line. These unrolling just sometimes makes it scroll heavy, much less useful to me as having a balance in width and height can be a make and break situation. A heavily unrolled version emphasized the need for a more vertical layout/monitor which is nice for mobile, but leaves lots of unused space on larger wider monitors which is honestly most of my main monitors are oriented with. I think this could be a simple fix as I think this is because of the use of prettier in Wakaru, and likely could excersize more control by influencing the unrolling to not be as aggressive.

On top of that, no other changes to the deobfuscated code was found, only the aggressive unrolling, showing to me that Wakaru wasn't helpful, and that Humanify was simply better off with just keeping its codebase simple and lean with only WebCrack. Wakaru offers a robust CLI that is much more supported than the api version in the current state. So I am in the belief that it should be up to the users to decide when they want to use Wakaru or not. It can be implemented as an optional plugin with a command line switch(--wakaru) but having it as the default didn't seem necessary to me.

Left is Humanify; Right side is Webcrack+Wakaru only:

[pionxzh]

Thank you for your feedback on Wakaru. I'd like to address some points you raised:

• Unrolling: Wakaru uses aggressive destructuring to improve variable names. However, when combined with prettier, it can lead to multi-line formatting that might not be ideal. We appreciate any samples or insights you can provide to help with this refinement.
• Formatting: We understand that prettier's output may not always be ideal. This is why we are exploring integration with other formatting tools to offer better flexibility and results. We have ongoing branches and PRs addressing this concern.

Wakaru is primarily a rule-based unminifier, not a deobfuscator. Our documentation should have highlighted this more clearly. Users have the flexibility to pick and choose rules that suit their needs, and they can remove those they find unnecessary (including prettier).

We are integrating large-scale snapshot testing to better understand Wakaru's impact on larger codebases. This will help us fine-tune the rules and improve overall functionality.

[Acters]

Thank you for your feedback on Wakaru. I'd like to address some points you raised:

* **Unrolling**: Wakaru uses aggressive destructuring to improve variable names. However, when combined with `prettier`, it can lead to multi-line formatting that might not be ideal. We appreciate any samples or insights you can provide to help with this refinement.

* **Formatting**: We understand that `prettier`'s output may not always be ideal. This is why we are exploring integration with other formatting tools to offer better flexibility and results. We have ongoing branches and PRs addressing this concern.

Wakaru is primarily a rule-based unminifier, not a deobfuscator. Our documentation should have highlighted this more clearly. Users have the flexibility to pick and choose rules that suit their needs, and they can remove those they find unnecessary (including prettier).

We are integrating large-scale snapshot testing to better understand Wakaru's impact on larger codebases. This will help us fine-tune the rules and improve overall functionality.

Thank you for addressing my concerns, I do find your package intriguing, think there is quite a bit of potential. I can't share closed source material but I think that most of the material I have is geared towards de obfuscation and reverse research.
So I do think it was my mistake for using it with the wrong expectations. Thank you

[0xdevalias]

I was thinking about this more today, and given the current usage of webcrack is pretty localised within the unminify function; I could imagine it being relatively straightforward to lift that into an 'unbundle plugin' sort of thing (similar to how there are currently different LLM plugins), and then allowing wakaru to be another option:

humanify/src/unminify.ts

Lines 6 to 13 in 64a1b95

	export async function unminify(
	filename: string,
	outputDir: string,
	plugins: ((code: string) => Promise<string>)[] = []
	) {
	ensureFileExists(filename);
	const bundledCode = await fs.readFile(filename, "utf-8");
	const extractedFiles = await webcrack(bundledCode, outputDir);