blockCTF-2024

FlowerApp

Catgeory: Reversing
Points: 200
Solves: 17

• This is an iOS application built using SwiftUI.
• The Mach-O binary lies in flowerapp.app/Contents/MacOS directory.
• On opening the binary in IDA, could notice user-defined functions like loadf , cc , drawFlower
• In Exteral symbols, I could notice references to CCCrypt which is Apple’s CommonCrypto framework.
• Starting with function loadf,

  • they have loading some base64-encoded data stored in NSUserDefaults with keys “a”, “b” and “c” .

    v82 = (id)objc_opt_self(&OBJC_CLASS___NSUserDefaults);
    v5 = objc_msgSend(v82, "standardUserDefaults");
    v6 = objc_retainAutoreleasedReturnValue(v5);
    v7 = (void *)String._bridgeToObjectiveC()('a', 0xE100000000000000LL);
    v8 = objc_msgSend(v6, "stringForKey:", v7);
    v9 = objc_retainAutoreleasedReturnValue(v8);
    objc_release(v6);
    v10(v7);
    if ( !v9 )
        BUG();
    v11 = static String._unconditionallyBridgeFromObjectiveC(_:)(v9);
    v13 = v12;
    v14(v9);
    v15 = objc_allocWithZone(&OBJC_CLASS___NSData);
    swift_bridgeObjectRetain(v13);
    v16 = (void *)String._bridgeToObjectiveC()(v11, v13);
    v17 = objc_msgSend(v15, "initWithBase64EncodedString:options:", v16, 0LL);

  • They are passing these 3 values to function cc.

  • Checking the strings section, we get 3 values
    

  • These values passes through several intermediate functions before it was finally passed to closure #1 in closure #1 in closure #1 in cc(a:b:c:) (not sure why the functions are in English sentences lol) , where this function uses CCCrypt package.
    

  • We could also see the code,

    result = CCCrypt(1u, 0, 1u, a3, keyLength, a6, dataIn, dataInLength, (void *)(v16 + 32), v18, dataOutMoved);

• When checking the source code of this framework and comparing the arguments we just got,
  • Operation was Decrypt
  • Algorithm used is kCCAlgorithmAES
  • Uses PKCS7 padding
• Based on the values we have, we could say first string is the key, second is the iv and the third one is the encrypted data.
• On decrypting the data with the above information, we get the flag

  from Crypto.Cipher import AES
  from Crypto.Util.Padding import unpad
  from base64 import b64decode
  
  key = b64decode(b"qQwrmkzuhJv6fzCF2XsxuaB+ZBtMEH+Cd3fpTgJpEM8=")
  iv = b64decode(b"FjmNRmlNzMZYK8TbIItuVA==")
  ciphertext = b64decode(b"8XvXFKhm8YFfQShtVXcNZh5F8q0zBJMTnfBSh33SEr8r4hMWb/E2VJq20QO2Byef")
  
  cipher = AES.new(key, AES.MODE_CBC, iv)
  plaintext = cipher.decrypt(ciphertext)
  print(plaintext.strip())

  Flag: flag{congrats_on_swiftly_decoding_this}

Protect your API Key

Catgeory: Reversing
Points: 400
Solves: 12

• This is a very simple application that has only one activity i.e. MainActivity.

• The apk also has an asset file 8.data whose contents is encrypted.

• This activity loads a native library libapp.so that has two native functions run and stringFromJNI.

• The run function is called with Context and a string com.some.real.better.practice.myapplication.RideHailing as arguments.

• On opening the library in Ghidra, starting with stringFromJNI, it just returns 0 (or some random value).

• On checking run function,

  • There are numerous string modification steps taking place.
  • Methods are being invoked using JNI.

• This seems like a pain to reverse with over 5.5k lines of code.

• Lets check the application dynamically, starting with the strings created using env.NewStringUTF() and env.SetByteArrayRegion using Medusa.

• We could see numerous strings used.

  

• As we scroll down through the output, we start to see the juicy part of the challenge like com.some.better.practice.app.MainActivity.getAssets()Landroid/content/res/AssetManager; , javax.crypto.spec.SecretKeySpec.<init>([BLjava/lang/String;)V, AES/ECB/PKCS5Padding and dalvik.system.InMemoryDexClassLoader.<init>(Ljava/nio/ByteBuffer;Ljava/lang/ClassLoader;)V .

• In simple, they are decrypting the assets file 8.data using AES ECB mode with PKCS5Padding and loading the dex file in memory using InMemoryDexClassLoader.

• The AES key is gr3443.,g,3-s@[w .

• On decrypting the 8.data file, we get a dex file.
  

• On loading the dex file, we see the class com.some.real.better.practice.myapplication.RideHailing and a decryption function that provides the flag.

public static String decryptMsg(byte[] cipherText) throws Exception {
    SecretKey secret = new SecretKeySpec("er34rgr3443.,g,3-09gjs@[wpef9j3j".getBytes(), "AES");
    Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
    cipher.init(2, secret);
    String decryptString = new String(cipher.doFinal(cipherText), "UTF-8");
    return decryptString;
}

public static void main(String[] args) {
    try {
        byte[] data = Base64.getDecoder().decode("9Bmk+Nc8i7oz2+sRYI9Q1fZ/metvBlUzoMMdC2aLstA=");
        String api_key = decryptMsg(data);
        System.out.println(api_key);
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
}

Flag: flag{3fh9.gkf29j.7}