rdbo / libmem

Advanced Game Hacking Library for C, Modern C++, Rust and Python (Windows/Linux/FreeBSD) (Process/Memory Hacking) (Hooking/Detouring) (Cross Platform) (x86/x64/ARM/ARM64) (DLL/SO Injection) (Internal/External) (Assembler/Disassembler)
GNU Affero General Public License v3.0
784 stars 91 forks source link

Find more lightweight alternatives to Keystone and LIEF (maybe Capstone too) #78

Closed rdbo closed 1 year ago

rdbo commented 1 year ago

Even though these libraries are pretty good they have size problems. LIEF is overwhelmingly big, having unnecessary bloated features like JSON support and even a TLS embedded client for some reason (???). Keystone would be perfect IF you could disable support for certain architectures, which would make it more lightweight (like with Capstone, which I disabled the unused archs). Unfortunately, this is not the case. Both of these libraries weigh +100M, which is way too big to be acceptable. Capstone is on the lighter size (still a bit big, but not even comparable to the other 2), weighing ~8MB. The point is, there should be lighter alternatives to minimize libmem's size.

rdbo commented 1 year ago

I also opened an issue some days ago on Keystone reporting this problem and still got no answer: https://github.com/keystone-engine/keystone/issues/545

The project seems to have stalled or something.

rdbo commented 1 year ago

Current library size status (release mode):

$ du -h libcapstone.a 
3.7M    libcapstone.a

$ du -h libkeystone.a 
60M     libkeystone.a

$ du -h libLIEF.a 
24M     libLIEF.a

As for libmem itself:

$ du -h libmem.so 
25M     libmem.so

Things are looking better, but I don't think it's possible to optimize this much further. The biggest library in use currently is Keystone, even though I found a way to disable unused architectures. If one were to find a replacement for it, this replacement would need to have base address resolution, like Keystone. For example, in x86 there are relative jumps, and Keystone allows you to pass the current address to the assembler and it automatically resolves the relative address, which is very convenient. Capstone does the same, but since it's not taking much space, I would consider leaving it in the project. LIEF is still an issue. Even though it's not the biggest library, 25M is still a large space just for symbol enumeration. Maybe I should get rid of it completely and reimplement my old symbol enumeration functions.

rdbo commented 1 year ago

There has been further improvements on how big libmem is. Currently, these are the sizes:

$ du -h libcapstone.a 
1.7M    libcapstone.a

$ du -h libkeystone.a 
4.8M    libkeystone.a

$ du -h libLIEF.a 
24M     libLIEF.a

$ du -h liblibmem.so 
7.5M    liblibmem.so

The size of libmem has gotten into the acceptable range, but LIEF is still a little too big; I will probably have to replace it. Since Capstone and Keystone are super small now, I don't think that will be necessary for them.

rdbo commented 1 year ago

I don't think this is necessary anymore. Capstone and Keystone are pretty small now. I don't think there's anything much better than LIEF