ntddk

お	(*･ρ･)ｼﾞｭﾙﾘ 	名詞	
お	(*>ヮ<)(>ヮ<*)ﾈｰ 	名詞	
お	ヾ(๑╹◡╹)ﾉ"♡ 	名詞	
お	 (╹⌓╹ )	名詞	
お	(/ω＼)	名詞	
お	 (ヾﾉ･ω･`)ﾅｲﾅｲ 	名詞	
お	☆(ゝω･)v 	名詞	
お	ヾ(＞ヮ＜*)ﾅﾃﾞﾅﾃﾞ 	名詞	
お	(*/ω＼*) 	名詞	
お	(＝△＝`歩)	名詞	

ntddk

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import math

import chainer
import chainer.links as L
import chainer.functions as F

ntddk

from PyPDF2.generic import (
    DictionaryObject,
    NumberObject,
    FloatObject,
    NameObject,
    TextStringObject,
    ArrayObject
)

# x1, y1 starts in bottom left corner

ntddk

// https://twitter.com/msuiche

int threadMain()
{
  unsigned int i; // edi@1
  _DWORD *v1; // eax@2
  void *v2; // esi@7
  char v4; // [sp+13h] [bp-2Dh]@0
  char v5; // [sp+14h] [bp-2Ch]@1
  void *Memory; // [sp+18h] [bp-28h]@1

ntddk

PyExZ3 Example with HackSysExtremeVulnerableDriver

TL;DR: Using symbolic execution to recover driver IOCTL codes that are computed at runtime.

The goal here is to find valid IOCTL codes for the HackSysExtremeVulnerableDriver by analyzing the binary. The control flow varies between the binary and source due to compiler optimizations. This results in a situation where only a few IOCTL codes in the assembly are represented as a constant with the remaining being computed at runtime.

The code in hevd_ioctl.py is a approximation of the control flow of the compiled IrpDeviceIoCtlHandler function. The effects of the compiler optimization are more pronounced when comparing this code to the original C function. To comply with requirements of the PyExZ3 module, the target function is named after the script's filename, and the `ex