steven-michaud / hookcase Goto Github PK

Tool for reverse engineering macOS/OS X

C++ 81.37% C 5.42% Assembly 4.54% Makefile 0.45% Objective-C++ 8.22%

c-plus-plus objective-c-plus-plus kernel-modules macos macosx reverse-engineering assembly-language dyld mach-o

hookcase's Introduction

HookCase

HookCase is a tool for debugging and reverse engineering applications on macOS (aka OS X), and the operating system itself. It re-implements and extends Apple's DYLD_INSERT_LIBRARIES functionality. It can be used to hook any method in any module (even non-exported ones, and even those that don't have an entry in their own module's symbol table). In a single operation, it can be applied to a parent process and all its child processes, whether or not the child processes inherit their parent's environment. It supports watchpoints. So HookCase is considerably more powerful than DYLD_INSERT_LIBRARIES. It also doesn't have the restrictions Apple has placed on DYLD_INSERT_LIBRARIES. So, for example, HookCase can be used with applications that have entitlements. HookCase runs on OS X 10.9 (Mavericks) through macOS 14 (Sonoma).

Steven Michaud, 10/2023

hookcase's People

Contributors

Stargazers

Watchers

Forkers

theotherside olivierh59500 chaojianhu pyq881120 dbrumley 4ch12dy techlord-rce zhencang maurice-schuppe ang3ll caledoniaproject aonorin team-firebugs awesome-security tnt-wolve mikalv qinglong61 stonedreamforest dothanthitiendiettiende c0deh4xor geekonion cozmavladimir magicpriest cydia5530 jack51706 shuixi2013 pai-po n0ncetonic xjbevasion grospy tfr rastuszhang maxwellsun csanycall tchernicum sergvs pradorocchi fengjixuchui haidragon thongvm cduvenhorst pharazone doorxp githubismyresume attackgithub shinsonh acidburn0zzz wwxxyx junetou igit-cn st-rnd kernal-gh modulexcite d4tocchini n0thing2speak compmfm sushaoyu liuxuan30 lalospidey kingking888 kernelbk stevenchen1976 nicholaslin lgq2015 c128128 im-bill magicfuzzx shadowce lilang-wu re-expoc rocker9527 impost0r xcode2010 willingbug safe3 marcostolosa wxh841969240 andrewpedia gcclua scyclzy tyreldelton y11en dillatroit terminar spidy0x0 liuyi12138 dargonlee sagar19raorane panjiancai 5l1v3r1 samuel-zhan ouguochong spadexiu martinfx

hookcase's Issues

Dynamic Patch Hook on BigSur

Hello, I build HookCase, loaded kernel module. So I try dynamic-hooking example:

HC_INSERT_LIBRARY=......./HookCase/Examples/dynamic-hooking/hook.dylib /Applications/Safari.app/Contents/MacOS/Safari

And there is no log from hooks. So it looks like dynamic hook works with main function and should be called for any application, yes? What could be wrong here?

`reset_hook()` fails in interpose library when `caller` calls hooked function

Here's an example patch hook from the hook library template:

    int (*patch_example_caller)(char *arg1, int (*arg2)(char *)) = NULL;
    
    static int Hooked_patch_example(char *arg1, int (*arg2)(char *))
    {
      int retval = patch_example_caller(arg1, arg2);
      LogWithFormat(true, "Hook.mm: patch_example(): arg1 \"%s\", arg2 \'%p\', returning \'%i\'",
                    arg1, arg2, retval);
      PrintStackTrace();
      // Example of using add_patch_hook() to dynamically add a patch hook for
      // 'arg2'.
      add_patch_hook(reinterpret_cast<void*>(arg2),
                     reinterpret_cast<void*>(dynamic_patch_example));
      // Not always required, but using it when not required does no harm.
      reset_hook(reinterpret_cast<void*>(Hooked_patch_example));
      return retval;
    }

The bug is that, whenever patch_example_caller() indirectly calls a function that has also been hooked with a patch hook, reset_hook() doesn't work -- it doesn't re-hook patch_example_caller().

Most of the time this doesn't matter. Most functions have a standard prologue in machine code:

    push  %rbp
    mov   %rsp, %rbp

For patch hooks on these functions, the call to reset_hook() is in effect a no-op, and isn't necessary. But for functions without a standard prologue, not calling reset_hook() at the end of your patch hook means that the hook is only called once. The same applies if the call to reset_hook() fails.

It seems BigSur 11.3 broke HookCase

Hi,

kext is loaded but it's not working under BigSur 11.3 :(
I don't know how to debug this.
Please let me know if I can be of any help and thanks for your work.

$ /usr/bin/kmutil showloaded |grep -i hook
No variant specified, falling back to release
  175    0 0xffffff7f9b5c7000 0x11000    0x11000    org.smichaud.HookCase (5.0.2) ED3C0F6A-FECE-3942-B356-82CB8DAF4B1B <8 6 5 3 2 1>

$ sysctl -a | grep osrelease
kern.osrelease: 20.4.0

$ uname -r
20.4.0

I recently found that It shows error when I run the app

Application Specific Information:
dyld: launch, running initializers

Thread 0 Crashed:
0 libdyld.dylib 0x00007fff62af5f10 dyld3::dyld_get_image_versions(mach_header const*, void (unsigned int, unsigned int, unsigned int) block_pointer) + 30
1 libdyld.dylib 0x00007fff62af6429 dyld_get_active_platform + 51
2 libdyld.dylib 0x00007fff62af6d64 dlopen + 233
3 dyld 0x000000010ec7e69e dyld::getExecutablePath() + 13
4 dyld 0x000000010ec7d503 dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 1167
5 dyld 0x000000010ec7d036 _dyld_start + 54

macOS 10.14.5 kernel panics when using HC_INSERT_LIBRARY

The current version of HookCase (3.1) triggers a kernel panic on macOS 10.14.5 when you try to use HC_INSERT_LIBRARY to insert a hook library in any process. The HookCase kext does load, but the kernel panics the first time you try to use it (via HC_INSERT_LIBRARY). This behavior is new with macOS 10.4.5. It doesn't happen with earlier versions of Mojave (10.14), and doesn't happen even with the latest updates for High Sierra (10.13) and Sierra (10.12).

Shinvou reported this issue with a 10.14.5 beta (#8 (comment)). I'd hoped that it might get fixed in the 10.14.5 release, but apparently it hasn't.

I'll be working on this.

macOS 12.5 breaks HookCase

macOS 12.5, released today, triggers the following kernel panic when you try to load a hook library (for example the events example). HookCase 6.0.3 still works fine with macOS 11.6.8 build 20G730, also released today.

panic(cpu 2 caller 0xffffff80097d0773): Kernel trap at 0xffffff80096a1e63, type 13=general protection, registers:
CR0: 0x000000008001003b, CR2: 0xffffffbd913db000, CR3: 0x000000008d40b181, CR4: 0x00000000003606e0
RAX: 0x0000000110795000, RBX: 0x561c8d8400000008, RCX: 0xfffffff2809f4808, RDX: 0x0000000000000000
RSP: 0xfffffff2809f4750, RBP: 0xfffffff2809f4760, RSI: 0xffffff903aa161e0, RDI: 0x561c8d8400000008
R8:  0xffffff903aa161e0, R9:  0x0000000000000013, R10: 0xfffffffeef8428b7, R11: 0x00000000000003a7
R12: 0x561c8d8400000000, R13: 0x00000000000a8000, R14: 0xffffff96a1dadaa0, R15: 0xfffffff2809f4808
RFL: 0x0000000000010282, RIP: 0xffffff80096a1e63, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0xffffffbd913db000, Error code: 0x0000000000000000, Fault CPU: 0x2 VMM, PL: 0, VF: 0

Panicked task 0xffffffa03e6ee380: 1 threads: pid 94749: Safari
Backtrace (CPU 2), panicked thread: 0xffffff96a1dadaa0, Frame : Return Address
0xffffff800950d170 : 0xffffff800967fd6d mach_kernel : _handle_debugger_trap + 0x41d
0xffffff800950d1c0 : 0xffffff80097e1016 mach_kernel : _kdp_i386_trap + 0x116
0xffffff800950d200 : 0xffffff80097d0383 mach_kernel : _kernel_trap + 0x4d3
0xffffff800950d250 : 0xffffff800961fa70 mach_kernel : _return_from_trap + 0xe0
0xffffff800950d270 : 0xffffff800968013d mach_kernel : _DebuggerTrapWithState + 0xad
0xffffff800950d390 : 0xffffff800967f8f6 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffff800950d3f0 : 0xffffff8009f14d93 mach_kernel : _panic + 0x84
0xffffff800950d4e0 : 0xffffff80097d0773 mach_kernel : _sync_iss_to_iks + 0x2c3
0xffffff800950d660 : 0xffffff80097d0456 mach_kernel : _kernel_trap + 0x5a6
0xffffff800950d6b0 : 0xffffff800961fa70 mach_kernel : _return_from_trap + 0xe0
0xffffff800950d6d0 : 0xffffff80096a1e63 mach_kernel : _IORWLockWrite + 0x13
0xfffffff2809f4760 : 0xffffff7fa37f06c6 org.smichaud.HookCase : __Z31user_region_codesigned_iteratorP8ipc_portP12vm_map_entryjPv + 0x49
0xfffffff2809f47a0 : 0xffffff7fa37ed6ee org.smichaud.HookCase : __Z22vm_map_iterate_entriesP8ipc_portyyPFvS0_P12vm_map_entryjPvES3_ + 0x150
0xfffffff2809f47f0 : 0xffffff7fa37edcec org.smichaud.HookCase : __Z22user_region_codesignedP8ipc_portyy + 0x59
0xfffffff2809f4830 : 0xffffff7fa37eda7f org.smichaud.HookCase : __Z12proc_copyoutP8ipc_portPKvym + 0x102
0xfffffff2809f48f0 : 0xffffff7fa37f2d56 org.smichaud.HookCase : __Z15maybe_cast_hookP4proc + 0x652
0xfffffff2809f5e20 : 0xffffff7fa37f7317 org.smichaud.HookCase : __Z28thread_bootstrap_return_hookP17x86_saved_state_tP10_kern_hook + 0xa8
0xfffffff2809f5e70 : 0xffffff7fa37e89b5 org.smichaud.HookCase : _kernel_trampoline + 0x25
0xfffffff2809f5fa0 : 0xffffff800961f19e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         org.smichaud.HookCase(6.0.3)[7F4FF788-ABC4-37C3-B850-5ED53A7EC2CB]@0xffffff7fa37e8000->0xffffff7fa37f9fff

Process name corresponding to current thread (0xffffff96a1dadaa0): Safari
Boot args: keepsyms=1 kernel_stack_pages=6

Error in "sudo kmutil load -p /usr/local/sbin/HookCase.kext" macOS Big Sur 11.6.1

HookCase doesn't (yet) support macOS 12

Hi, Steven

Error Domain=KMErrorDomain Code=30 "Validating extension failed: Kext org.smichaud.HookCase v5.0.5 in executable kext bundle org.smichaud.HookCase at HookCase/HookCase/build/Release/HookCase.kext:

Could you try HookCase on macOS 12? Thanks

LogWithFormat() displays some strings incorrectly

LogWithFormat() in the hook library template can display strings incorrectly that contain characters with different encodings. Sometimes it fails to display any part of the string. This happens when the first "preferred language" in the Language & Region pref panel doesn't use the kCFStringEncodingMacRoman string encoding -- in other words, when that language doesn't use a Latin script. Examples are Russian, Greek and Chinese.

The cause is a bug or design flaw in the CFStringCreateWithFormatAndArguments() function used by LogWithFormatV(): Unlike similar functions (for example CFStringCreateWithCString() and CFStringGetBytes()), it doesn't allow you to specify a string encoding. Instead it always uses the string encoding associated with the "preferred language".

For languages that use Latin scripts, this is always kCFStringEncodingMacRoman. This encoding can handle strings that combine characters from many different encodings, and is in fact used by macOS itself at the most basic level (the LC_C_LOCALE). But the encodings associated with languages that use non-Latin scripts are specific to a particular language, and generally don't allow you to add characters to a string from any other encoding system.

Some apps were frozen

for example: (https://apps.apple.com/cn/app/qq/id451108668?mt=12). When I login my account and do noting for a while. It will be unresponsive. Even I Force kill the app and run it again. The only way is reboot the OS.
The kext is loaded and QQ does not load any other dylib. tested in Macos 10.15.7 and 11.2

not Found private symbol "_proc_lock" and "_proc_unlock" On Intel hardware for MacOS 12.5

kernel_dlsym("_proc_lock")

kernel_dlsym("_proc_unlock")

return NULL;

HookCase can miss a process that was launched using execv()

I find this while testing sh script file.
For example, if I run a sh file by bash test.sh, the calling relation will be like:

inject dylib into bash
bash fork and exec other file
inject dylib into other file

But when I use sh test.sh, the calling relation will be like:

inject dylib into sh
sh exec bash (no fork)
bash fork and exec other file
inject dylib into other file

the child process will be injected but the sh process will not be injected.
I also verified this by calling exec without fork in a demo.
I think mybe HookCase only inject a process when it create, but use exec can escape it.

We can't hook some modules' methods

Thinking about process_hook_rising() and process_hook_falling(), I realized there's a problem:
As things now stand, modules can get loaded without our having a chance to set hooks in them.

In process_hook_rising() we set up a call to dyld::runInitializers() to run the hook library's C++ initializers after we return to user space. And later (in process_hook_falling()) we set up a call to _dyld_register_func_for_add_image() to register a callback that tells us when a new module is loaded. But if any of the hook library's C++ initializers (or those of its dependencies) call dlopen(), they may load modules that our callback never sees (since it hasn't been registered yet).

The solution, I think, is to consolidate process_hook_rising() and process_hook_falling() into a single method -- process_hook_flying(). We'll also need to replace hook_state_rising and hook_state_falling with a single state -- hook_state_flying. We'll lose the ability to run our hook library's C++ initializers separately, before those of the main executable. But as best I can tell that doesn't matter.

The hook library's C++ initializers (and those of its dependencies) will now run from dyld::initializeMainExecutable(), mixed in with those of the main executable. This might result in the hook library's C++ initializers running a little later. But its dependencies will mostly also be dependencies of the main executable. So mostly it should make no difference.

I'm about to land a patch that fixes this problem.

Problems with interpose hooks

I hooked preview with the code, and log the pdf operation(open close)
INTERPOSE_FUNCTION(open),
INTERPOSE_FUNCTION(read),
INTERPOSE_FUNCTION(write),
INTERPOSE_FUNCTION(close),
INTERPOSE_FUNCTION(mmap),
INTERPOSE_FUNCTION(msync),
INTERPOSE_FUNCTION(munmap),
...
It works well in macOS10.15.7 when I open a pdf file. The logs like these
open pdf.file fd:10
close fd:10
open pdf.file fd:10
close fd:10
open pdf.file fd:10
mmap fd:10 offset:xxx len:xxx
close fd:10

I copy the Preview.app and my dylib to macOS11.1(avoid different version). It doesn't work. the logs like these
open pdf.file fd:10
close fd:10

Weirdness hooking calls to `open()` in terminal apps

hook lib

int Hooked_open(const char *path, int flags, ...)
{
    int ret;
    int mode = 0;

    if (flags & O_CREAT) {
        va_list ap;
        va_start(ap, flags);
        mode = va_arg(ap, int);
        va_end(ap);
    }

    ret = open(path, flags, mode);
    LogWithFormat(true, "[open](%s, 0x%x)-->%d", path, flags, ret);
    
    return ret;
}

INTERPOSE_FUNCTION(open),

command

HC_INSERT_LIBRARY=/path/to/hook.dylib  /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal

Patch Hook for sub_123abc Not Working

First of all, I'd like to say this is an impressive project (even though I don't understand half the code).

So I am trying to insert a hook into the Spotify app so I can keep track of what songs I skip. In IDA, I found the procedure that handles the media control keys. I found that the code is identical to that in https://github.com/nevyn/SPMediaKeyTap so I was able to obtain the function signature.

I basically copy and pasted your template library and added the following code to hook the desired, unnamed procedure:

#define PARAM_SIGNATURE CGEventTapProxy proxy, \
                        CGEventType type, \
                        CGEventRef event, \
                        void *refcon

int (*sub_10010C230_caller)(PARAM_SIGNATURE) = NULL;

static int Hooked_sub_10010C230(PARAM_SIGNATURE)
{
    LogWithFormat(true, "HERE!");
    int retval = sub_10010C230_caller(proxy, type, event, refcon);

    reset_hook(reinterpret_cast<void*>(Hooked_sub_10010C230));
    return retval;
}

However, when I run with HC_INSERT_LIBRARY=skiphook.dylib /Applications/Spotify.app/Contents/MacOS/Spotify, I get no output when using the media control keys.

The only thing I can think of is that this procedure is passed as a callback, so it presumably runs on not the main thread. Would this affect the hook?

32-bit hook libraries sometimes fail to build on macOS 10.14

Up to the present, all hook libraries included with HookCase are built with 32-bit and 64-bit code combined into a single binary. But sometimes the 32-bit parts of these builds fail on macOS Mojave, usually with error messages about missing include files. The underlying reason for this is that Apple is trying to make it difficult to do any building from the command line. By default, installing XCode, or even its command line tools, doesn't install all the files needed for building from the command line. For example /usr/include is missing.

The standard workaround for this is to install a package that comes with XCode, but gets hidden away in the /Library/Developer/CommandLineTools/Packages directory:

    installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /

Note that you need to do this again with each new version of XCode. For more information see https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja.

Apple has of course deprecated 32-bit apps, and will be removing support for them. And, though Apple claims that macOS Mojave still supports 32-bit apps fully, I don't know of any that work there. For example TextWrangler doesn't. So I no longer think there's much point in HookCase continuing to support 32-bit hook libraries on Mojave (and above). I've created a patch to all the hook library Makefiles for HookCase's hook library examples, which removes support for 32-bit builds on Mojave and above. I'm about to land it.

HookCase and macOS 10.14.4

Hi Steven,

can you confirm that this extension works as expected on the latest version of macOS 10.14.4? For me the kext loads as expected but when injecting processes - the process won't start.

Thanks in advance.

Patch hooks at numerical addresses don't work in the main executable

Version 2 of HookCase allows you to set a patch hook at a numerical address by specifying the hexadecimal address in the function's name. For example, you can use the name sub_123abc() to set a patch hook at offset 0x123abc in a given module.

But, as reported by zhaoyeming (#3 (comment)), this doesn't work for functions in the main executable.

Here's the problem:

In a Mach-O binary file of a main executable, all symbol addresses are offsets from the beginning of the PAGEZERO segment. But once the main executable is loaded into memory, the symbol addresses all become offsets from the beginning of the Mach-O header. So all their addresses (relative to the beginning of the loaded image's Mach-O header) get decremented by the size of the PAGEZERO segment.

When you use 'nm' or a disassembler to get the address of a function in a main executable, it will be "too big". But it isn't fair to ask users to figure this out on their own. So HookCase will need a patch to take care of this problem "automatically". I'm working on it, and should be able to land the patch in the next day or two.

how can i hook unexported functions?

cydiasbustrate can hook function by address, mshookfunction(modulebase + offset, proxy_func, stub_func). plz tell me how can i hook a function by address?

macOS 12.1 (build 21C52) breaks HookCase

The HookCase kernel extension loads correctly (using kmutil load -p /usr/local/sbin/HookCase.kext). But then no logging works. (I tried the events and xpcproxy examples, with Safari and Firefox.) Probably no hooks are being created.

It makes no difference whether SIP is on (csrutil enable --without kext) or off (csrutil disable).

Apple released other updates at the same time (macOS 11.6.2 build 20G314 and macOS 10.15.7 build 19H1615). Neither of these breaks HookCase. I suspect Apple has changed one of the kernel structures (on macOS 12.1) used internally by HookCase.

I'll be working on this.

Is it possible to PATCH_HOOK a function inside an executable instead of a shared lib?

I don't understand the internals, but from my tests it seems it does not work for functions inside executable. It complains that the module is not loaded in process.
Thanks!

Unsupported architecture Apple Silicon M1

Would it be possible to add such support?

macOS 10.15.7 build 19H2026 breaks HookCase

On macOS 10.15.7 build 19H2026, released today, HookCase fails to load with the following error. There are no problems on any of the earlier builds of macOS 10.15.7 (build 19H1922 and prior).

sudo kextutil /usr/local/sbin/HookCase.kext 
Password:
Kext with invalid signature (-67062) allowed: <OSKext 0x7fe9ed436a40 [0x7fff864dcce0]> { URL = "file:///usr/local/sbin/HookCase.kext/", ID = "org.smichaud.HookCase" }
Code Signing Failure: not code signed
Disabling KextAudit: SIP is off
(kernel) kxld[org.smichaud.HookCase]: The following symbols were defined more than once:
(kernel) kxld[org.smichaud.HookCase]: 	_mac_vnode_check_open: 0xffffff7f89246330 - 0xffffff8006eac830
(kernel) Can't load kext org.smichaud.HookCase - link failed.
(kernel) Failed to load executable for kext org.smichaud.HookCase.
(kernel) Kext org.smichaud.HookCase failed to load (0xdc008016).
(kernel) Failed to load kext org.smichaud.HookCase (error 0xdc008016).
Failed to load /usr/local/sbin/HookCase.kext - (libkern/kext) link error.
Check library declarations for your kext with kextlibs(8).

Intermittent double fault kernel panics

panic(cpu 4 caller 0xffffff800ffcfa67): Double fault at 0xffffff800ffc3424, registers:
CR0: 0x000000008001003b, CR2: 0xffffffcb3eedfff8, CR3: 0x000000000e6f51d5, CR4: 0x00000000003626e0
RAX: 0x0000000000000001, RBX: 0x0000000000000000, RCX: 0x0000000000000001, RDX: 0x0000000000011bed
RSP: 0xffffffcb3eee0000, RBP: 0xffffffcb3eee0000, RSI: 0xffffffb0c0837000, RDI: 0xffffffa02cbcb010
R8:  0xffffff800ffc3390, R9:  0xffffffcb3eee0290, R10: 0xffffffcb3eee02b8, R11: 0xffffff8b636e9230
R12: 0x0400000000000000, R13: 0xffffffb0c0837000, R14: 0x0000000000011bed, R15: 0x0000000000000000
RFL: 0x0000000000010246, RIP: 0xffffff800ffc3424, CS:  0x0000000000000008, SS:  0x0000000000000000
Error code: 0x0000000000000000
 @trap_native.c:168
Panicked task 0xffffff902a3ab380: 1 threads: pid 1729: stat
Backtrace (CPU 4), panicked thread: 0xffffff8b5fb40000, Frame : Return Address
0xffffff800fd0e240 : 0xffffff800fe7cead mach_kernel : _handle_debugger_trap + 0x41d
0xffffff800fd0e290 : 0xffffff800ffdf5d6 mach_kernel : _kdp_i386_trap + 0x116
0xffffff800fd0e2d0 : 0xffffff800ffce943 mach_kernel : _kernel_trap + 0x4d3
0xffffff800fd0e320 : 0xffffff800fe1ca70 mach_kernel : _return_from_trap + 0xe0
0xffffff800fd0e340 : 0xffffff800fe7d27d mach_kernel : _DebuggerTrapWithState + 0xad
0xffffff800fd0e460 : 0xffffff800fe7ca36 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffff800fd0e4c0 : 0xffffff8010714ed3 mach_kernel : _panic + 0x84
0xffffff800fd0e5b0 : 0xffffff800ffcfa67 mach_kernel : _sync_iss_to_iks_unconditionally + 0x167
0xffffff800fd0e6c0 : 0xffffff801071ccb8 mach_kernel : _panic_double_fault64 + 0x27
0xffffff800fd0e6d0 : 0xffffff800fe1d2ef mach_kernel : _hndl_double_fault + 0xf
0xffffffcb3eee0000 : 0xffffff8012a4aaf6 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD10space_freeEP9vtd_spacejj + 0x44
0xffffffcb3eee0040 : 0xffffff8012a4a724 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD9checkFreeEP9vtd_spacej + 0xca
0xffffffcb3eee0080 : 0xffffff8012a4a1a7 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD11space_allocEP9vtd_spacejjjPK21IODMAMapSpecificationPK13upl_page_info + 0x125
0xffffffcb3eee0120 : 0xffffff8012a4cbc9 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD14spaceMapMemoryEP9vtd_spaceP18IOMemoryDescriptoryyjPK21IODMAMapSpecificationP12IODMACommandPK16IODMAMapPageListPySC_ + 0x23b
0xffffffcb3eee0220 : 0xffffff8012a4d157 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD13iovmMapMemoryEP18IOMemoryDescriptoryyjPK21IODMAMapSpecificationP12IODMACommandPK16IODMAMapPageListPySA_ + 0x43
0xffffffcb3eee0260 : 0xffffff801065bdbf mach_kernel : __ZN25IOGeneralMemoryDescriptor6dmaMapEP8IOMapperP18IOMemoryDescriptorP12IODMACommandPK21IODMAMapSpecificationyyPyS9_ + 0x1df
0xffffffcb3eee02f0 : 0xffffff8010657713 mach_kernel : __ZNK25IOGeneralMemoryDescriptor19dmaCommandOperationEjPvj + 0x463
0xffffffcb3eee03a0 : 0xffffff8010657dba mach_kernel : __ZN25IOGeneralMemoryDescriptor18getPhysicalSegmentEyPyj + 0x1da
0xffffffcb3eee0480 : 0xffffff801065b63c mach_kernel : __ZN18IOMemoryDescriptor26ktraceEmitPhysicalSegmentsEv + 0x2ac
0xffffffcb3eee0530 : 0xffffff8010658163 mach_kernel : __ZN25IOGeneralMemoryDescriptor7prepareEj + 0x103
0xffffffcb3eee0560 : 0xffffff8012b8a462 com.apple.iokit.IOStorageFamily : __ZL11dkreadwritePv9dkrtype_t + 0x44a
0xffffffcb3eee0620 : 0xffffff8010168468 mach_kernel : _spec_strategy + 0x448
0xffffffcb3eee0680 : 0xffffff801015eb92 mach_kernel : _VNOP_STRATEGY + 0x42
0xffffffcb3eee06c0 : 0xffffff8013110e07 com.apple.filesystems.apfs : _nx_bio_doread + 0x1b5
0xffffffcb3eee0710 : 0xffffff8013110871 com.apple.filesystems.apfs : __vnode_dev_read + 0x2a5
0xffffffcb3eee07a0 : 0xffffff801310f562 com.apple.filesystems.apfs : _vnode_dev_read + 0x15
0xffffffcb3eee07c0 : 0xffffff801322a9cc com.apple.filesystems.apfs : _obj_read + 0x16a
0xffffffcb3eee0810 : 0xffffff8013229c2d com.apple.filesystems.apfs : _obj_get + 0x76d
0xffffffcb3eee0930 : 0xffffff8013201095 com.apple.filesystems.apfs : _btree_node_get_internal + 0x1a3
0xffffffcb3eee0a20 : 0xffffff8013200ee3 com.apple.filesystems.apfs : _btree_node_get + 0x76
0xffffffcb3eee0aa0 : 0xffffff801320b91e com.apple.filesystems.apfs : __bt_lookup_variant + 0x3c4
0xffffffcb3eee0bc0 : 0xffffff80131f5bb9 com.apple.filesystems.apfs : _tree_lookup_le + 0x2c
0xffffffcb3eee0bf0 : 0xffffff80131c733a com.apple.filesystems.apfs : _lookup_file_extent + 0x233
0xffffffcb3eee0c90 : 0xffffff801314b7dc com.apple.filesystems.apfs : _apfs_vnop_blockmap + 0xbd5
0xffffffcb3eee0df0 : 0xffffff801015eaf1 mach_kernel : _VNOP_BLOCKMAP + 0xf1
0xffffffcb3eee0e80 : 0xffffff8010109a75 mach_kernel : _cluster_pageout_ext + 0x875
0xffffffcb3eee1000 : 0xffffff8010110898 mach_kernel : _cluster_read_ext + 0xf08
0xffffffcb3eee11e0 : 0xffffff801010fb04 mach_kernel : _cluster_read_ext + 0x174
0xffffffcb3eee1250 : 0xffffff80131569a4 com.apple.filesystems.apfs : _apfs_nstream_read + 0x295
0xffffffcb3eee1320 : 0xffffff801315791c com.apple.filesystems.apfs : _apfs_inode_getxattr + 0x1a7
0xffffffcb3eee1400 : 0xffffff801315776a com.apple.filesystems.apfs : _apfs_vnop_getxattr + 0xa3
0xffffffcb3eee1430 : 0xffffff801015e5ca mach_kernel : _VNOP_GETXATTR + 0x5a
0xffffffcb3eee14a0 : 0xffffff80113f1e5b com.apple.AppleFSCompression.AppleFSCompressionTypeZlib : _compression_decode_buffer + 0xc3d
0xffffffcb3eee1500 : 0xffffff80113f21ae com.apple.AppleFSCompression.AppleFSCompressionTypeZlib : _compression_decode_buffer + 0xf90
0xffffffcb3eee15c0 : 0xffffff80113f1b25 com.apple.AppleFSCompression.AppleFSCompressionTypeZlib : _compression_decode_buffer + 0x907
0xffffffcb3eee1650 : 0xffffff8010172e0e mach_kernel : _decmpfs_pagein_compressed + 0x83e
0xffffffcb3eee17d0 : 0xffffff801317314b com.apple.filesystems.apfs : _apfs_pagein_with_verification + 0x386
0xffffffcb3eee1900 : 0xffffff8013172c4d com.apple.filesystems.apfs : _apfs_pagein + 0x816
0xffffffcb3eee1a00 : 0xffffff80104fa4b9 mach_kernel : _vnode_pagein + 0x689
0xffffffcb3eee1b00 : 0xffffff800ff10878 mach_kernel : _vnode_pager_cluster_read + 0x48
0xffffffcb3eee1b60 : 0xffffff800ff259e3 mach_kernel : _vm_fault_page + 0x963
0xffffffcb3eee1c80 : 0xffffff800ff21604 mach_kernel : _vm_fault$XNU_INTERNAL + 0x16e4
0xffffffcb3eee1f10 : 0xffffff800ffce6de mach_kernel : _kernel_trap + 0x26e
0xffffffcb3eee1f80 : 0xffffff800fe1ca70 mach_kernel : _return_from_trap + 0xe0
0xffffffcb3eee1fa0 : 0xffffff800fe1bdeb mach_kernel : __bcopy + 0xb
0xffffffcb3eee2120 : 0xffffff800ff2d8a3 mach_kernel : _kmem_free + 0x183
0xffffffcb3eee2160 : 0xffffff800ff3ff6e mach_kernel : _vm_map_copyin_internal + 0x18e
0xffffffcb3eee2270 : 0xffffff7fa9fe1918 org.smichaud.HookCase.kext : __Z15get_module_infoP4procPKcyP12_module_info + 0x778
0xffffffcb3eee3830 : 0xffffff7fa9fe69db org.smichaud.HookCase.kext : __Z15maybe_cast_hookP4proc + 0x64b
0xffffffcb3eee5dd0 : 0xffffff7fa9feeedb org.smichaud.HookCase.kext : __Z28thread_bootstrap_return_hookP17x86_saved_state_tP10_kern_hook + 0xbb
0xffffffcb3eee5e10 : 0xffffff7fa9fe52cb org.smichaud.HookCase.kext : __Z12do_kern_hookP17x86_saved_state_t + 0xcb
0xffffffcb3eee5e50 : 0xffffff7fa9ff1785 org.smichaud.HookCase.kext : _handle_kernel_hc_int1 + 0x15
0xffffffcb3eee5e70 : 0xffffff7fa9fd34f5 org.smichaud.HookCase.kext : _kernel_trampoline + 0x25
0xffffffcb3eee5fa0 : 0xffffff800fe1c19e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         com.apple.iokit.IOPCIFamily(2.9)[27B9FAE8-483C-3208-B216-3133690B25AC]@0xffffff8012a36000->0xffffff8012a62fff
         com.apple.iokit.IOStorageFamily(2.1)[9911895E-CCD2-3899-AB5C-D500919F59AA]@0xffffff8012b7b000->0xffffff8012b91fff
         com.apple.filesystems.apfs(1934.141.2)[2C7FD87C-9D3C-3B49-BB05-4B0EAC7A1183]@0xffffff801310b000->0xffffff8013289fff
            dependency: com.apple.driver.AppleEFINVRAM(2.1)[5886368A-14F0-320E-8427-C8EB472E76B7]@0xffffff80113b2000->0xffffff80113bbfff
            dependency: com.apple.driver.AppleEffaceableStorage(1.0)[DED354B0-1079-3746-90DC-DDF419DEA2D4]@0xffffff80113c8000->0xffffff80113cdfff
            dependency: com.apple.iokit.CoreAnalyticsFamily(1)[D9B274C7-317C-3CA7-B51B-F6F60AABBBD5]@0xffffff80118d3000->0xffffff80118dafff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[9911895E-CCD2-3899-AB5C-D500919F59AA]@0xffffff8012b7b000->0xffffff8012b91fff
            dependency: com.apple.kec.corecrypto(12.0)[D5F1BD46-6F9D-3F71-982E-15DA8EDA4FC1]@0xffffff80132c3000->0xffffff8013343fff
            dependency: com.apple.security.AppleImage4(4.2.0)[57D034A4-4514-3C5F-90ED-F0CA0199E865]@0xffffff801144f000->0xffffff8011467fff

Process name corresponding to current thread (0xffffff8b5fb40000): stat
Boot args: keepsyms=1 kernel_stack_pages=6  chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
21G320

Kernel version:
Darwin Kernel Version 21.6.0: Sun Nov  6 23:31:16 PST 2022; root:xnu-8020.240.14~1/RELEASE_X86_64
Kernel UUID: F831C932-31CA-3F2C-9E4C-2304C5641587
KernelCache slide: 0x000000000fc00000
KernelCache base:  0xffffff800fe00000
Kernel slide:      0x000000000fc10000
Kernel text base:  0xffffff800fe10000
__HIB  text base: 0xffffff800fd00000
System model name: MacBookPro15,2 (Mac-827FB448E656EC26)
System shutdown begun: NO
Hibernation exit count: 0

System uptime in nanoseconds: 1691739115792
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x00000189e38253cf
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x00000009bcbf4432 0x0000000000000000
Compressor Info: 2% of compressed pages limit (OK) and 2% of segments limit (OK) with 1 swapfiles and OK swap space
Zone info:
  Zone map: 0xffffff802cc39000 - 0xffffffa02cc39000
  . PGZ   : 0xffffff802cc39000 - 0xffffff802dc3a000
  . VM    : 0xffffff802dc3a000 - 0xffffff84fa6a0000
  . RO    : 0xffffff84fa6a0000 - 0xffffff8693f6c000
  . GEN0  : 0xffffff8693f6c000 - 0xffffff8b609d2000
  . GEN1  : 0xffffff8b609d2000 - 0xffffff902d438000
  . GEN2  : 0xffffff902d438000 - 0xffffff94f9e9e000
  . GEN3  : 0xffffff94f9e9e000 - 0xffffff99c6905000
  . DATA  : 0xffffff99c6905000 - 0xffffffa02cc39000
  Metadata: 0xffffffb099689000 - 0xffffffb0b9689000
  Bitmaps : 0xffffffb0b9689000 - 0xffffffb0bc689000

last started kext at 740128815770: org.smichaud.HookCase.kext	7.1.0 (addr 0xffffff7fa9fd2000, size 135168)
loaded kexts:
org.smichaud.HookCase.kext	7.1.0
@filesystems.smbfs	4.0
>AGPM	129
>!APlatformEnabler	2.7.0d0
>X86PlatformShim	1.0.0
@filesystems.autofs	3.0
>!ATopCaseHIDEventDriver	5450.8
>!AHIDALSService	1
>!AUpstreamUserClient	3.6.9
>!A!IKBLGraphics	18.0.8
>!AGraphicsDevicePolicy	6.5.7
>!AGFXHDA	140.3
@AGDCPluginDisplayMetrics	6.5.7
>!ABridgeAudio!C	240.6
>pmtelemetry	1
|IOUserEthernet	1.0.1
>usb.!UUserHCI	1
>AGDCBacklightControl	6.5.7
>!ABacklight	180.8
>!AMCCSControl	1.16
>!AFIVRDriver	4.1.0
>ACPI_SMC_PlatformPlugin	1.0.0
>!A!ICFLGraphicsFramebuffer	18.0.8
>BridgeAudioCommunication	240.6
>!AAVEBridge	6.1
>!AHV	1
>!ADiskImages2	126.141.2
>!A!IPCHPMC	2.0.1
>!A!ISlowAdaptiveClocking	4.0.0
>!AThunderboltIP	4.0.3
@UVCService	1
|SCSITaskUserClient	456.140.3
>BCMWLANFirmware4387.Hashstore	1
>BCMWLANFirmware4378.Hashstore	1
>BCMWLANFirmware4377.Hashstore	1
>BCMWLANFirmware4364.Hashstore	1
>BCMWLANFirmware4355.Hashstore	1
>!AFileSystemDriver	3.0.1
@filesystems.tmpfs	1
@filesystems.lifs	1
@filesystems.hfs.kext	583.100.10
@BootCache	40
@!AFSCompression.!AFSCompressionTypeZlib	1.0.0
@!AFSCompression.!AFSCompressionTypeDataless	1.0.0d1
@filesystems.apfs	1934.141.2
>!ABCMWLANBusInterfacePCIeMac	1
@private.KextAudit	1.0
>!ASmartBatteryManager	161.0.0
>!AACPIButtons	6.1
>!ASMBIOS	2.1
>!AACPIEC	6.1
>!AAPIC	1.7
@!ASystemPolicy	2.0.0
@nke.applicationfirewall	402
|IOKitRegistryCompatibility	1
|EndpointSecurity	1
@Dont_Steal_Mac_OS_X	7.0.0
@kec.!AEncryptedArchive	1
>driverkit.serial	6.0.0
@kext.triggers	1.0
>!AHIDKeyboard	228.2
>!AActuatorDriver	5460.1
>!AMultitouchDriver	5460.1
>!AInputDeviceSupport	5460.1
>!AHS!BDriver	5450.8
>IO!BHIDDriver	9.0.0
>!AGraphicsControl	6.5.7
>!AHDA!C	340.2
|IOHDA!F	340.2
>!A!ILpssUARTv1	3.0.60
>!A!ILpssUARTCommon	3.0.60
>!AOnboardSerial	1.0
>!UAudio	416.2
|IOAudio!F	340.2
@vecLib.kext	1.2.0
>!AAudioClockLibs	140.1
|IO!BSerialManager	9.0.0
|IO!BPacketLogger	9.0.0
|IO!BHost!CUSBTransport	9.0.0
|IO!BHost!CUARTTransport	9.0.0
>!ABacklightExpert	1.1.0
|IONDRVSupport	597
>!ASMBus!C	1.0.18d1
>!ASMBusPCI	1.0.14d1
>IOPlatformPluginLegacy	1.0.0
>X86PlatformPlugin	1.0.0
|IO!BHost!CTransport	9.0.0
>IO!BHost!CPCIeTransport	9.0.0
|IOAccelerator!F2	462.8
|IOAVB!F	1040.6
@plugin.IOgPTPPlugin	1040.3
|IOEthernetAVB!C	1.1.0
|CSR!BHost!CUSBTransport	9.0.0
|Broadcom!BHost!CUSBTransport	9.0.0
|Broadcom!B20703USBTransport	9.0.0
>!AIPAppender	1.0
>IOPlatformPlugin!F	6.0.0d8
@!AGPUWrangler	6.5.7
@!AGraphicsDeviceControl	6.5.7
|IOGraphics!F	597
|IOSlowAdaptiveClocking!F	1.0.0
>!AThunderboltEDMSink	5.0.3
>!AThunderboltDPOutAdapter	8.5.1
>usb.IOUSBHostHIDDevice	1.2
>usb.cdc.ecm	5.0.0
>usb.cdc.ncm	5.0.0
>usb.!UHub	1.2
>usb.cdc	5.0.0
>usb.networking	5.0.0
>usb.!UHostCompositeDevice	1.2
>!AThunderboltPCIDownAdapter	4.1.1
>!AThunderboltDPInAdapter	8.5.1
>!AThunderboltDPAdapter!F	8.5.1
>!AHPM	3.4.4
>!A!ILpssI2C!C	3.0.60
>!A!ILpssDmac	3.0.60
>!ABSDKextStarter	3
|IOSurface	302.14
@filesystems.hfs.encodings.kext	1
>!AXsanScheme	3
>!AThunderboltNHI	7.2.81
|IOThunderbolt!F	9.3.3
>usb.!UVHCIBCE	1.2
>usb.!UVHCICommonBCE	1.0
>usb.!UVHCI	1.2
>usb.!UVHCICommon	1.0
>!AEffaceableNOR	1.0
|IOBufferCopy!C	1.1.0
|IOBufferCopyEngine!F	1
|IONVMe!F	2.1.0
>!ABCMWLANCoreMac	1.0.0
|IOSerial!F	11
|IO80211!F	1200.12.2b2
|IOSkywalk!F	1.0
>mDNSOffloadUserClient	1.0.1b8
>IOImageLoader	1.0.0
>!AOLYHALMac	1
>corecapture	1.0.4
>usb.!UHostPacketFilter	1.0
|IOUSB!F	900.4.2
>!A!ILpssI2C	3.0.60
>!A!ILpssGspi	3.0.60
>usb.!UXHCIPCI	1.2
>usb.!UXHCI	1.2
>!AEFINVRAM	2.1
>!AEFIRuntime	2.1
>!ASMCRTC	1.0
|IOSMBus!F	1.1
|IOHID!F	2.0.0
|IOTimeSync!F	1040.3
|IONetworking!F	3.4
>DiskImages	493.0.0
|IO!B!F	9.0.0
|IOReport!F	47
$quarantine	4
$sandbox	300.0
@kext.!AMatch	1.0.0d1
|CoreAnalytics!F	1
>!ASSE	1.0
>!AKeyStore	2
>!UTDM	533.120.2
|IOUSBMass!SDriver	210.120.3
|IOSCSIBlockCommandsDevice	456.140.3
|IO!S!F	2.1
|IOSCSIArchitectureModel!F	456.140.3
>!AMobileFileIntegrity	1.0.5
$!AImage4	4.2.0
@kext.CoreTrust	1
>!AFDEKeyStore	28.30
>!AEffaceable!S	1.0
>!ACredentialManager	1.0
>KernelRelayHost	1
|IOUSBHost!F	1.2
>!UHostMergeProperties	1.2
>usb.!UCommon	1.0
>!ABusPower!C	1.0
>!ASEPManager	1.0.1
>IOSlaveProcessor	1
>!AACPIPlatform	6.1
>!ASMC	3.1.9
|IOPCI!F	2.9
|IOACPI!F	1.4
>watchdog	1
@kec.pthread	1
@kec.Libm	1
@kec.corecrypto	12.0

macOS 12.4 breaks HookCase

The kernel extension HookCase.kext refuses to load.

The error message from sudo kmutil -p /usr/local/sbin/HookCase.kext is:

Error Domain=KMErrorDomain Code=71 "Kernel request failed: (libkern/kext) kext (kmod) start/stop routine failed (-603946985)" UserInfo={NSLocalizedDescription=Kernel request failed: (libkern/kext) kext (kmod) start/stop routine failed (-603946985)}

Same as in #33

macOS 12.3 breaks HookCase

The kernel extension HookCase.kext refuses to load.

The error message from sudo kmutil -p /usr/local/sbin/HookCase.kext is:

    Error Domain=KMErrorDomain Code=71 "Kernel request failed: (libkern/kext) kext (kmod) start/stop routine failed (-603946985)" UserInfo={NSLocalizedDescription=Kernel request failed: (libkern/kext) kext (kmod) start/stop routine failed (-603946985)}

I'll be working on this.

Some NSObject methods crash if used from constructor functions

I use constructor function in my dylib like this:

#import <Foundation/Foundation.h>

__attribute__((constructor)) static void insert_entry() {
    NSLog(@"hello!");
}

When I try to insert dylib into ls use: HC_INSERT_LIBRARY=insert.dylib ls
then segmentation fault happened, i find that ls call _malloc_zone_malloc_instrumented_or_legacy recursively
[1] 38152 segmentation fault HC_INSERT_LIBRARY= ls -G
but if i use printf, everything is ok. I think maybe Hookcase caued malloc error?

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_malloc.dylib        	    0x7ff81525404a _malloc_zone_malloc_instrumented_or_legacy + 84
1   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
2   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
3   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
4   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
5   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
6   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
7   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
8   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
9   libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88
10  libsystem_malloc.dylib        	    0x7ff81525404e _malloc_zone_malloc_instrumented_or_legacy + 88

Unresolved symbol ___strncpy_chk

I finally wanted to give HookCase a try (after letting 7 months pass by...) but wasn't successful when I tried to install it.

Here's the error I got:

$ sudo kextutil /usr/local/sbin/HookCase.kext
Diagnostics for /usr/local/sbin/HookCase.kext:
Code Signing Failure: not code signed
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/usr/local/sbin/HookCase.kext"
kext signature failure override allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/usr/local/sbin/HookCase.kext"
(kernel) kxld[org.smichaud.HookCase]: The following symbols are unresolved for this kext:
(kernel) kxld[org.smichaud.HookCase]: 	___strncpy_chk
(kernel) Can't load kext org.smichaud.HookCase - link failed.
(kernel) Failed to load executable for kext org.smichaud.HookCase.
(kernel) Kext org.smichaud.HookCase failed to load (0xdc008016).
(kernel) Failed to load kext org.smichaud.HookCase (error 0xdc008016).
Failed to load /usr/local/sbin/HookCase.kext - (libkern/kext) link error.
Check library declarations for your kext with kextlibs(8).

I'm on macOS 10.12.6.

Some interpose hooks are skipped on Big Sur

Last commit: https://github.com/steven-michaud/HookCase/issues/21

I tested new version (5.0.1), and the problem still exists. I try to write a simple case.

INTERPOSE_FUNCTION(open)

static int Hooked_open(const char * filename, int flags, mode_t mode)
{
const char * lpDot = strrchr(filename, '.');
if (lpDot && (strcmp(lpDot, ".pdf")==0))
{
printf("open %s\n", filename);
}
return open(filename, flags, mode);
}

Then, Run Preview and open a pdf file. In macos 10.15.7, It will show 4 records. But In macos 11.1 It only show 1 record. So, I think maybe some hooks didn't attach.

Loading hook library in 'open' no longer loads it in its children

It used to be that you could use the following syntax to load a hook library into an application (and all its children):

HC_INSERT_LIBRARY=/full/path/to/hook.dylib open /Applications/[Application].app

This no longer works. Now your hook library only gets loaded into open itself.

I expect this has been true for a while. But I don't often use this syntax, so I didn't notice it. I'll try to restore the original behavior. In the meantime you can use the following syntax as a workaround:

HC_INSERT_LIBRARY=/full/path/to/hook.dylib open /Applications/[Application].app/Contents/MacOS/[Application]

macOS 14.4 breaks HookCase

When you try to load HookCase on macOS 14.4 (using /usr/local/sbin/kextutil load -p /usr/local/sbin/HookCase.kext), it refuses to load and you see the following error message:

Error Domain=KMErrorDomain Code=71 "Kernel request failed: (libkern/kext) kext (kmod) start/stop routine failed (-603946985)" UserInfo={NSLocalizedDescription=Kernel request failed: (libkern/kext) kext (kmod) start/stop routine failed (-603946985)}

I'll be working on this.

macOS 11.4 breaks HookCase

HookCase.kext loads correctly. But I got a kernel panic when I tried to load the "events" example hook library into Safari. There was an error message displayed at the top of the kernel panic report:

    panic(cpu 2 caller 0xffffff8006eaa6dd): "unexpected mode: 0"@/System/Volumes/Data/SWE/macOS/BuildRoots/e90674e518/Library/Caches/com.apple.xbs/Sources/xnu/xnu-7195.121.3/osfmk/kern/priority.c:929

This is presumably #27 over again. I'll be working on this. In the meantime don't use HookCase on macOS 11.4.

which part of the key code to remove the signature restriction about DYLD_INSERT_LIBRARIES

Kernel panic on 11.3.1

Hi there,

First off, awesome project!

Unfortunately, as soon as I got it setup and tried it out, got a kernel panic.

$ HC_INSERT_LIBRARY=/Users/test/HookCase/Examples/xpcproxy/hook.dylib open test.html
.... panic

$ /usr/bin/kmutil showloaded | grep HookCase
No variant specified, falling back to release
  172    0 0xffffff7f9b453000 0x11000    0x11000    org.smichaud.HookCase (5.0.5) FE389BA6-A958-3916-AF43-3067D3DD3C9D <8 6 5 3 2 1>

$ sysctl -a | grep osrelease
kern.osrelease: 20.4.0

Any ideas?

Thanks!

VMware Fusion can no longer start virtual machines when HookCase extension is loaded

Unloading the extension fixes the issue.

Kernel panics in `set_interpose_hooks_for_module()`

While working on issue #21 I saw two of these kernel panics. Both were on macOS 10.15.7, but on different machines (a VMWare VM and a MacPro). I suspect this is a HookCase bug.

Occasional page fault kernel panic

Hi Steven and thanks for this amazing project! Not sure if it is just me but I am getting the occasional KP while HookCase is loaded even if no processes are currently "injected". I wish I could figure out a way to reliably reproduce the panic but it happens at seemingly random times and the stack trace is always the same. From the looks of it, it may have something to do with the mac_vnode_check_open hook but I can't be sure.
Thanks again!

Running 10.15.2
panic(cpu 1 caller 0xffffff801ee6520a): Kernel trap at 0xffffff801ef9aec1, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000000000000077, CR3: 0x00000001bae350a4, CR4: 0x00000000001626e0
RAX: 0x0000000000000000, RBX: 0x0000000000208005, RCX: 0xffffff8122973bd8, RDX: 0x0000000000000002
RSP: 0xffffff81229738a0, RBP: 0xffffff81229738d0, RSI: 0xffffff8040b2e000, RDI: 0xffffff8039c008d0
R8: 0x0000000000000000, R9: 0x0000000000000007, R10: 0x0000000000000287, R11: 0xffffff801ef9ae78
R12: 0x0000000000000001, R13: 0xffffff8122973bd8, R14: 0xffffff8039c008d0, R15: 0x0000000000000007
RFL: 0x0000000000010202, RIP: 0xffffff801ef9aec1, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000077, Error code: 0x0000000000000000, Fault CPU: 0x1, PL: 0, VF: 0

Backtrace (CPU 1), Frame : Return Address
0xffffff8122973300 : 0xffffff801ed3bb1b mach_kernel : _handle_debugger_trap + 0x47b
0xffffff8122973350 : 0xffffff801ee733e5 mach_kernel : _kdp_i386_trap + 0x155
0xffffff8122973390 : 0xffffff801ee64e5e mach_kernel : _kernel_trap + 0x4ee
0xffffff81229733e0 : 0xffffff801ece2a40 mach_kernel : _return_from_trap + 0xe0
0xffffff8122973400 : 0xffffff801ed3b207 mach_kernel : _DebuggerTrapWithState + 0x17
0xffffff8122973500 : 0xffffff801ed3b5eb mach_kernel : _panic_trap_to_debugger + 0x21b
0xffffff8122973550 : 0xffffff801f4d24f9 mach_kernel : _panic + 0x61
0xffffff81229735c0 : 0xffffff801ee6520a mach_kernel : _sync_iss_to_iks + 0x2aa
0xffffff8122973740 : 0xffffff801ee64f08 mach_kernel : _kernel_trap + 0x598
0xffffff8122973790 : 0xffffff801ece2a40 mach_kernel : _return_from_trap + 0xe0
0xffffff81229737b0 : 0xffffff801ef9aec1 mach_kernel : _vn_authorize_open_existing + 0x111
0xffffff81229738d0 : 0xffffff801efbd624 mach_kernel : _vn_open_auth + 0x804
0xffffff8122973950 : 0xffffff801efa60d6 mach_kernel : _open1 + 0x196
0xffffff8122973ba0 : 0xffffff801efa749b mach_kernel : _openbyid_np + 0x29b
0xffffff8122973f40 : 0xffffff801f39acba mach_kernel : _unix_syscall64 + 0x28a
0xffffff8122973fa0 : 0xffffff801ece3206 mach_kernel : _hndl_unix_scall64 + 0x16

BSD process name corresponding to current thread: bird
Boot args: keepsyms=1 amfi_get_out_of_my_way=1

Mac OS version:
19C57

Kernel version:
Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64
Kernel UUID: C3E7E405-C692-356B-88D3-C30041FD1E72
Kernel slide: 0x000000001ea00000
Kernel text base: 0xffffff801ec00000
__HIB text base: 0xffffff801eb00000
System model name: MacBookPro11,1 (Mac-189A3D4F975D5FFC)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 235488635281
last loaded kext at 121699998679: @filesystems.smbfs 3.4 (addr 0xffffff7fa1869000, size 450560)
loaded kexts:
org.smichaud.HookCase 4.0.1

HC_INSERT_LIBRARY Not working on Mojave with SIP without kext protection

In High Sierra with SIP(without kext) was well. But Mojave's kernel say "CODE SIGNING: 430[PROCESS NAME] vm_map_protect can't have both write and exec at the same time".

macOS 13.3 breaks HookCase

macOS 13.3, released today, breaks HookCase 7.1.2 (the current version). As best I can tell it doesn't trigger kernel panics. But HookCase is no longer able to set hooks.

I'll be working on this.

macOS 12.6.4 and 11.7.5, also released today, still seem to work fine.

HookCase not loading libraries on processes directly started by launchd

I have noticed that HookCase gives a ‘cast_hook_flying’ error that the library could not be found or loaded only on daemons and xpcproxy. Any process that execs over xpcproxy still works though. I’m on 10.15.3 and it could be just me but if someone could let me know whether this is happening to them or not, I could gauge how to proceed. Thanks!

Persistent double fault kernel panics, probably caused by OpenCore Legacy Patcher

When I first use HookCase 7.1.3, it works properly.
But the next time i load it, if i try to inject, the kernel panic.
Then, even though i use HookCase 7.1.2, the kernel panic either.

panic(cpu 2 caller 0xffffff8005f496b7): Double fault at 0xffffff8008816d5b, registers:
CR0: 0x0000000080010033, CR2: 0xffffffbe064c3ff8, CR3: 0x00000000588b21c8, CR4: 0x00000000003626e0
RAX: 0xffffff8006a87b00, RBX: 0xffffff86b6d0c200, RCX: 0x0000000002000000, RDX: 0x0000000000000008
RSP: 0xffffffbe064c4000, RBP: 0xffffffbe064c4020, RSI: 0x0000000000000290, RDI: 0xffffffcb37069000
R8:  0x0000000000000004, R9:  0xffffffbe064c42e0, R10: 0xffffffbe064c4308, R11: 0xffffffbe064c4450
R12: 0xffffffcb3706b800, R13: 0xffffffcb37069000, R14: 0x0000000000000290, R15: 0x0000000000000008
RFL: 0x0000000000010246, RIP: 0xffffff8008816d5b, CS:  0x0000000000000008, SS:  0x0000000000000010
Error code: 0x0000000000000000
 @trap_native.c:168
Panicked task 0xffffff951e6e9208: 1 threads: pid 1467: ls
Backtrace (CPU 2), panicked thread: 0xffffff8b85f10598, Frame : Return Address
0xffffff8005b0d270 : 0xffffff8005deb31d mach_kernel : _handle_debugger_trap + 0x4ad
0xffffff8005b0d2c0 : 0xffffff8005f59236 mach_kernel : _kdp_i386_trap + 0x116
0xffffff8005b0d300 : 0xffffff8005f48480 mach_kernel : _kernel_trap + 0x3e0
0xffffff8005b0d350 : 0xffffff8005d85951 mach_kernel : _return_from_trap + 0xc1
0xffffff8005b0d370 : 0xffffff8005deb5fd mach_kernel : _DebuggerTrapWithState + 0x5d
0xffffff8005b0d460 : 0xffffff8005deaca9 mach_kernel : _panic_trap_to_debugger + 0x1a9
0xffffff8005b0d4c0 : 0xffffff80065e08cb mach_kernel : _panic + 0x84
0xffffff8005b0d5b0 : 0xffffff8005f496b7 mach_kernel : _sync_iss_to_iks_unconditionally + 0x167
0xffffff8005b0d6c0 : 0xffffff80065e88f8 mach_kernel : _panic_double_fault64 + 0x27
0xffffff8005b0d6d0 : 0xffffff8005d85e4f mach_kernel : _hndl_double_fault + 0xf
0xffffffbe064c4020 : 0xffffff8008816cf2 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD10space_freeEP9vtd_spacejj + 0x1da
0xffffffbe064c4060 : 0xffffff800881678e com.apple.iokit.IOPCIFamily : __ZN8AppleVTD9checkFreeEP9vtd_spacej + 0xca
0xffffffbe064c40a0 : 0xffffff8008816211 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD11space_allocEP9vtd_spacejjjPK21IODMAMapSpecificationPK13upl_page_info + 0x125
0xffffffbe064c4140 : 0xffffff8008818c21 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD14spaceMapMemoryEP9vtd_spaceP18IOMemoryDescriptoryyjPK21IODMAMapSpecificationP12IODMACommandPK16IODMAMapPageListPySC_ + 0x23b
0xffffffbe064c4240 : 0xffffff800881960f com.apple.iokit.IOPCIFamily : __ZN20AppleVTDDeviceMapper13iovmMapMemoryEP18IOMemoryDescriptoryyjPK21IODMAMapSpecificationP12IODMACommandPK16IODMAMapPageListPySA_ + 0xb1
0xffffffbe064c42b0 : 0xffffff800652b0ef mach_kernel : __ZN25IOGeneralMemoryDescriptor6dmaMapEP8IOMapperP18IOMemoryDescriptorP12IODMACommandPK21IODMAMapSpecificationyyPyS9_ + 0x1df
0xffffffbe064c4340 : 0xffffff8006526a54 mach_kernel : __ZNK25IOGeneralMemoryDescriptor19dmaCommandOperationEjPvj + 0x2b4
0xffffffbe064c43f0 : 0xffffff800651c51a mach_kernel : __ZN12IODMACommand7prepareEyybb + 0x30a
0xffffffbe064c4520 : 0xffffff80085848ad com.apple.iokit.IONVMeFamily : __ZN24IONVMeBlockStorageDevice16doAsyncReadWriteEP18IOMemoryDescriptoryyP19IOStorageAttributesP19IOStorageCompletion + 0x365
0xffffffbe064c4600 : 0xffffff80089391ed com.apple.iokit.IOStorageFamily : __ZN20IOBlockStorageDriver14executeRequestEyP18IOMemoryDescriptorP19IOStorageAttributesP19IOStorageCompletionPNS_7ContextE + 0x129
0xffffffbe064c4670 : 0xffffff800893be07 com.apple.iokit.IOStorageFamily : __ZN20IOBlockStorageDriver14prepareRequestEyP18IOMemoryDescriptorP19IOStorageAttributesP19IOStorageCompletion + 0x21b
0xffffffbe064c4720 : 0xffffff80089428c2 com.apple.iokit.IOStorageFamily : __ZL11dkreadwritePv9dkrtype_t + 0x61c
0xffffffbe064c47d0 : 0xffffff8006020124 mach_kernel : _spec_strategy + 0x454
0xffffffbe064c4830 : 0xffffff8005fb6fd5 mach_kernel : _buf_strategy + 0x1f5
0xffffffbe064c48d0 : 0xffffff8008e952ff com.apple.filesystems.apfs : _apfs_vnop_strategy + 0x731
0xffffffbe064c49c0 : 0xffffff8005fc0a71 mach_kernel : _cluster_pageout_ext + 0x1011
0xffffffbe064c4b10 : 0xffffff8005fc96d5 mach_kernel : _advisory_read_ext + 0x365
0xffffffbe064c4bd0 : 0xffffff8005fc9989 mach_kernel : _advisory_read_ext + 0x619
0xffffffbe064c4c40 : 0xffffff8005fc67d7 mach_kernel : _cluster_read_ext + 0x827
0xffffffbe064c4e00 : 0xffffff8005fc6124 mach_kernel : _cluster_read_ext + 0x174
0xffffffbe064c4e70 : 0xffffff8008e9ec8e com.apple.filesystems.apfs : _apfs_nstream_read + 0x288
0xffffffbe064c4f40 : 0xffffff8008e9f6e3 com.apple.filesystems.apfs : _apfs_inode_getxattr + 0x1b5
0xffffffbe064c5030 : 0xffffff8008e9f508 com.apple.filesystems.apfs : _apfs_vnop_getxattr + 0xfb
0xffffffbe064c5080 : 0xffffff80060159ec mach_kernel : _VNOP_GETXATTR + 0x4c
0xffffffbe064c50d0 : 0xffffff80071feb99 com.apple.AppleFSCompression.AppleFSCompressionTypeZlib : _compression_decode_buffer + 0x198d
0xffffffbe064c5130 : 0xffffff80071fddbc com.apple.AppleFSCompression.AppleFSCompressionTypeZlib : _compression_decode_buffer + 0xbb0
0xffffffbe064c5220 : 0xffffff800602aa3b mach_kernel : _decmpfs_pagein_compressed + 0x7fb
0xffffffbe064c5390 : 0xffffff8008ebb739 com.apple.filesystems.apfs : _apfs_pagein_with_verification + 0x3a2
0xffffffbe064c54c0 : 0xffffff8008ebb257 com.apple.filesystems.apfs : _apfs_pagein + 0x8c3
0xffffffbe064c55c0 : 0xffffff8008eb1522 com.apple.filesystems.apfs : _apfs_vnop_pagein + 0xd7
0xffffffbe064c5600 : 0xffffff80063c2166 mach_kernel : _vnode_pagein + 0x1256
0xffffffbe064c5700 : 0xffffff8005e7f948 mach_kernel : _vnode_pager_cluster_read + 0x48
0xffffffbe064c5760 : 0xffffff8005e95ed5 mach_kernel : _vm_fault_page + 0x925
0xffffffbe064c5870 : 0xffffff8005e9072f mach_kernel : _vm_fault$XNU_INTERNAL + 0xf4f
0xffffffbe064c5ad0 : 0xffffff8005f483ba mach_kernel : _kernel_trap + 0x31a
0xffffffbe064c5b40 : 0xffffff8005d85951 mach_kernel : _return_from_trap + 0xc1
0xffffffbe064c5b60 : 0xffffff8005f02115 mach_kernel : _strncmp + 0x15
0xffffffbe064c5c50 : 0xffffff7f9cc2d4bd org.smichaud.HookCase : __Z11find_symbolPKcP13_symbol_table + 0xca
0xffffffbe064c5cb0 : 0xffffff7f9cc304f9 org.smichaud.HookCase : __Z15maybe_cast_hookP4proc + 0x4ee
0xffffffbe064c7e20 : 0xffffff7f9cc34be0 org.smichaud.HookCase : __Z28thread_bootstrap_return_hookP17x86_saved_state_tP10_kern_hook + 0xc4
0xffffffbe064c7e70 : 0xffffff7f9cc25055 org.smichaud.HookCase : _kernel_trampoline + 0x25
0xffffffbe064c7fa0 : 0xffffff8005d8519e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         com.apple.iokit.IOPCIFamily(2.9)[752CD69F-309E-31FF-881C-2A22ACB6C0B6]@0xffffff8008800000->0xffffff800882ffff
         com.apple.iokit.IOStorageFamily(2.1)[521B092C-AECB-357C-BE62-5E582EF058A2]@0xffffff8008933000->0xffffff8008949fff
         com.apple.iokit.IONVMeFamily(2.1)[2351626F-4F3C-3971-AAB5-08FCF53022E1]@0xffffff8008568000->0xffffff8008594fff
            dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[4E741445-0025-3DB8-8292-C7533F3C0917]@0xffffff8007392000->0xffffff80073c0fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[752CD69F-309E-31FF-881C-2A22ACB6C0B6]@0xffffff8008800000->0xffffff800882ffff
            dependency: com.apple.iokit.IOReportFamily(47)[EF0F8F2D-D40B-3B22-A3BC-8BB0145DA2F7]@0xffffff8008841000->0xffffff8008843fff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[521B092C-AECB-357C-BE62-5E582EF058A2]@0xffffff8008933000->0xffffff8008949fff
         com.apple.filesystems.apfs(2142.61.2)[11FBF316-D87F-396C-803B-F1CBD0C96179]@0xffffff8008e4c000->0xffffff8008fdbfff
            dependency: com.apple.driver.AppleEFINVRAM(2.1)[53554E15-F0D2-3EA5-BB35-30ED9C5283EA]@0xffffff80071bd000->0xffffff80071c6fff
            dependency: com.apple.driver.AppleEffaceableStorage(1.0)[BFFA34B0-1747-3367-8C51-665BCD859E31]@0xffffff80071d3000->0xffffff80071d8fff
            dependency: com.apple.iokit.CoreAnalyticsFamily(1)[D0FF0186-6F90-3AF1-9F7E-A2BD383CCA20]@0xffffff80076dc000->0xffffff80076e5fff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[521B092C-AECB-357C-BE62-5E582EF058A2]@0xffffff8008933000->0xffffff8008949fff
            dependency: com.apple.kec.corecrypto(12.0)[7A2A4035-FDBB-38A2-88B7-7AF62A0BD48B]@0xffffff8009021000->0xffffff8009099fff
            dependency: com.apple.security.AppleImage4(5.0.0)[726F02C0-67F1-3D38-9BE4-CDFE14227DAE]@0xffffff800725e000->0xffffff800727cfff

Process name corresponding to current thread (0xffffff8b85f10598): ls
Boot args: keepsyms=1

Feature difference to Cydia Substrate and Frida?

Hey Steven,

Great project, thank you for the contribution to iOS development. I'm wondering what are the biggest reasons to use HookCase over other hooking solutions such as Cydia Substrate and Frida. Any insight into this?

Cheers,
Steve

Hooked_openat_dprotected_np function cause hookcase disabled

hook.dylib

int Hooked_open(const char *path, int flags, ...)
{
    int ret;
    int mode = 0;

    if (flags & O_CREAT) {
        va_list ap;
        va_start(ap, flags);
        mode = va_arg(ap, int);
        va_end(ap);
    }

    ret = open(path, flags, mode);
    LogWithFormat(true, "[open](%s, 0x%x)-->%d", path, flags, ret);
    
    return ret;
}

//int Hooked_openat_dprotected_np(int fd, const char* path, int flags, int dpclass, int dpflags, ...)
//{
//    int mode = 0;
//
//    if (flags & O_CREAT) {
//        va_list ap;
//        va_start(ap, dpflags);
//        mode = va_arg(ap, int);
//        va_end(ap);
//    }
//
//    return openat_dprotected_np(fd, path, flags, dpclass, dpflags, mode);
//}

INTERPOSE_FUNCTION(open),

command

HC_INSERT_LIBRARY=/path/to/hook.dylib  ls -l

when above code Hooked_openat_dprotected_np is uncommented, hookcase will not work

Can't hook fread write.

INTERPOSE_FUNCTION(fopen),
INTERPOSE_FUNCTION(fread),
INTERPOSE_FUNCTION(fwrite),
INTERPOSE_FUNCTION(fclose),

...

I found that only hook fopen/fclose.

panic on 10.15.7

when start , panic in. user_trap_hook,line:
user_trap_t caller = (user_trap_t)hookp->caller_addr; caller(state); // Might not return
I found hookp->caller_addr is NULL.

Interpose hooks largely broken on macOS 13 (Ventura)

dtruss objective c code

        NSString *str = @"11111111111111111";
        NSError *error;
        [str writeToFile:@"/Users/abc/test.txt" atomically:TRUE encoding:NSUTF8StringEncoding error:&error];

fstatat64(0xFFFFFFFFFFFFFFFE, 0x7FF7BFCDA9D0, 0x7FF7BFCDA3C0) = -1 Err#2
getattrlist("/Users/abc\0", 0x7FF7BFCDA0E0, 0x7FF7BFCDA0D8) = 0 0
open_dprotected_np(0x7FF7BFCDA9D0, 0xA02, 0x3) = 3 0
write(0x3, "11111111111111111\0", 0x11) = 17 0
fsync(0x3, 0x0, 0x0) = 0 0
fsetxattr(0x3, 0x7FF7BFCDAC60, 0x600001B65190) = 0 0
rename("/Users/abc/.dat.nosync7b14.Ok7wlO\0", "/Users/abc/test.txt\0") = 0 0
close(0x3) = 0 0

but can't hook open_dprotected_np and rename in that objective c code indirect call them, meanwhile direct call open_dprotected_np/rename in objective c marh-o is ok.

ProductName: macOS
ProductVersion: 13.0.1
BuildVersion: 22A400

When setting a patch hook in an executable, it must be invoked using a full path

This issue is spun off from #10 (comment).

Working on issue #10, I discovered that, when setting a patch hook in an executable, HC_INSERT_LIBRARY won't work properly unless the executable is invoked using a full path. For example:

    HC_INSERT_LIBRARY=/full/path/to/hook.dylib /full/path/to/executable

When the executable is invoked using a relative path (for example ./executable), HookCase displays (in the Console app) the misleading error message 'Module "/full/path/to/executable" not (yet) present/loaded in process".

HC_INSERT_LIBRARY does need to be a full path. But it shouldn't be necessary also to specify one for the executable.

I have a fix for this, which I'll land shortly.

steven-michaud / hookcase Goto Github PK

hookcase's Introduction

HookCase

Table of Contents

hookcase's People

Contributors

Stargazers

Watchers

Forkers

hookcase's Issues

Recommend Projects

Recommend Topics

Recommend Org