koobas.hobune.stream
Hook before Assembly-CSharp.dll is loaded?
A question mainly for Android - is there any way to get some code to run before the main Assembly-CSharp.dll is loaded. We need to encrypt the DLL to dissuade reverse-engineering. I'm reticent to dismantle the bootstrapping code that Unity generates, but this is the only other option I can think of. Has anyone else been here? Needing to do some processing before Mono starts up properly?
Do you want to encrypt compiled dll? How is Unity supposed to load it then?
If you meant obfuscation, then it should be done prior to deployment of your app to target device.
No, the idea is to modify the DLL in the AP$$anonymous$$, encrypt it before we distribute and then decrypt it when the app is started.
It looks like this is the way to hook into the startup on android:
http://docs.unity3d.com/Documentation/Manual/PluginsForAndroid.html
Extending the UnityPlayerActivity Java Code
With Unity Android it is possible to extend the standard UnityPlayerActivity class (the primary Java class for the Unity Player on Android, similar to AppController.mm on Unity iOS).
An application can override any and all of the basic interaction between Android OS and Unity Android. You can enable this by creating a new Activity which derives from UnityPlayerActivity
Except the problem here is that Unity seems to directly access the package code path to get the assets (or via Asset$$anonymous$$anager). $$anonymous$$aybe you can override the getPackageCodePath and specify an alternate location to load assets from, but then you'd have to emulate the entire package and maybe screw with some other systems.... seems very fragile. I've pushed back on this and am looking at obfuscation
if you are going to decrypt entire dll image at runtime (what you normally do) then forget it and dont waste your and time and your customers money with encryption. snapsots of dll images can be easily taken directly from process memory and flushed to file.
obfuscation is definitely the best way to go. I have even seen obfuscator which embeds custom native stubs in nearly all managed routines, making them absolutely invisible to reflector.
I don't think is so easy, could you tell me how to do this? "snapsots of dll images can be easily taken directly from process memory and flushed to file."
Is easy and can be done in many ways. For example get "process explorer", start and select target process. Under view enable DLL in lower pane view, add "Base" and "Size" columns. In the dll list find the dll youre looking for. Now you have virtual address base and size of your decrypted dll image. Now you can dump that memory block to dll file with arbitrary memory hex editor, or make your own memory dumper using Win API OpenProcess and ReadProcess$$anonymous$$emory.
sorry missed that. I don't know exact procedure for android (im coding mostly win/linux/qnx). But I read about rooted android memory editos, so accessing external process memory seems possible. The general principle should be applicable to arbitrary XYZ OS: open process memory, locate dll image base and size, dump.
You can also dump the entire process virtual memory. In most OSes with paged memory dll images are loaded at page boundaries (4096 byte) and are protected by guard pages. You just need to scan for ELF signature at boundaries and either parse elf header or dump everything until you hit guard page. And voila - you have images of all loaded dlls of that process.
To cut long story short: look at linux_proc_maps in googles volatility framework. This is the closest android answer I could find.
that trick doesn't work with Android emulator. The Android emulator does temporary store dll files if you play Unity games
if app can decrypt it, people can too. Obfuscation is the only way.
Yes I'm also planning to do this, but we can only obfuscate so far, because we have to maintain the interface between $$anonymous$$ono and the events/methods/classes the scene expects to be there. I do realise that there is no holy grail for protecting code that ultimately has to run on a client's device, and if you really take this seriously, you'll only end up with an arms race, but I have been charged to protect the code. I believe encrypting/fragmenting/encoding/cyphering/hiding the DLL should at least deter many of the more light-weight tamperers.
I'm also interested in if someone can suggest anything other than obfuscation.
