blug

redpwnCTF 2021 - javaisez3

If you participated in redpwnCTF 2021, you might know that I authored the javaisez3 reverse-engineering challenge. So… here is my writeup. I attempted to write this writeup in a way that is friendly to those who do not have a lot of experience with the Java Virtual Machine (JVM), so hopefully you will find this educational and helpful should you ever run into future Java bytecode reverse-engineering scenarios.

It will also help if you do a quick reading on how the JVM works. The JVM is a stack machine with a stack-per-method model (different methods have separate stacks). Each operand on the stack consists of 4 byte words and values can be stored and loaded from local variables unique to each method. Something important to keep in mind is that the JVM does not pop arguments off the stack in the reverse order for method invocations (which you expect in something like x64 assembly), so the following set of instructions is equivalent to xyz.itzsomebody.MyClass.myMethod(0, "hello world").

iconst_0 // push 0
ldc "hello world" // push "hello world" to stack
invokestatic xyz/itzsomebody/MyClass myMethod (ILjava/lang/String;)V // invoke method

Note: I did not proofread much. I am too tired now. :lemonthink:

A quick introduction to Java bytecode: https://en.wikipedia.org/wiki/Java_bytecode
And, of course, nothing beats the JVM specification: https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html

Edit: The challenge can now be downloaded from the redpwnCTF 2021 challenges repository! (https://github.com/redpwn/redpwnctf-2021-challenges/)

Piano arrangment of "Mario & Luigi: BIS -- Final Battle" sountrack

It’s been awhile since I posted! I spent a fair amount of time transposing today and yesterday the Final Battle soundtrack from Mario and Luigi: Bowser’s Inside Story.

Link

As you can see from my usage of accidentals (f natural intead of f double-sharp, lol), I was kinda lazy plus I’m bad at transposing in general.

The "Calculus Rush"

Some of you may have heard of this, some of you may have not. The “Calculus Rush” is a reference to when students (particularly those in high-school) “rush” to the next math class – that is, instead of actively developing their problem-solving skills with what they already know, they spread themselves thin by learning new material. Several articles have been written about this which you can find by googling for or “the rush to calculus” or some similar alliteration. This does not apply to every student and/or school, but it’s foolhardy to deny that this is a problem in education in general.

The "What's the trick?" Dilemma

Frequently, I see students asking questions more-or-less along the lines of “What’s the trick for this problem?” with the assumption that for every type of problem, there is a ready-made trick to that allows said students to get the answer quickly – essentially asking for a full solution that is copied for a similar problem that “requires” the same so-called trick. The reason this annoys me is that it fosters an environment where problem-solving and understanding are discouraged and rote memorization is encouraged.

While this rant is primarily aimed at poorly-implemented pedagogy in mathematics, it applies to pretty much every other subject as well.

Killing Threadtear's Sandbox

Full PoC w/ abitrary code execution: Link to Issue

Update: The vulnerability has been partially fixed; however, the patch unintentionally removes desired functionality as stated here.

Not too long ago, I was casually perusing my way through GitHub and found the Threadtear Java bytecode deobfuscator. For those of you who don’t know, I have a strong interest for Java bytecode-related projects — especially when deobfuscation and obfuscation are involved.

There’s a warning on the README.md of the repository which specifically informs the user it is possible to successfully execute arbitrary code through the deobfuscator for malicious purposes. So of course, I decided to take up the challenge and create a proof of concept of an ACE exploit in Threadtear.