Interest in Krakatau 2?

[Storyyeller]

@KOLANICH @Janmm14 @QwertyYtPl @samczsun @lab313ru @Dmunch04

I've been thinking about doing a complete ground-up redesign and modernization of Krakatau, but I'm not sure if there is enough interest to justify the effort, so I was curious if anyone would be interested in such a project. One particular problem is that I haven't been active in Java reverse engineering myself since 2015 or so, so I would be reliant on users to do all the testing. What do you think?

[lab313ru]

Really, don't sure about any future of this project... I prefer to use CFR during last years.

What would be interesting is a Kotlin specific decompiler (which uses metadata, deals with lambdas, etc.)

Thank you anyway for your awesome project!

[Janmm14]

I have a bunch of obscure samples for potential testing.
I think besides support for basic and better display of custom/complex invokedynamic, an option for it to do unambiguous imports helps much in user-friendlyness.

I don't know about krakatau internals but I liked its peephole analysis/optimizations it did, as its unique to krakatau.

What is your goal for rewriting Krakatau? Better code? Python 3? Fun side project?

[XenoAmess]

I would help if yourewrite it in java. If still python, then I could do nearly nothing. XenoAmess

…

________________________________ From: Janmm14 ***@***.***> Sent: Sunday, April 24, 2022 6:06:26 AM To: Storyyeller/Krakatau ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [Storyyeller/Krakatau] Interest in Krakatau 2? (Issue #185) I have a bunch of obscure samples for potential testing. I think besides support for basic and better display of custom/complex invokedynamic, an option for it to do unambiguous imports helps much in user-friendlyness. I don't know about krakatau internals but I liked its peephole analysis/optimizations it did, as its unique to krakatau. — Reply to this email directly, view it on GitHub<#185 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEFFR2JLVANMCPXV5XSDBOTVGRX6FANCNFSM5UFGUI6A>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Storyyeller]

If I'm going to write anything new, it will be in Rust. But I don't need help with the coding anyway. What I need help with is testing, and in particular identifying interesting samples of obfuscated applications, figuring out where the decompiler works well or not, highlighting features that would be useful to add, etc.

[KOLANICH]

@Storyyeller, Krakatau was the only Java decompiler I know that has reliably decompiled the code that was not originally in Java (I use it on the project written in Scala called Kaitai Struct, I have written the kinda python bindings to the compiler using JVM, but I cannot share it because KS is under GPL, since Scala methods calls map to Java methods calls in obscure ways, I had to decompile the binary to know how exactly I should call which methods) somehow correctly. Other decompilers usually either throw exceptions on such code or emit incorrect code. So yes, there is interes in Krakatau, if one is interacting to Scala code from other languages.

CFR is cool but it often doesn't decompile Scala code correctly.

One particular problem is that I haven't been active in Java reverse engineering myself since 2015 or so, so I would be reliant on users to do all the testing.

Why not to use the existing test suites?

[Storyyeller]

Status update and some questions for you all:

The new disassembler is mostly finished and in the testing and polish stage. I haven't started the assembler or decompiler yet. I expect the assembler to be a bit longer than the disassembler and the decompiler to take longer than both put together.

Question 1:

Currently, the plan is to support three output modes:

• Zip/jar output - create a zip archive with a separate file per class
• Single file output - output to file with the specified filename
• Directory output - create a separate file per class under the specified output directory

Directory output is the currently recommended way to use Krakatau, but it is problematic because there is no guarantee that the class names will result in valid filenames. There may be errors trying to create files with the corresponding names, or even worse, output from one class might silently overwrite another on case insensitive filesystems, e.g. Windows.

Currently, Krakatau has complicated name mangling logic to try to work around this, but this has the downsides that a) it adds a lot of complexity, and b) there is no way for users to predict where the output for a given class will actually be written to anyway.

Therefore, my plan is to remove all the name mangling logic in v2 and just say that directory output is "use at your own risk" and recommend that you use zipfile output instead. Is this ok with everyone?
@Morgon

Question 2

Deployment - I never bothered to set anything fancy up packaging-wise for v1, but now that I'm rewriting it in Rust, I figure it's a good time to try to find out what people think the best distribution strategy would be.

tagging @anthraxx, @MartinThoma, @toddATavail as well since you asked about packaging issues before

[KOLANICH]

a) it adds a lot of complexity

As long as this complexity is isolated, it is OK.

there is no way for users to predict where the output for a given class will actually be written to anyway.

One can just create a tsv file with the pairs mangled name <-> original name.

Therefore, my plan is to remove all the name mangling logic in v2 and just say that directory output is "use at your own risk" and recommend that you use zipfile output instead. Is this ok with everyone?

I thknk it is extremily inconvenient. To analyse the source I usually unpack the zip archives of the decompilers emitting them and it has always felt weird that they emit an archive, not a dir. Thank you for clarifying that aspect. While it is likely no binaries I had analysed had such paths, I think the potential inability to get decompilation results in a form of file tree is not good.

I figure it's a good time to try to find out what people think the best distribution strategy would be.

I guess one can try to create GitHub Actions pipeline emitting GitHub Pages, which will generate a repo that can be consumed by native repository managers like apt and dnf. I already did the things like that, but on GitLab (but for apt only). Since you are going to use rust, https://github.com/mmstick/cargo-deb can be helpful.

[Janmm14]

Krakatau is currently used in some guis for decompilation. They usually ask for decompilation/disassemble of a single class file. To make this easy for potential bad-named class files (multiple issues with that in the past) I'd suggest to allow single class file name input and defined output file name where the name of the input file is ignored.

[Storyyeller]

I'm already planning to do that. The question is whether directory output is also necessary.

[xxDark]

I just heard about that Krakatau is being re-written in Rust, would it be possible to add JNI bindings for easier use? That would be very handy
Thank you for your work!

[KOLANICH]

@xxDark, you may want to try GraalVM with GraalPython module. It allows to use not only python from java and java from python, but also other languages, like JS.

[xxDark]

@xxDark, you may want to try GraalVM with GraalPython module. It allows to use not only python from java and java from python, but also other languages, like JS.

I never actually looked into how Graal itself works, I might give it a shot just to try and see how it goes
But ultimately we would gladly wait for Krakatau 2 :)

[Storyyeller]

I briefly looked at the Recaf repository, and it looks like it is mostly focused on disassembly and reassembly rather than decompilation, correct? I expect it to take much longer to rewrite the Krakatau decompiler than the assembler and disassembler, so I was wondering if you would be interested in trying it out once I finish the assembler, even without the decompiler being rewritten. It seems like just having access to the Krakatau assembler and disassembler would already be very useful for you.

As for JNI support, that's something I might consider later, but it's not an immediate priority. I think calling it as a subprocess would be easiest for now.

[Storyyeller]

By the way, one other question for you all - I've been thinking about removing the ACC_SUPER and strictfp flags when disassembling in non-roundtrip mode since those flags don't actually do anything in modern Java and just add visual noise to the disassembly which might make it harder to understand. What do you think?

[KOLANICH]

I don't have any strong opinion on that since I'm not familiar to that impl details.

don't actually do anything in modern Java

I guess if the code is intended to be executed on the versions of Java where they do something (does the bytecode format have any mechanism to indicate that?), they should be kept.

[Col-E]

I briefly looked at the Recaf repository, and it looks like it is mostly focused on disassembly and reassembly rather than decompilation, correct?
...
It seems like just having access to the Krakatau assembler and disassembler would already be very useful for you.

The current master branch contains the current 2X release source, which has a really crappy assembler in it. We're focusing our efforts on getting 3X ready for release, and on that branch we recently invested into making a new assembler. In addition to not being crap, it offers some quality-of-life features like in-line expressions and name-based variable access. Stuff to make the bytecode a bit more accessible to new users. With that in mind, I don't think we would get a lot of value from a new assembler at the moment, especially if it were to require an layer of interop and not support the features our current model operates off of.

As everyone else has said thus far, we still look forward to whatever progress gets made on Krakatau 2 :)

[KOLANICH]

BTW for parsing java bytecode you can try to utilize Kaitai Struct

[Storyyeller]

The main advantage of Krakatau is full support for every part of the classfile format, as well as support for bytecode that makes use of a number of bugs and undocumented features in older versions of the JVM. Admittedly, that's not so relevant nowadays. It definitely prioritizes control over low level details over beginner-friendliness though - it's more aimed at bytecode hackers who are already familiar with how Java bytecode works.

[Storyyeller]

Status update: I started work on the assembler today.

[Janmm14]

I briefly looked at the Recaf repository, and it looks like it is mostly focused on disassembly and reassembly rather than decompilation, correct? I expect it to take much longer to rewrite the Krakatau decompiler than the assembler and disassembler, so I was wondering if you would be interested in trying it out once I finish the assembler, even without the decompiler being rewritten. It seems like just having access to the Krakatau assembler and disassembler would already be very useful for you.

I use recaf as a gui for decompilers when very old Helios 0.0.7 fails me. Recaf aims to be able to read zip files like the jvm and uses CAFED00D to normalize bytecode.

[Storyyeller]

Do you have any samples handy that I can use to test the zipfile reading issue you mentioned?

[Janmm14]

Do you have any samples handy that I can use to test the zipfile reading issue you mentioned?

Actually I was wrong with that part, recaf doesn't include such a feature and I'm not sure whether I got such a jar so far or whether current jvm does open initial jar differently from its java zip implementation at all.
However I encountered some zip files which refuse to open with many non-java programs. One such a zip file is https://www.mediafire.com/file/3wybtz4uu152fk1/Origin_Realms.jar.src.zip/file (it doesn't contain class files tho), another one I remember is but you need an account to download on the page when you google it.

[Col-E]

Actually I was wrong with that part, recaf doesn't include such a feature

What do you mean? The 3X branch does read zip files as the JVM does. Both 2X and 3X include bytecode normalization (Removing intentionally malformed attributes that aren't used at runtime in order to crash reverse engineering tools/libraries).

Do you have any samples handy

The library we made to read zip files as the JVM does has some samples in the test directory. See the *-trick jars.
https://github.com/Col-E/LL-Java-Zip/tree/master/src/test/resources

The major thing being that most zip parsers sig scan going forward for section headers. The JVM looks for the "end central directory entry" by looking backwards because that is optimal. The entry is found at the end of the file. Now consider if you use a hex editor to put two zip files together. Most tools will read/display the one at the beginning. But the JVM will read the one at the end. You can add on some extra tricks to make for a confusing archive, but this is the major gist.

[Janmm14]

@Col-E i was just using githubs search so it doesnt check branches. also he didnt ask for abnormal bytecode, so my answer was fully related to zip files

[fee1-dead]

The CharMatcher$Invisible class from guava is interesting: https://github.com/google/guava/blob/c111c0150225739b3f5914d1739cd22fb692bce7/guava/src/com/google/common/base/CharMatcher.java#L1459-L1476

I was writing my own rust library for parsing class files and hit this. There was an unpaired surrogate codepoint in that string which is not valid UTF-8 when decoded.

[Storyyeller]

Status update: I finished the initial version of the new assembler and started testing it today.

[Storyyeller]

I have finished testing the assembler and disassembler and think they are ready for public testing now. Anyone interested in trying them out?

New features:

• Much, much faster than before
• Support for new-style Code attrs in pre 45.3 classfiles
  ** For pre 45.3 classfiles, disassembler will try disassembling the bytecode in both formats. If only one of them is valid, it will just use that. If both are valid (which can only happen for a specially crafted classfiles like my Invisible Crackme), it will print out a warning and display the disassembly of the old-style parse. You can pass the new --no-short-code-attr option in order to force it to disassemble pre-45.3 classfiles using only the new style.
  ** As before, the assembler will output old-style Code attrs by default for pre-45.3 classfiles. However, you can use the new-style instead by using the new "long" option after the ".code" directive. (Also backported to Krakatau 1)
• Improved constant pool allocation algorithm fixes rare case where a specially crafted combination of ldc and wide raw .consts could cause Krakatau 1 assembler to fail even though there is a valid way to allocate the constants.
• Various cases of invalid attributes are now supported that Krakatau 1 did not support. (e.g. Record attribute inside a Record attribute)
• Support for bytecode features up to Java 18 (Also backported to Krakatau 1)
• Miscellaneous bugfixes (Also backported to Krakatau 1)
• Improved disassembler output - disassembler no longer writes out trailing whitespace at the end of each line.
• Disassembler supports disassembling multiple classes to a single combined .j file (Also backported to Krakatau 1)

Backwards incompatible changes:
I deliberately kept the assembler syntax as close as possible and tried to maintain as much backwards compatibility as possible. However, I decided to make a few extremely minor simplifications to the assembler syntax in order to simplify the implementation:

• Subattributes of a Code attribute must now appear at the end of the attribute, following all bytecode, .catch, and .stack directives. This is already how the disassembler disassembles things, so only hand-written assembly files might be affected.
• Float literals must now end in lowercase f (previously either case worked)
• Long literals must now end in uppercase L (previously either case worked)
• Hexidecimal float and double literals can no longer have a mantissa more than 64 bits long (for example, "0x10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000p-1474" was previously accepted but is now invalid.)
• +/- infinity/double float literals must now be exactly "Infinity" (case sensitive). Previously any capitalization was accepted.
• NaN float/double literals must now be exactly "NaN" (case sensitive). Previously any capitalization was accepted.
• Escape sequences in string literals in the assembler are stricter. Only \\, \n, \r, \t, \', \", \u, \U, and \x are supported now. Previously, the assembler would support anything that the (extremely lax) Python string literal syntax would support. The assembler still supports both ' and " strings as well as binary strings.
• Command line parameters in long form now take two dashes instead of one, as is the common practice (e.g. "--roundtrip" instead of "-roundtrip")

[XenoAmess]

I have finished testing the assembler and disassembler and think they are ready for public testing now. Anyone interested in trying them out?

New features:

• Much, much faster than before
• Support for new-style Code attrs in pre 45.3 classfiles
  ** For pre 45.3 classfiles, disassembler will try disassembling the bytecode in both formats. If only one of them is valid, it will just use that. If both are valid (which can only happen for a specially crafted classfiles like my Invisible Crackme), it will print out a warning and display the disassembly of the old-style parse. You can pass the new --no-short-code-attr option in order to force it to disassemble pre-45.3 classfiles using only the new style.
  ** As before, the assembler will output old-style Code attrs by default for pre-45.3 classfiles. However, you can use the new-style instead by using the new "long" option after the ".code" directive. (Also backported to Krakatau 1)
• Improved constant pool allocation algorithm fixes rare case where a specially crafted combination of ldc and wide raw .consts could cause Krakatau 1 assembler to fail even though there is a valid way to allocate the constants.
• Various cases of invalid attributes are now supported that Krakatau 1 did not support. (e.g. Record attribute inside a Record attribute)
• Support for bytecode features up to Java 18 (Also backported to Krakatau 1)
• Miscellaneous bugfixes (Also backported to Krakatau 1)
• Improved disassembler output - disassembler no longer writes out trailing whitespace at the end of each line.
• Disassembler supports disassembling multiple classes to a single combined .j file (Also backported to Krakatau 1)

Backwards incompatible changes: I deliberately kept the assembler syntax as close as possible and tried to maintain as much backwards compatibility as possible. However, I decided to make a few extremely minor simplifications to the assembler syntax in order to simplify the implementation:

• Subattributes of a Code attribute must now appear at the end of the attribute, following all bytecode, .catch, and .stack directives. This is already how the disassembler disassembles things, so only hand-written assembly files might be affected.
• Float literals must now end in lowercase f (previously either case worked)
• Long literals must now end in uppercase L (previously either case worked)
• Hexidecimal float and double literals can no longer have a mantissa more than 64 bits long (for example, "0x10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000p-1474" was previously accepted but is now invalid.)
• +/- infinity/double float literals must now be exactly "Infinity" (case sensitive). Previously any capitalization was accepted.
• NaN float/double literals must now be exactly "NaN" (case sensitive). Previously any capitalization was accepted.
• Escape sequences in string literals in the assembler are stricter. Only \, \n, \r, \t, ', ", \u, \U, and \x are supported now. Previously, the assembler would support anything that the (extremely lax) Python string literal syntax would support. The assembler still supports both ' and " strings as well as binary strings.
• Command line parameters in long form now take two dashes instead of one, as is the common practice (e.g. "--roundtrip" instead of "-roundtrip")

Hi.
You said you would use rust, so is there anyway for calling your program from java side? like a jni jar or something?

[fee1-dead]

1. I don't see support of discovering of shared libs written in Rust installed within system in cargo, like we do with C and C++ libs using pkg-config and CMake

There is. But for C libraries. openssl-sys links to openssl dynamically.

[fee1-dead]

Also Python impl is good for prototypig and tinkering. Compilation of Rust impl takes quite some time even after a change of 1 line in one file.

Is python still going to be maintained? Also you should try incremental compilation as that would improve compile times after small changes.

[KOLANICH]

They would use WASM for plugins like feather-rs does.

[KOLANICH]

There is. But for C libraries. openssl-sys links to openssl dynamically.

Thanks for the info. But as I have said, in order to debloat projects written in Rust, it should be de-facto working in practice for Rust libs. If it is working in the tools, but the community is within a tragedy of commons situation and cannot make it work and prefer to bloat the software, then implementing the needed features in the tools becomes useless, because noone will use them.

Also you should try incremental compilation as that would improve compile times after small changes.

Thanks for the info, I should read about it.

[Storyyeller]

I have tried disassembly of the Scala code relevant to me with Python and Rust versions, both versions worked without an error, but the Rust version has emitted prettier code, unfortunately we cannot directly compare them with diffs.

Rust version works significantly faster, but not the orders of magnitude: 4.7s (optimized build, almost no difference to unoptimized one) vs 9.4s (cpython 3.9). The jar is small enough to fit into FS cache: 1.5 MiB.

The Rust version is bloated. Rust itself is the language incapable of proper dynamic linking and code reuse, so it fetches and rebuilds all the deps. While building this package the most controversal deps it fetches are deps of zip crate, the ones it is likely are never used within jars: zstd, aes and so on.

I guess the next goals can be:

1. making output of Python and Rust versions of Krakatau comparable.
2. Allowing the Python decompiler to consume the zip archives created by the disassembler and ensuring that it outputs the same code when fed with the archives produced by Python and Rust versions
3. optimize the single-threaded impl to make "fast" Rust work really orders of magnitude faster than slow interpreted cpython 3.9.
4. maybe create a cffi API for the disassembler and integrate it into Python decompiler
5. .stack_size(256 * 1024 * 1024) I own a machine from 2001 where a 256 MiB used to be the whole physical RAM. I have upgraded it to 512 MiB and used python version of Krakatau on it succesfully (from a graphic LXQt session, so as you can guess that quite some of the RAM was consumed by the GUI apps that are a part of LXQt).

Thanks for the feedback! I'll see if I can optimize it a bit after the holidays. Could you provide the jar you used for benchmarking? I would expect a much larger speedup for optimized builds than that.

[KOLANICH]

mkdir -p ./destdir
wget -O ./destdir/kait.deb https://dl.cloudsmith.io/public/kaitai/debian-unstable/deb/any-distro/pool/any-version/main/k/ka/kaitai-struct-compiler_0.10-SNAPSHOT20220813.105458.a4435936/kaitai-struct-compiler_0.10-SNAPSHOT20220813.105458.a4435936_all.deb
ar x --output=./destdir ./destdir/kait.deb ./data.tar.gz
tar -zxv --directory ./destdir -f ./destdir/data.tar.gz ./usr/share/kaitai-struct-compiler/lib/io.kaitai.kaitai-struct-compiler-0.10-SNAPSHOT20220813.105458.a4435936.jar
mv ./destdir/usr/share/kaitai-struct-compiler/lib/io.kaitai.kaitai-struct-compiler-0.10-SNAPSHOT20220813.105458.a4435936.jar ./kait.jar
rm -rf ./destdir

[KOLANICH]

I'm sorry, it was my fault, I have mistakingly called debug version insead of release one (it resided in a different dir). The release one is really faster: 0.6s.

[Storyyeller]

@KOLANICH I updated it to remove unnecessary zip dependencies, reducing the binary size from 8.5mb to 7.3mb. I also tried to optimize the disassembler. However, it is already so fast that it was difficult to even benchmark or profile, and it looks like a lot of the remaining time is just spent on IO, which is unavoidable, so there doesn't seem to be much potential for further speedups here.

[Storyyeller]

Allowing the Python decompiler to consume the zip archives created by the disassembler and ensuring that it outputs the same code when fed with the archives produced by Python and Rust versions

One other note - I did do extensive testing before release making sure that Py disassembler -> Py assembler, Py disassembler -> Rust assembler, Rust disassembler -> Py assembler, Rust disassembler -> Rust assembler, etc. all give compatible results where expected. In fact, the main reason I backported most of the new features to the Python version was to make this comparison easier.

[moikeygraham]

@Storyyeller just wanted to drop a comment here to say the v2 Rust assembler / dissembler is great! Noticed a large speed improvement. Have not ran into any issues thus far.

Are there any plans to port the decompiler also?

[Storyyeller]

@Storyyeller just wanted to drop a comment here to say the v2 Rust assembler / dissembler is great! Noticed a large speed improvement. Have not ran into any issues thus far.

Are there any plans to port the decompiler also?

Thanks! I hadn't attempted to rewrite the decompiler yet because it would be a lot of work and I worried that noone would use it anyway due to the lack of response on the assembler/disassembler.

[KOLANICH]

worried that noone would use it anyway

I usually use the decompiler component of Krakatau.

[Janmm14]

The Krakatau decompiler is still the one resisting most obfuscation techniques and providing accurate results. Quiltflower and the other ones cannot compete when having obfuscated bytecode.

It is your decision whether you want to invest the time into this.
Decompilation has never been a popular topic.
Other decompilers focus on readability and good regular invokedynamic display, Krakatau focuses on correct and mostly runnable decompilability of even highly obfuscated source code at the cost of some readability.
Combined with the need for all libraries and python, other decompilers (mostly in java) had it a lot easier.

[XenoAmess]

yes you can try eclipse instead for decompiler. decompiling is not that same question to deassemble...

…

________________________________ From: Janmm14 ***@***.***> Sent: Wednesday, February 1, 2023 11:04:54 AM To: Storyyeller/Krakatau ***@***.***> Cc: XenoAmess ***@***.***>; Mention ***@***.***> Subject: Re: [Storyyeller/Krakatau] Interest in Krakatau 2? (Issue #185) The Krakatau decompiler is still the one resisting most obfuscation techniques and providing accurate results. Quiltflower and the other ones cannot compete when having obfuscated bytecode. It is your decision whether you want to invest the time into this. Decompilation has never been a popular topic. Other decompilers focus on readability and good regular invokedynamic display, Krakatau focuses on correct and mostly runnable decompilability of even highly obfuscated source code at the cost of some readability. Combined with the need for all libraries and python, other decompilers (mostly in java) had it a lot easier. — Reply to this email directly, view it on GitHub<#185 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEFFR2LPN67DIBDHHOGJERLWVHHFNANCNFSM5UFGUI6A>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[moikeygraham]

The Krakatau decompiler is still the one resisting most obfuscation techniques and providing accurate results. Quiltflower and the other ones cannot compete when having obfuscated bytecode.

@KOLANICH +1 to this. Its far superior to anything else out there in my opinion. I will always favour correctness over readability.

Thanks! I hadn't attempted to rewrite the decompiler yet because it would be a lot of work and I worried that noone would use it anyway due to the lack of response on the assembler/disassembler.

@Storyyeller I tend to use all three equally and often!

[Storyyeller]

Thanks for the responses everyone. It might be a while before I have the time, but I'll look into working on the decompiler.

[Storyyeller]

FYI, I started working on the decompiler last week. However, it will take a long time to get anywhere, so don't get your hopes up.

[moikeygraham]

FYI, I started working on the decompiler last week. However, it will take a long time to get anywhere, so don't get your hopes up.

Amazing news 😀 let me know if I can help in any way (my Rust experience is limited, but happy to do some testing / QA)

[XenoAmess]

Hi.

@Storyyeller

now it can only do krak2 --roundtrip --out 1 2

but when 1 we can put out first, like -out -roundtrip

well is this by means to do so?

really don't think there should be such order limit for -- params...

[XenoAmess]

Like I said before I'm really interested in krak2
So now we have something like this:
https://plugins.jetbrains.com/plugin/18144-bytecode-editor-xenoamess-tpm-/versions/stable/292491
If there be people who using jb-idea and wanna play with krak2 somehow it might be the best solution at current timestamp.
(only windows supported currently because of no money for buying mac. If krak2 repo can provide compiled bins as release, would be appreciated.)

[Storyyeller]

Update: My previous comment on Feb 12 was way too optimistic. I've been busy and haven't gotten the chance to work on the decompiler at all lately.

Today, I finally found the time to work on Krakatau again, but not on the decompiler. I improved the error messages for the assembler and disassembler (#194).

[Storyyeller]

Updated Krakatau v2 to handle the fake directory attack (https://github.com/x4e/fakedirectory). v1 is still affected.

[Janmm14]

Nice! (although it won't affect my workflow)

[Storyyeller]

Updated Krakatau v2 to ignore CRC checksums in jar files.

[XenoAmess]

@Storyyeller
Hi.
As it seems a little stable now, could you please set up a online cicd workflow and release some windows&linux&mac binary for krakatau2?
Thanks.

[Storyyeller]

I'm not sure how to do that.

[Storyyeller]

Update: I haven't worked on the decompiler at all since early February. I still intend to rewrite it eventually, but I don't know if or when I'll be able to start making progress on it.

[tonyspumoni]

Definitely interested in the v2 decompiler. Happy to jump in and help where I can, too

[Storyyeller]

The basic problem is that I didn't want the v2 decompiler to just be a straight rewrite of v1. I wanted to come up with a better structuring algorithm in order to handle try blocks with multiple catch arms, which the v1 algorithm can't handle. But then I got stuck trying to come up with a new algorithm and eventually gave up.

[Kreijstal]

rip