Unity3D protection in “AU2” dance games

Today's story is about dancing games. Specifically, about

These games employ some tricks in the APK file structure as well as modified libmono.so. I will go through each of the protection mechanisms step-by-step and explain how it works. In the end, you will have all the necessary information to implement your own decryption tool that can decrypt AU2 protected DLL files.

Since this research builds on my previous work, I strongly suggest that you read at least Part 1 and Part 2 of my series about Unity3D protections.

Let's get started!

Modified APK/ZIP file

As you probably know, APK file is actually a ZIP file. Game authors have taken the ZIP file and modified some of ZIP internal structures. Depending on which tool you use to decompress the APK, it may or may not cause problems.

For example, the very popular ICSharpCode.SharpZipLib library fails with an error:

Unhandled Exception: ICSharpCode.SharpZipLib.Zip.ZipException: Version required to extract this entry not supported (788)
   at ICSharpCode.SharpZipLib.Zip.ZipFile.TestLocalHeader(ZipEntry entry, HeaderTest tests)
   at ICSharpCode.SharpZipLib.Zip.ZipFile.GetInputStream(Int64 entryIndex)
   at ICSharpCode.SharpZipLib.Zip.ZipFile.GetInputStream(ZipEntry entry)

This is an easy thing to fix, since SharpZipLib is an open-source project. Just find the offending check and comment it out.

Unpack libmono.so

Once the APK is unpacked and you open Assembly-CSharp.dll in the hex editor, you'll see that DOS and PE signatures are changed to lowercase "mz" and "pe". And the entire PE section table is encrypted.

So, it's very likely that libmono.so was modified. But you can't analyze it right away because it's encrypted with some protection I can't recognize.

I'll be very honest - I don't have a good solution for this part. The cryptor itself is not particularly difficult. However, these games also use libjiagu.so which employs some anti-debug protection. In the end I just made a memory dump from running process and did static analysis of dumped libmono.so in IDA. If I figure out a better way, I'll update the post.

Modifications of libmono.so

Once the libmono.so is unpacked, you can get to the good stuff. Authors of this protection did not go the usual way of changing mono_image_open_from_data_with_name, they changed several methods instead.

First change is in mono_image_load_pe_data - there is an additional check for "mz" signature:

...
memcpy (&msdos, image->raw_data + offset, sizeof (msdos));
if (!(msdos.msdos_sig [0] == 'M' && msdos.msdos_sig [1] == 'Z') && 
    !(msdos.msdos_sig [0] == 'm' && msdos.msdos_sig [1] == 'z'))
   goto invalid_image;

msdos.pe_offset = GUINT32_FROM_LE (msdos.pe_offset);
offset = msdos.pe_offset;
offset = do_load_header (image, header, offset);
...

Similarly, do_load_header is modified to support "pe" signature:

static int do_load_header (MonoImage *image, MonoDotNetHeader *header, int offset)
{
   MonoDotNetHeader64 header64;
#ifdef HOST_WIN32
   if (!image->is_module_handle)
#endif
   if (offset + sizeof (MonoDotNetHeader32) > image->raw_data_len)
      return -1;

   memcpy (header, image->raw_data + offset, sizeof (MonoDotNetHeader));
   if (!(header->pesig [0] == 'P' && header->pesig [1] == 'E') &&
       !(header->pesig [0] == 'p' && header->pesig [1] == 'e') &&)
      return -1;
...

And the section headers are decrypted in the load_section_tables:

// initialize decryption key
decrypt_init();

for (i = 0; i < top; i++){
   MonoSectionTable *t = &iinfo->cli_section_tables ;

   if (offset + sizeof (MonoSectionTable) > image->raw_data_len)
      return FALSE;

   // additional check for "mz" header
   if ( image->raw_data[0] == 'm' && image->raw_data[1] == 'z' )
   {
      // special treatment of sections in "mz" file
      // copy section header
      memcpy (t2, image->raw_data + offset, sizeof (MonoSectionTable));

      // decrypt each field separately
      decrypt(&t2Name, 8, i);
      decrypt(&t2.Misc, 4, i);
      decrypt(&t2.VirtualAddress, 4, i);
      decrypt(&t2.SizeOfRawData, 4, i);
      decrypt(&t2.PointerToRawData, 4, i);
      decrypt(&t2.PointerToRelocations, 4, i);
      decrypt(&t2.PointerToLinenumbers, 4, i);
      decrypt(&t2.NumberOfRelocations, 2, i);
      decrypt(&t2.NumberOfLinenumbers, 2, i);
      decrypt(&t2.Characteristics, 4, i);

      // copy decrypted header to proper place
      memcpy (t, t2, sizeof (MonoSectionTable));
   }
   else
   {
      // original code
      memcpy (t, image->raw_data + offset, sizeof (MonoSectionTable));
   }
   offset += sizeof (MonoSectionTable);
...
}

The decryption method is an overly-complicated XOR:

void decrypt_init()
{
   m_decryptionKey[0] = 'm';
   m_decryptionKey[1] = 'p';
   m_decryptionKey[2] = 'z';
   m_decryptionKey[3] = 'e';
   m_decryptionKey[4] = 'e';
   m_decryptionKey[5] = 'z';
   m_decryptionKey[6] = 'p';
   m_decryptionKey[7] = 'm';
   m_decryptionKeySize = 8;
}

void decrypt(_BYTE *a1_data, int a2_size, unsigned __int8 a3)
{
   // XOR data with the key.
   int keyIdx = 0;
   for ( int i = 0; i < a2_size; ++i )
   {
      a1_data[i] ^= m_decryptionKey[keyIdx++];
      if ( keyIdx == m_decryptionKeySize )
         keyIdx = 0;
   }

   // "Generate" key for next call. Nightmare! :)
   for ( int i = 0; i < a2_size; i++ )
      m_decryptionKey[i] = a1_data[i] ^ a3;
   m_decryptionKeySize = a2_size;
}

Broken IL method headers

Now we can open file in dnSpy. However, all methods have empty method bodies. In fact, all the method headers are invalid, both header size and code size is shown as zero.

// Token: 0x06000001 RID: 1 RVA: 0x00002050 File Offset: 0x00000250
.method public hidebysig specialname rtspecialname instance void .ctor () cil managed 
{
   // Header Size: 0 bytes
   // Code Size: 0 (0x0) bytes
   .maxstack 0
} // end of method HideAndroidButtons::.ctor

So, there is still something missing. 🙂

This looks like a result of a JIT-hooking protection. But there is no JIT hooking in Mono framework! So, the protection authors must have invented another trick..

It took me some time to figure this one out.

First, there is some additional code in load_tables. It generates a decryption key from 2 fields in the #~ stream header. See ECMA-335, II.24.2.6 #~ stream for the description of the structure.

/*
 * Load representation of logical metadata tables, from the "#~" stream
 */
static gboolean
load_tables (MonoImage *image)
{
   const char *heap_tables = image->heap_tables.data;
...
   protectedModuleInfo = NIL;
   if ( LOBYTE(heap_tables->reserved0)
        || BYTE1(heap_tables->reserved0)
        || BYTE2(heap_tables->reserved0)
        || HIBYTE(heap_tables->reserved0) )
   {
      // Find next unused slot. Protection supports max 50 protected modules per process.
      for ( i = 0; i <= 49; ++i )
      {
         protectedModule = &m_ptrProtectedModules[i];
         if ( !protectedModule->moduleId )
            break;
      }

      protectedModule->key[0] = heap_tables->reserved0;
      protectedModule->key[1] = BYTE1(heap_tables->reserved0);
      protectedModule->key[2] = BYTE2(heap_tables->reserved0);
      protectedModule->key[3] = HIBYTE(heap_tables->reserved0);
...
      protectedModule->key[4] = heap_tables->valid[0];
      protectedModule->key[8] = heap_tables->valid[4];
      protectedModule->key[6] = heap_tables->valid[2];
      protectedModule->key[9] = heap_tables->valid[5];
      protectedModule->key[11] = heap_tables->valid[7];
      protectedModule->key[5] = heap_tables->valid[1];
      protectedModule->key[7] = heap_tables->valid[3];
      protectedModule->key[10] = heap_tables->valid[6];
...
   }

   heap_sizes = heap_tables [6];
   image->idx_string_wide = ((heap_sizes & 0x01) == 1);
   image->idx_guid_wide   = ((heap_sizes & 0x02) == 2);
   image->idx_blob_wide   = ((heap_sizes & 0x04) == 4);
...

Second, the decryption of method header is done in mono_metadata_parse_mh_full. Tiny and fat headers are handled separately but the idea is the same.

MonoMethodHeader *
mono_metadata_parse_mh_full (MonoImage *m, MonoGenericContainer *container, const char *ptr)
{
...
   switch (format) {
   case METHOD_HEADER_TINY_FORMAT:
      mh = (MonoMethodHeader *)g_malloc0 (MONO_SIZEOF_METHOD_HEADER);
      ptr++;
      mh->max_stack = 8;
      mh->is_transient = TRUE;
      local_var_sig_tok = 0;
      mh->code_size = flags >> 2;
      mh->code = (unsigned char*)ptr;
      return mh;

   case 0: // encrypted code, tiny header
      mh = (MonoMethodHeader *)g_malloc0 (MONO_SIZEOF_METHOD_HEADER);
      *ptr |= 2;                     // change method header flags from 0 to 2 -> tiny header
      origCode = (BYTE *)(ptr + 1);  // tiny method header is 1 byte long, followed by IL code
      mh->max_stack = 8;
      local_var_sig_tok = 0;
      mh->code_size = flags >> 2;

      // try to allocate buffer for decrypted code. If allocation fails, code will be decrypted in-place.
      buffer = (BYTE *)g_malloc0 (mh->code_size);
      if ( buffer )
      {
         memcpy(buffer, origCode, mh->code_size);
         decryptMethod(buffer, mh->code_size, m->name);
         mh->code = buffer;
      }
      else
      {
         decryptMethod(origCode, mh->code_size, m->name);
         mh->code = origCode;
      }
      mh->code_size |= 0x80000000;   // set highest bit of code_size. It will be used later.
      return mh;
...

The decryption routine is just a simple XOR again:

void __cdecl decryptMethod(BYTE *data, int dataSize, char *moduleName)
{
   ProtectedModule *pm;
   int idx;
   int i;

   pm = getProtectedModule(moduleName);
   idx = 0;
   for ( i = 0; i < dataSize; ++i )
   {
      switch ( idx )
      {
         case 0:
            data[i] ^= pm->key[0];
            break;
         case 1:
            data ^= pm->key[1];
            break;
         case 2:
            data ^= pm->key[2];
            break;
         case 3:
            data ^= pm->key[3];
            break;
         case 4:
            data ^= pm->key[4];
            break;
         case 5:
            data ^= pm->key[5];
            break;
         case 6:
            data ^= pm->key[6];
            break;
         case 7:
            data ^= pm->key[7];
            break;
         case 8:
            data ^= pm->key[8];
            break;
         case 9:
            data ^= pm->key[9];
            break;
         case 10:
            data ^= pm->key[10];
            break;
         case 11:
            data ^= pm->key[11];
            break;
         default:
            break;
      }
      if ( ++idx == 12 )
         idx = 0;
   }
}

To fix this problem, you'll need parser for most .NET metadata structures. I used Asmex source as a base for my tool.

More IL code encryption

You make a tool that fixes method headers and decrypts IL code and run it - but the result still looks like junk:

// Token: 0x06000001 RID: 1 RVA: 0x00002050 File Offset: 0x00000250
.method public hidebysig specialname rtspecialname instance void .ctor () cil managed 
{
   // Header Size: 1 byte
   // Code Size: 7 (0x7) bytes
   .maxstack 8
   /* 0x00000251 3514         */ IL_0000: bgt.un.s  
   /* 0x00000253 3130         */ IL_0002: ble.s     
   /* 0x00000255 303A         */ IL_0004: bgt.s     
   /* 0x00000257 1A           */ IL_0006: ldc.i4.4
} // end of method HideAndroidButtons::.ctor

That's because there's another XOR encryption hidden inside mini_method_compile and mono_method_get_header. Remember, how highest bit of IL code size was set during previous decryption routine? Now this bit is checked and decryption loop is executed. Something like this:

MonoMethodHeader*
mono_method_get_header (MonoMethod *method)
{
...
   header = mono_metadata_parse_mh_full (img, container, loc);
   if ( header->code_size < 0 )
   {
      header->code_size &= 0x7FFFFFFF;
      for ( i = 0; i < header->code_size; ++i )
         header->code ^= 0x30;
   }
...

Why? Probably because 2 XOR encryptions are much stronger than just one. Oh, wait, what?! 😀 Adding one extra line to the tool is an easy fix.

Changed IL opcodes.

Now the decrypted IL code looks makes some sense. There is a ret instruction in the end and some methods actually look correct. Not this one, however:

// Token: 0x06000001 RID: 1 RVA: 0x00002050 File Offset: 0x00000250
.method public hidebysig specialname rtspecialname instance void .ctor () cil managed 
{
   // Header Size: 1 byte
   // Code Size: 7 (0x7) bytes
   .maxstack 8
   /* 0x00000251 05           */ IL_0000: ldarg.3
   /* 0x00000252 24           */ IL_0001: UNKNOWN1
   /* 0x00000253 01           */ IL_0002: break
   /* 0x00000254 00           */ IL_0003: nop
   /* 0x00000255 00           */ IL_0004: nop
   /* 0x00000256 0A           */ IL_0005: stloc.0
   /* 0x00000257 2A           */ IL_0006: ret
} // end of method HideAndroidButtons::.ctor

That's because protection authors have swapped around some IL opcodes. Normally, CIL opcode table looks like this:

• 0x02 - ldarg.0
• 0x03 - ldarg.1
• 0x04 - ldarg.2
• 0x05 - ldarg.3
• 0x06 - ldloc.0
• 0x07 - ldloc.1
• 0x08 - ldloc.2
• 0x09 - ldloc.3
• 0x24 - UNUSED
• 0x28 - call

In this modified version, ldarg.* and ldloc.* opcodes have been switched around and the call opcode is changed from 0x28 to 0x24:

• 0x02 - ldarg.3
• 0x03 - ldarg.2
• 0x04 - ldarg.1
• 0x05 - ldarg.0
• 0x06 - ldloc.3
• 0x07 - ldloc.2
• 0x08 - ldloc.1
• 0x09 - ldloc.0
• 0x24 - call
• 0x28 - call

The change is done in the methods mini_method_compile and inline_method. There's an extra check which tells if the module is protected. For protected module, an alternative implementation of mono_method_to_ri is called. If you're interested in the finer details, I suggest you study the code yourself.

To fix that, you'll need to make a simple .NET disassembler. You don't need a full-featured engine, simple length disassembler with lookup tables is more than enough for task in hand. I reused almost 10-years old code stored in my "old projects" folder - and now it is available on my bitbucket repo as well. 🙂

The code for fixing the opcodes is very simple:

static void FixAu2Opcodes(byte[] ilCode)
{
    int i = 0;
    while (i < ilCode.Length)
    {
        byte opcode = ilCode[i];
        switch (opcode)
        {
            case 2:
                ilCode[i] = 5;
                break;
            case 3:
                ilCode[i] = 4;
                break;
            case 4:
                ilCode[i] = 3;
                break;
            case 5:
                ilCode[i] = 2;
                break;
            case 6:
                ilCode[i] = 9;
                break;
            case 7:
                ilCode[i] = 8;
                break;
            case 8:
                ilCode[i] = 7;
                break;
            case 9:
                ilCode[i] = 6;
                break;
            case 0x24:
                ilCode[i] = 0x28;
                break;
            default:
                break;
        }
        i += DotnetLengthDisasm.GetInstructionSize(ilCode, i);
    }
}

The end result looks like this:

Conclusion

At the time of writing, if you search for modified versions of these 2 games, you'll find out that there are zero mods or cheats available. Zero!

But there are also Thai and Indonesian versions of the same game, as well as an older English version of the game. They do not use custom libmono.so:

There are plenty of cheats and mods available for all of them. From the quick Google search:

• AndroidRepublic: AU2 Mobile v4.9 MOD [UPDATE]
• AndroidRepublic: AU2:Dancing Idol Ver 1.3 Mod Menu | Auto Perfect | Auto Dance
• AndroidRepublic: AU2 Dance v1.1 [MOD]
• Platinmods: AU2 Mobile Ver. 4.5 Mod Menu | Auto Perfect | Auto Dance
• Platinmods: AU2 Mobile-ID Ver 1.4 Mod Menu | Auto Perfect | Auto Dance
• Platinmods: AU2 Dance v1.1 Mod Menu | Auto Perfect | Auto Dance

Such large difference in number of available mods suggests that this protection is good enough to stop most wanna-be-hackers of the Android MOD groups. Nice work!

---