______      _______ ______    _______    _____      _____    _______  
    _/   _  )__ _/  _   /_\     \ _/  _   /_ _/     \_   /   _/_ _/  _   /__  
    \   _/     \\  -\___\ \\     \\  -\___\ \\   _\   \--\___   \\  -\___\  \  
   /    \       └  _/      └      └  _/      └   \     └   :/    └  _/      _\  
 └/_____:\_____/____________\      \________/____:\_____\_______/___________\   
   _______   _____ _____\      \   __________    _____  
  /   __  )__\    \\    \\      \ /    _    /   /   _/____  
 /   /_      \     \     \       \\   -\____\---\___      \   0day scene 2010  
/      \      └     \     .       .   _/      .   :/       \  
\______:\______\___________\       \___________\___________/└ ----------------+  
.                          /_______/                       .                    
This is intended as an addendum to the existing 0day rules. All the old rules   
are still valid, unless they have been altered or updated by this addendum.  
The 0day scene has gone through major changes in this decade. As technologies   
have changed, so have we, but our adaptations have left many grey areas in the   
current rules. The last rules update was years ago when programs were much   
smaller and transfer speeds much lower. The existing 0day rules did not address   
problems of software encountered today, simply because at that date it did not   
exist. These changes have led to a series of loopholes which groups have been   
taking advantage of. The new rules we constructed aim to close these loopholes,  
as well as increase the general quality level of releases in the scene.  
This document covers a new ruleset for 0day.  These rules and guidelines are  
intended for release-groups in the first place, and sites secondary. We hope   
that in time many sites will take over the majority of these rules. The   
following groups have signed and committed to following these rules:  
                   SHOCK SSG TBE UNLEASHED VACE ZWT   
These rules will go into effect starting January 31st, 2010.  
* Release Name  
Developer.Name is only mandatory if the application name is not unique enough  
for duping. Groups should use some common sense to keep the directory name   
reasonable length.  
>>> Define "application name is not unique enough for duping".
>>> Can directories that do not contain developer names but "are not unique enough for duping"
>>> be nuked? Rule is not clear, therefore it is pointless.

The program name should be the "official" name of the application. Do not omit  
dashes, think of your dupe results.  

>>> What kind of rule is this? How can that be enforced? Why are we trying
>>> to satisfy dupechecking facilities and users here?
The Language tag must be used only on NON english releases. Multilingual and  
bilingual are optional.  

>>> So how do we handle multilingual non-english releases?

Currently valid OS tags are:   
        - Win98, WinME, WinNT, Win2k, WinXP, Win2k3, Vista, Win2k8, Win7  
          (can have an optional tag for more specific edition)  
        - [Distribution.]Linux  
        - MacOSX  
        - [Free|Net|Open]BSD  
        - [Open]Solaris  
        - AIX  
        - HPUX  
        - Open.Enterprise.Server (NetWare)  
The Operating.System tag should be omitted when WinAll (= NT5 based windows   
and optionally earlier, always with latest official service pack). Using a   
UnixAll (= all of the operating systems above, excluding Windows, Linux or   
MacOSX) or a WinAll tag means your app *must* run on *all* of the operating   
systems that fall under it.  
CPU should be omitted when x86, must be x64 for x86_64/EM64T, but not IA64!  
Currently valid CPU tags are:   
        - x86, x64, IA64, PPC, SPARC, SPARC64, RISC, Alpha  
Release.Type can be omitted for Crack/Regged, but is mandatory for keygen  
releases. Possible tags are:  
        - Keygen.Only Keymaker.Only  
        - Incl.Keygen Incl.Keymaker  
        - Incl.Keygen.and.Patch Incl.Keymaker.and.Patch  
        - Cracked  
        - Regged  

>>> So can keygenned releases that don't contain "incl.keygen" in the directory
>>> be nuked? What about releases that contain "license generators"?
Additional.Tags like READ.NFO, DIRFIX, NFOFIX.. must go as follows:  
  - DevelopersName.ProgramName.v1.2.Regged.READ.NFO-GROUP  
  - DevelopersName.ProgramName.v1.2.Regged.DIRFIX-GROUP  
You can use underscores or dots as seperator in the releasename, but do not mix  
them if there is no reason for it (e.g. a program name contains underscores and  
your seperator is a dot is a valid reason to mix)  

>>> But the above line (starting "[<Developer.name>.]") implies only dots are
>>> allowed?
The lists in this section are by no means complete. They are here to serve as a  
guideline for proper dirname construction.  

>>> Great. So if anything, they were pointless. Why try to clarify something that
>>> groups already know how to handle? If anything, you've introduced more confusion
>>> instead of clearing things up.
* Packaging:  
Filenames must be named up to a maximum of 8.3 characters (filename/extension).  

Acceptable compression format at this time is any compression method that  
supports multiple volumes and long file names, followed by the traditional  
PKZIPing. Compressions other than RAR should include an extract utility or be a  
self-extracting archive.  
The traditional packaging methods (zip/diz) shall be maintained, with a diz   
file being present in each zip. The diz file should contain as a bare minimum   
the number of the current disk and the maximum number of disks.   

>>> Should != Must. Therefore, no need to include the above mentioned
>>> info.. have fun guys.
Suggested file_id.diz layout is as follows:  
  [xx/??], where ?? is the total nr of disks in the release. The total number   
  of lines of your diz should not exceed 30.  

>>> Suggested != Must. Can we see some ASCII elephants please?
>>> Again, Should != Must. Can releases with diz's exceeding 30 lines be nuked?
On a side note: using ridiculous compressions that will save 10 disks but takes  
10 hours to unpack are not an acceptable solution.  

>>> Nice level of clarity there. Also, you've only "banned" that particular 
>>> scenario in that sentence, so it's rather pointless.
* Release Size:  
Allowed split volume sizes are:  
        - 1,444,000 bytes  
        - 2,888,000 bytes  
        - 5,000,000 bytes  
        - 10,000,000 bytes  
        - 50,000,000 bytes  

>>> Some groups pack at 5*1024, rather than 5*1000 (giving 5,242,880 bytes)
>>> Is this no longer allowed? Should this be nuked? Nice level of clarity here.
The utils disk limit is as of now 70 x 5,000,000 bytes or 35 x 10,000,000 bytes.   
This equates to a total of 350,000,000 bytes of compressed data. Oversize   
releases are allowed when no ISO release exists and the group (or an iso group   
they work with) is not in possession of the iso to release. In other words,   
there is NO size limit for 0day apps, except when an iso exists!  

>>> Does this mean it is no longer possible to pack releases at 1,444,000/2,888,000 splits
>>> for "utils", even though they've just been mentioned as valid sizes?
>>> Define "utils"
>>> "no ISO release exists" - ok, so what about nuked ISO releases?
>>> "is not in possession of the iso to release" - how is it ever possible to enforce that?
The games disk limit is as of now 80 x 5,000,000 bytes or 40 x 10,000,000 bytes.  
This equates to a total of 400,000,000 bytes of compressed data.  

>>> Define "game" - web game, game rip, what?
Any release should have less than 100 volumes. In case 10,000,000 bytes do not  
suffice, you are allowed to use volumes of larger size; up to 50,000,000 bytes.  

>>> Should != Must.
A size proper is valid when a group manages to reduce the size of the original   
release by at least 30% without sacrificing essential content:  
 - Documentation, help files, and other non functional items can be ripped from   
   a release to decrease size. No functional parts of an application may be   
 - C++ redistributables, .NET framework, and other common operating system   
   components may be ripped. The nfo should note what has been ripped and   
   optionally include an url where it can be downloaded.  
 - A documentation addon is only allowed if the documentation cannot be   
   downloaded freely and publicly (without registration) from the developer's   
* Specific Release Type:  
All of these releases should provide functionality identical to that of a fully  
licensed copy.  

>>> Should != Must. I've got 1000 releases lined up that open a goatse image instead of
>>> providing the functionality of the app. And they're all valid - huzzah!
- Cracked: The program file has been altered to register the program. Any   
  nags/trial limitations should be removed. Any remnants of "Trial" in the app  
  need to be removed. Any "phone-home" checks should be disabled!  

>>> Is it valid for groups to tell us to edit our hosts file?
- Regged: Any way to make an application "registered" without requiring  
  modification of any of the applications executables/libraries. Must include  
  a text file with the required information, serials should not be put in the  
  release nfo. Please name this file carefully, as to deter possible   
  webspiders looking for serial information.  

>>> Should != Must.
- Keygen: A small standalone program which generates valid serials/keyfiles  
  which are based on user input or hardware id.  
  Keygens can be written in any language but they should be native executables  
  for the OS the application is meant for: Linux keygens for Linux applications,  
  Mac keygens for Mac applications, etc. This means that if you do not follow  
  this suggestion, you could get propered. However, you won't be nuked if there  
  is no native keygen available.  
  A keygen that generates a system-dependant serial must explicitly warn the  
  user of this fact, either in the nfo OR at runtime.  

>>> Nice that you finally use the "must" keyword here, on such a minor point.
  Windows keygens in java are allowed if the the program is coded in java or   
  uses java. Same with any other interpreter language. If a library is included  
  with the latest windows install, as is the case for VB6/.NET/VBScript   
  currently, then keygens written in these languages are allowed without   
  question. The motivation here is that a scene release should run on a clean  
  OS install, introducing no additional dependencies other than those imposed  
  by the application being released.  
  A console-based application that usually runs on headless systems (servers,   
  etc) requires a console-based keygen.  
  Generic Keygens (All.Products) are allowed and dupe full releases for as long  
  as the generic keygen continues to work for *every* application it was  
  intended for.  

>>> Do groups that release products contained within these multigens have to provide proof that
>>> the multigens no longer work for every application? Think about the scenario
>>> of a multigen that covers say 25 products. A group releases a newer version of
>>> one of the products - this means the multigen needs to be checked again *every* product
>>> to verify whether its still valid, and whether this new release is a dupe.
  Keygen.Only releases are releases that only contain the actual keygen, no  
  installation files. They are meant as an addition to previous Crack/Regged  

>>> "Meant" - what other purpose do they serve?
  A Keygen.and.Patch release combines a keygen with a crack to enable full  
  functionality. You are still allowed to release a keygen.only for these  
- Retail: A store-bought supply is included in this release. You are allowed to  
  release a retail after a previous release if there is an added benefit to  
  using the retail version. In this case you are required to add a READ.NFO tag  
  to your dirname and list the benefits when compared to the previous release.  
- PROPER/WORKING: a proper of a previous scene-release that was not fully   
  working should always include adequate proof and information for nukers to   
  test and confirm the validity of the proper. This means including screenshots,  
  pieces of code, or clear steps to reproduce the problems that occur with  
  the release you are propering.  

>>> Do releases that do not contain "adequate proof" get nuked? You're trying
>>> to be friendly to nukers here, but you're just making their life harder.
- READ.NFO: If you label a release READ.NFO, please have a clearly stated   
  section in your nfo on what the READ.NFO is all about, dont make people guess.  
  If you want people to read it for a certain reason, make sure they can.  
* Operating Systems:  
If a developer has not mentioned default or minimum requirements for operating  
system, the default is Windows XP, which is also a minimum.  
If a program supports Windows Operating Systems before WinXP, then your crack  
*should* work on them aswell.  

>>> What about after?
Optional: combine multiple operating system versions for the same CPU in 1   
release if it remains within size limits, for example:  
- FreeBSD5,6,7 x86 can be in a single release tagged FreeBSD  
If the installers are freely downloadable (available without registration) and   
the same keygen/crack works for every version, consider only including the   
latest version of the OS.  
Please keep in mind that the contents of .tar.gz, .rpm, .deb and any other  
packaging system are generally identical. Please make a note in your nfo in  
case of exceptions.  
* Minor Updates:  
MU stands for Minor Update. This term denotes an update of a previously   
released application within a certain time-period, the MU-period. Major updates  
are allowed regardless of the last time a previous version was released. In  
this case, the nfo should include some motivation for considering this a major  
update (security- and stability-critical hotfixes for instance)  

>>> Define a "major update" - again, no clarity.
MU-period of 1 month, disregarding the number of days in a month. Examples:  

>>> When does the month officially end? Last day, GMT+1? Why not be clear?
>>> When do these rules changes take effect? Do releases before 31st of Jan still
>>> apply the old 14 day rule, or apply the new one?
- a release on 2010-01-01 will be out of mu on 2010-02-01  
- a release on 2010-01-15 will be out of mu on 2010-02-15  
- a release on 2010-01-29 will be out of mu on 2010-02-28  
- a release on 2010-01-31 will be out of mu on 2010-02-28  
- a release on 2010-02-28 will be out of mu on 2010-03-28  
- a release on 2010-03-31 will be out of mu on 2010-04-30  

>>> This is just stupidly confusing now. What was wrong with a constant day length?
>>> Don't get me wrong, an increase from 14 days is a great idea, but adding the confusion
>>> of a non-constant length of time is just silly.
This ensures no more than a single release of the same application per month,  
while keeping duping simple.   

>>> Again, why are you trying to please dupechecking services and users?
The minor update period is counted from the last valid release which contained   
the software itself. In other words, keymaker.only releases are not considered.  

>>> Define "valid". I'm guessing nuked releases are not. What about handling
>>> different flavours of releases? Acme.XYZ.Gold vs. Acme.XYZ.Platinum. They're both
>>> valid releases of the same application.
* General Rules:  
- If the age of the last modified file of an installed program is older than   
  one (1) year it is not allowed to pre it without a READ.NFO or INTERNAL tag.  
- A group should release the newest version of the software available.  

>>> Should != Must. I've got Nero v1 release ready to pre.
  Exceptions are possible when the software is not available publicly, or if  
  it was never released before, which *must* be mentioned in the nfo-file.   
  This means you can release an older version of an application, but *only* if   
  it is newer than any existing release of the same app, and you have a valid  
  reason for not releasing the latest version (for instance, it is very hard  
  to get the supply, or the application takes months to crack).  
  There is a grace-period of 3 days: if a new version came out in the last 3   
  days before your release, you will not get nuked if you release the older   

>>> Is 3 days realy required for internet-download applications?
- Releases should provide the same functionality as a retail copy of the  
  application (where possible and reasonable). Examples:  
  - a virus scanner must be able to update  
  - a flexlm application should include every useful feature  
  - a keygen should provide either all, or the best license (watermarks are   
    still allowed)  

>>> "must be able to update" - how many times? indefinitely?
>>> Should != Must.
>>> Define "every useful feature"
- Your nfo should provide a minimum of useful information, including:  
  - (complete) application name  
  - (complete) version, including if it is a beta version  
  - the release date  
  - type of crack included  
  - short description of the application/game  
  - description on how to use the crack (important!)  
  - operating systems this release will work on  
  - pre-requisites for the application/game  
  - url to the application's website  

- If you do not want your work to be used by other groups (be it documents,   
  cracking methods, tools, or similar), then make sure you don't give it out  
  to anyone you can't trust. It is deemed public property as soon as it is  
  publicly available, and you lose any exclusive rights to it.  

>>> Thanks for clearing that up.. duh. Pointless rule.
- Stealing cracks/keygens from P2P, WEB, or other scene groups is clearly not   

>>> There was me thinking they were. Pointless rule.
- Security should be everyone's primary concern. Including nicknames or  
  identities of people that have not given explicit permission in your nfo's   
  is absolutely not allowed, and may result in severe repercussions.  

>>> Again, thanks for clearing that up. Pointless rule.
A big thanks to everyone involved in creating this document!   
Last modified: 10 January 2010  

>>> There were glaring insufficiencies in the old rules, and there continue to
>>> be after this. Rather than being a ruleset, it is more a few guidelines with
>>> some general commentary. "This is how things should probably be done" just 
>>> introduces a world of confusion, and if anything, makes the whole situation worse.
>>> A* for effort, F for achieving anything [except increasing the MU length/size limit.. 
>>> which you could have done in a single paragraph]
>>> I suggest you go back to the drawing board and write some real "rules".