highly experimental macOS hijacking for v8killer launcher

[Steve-xmh]

WARNING: Still very unstable and not-process-elegant :P

I assume that user have installed Xcode on their Mac computers which contains codesign for re-signing the target executable program. Then we copy the entire application bundle to a temporary direction to modify the program to hijacking v8killer. Then sign and run, that's it.

写英语好辛苦还是用中文再写一遍吧（雾）
反正现阶段我能实现的是对目标应用程序（通常是 App Bundle）拷贝到一个临时目录然后作注入和签名操作（这个过程也许可以被缓存？）最后再执行修改后的产物，理论上只要签名成功应该就可以被执行了。
然鹅现实很骨感（）
签名过程还是有问题，不过还是为了集思广益提前开这个草稿 PR ，我会把详细的情况发到评论里面，可以帮忙参考一下。

[Steve-xmh]

本人目前的执行流程（以 QQ 举例）：

     Running `/Users/stevexmh/Documents/programs/v8_killer/target/debug/v8_killer_launcher /Applications/QQ.app/Contents/MacOS/QQ`
[*] Executable: /Applications/QQ.app/Contents/MacOS/QQ
[*] Args: []
[*] Core lib path: /Users/stevexmh/Documents/programs/v8_killer/target/debug/libv8_killer_core.dylib
[*] creating executable temp path: "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI"
[*] executable is under a bundle: "/Applications/QQ.app"
[*] copying bundle to temp path: "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app"
[*] removing signature: "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app"
[*] removed signature: "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app"
[*] copying v8_killer to temp path: "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app/Contents/Frameworks/V8Killer.framework/libv8_killer_core.dylib"
[*] hijacking bundle executable...
[*] hijacking "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app/Contents/Frameworks/V8Killer.framework/libv8_killer_core.dylib" to "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app/Contents/MacOS/QQ"
[crates/insert_dylib/src/lib.rs:103:24] args = [
    "insert_dylib",
    "--all-yes",
    "--inplace",
    "--strip-codesig",
    "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app/Contents/Frameworks/V8Killer.framework/libv8_killer_core.dylib",
    "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app/Contents/MacOS/QQ",
]
[crates/insert_dylib/src/lib.rs:108:50] args.len() as c_int = 6
insert_dylib_main
Binary is a fat binary with 2 archs.
It doesn't seem like there is enough empty space. Continue anyway? [y/n] y
It doesn't seem like there is enough empty space. Continue anyway? [y/n] y
Added LC_LOAD_DYLIB to all archs in /var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app/Contents/MacOS/QQ
[crates/insert_dylib/src/lib.rs:108:18] unsafe { insert_dylib_main(dbg!(args.len() as c_int), args.as_ptr()) } = 0
[*] signing modified executable/dylib...
Executable=/Applications/QQ.app/Contents/MacOS/QQ
[*] signed: "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app/Contents/Frameworks/V8Killer.framework"
/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app: internal error in Code Signing subsystem
[*] failed to sign: "/var/folders/yz/gfxc6vfd04lg_h_j1kcgy39h0000gn/T/v8-killer-app-.jyvqYv6RduuI/QQ.app"
thread 'main' panicked at crates/launcher/src/lib.rs:290:55:
called `Result::unwrap()` on an `Err` value: "failed to sign"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[ShellWen]

Thank you very, very much for your efforts, but I think this is a PR I probably won't merge.

I think it's a very primitive solution and at the same time out of the focus of this project.
The direction I would suggest is to check if the target program has a code signature, and if it does (and can't be injected) then just report an error and exit (directing the user to manually patch using another program).

Thank you very much for your contribution and I look forward to your ideas.

[ShellWen]

Perhaps you could try moving this patch-related logic into a separate program.

[Steve-xmh]

Thank you very, very much for your efforts, but I think this is a PR I probably won't merge.

I think it's a very primitive solution and at the same time out of the focus of this project.
The direction I would suggest is to check if the target program has a code signature, and if it does (and can't be injected) then just report an error and exit (directing the user to manually patch using another program).

Thank you very much for your contribution and I look forward to your ideas.

If that is what your project was focus on, then there (almost) won't be any methods for the program that has been already signed to inject, and only the program that was compiled from user's computer can be able to inject the dynamic library.

And our situation is that all the programs we wanted to patch was always bundled in application bundle and all of them are signed.

[Steve-xmh]

Thank you very, very much for your efforts, but I think this is a PR I probably won't merge.

I think it's a very primitive solution and at the same time out of the focus of this project.
The direction I would suggest is to check if the target program has a code signature, and if it does (and can't be injected) then just report an error and exit (directing the user to manually patch using another program).

Thank you very much for your contribution and I look forward to your ideas.

Also, I have checked the error logging from the codesign that indicated that there's no more free space to add the sign signature section.

[ShellWen]

I mean, V8 Killer is more of a tool for developers than for end users.

[Steve-xmh]

I mean, V8 Killer is more of a tool for developers than for end users.

Well, so if just focus for developer then it will be okay to inject by setting environment variable or other convenience methods. I'll split the code only focus on just injecting V8 Killer.

[Steve-xmh]

I may have some other enhancements that can improve developer experience, but will be present on separate pull request or only my fork.

[ShellWen]

Before merging PRs, I would like to ask if there is an easy way to detect if the injection is successful or not? I mean, is it possible to show an error message to the user if the injection is unsuccessful due to codesign issues?

[ShellWen]

After completing all the tasks, please request a review from me. Thank you very much for your help.

[ShellWen]

It would be nice if you could add support for GitHub Actions on macOS, which I know next to nothing about.

[Steve-xmh]

Before merging PRs, I would like to ask if there is an easy way to detect if the injection is successful or not? I mean, is it possible to show an error message to the user if the injection is unsuccessful due to codesign issues?

AFAIK, programs that have signed or disabled dylib hijacking entitlement will simpily ignore the environment variable, or just failed to launch without any exit code. So you may have to implement a method that can let V8 Killer invoke to the launcher that the operation was succeed.

[Steve-xmh]

After completing all the tasks, please request a review from me. Thank you very much for your help.

I've modified CI workflow file with these changes:

• Removed dtolnay/rust-toolchain@stable job which is now useless as Github Action System Image are already have built-in stable version of Rust toolchain.
• Added compile target for x86_64-apple-darwin and aarch64-apple-darwin and merge the output into a fat mach-o executable program/dynamic library which can be an universal program for both Intel chip and Apple Silicon platform of macOS.

Here's a succeed job that you can check the artifacts and output: https://github.com/Steve-xmh/v8_killer/actions/runs/8128486657/job/22214430999

[Steve-xmh]

@ShellWen please have a review, thanks!

[ShellWen]

Before merging PRs, I would like to ask if there is an easy way to detect if the injection is successful or not? I mean, is it possible to show an error message to the user if the injection is unsuccessful due to codesign issues?

AFAIK, programs that have signed or disabled dylib hijacking entitlement will simpily ignore the environment variable, or just failed to launch without any exit code. So you may have to implement a method that can let V8 Killer invoke to the launcher that the operation was succeed.

I'm lazy to do that. So... It's Okay. 😇

[ShellWen]

lgtm

[ShellWen]

I'm so grateful. 🥰