search

zhkl0228 / unidbg

Allows you to emulate an Android native library, and an experimental iOS emulation
Apache License 2.0
3.88k stars 966 forks source link

Unidbg keeps executing old code after patching #407

Open rasentry opened 2 years ago

rasentry commented 2 years ago

I am using android arm64 emulator. Here is what happens: I patch arm64 code after several passes but patch is not applied, emulator keeps executing the old code. I dug deeper and found out that this problem is connected to unicorn translation cache, the old code gets cached. The same problem with mmap/munmap, when I do several cycles allocate/free memory with UnicornConst.UC_PROT_EXEC protection flag I get the same block with the same memory address and write my code to the memory block and it gets cached and any changes to the code does not affect the result - the code from previous mmap keeps executing. It seems to me that unidbg has to clear translation cache when mmap with UnicornConst.UC_PROT_EXEC gets called (via uc_ctl_remove_cache) and it would be good to have this method in the backend API to clear translation cache manually. Maybe there is a better solution I just don't know.

Thank you for unidbg, it is a great tool.

rasentry commented 2 years ago

Here guy has similar issue https://github.com/unicorn-engine/unicorn/issues/1561

zhkl0228 commented 2 years ago

Try to patch it before execution.

zhkl0228 commented 2 years ago

unidbg-api/src/main/java/com/github/unidbg/ModuleListener.java

rasentry commented 2 years ago

Try to patch it before execution.

It won't help. Application I deal with allocate memory via mmap writes code into it and executes it then do munmap and repeat cycle getting the same memory address and crushes because this time code is new but runs the old one from translation cache.

wtdcode commented 2 years ago

Try to patch it before execution.

It won't help. Application I deal with allocate memory via mmap writes code into it and executes it then do munmap and repeat cycle getting the same memory address and crushes because this time code is new but runs the old one from translation cache.

I just notice this thread. Your situation is slightly different from https://github.com/unicorn-engine/unicorn/issues/1561 and calling uc_ctl_remove_cache before execution should work for your case.