0

My friend and I am trying to decrypt the Assembly-CSharp.dll file from an Android game which was written in Unity3D. Normally these files are readable when using something like JustDecompile, but this one is encrypted.

We managed to modify the APK so that it is debuggable and also managed to get the stuff running so that we can debug the APK in IDA Pro. This runs fine so far and we can also set breakpoints and all that stuff.

But when debugging the APK in IDA Pro we are not able to find the points where the client is decrypting the Assembly-CSharp.dll file as this seems to happen in libmono.so. Here is an example what the encrypted DLL looks like right now: enter image description here

and what it should look like (from a game, made by me with unity): enter image description here

After making some adjustments of how the files are loaded from the APK, we were able to load libmono.so and also libunity.so into IDA, but we can not debug these files.

Whenever we want to debug them the IDA system tells us that these files can not run by themselves. Now we have 3 possible ways how to get to the point we want to:

  1. Finding the correct entry for libmono.so over debugging the classes.dex file
  2. Loading libmono.so or libunity.so to jump step by step to the point where the Assembly-CSharp.dll gets decrypted and extract the DLL (not sure how to do this yet ^^)
  3. Finding a way to load the libmono.so into IDA and debug it with another tool (I found a tool here which is called native-shim, this could probably help us).
Improve this question

2 Answers 2

Reset to default
4

I think the solution is a very simple one, with one small tweak.

To decrypt the file, XOR the encrypted data with the bytes 0xFCC6DC7FDCC7DFE0 and you will get the unencrypted file.

You can see this pattern by looking at the encrypted file and a valid dll. You can see a repeating pattern that is easy to pick out if you find areas that are supposed to be all 0's.

It appears that the encrypted files have a 16-byte header that is likely

    4-byte     file-signature  (0x0b25c4fa)
    4-byte     file size
    4-byte     file size (duplicated ?)
    4-byte     flag?

The rest of the file is the encrypted file.

With one small difference .. at least the first 2 bytes of the unencrypted file is mangled somehow to obscure it further. For a dll, start by setting the first 2 bytes to 0x4D5A, that should get it recognized by some tools such as 010Editor. You may have to play with the DOS_HEADER (the first 64 bytes of a dll) structure to see if it makes sense.

Improve this answer
0

You might to try GDB gcore which will require root. It will dump the memory and you can recovery decrypted files from dumped file http://www.iandrohacker.net/2015/11/tutorial-how-to-decrypt-encrypted-dll.html

Improve this answer
5
  • this will not work, i already tried this and only get a dump which is first of all full of 00 00 00 00. and when i wanna extract the dlls withthis guide, i only get 3 000001.com exe files. i got told about this when i was running into this issue, that this happens because the Assembly-CSharp.dll gets decrypted in the "mono_image_open_from_data_with_name" method from the libmono.so.
    – Gardosen
    Commented Feb 26, 2017 at 22:04
  • Well but for me it works as long as the dll are stored in the RAM. You can try another guide about dump decrypted dll using IDA but with broken english. I haven't tested it yet iandrohacker.net/2016/08/…
    – 0xabc
    Commented Feb 27, 2017 at 9:19
  • so we tried again this guide and this time i was going ingame instead of just going for the character select of the game. we now got a file which looks more decrypted, and when we follow the guide, it says at the end "87 headers found, 3 files recovered". but sadly these are only 3 stange MSDOS files with 30-50kb with a .com ending. :(
    – Gardosen
    Commented Feb 27, 2017 at 20:06
  • can you tell me the name of the game? i would like to take a look
    – 0xabc
    Commented Mar 1, 2017 at 17:22
  • small additional comment: i have the feeling that the dlls are protected somehow. i have alot of lua code it seems in the dump, but i have endless long areas of 00 00 00 00 00 and the dgb core command is throwing hundrets of warnings that he was not able to read specific areas.
    – Gardosen
    Commented Mar 2, 2017 at 8:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.