by alxbl

NorthSec 2020 Writeup: After Party

This post outlines the solution to NorthSec 2020’s After Party challenge and includes both flags.


You are given a zip file, which when unzipped contains the following:


Looking into the jar with unzip -l afterparty.jar, it contains the following files:

Archive:  afterparty.jar
Length     Date       Time    Name
---------  ---------- -----   ----
    63     2020-05-03 14:17   META-INF/MANIFEST.MF
    0      2020-05-03 14:17   prom/
    2024   2020-05-03 11:56   prom/Bootstrap.class
    149    2020-05-03 10:17   prom/IValidator.class
    1464   2020-05-03 14:17   prom/Main.class
    1637   2020-05-03 14:17   prom/Validator.class
---------                     -------
    5337                     6 files

Flag 1: Java Decompilation

The next step is to open the Java application in a decompiler to understand what it’s doing. I used jd-gui.

JD-GUI decompiler

The natural starting point is Main.main which is the application’s entry point. The code looks like the following:

package prom;


public class Main {
  public static void main(String[] args) throws Exception {
    System.out.print("Password : ");
    BufferedReader buffer = new BufferedReader(
        new InputStreamReader(
    String pass = buffer.readLine();
    pass = pass.strip();
    if (pass.equals("FLAG-XXXXXXXXXXXXXXXXXXXXX")) {
      System.out.println("You can enter the party !");
    IValidator validator = Bootstrap.<IValidator>get(
    if (validator.validate(pass)) {
      System.out.println("You can enter the secret place !");
    } else {
      System.out.println("You won't get in with that password !");

Right off the bat, we see on lines 8-16 that the password is being checked against a flag. That’s flag 1/2 in the challenge. Beyond that, though there is an extra validation step that checks whether you are allowed to the “secret” place.

Flag 2: JNI-assisted Validator

In order to understand this one, we need to dive into line 18: `Bootstrap.get(IValidator.class).

package prom;


public class Bootstrap extends ClassLoader {
  private static Bootstrap _inst = new Bootstrap();

  static {
    File f = new File(System.getProperty("java.class.path"));
    File dir = f.getAbsoluteFile().getParentFile();
    File mod = new File(dir, "");

  public static <T> T get(Class<T> clazz) throws Exception {
    String name = clazz.getName();
    int pos = name.lastIndexOf(".") + 1;
    String beginning = name.substring(0, pos);
    String last = name.substring(pos);
    last = last.replaceFirst("I", "");
    Class<T> inst = _inst.findClass(String.valueOf(beginning) + last);
    return inst.newInstance();

  public native Class findClass(String paramString) throws ClassNotFoundException;

We can see that the code is going to load and modify the class name to remove the I prefix (making it Validator) and then calls the Java Native Interface (JNI) function findClass. Looking at Validator.class, the decompiler is spitting out an internal error, and we can’t seem to read the code.

It looks like we have to dive into the shared object and look at what findClass is doing. To do that, we pop into Ghidra and locate the mangled findClass function. According to the JNI spec, the exported function name must be something like Java_package_class_method, so we filter the function list by Java and find Java_prom_Bootstrap_findClass. That looks right.

Exported JNI function

Now looking at the disassembly of this function is a bit messy because JNI exposed native functions to interact with the Java VM. Understanding all the native functions and API is time consuming and not necessary. We can guestimate by looking at the strings being called. Here’s the Ghidra decompiler output, with the interesting bits highlighted:

Reversing the findClass function

In step 1, the method is retrieving the class name from the .jar. Then, in step 2, the stream is read with, which returns the total number of bytes read (total_size). Finally, a buffer is allocated and then in step 3 there is a loop which seems to update a key and performs a XOR over the dst buffer. One of those calls after the malloc is likely performing a memcpy at the JVM level, so we just take a guess and run with it.

Getting this code to run is quite difficult since the Java Archive needs to be repacked and existing Java tooling makes it difficult to debug a .jar without having the original sources. Instead, we re-implement the simple decryption loop in Python and recover the decrypted .class:

with open('Validator.class', 'rb') as f:
    data =

CLASS = 'prom.Validator'
KEY = len(data) + 0x1264ec8
out = []
for i in range(len(data)):
    KEY = (KEY * 0xd + 0xbeb0 + len(CLASS)) & 0xFFFFFFFF
    b = data[i] ^ (KEY & 0xFF)

with open('out.class', 'wb') as o:

Lastly, we create a new afterparty.jar with the Validator.class replaced by our decrypted version and open the resulting archive in jd-gui to decompile the validation code:

package prom;

import java.util.regex.Pattern;
import prom.IValidator;

public class Validator implements IValidator {
  public boolean validate(String flag) {
    if (!flag.startsWith("FLAG-"))
      return false;
    if (flag.length() != 25)
      return false;
    Pattern pattern = Pattern.compile("^FLAG-[a-f0-9]+$");
    if (!pattern.matcher(flag).matches())
      return false;
    String rest = flag.substring(5);
    int code1 = rest.substring(0, 2).hashCode();
    int code2 = rest.substring(2, 4).hashCode();
    int code3 = rest.substring(4, 6).hashCode();
    int code4 = rest.substring(6, 8).hashCode();
    int code5 = rest.substring(8, 10).hashCode();
    int code6 = rest.substring(10, 12).hashCode();
    int code7 = rest.substring(12, 14).hashCode();
    int code8 = rest.substring(14, 16).hashCode();
    int code9 = rest.substring(16, 18).hashCode();
    int code10 = rest.substring(18, 20).hashCode();
    if (code1 + code2 + code3 + code4 + code5 + code6 + code7 + code8 + code9 + code10 != 22998)
      return false;
    if (code1 != 1821)
      return false;
    if (code2 != 1604)
      return false;
    if (code3 != 1802)
      return false;
    if (code4 != 1691)
      return false;
    if (code5 != 1867)
      return false;
    if (code6 != 3140)
      return false;
    if (code7 != 3186)
      return false;
    if (code8 != 3180)
      return false;
    if (code9 != 1570)
      return false;
    if (code10 != 3137)
      return false;
    return true;

Oh, so it looks like we have to bruteforce some hashcodes two characters at a time in order to recover the flag. The important point here is to note the regular expression which limits the character set to a-f0-9. Failing to notice that will yield a lot of non-sensical flags because of hashcode collisions.

The easiest way to bruteforce this is in Java since there is no need to re-implement hashCode():

package afterp;

import java.util.regex.Pattern;
import java.util.ArrayList;
import java.util.Arrays;

public class AfterParty {
    public static String Good = "0123456789abcdef";
    public static void main(String[] args) {
        ArrayList<Integer> x = new ArrayList<Integer>(
                1821, 1604, 1802, 1691, 1867,
                3140, 3186, 3180, 1570, 3137

        var flag = "";
        var found = false;
        for (int c = 0; c < 10; ++c) {
            found = false;
            for (
                var b = 0;
                b < AfterParty.Good.length();
            ) {
                for (
                    var a = 0;
                    a < AfterParty.Good.length();
                ) {

                    String match = Character.toString(
                        AfterParty.Good.charAt(b)) +

                    if (match.hashCode() == x.get(c)) {
                        flag += match;
                        found = true;
                    if (found) break;
                if (found) break;

        System.out.println("FLAG-" + flag);
        System.out.println(validate("FLAG-" + flag));

I haven’t coded in Java since 2012, so please forgive my non-idiomatic Java. Suffice to say that the code works and we get the last flag of the track.