HikariObfuscator / Core

Shared Obfuscation Core
123 stars 46 forks source link

Switching over to HikariCore #4

Open woachk opened 4 years ago

woachk commented 4 years ago

Before switching over to https://github.com/HikariRebooted/HikariCore and pushing it as a part of the HikariObfuscator organisation, this repository should perhaps be renamed.

Naville commented 4 years ago

What do you mean though? Imma a bit confused. Current master of this repo already contains extra fixed unless you've manually ported them to Rebooted

Naville commented 4 years ago

Since technically this is still de facto Core with latest bug fixes and patches, IMO we should probably still treat it as one. Your fork could be integrated as a new sub-repo and use git submodule to reference stuffs in the real Core

Naville commented 4 years ago

For now the roadmap would be, IMHO:

These should do for LLVM9 while we are at it, the next step would be getting rid of the legacy pass, which involves fixing a bit known bugs here and there in the master

woachk commented 4 years ago

Hello, I manually ported over the fixes yesterday.

Reboot/HikariCore is not exactly the same source tree either because of compatibility concerns with newer LLVM.

Naville commented 4 years ago

@woachk Unless I'm misunderstanding here, probably 99% of the stuff in src/Passes is still the same as master. So what I mean here is change that directory to submodule and in Core's CMakeLists.txt, add something like:

option(BUILD_GENERIC_LOADER "Build Generic AppleClang Loader" OFF)
IF(BUILD_GENERIC_LOADER)
    add_compile_definitions(-DHIKARI_GENERIC_LOADER)
ENDIF()

and then update the master core into something like:

#ifdef HIKARI_GENERIC_LOADER
dosth()
#else
dosthelse()
#endif

This in theory allows us to spend the minimum effort on manually porting fixes while keep everything tidy, IMHO

Naville commented 4 years ago

Although I'm open to suggestions with a more detailed guide on what needs to be done on my side