belong to us

[MagneticMonopole]

My solution:

Code: Select all

8c8c67*C1c67*1+C528**C8c9c67*C4c67*1+C528**C8c9c67*C4c67*1+C528**C8c4c67*C528**C
9c9c67*C8c67*1+C528**C9c8c67*C7c67*1+C528**C9c9c67*C4c67*1+C528**C9c9c67*C1c67*1+C528**C
8c4c67*C528**C8c8c67*C2c67*1+C528**C8c8c67*C1c67*1+C528**C9c9c67*C2c67*1+C528**C8c8c67*C
5c67*1+C528**C

Far from lightweight or elegant. I did not venture to decipher the symbols beyond "print number" and "print ascii".

Having the emulator run a second time over the output of the first round is either genius or madness. At the very least, I take the liberty to consider it ... unfriendly.

Btw, there was an obfuscator involved? I used both jad and jode, still getting rather unusual method names, which even a mere disassembler confirmed.[/code]

[adum]

yeah, i used my favorite obfuscator which really smacks java bytecode pretty hard.

[michuber]

Finally I found http://www.reversed-java.com which decompiles much better than JD.
So finding the differences to HVM was much easier.
Unfortunately it fails on "Protected Password 4", by now

[Icho]

The class file accepts the following String:

Code: Select all

88*5+258**C99*2+258**C88*1+258**C88*2+258**C84*258**C99*1+258**C99*4+258**C99*2-258**C99*8+258**C84*258**C89*4+258**C89*4+258**C88*1+258**C

The online checker doesn't. Is that intended or a bug?

[nighthalk]

all this thing is is the HVM interpreter which on the first pass swaps +13/-13 a - m with n - z, and all the opcodes are interpereted with a -12 base. but thats just to obscuferate what it does. i did however notice batch files HATE the ^ key (which my first elegant attempt was, then i did the unclean 1 letter at a time approach

[tails]

Aha, that seems to be a bug :-)

The Java class doesn't clear the stack before the second run. The code set up the data on the stack in the first run, and uses them in the second run. How neat :-) Maybe the online checker doesn't allow this?

[swgr]

Very interesting challenge.

At first I do some fixing work for the obscured decompile code to make it clearer. And then I suddenly realize ( actually, guess ) that a(String, String, boolean) is a HVM interpreter when I see the long ( and broken ) switch list. Luckily this is correct.

By the way, HVM code length limitation in this challenge is also sick.. >_<

Here is my solution:

Code: Select all

99*19*+4+89*8+49*7+49*6+7c9c0^C2c1^C2^C8c9c0^C4c1^C0c3^C2^C2^C4c8c0^C0c3^C2^C9c9c0^C8c1^C2^C8c9c0^C7c1^C2^C9c9c0^C4c1^C2^C9c9c0^C1c1^C2^C2^C7c9c0^C3c1^C2^C7c9c0^C2c1^C2^C9c9c0^C2c1^C2^C7c9c0^C6c1^C2^C

[MatRush]

Byte code is abstruse...
Does there any good java-decompiler?

[Redford]

There are only a few decompilers, the best is DJ Java Decomp, but it has ugly and strange gui, and it's commercial. And it's only decompiler, not deobfuscator. Also, I used JavaDeObfuscator, but it only can rename methods and fields, nothing more.
Does anyone knows what "Emyoolay" means?

Nice task, adum

[laz0r]

I think "Emyoolay" is a pun on "emulate", and possibly a slight hint towards the three-letter "HVM" - there might be a deeper meaning, though!

[Hippo]

At first I tought the double HVM call is a wrongly decompiled code but using third decompiler shown the truth jode did rather well.

I didn't notice the HVM does not clear stack so I used purely HVM solution. Requiring just two ROT13 swaps.