Zeroday.Scene.Rules.v2010-RULES

- 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.

Some-Some-Some-Some-Some-Some-Some-Some-Some-Some.Software.Corp.Mega.Ueber.Leet.Super.Duper.Duper.Duper.Duper.Duper.Duper.v1.0-GRP

 ______ _______ ______ _______ _____ _____ _______
 _/ _ )__ _/ _ /_\ \ _/ _ /_ _/ \_ / _/_ _/ _ /__
 \ _/ \\ -\___\ \\ \\ -\___\ \\ _\ \--\___ \\ -\___\ \
 / \ · _/ · · _/ · \ · :/ · _/ _\
 ·/_____:\_____/____________\ \________/____:\_____\_______/___________\ 
 /______/ 
 _______
 _______ _____ _____\ \ __________ _____
 / __ )__\ \\ \\ \ / _ / / _/____
 / /_ \ \ \ \\ -\____\---\___ \ 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:

 ACME AiR AGAiN ALiAS ARN BACKLASH BEAN BLiZZARD BRD CORE CRD 
 CROSSFiRE DIGERATI DVT EMBRACE FALLEN FAS iNViSiBLE LND
 MESMERiZE NGEN NULL ORiON OUTLAWS RiTUEL ROGUE rG
 RAiN SHOCK SSG TBE TE UNLEASHED VACE ZWT 

This particular 2010.1 revision was created to address a number of unclear bits
in the original release. Although we do appreciate constructive criticism, we
would like to point out that these rules were not created by an individual, and
as such they are not trivial to construct. With this new revision we hope to
clarify the rules to match our intentions when we released them. If you did not 
get the rules you want, please remember that this was a combined effort from a 
large number of groups, where the opinion of the collective supersedes that of 
any single group.

These rules will go into effect starting January 31st, 2010.

When a rule is described as *should*, we interpret this as follows: you are
expected to follow the rule, if you do not, groups are free to proper your
release. If it is not propered however, you will not get nuked.

When a rule is described as *must*, there is no compromise, you either follow
the rule or you get nuked.

1) Release Name
~~~~~~~~~~~~~~~

[<Developer.name>.]<Program.name>.v<Version>[.<Language>][.<OS>][.<CPU>]
[.<Release.Type>][.<Additional.Tags>]-<Groupname>

1.1) Developer.Name is only mandatory if the application name is not unique 
enough for duping. This means that you must include the developer in the case 
where duping for your application name will also return results that do not 
match the application you are releasing. Groups should use some common sense to 
keep the directory name reasonable length.

1.2) The program name must be the "official" name of the application. Do not 
omit dashes, think of your dupe results. This is the name in the about box or 
splashscreen of the application, or if this is not available, the name listed 
on the website. Releases that are named incorrectly require a DIRFIX or they 
will be nuked. A DIRFIX release is a directory with inside a zip that includes 
both nfo file and file_id.diz.

1.3) The Language tag must be used only on NON english releases. Multilingual 
and bilingual are optional, every language included must be listed in the nfo 
when these tags are used. 

1.4) 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)

1.5) It is recommended to omit the Operating.System tag when it is 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.

1.6) It is recommended to omit the CPU tag when it is x86; it must be x64 for 
x86_64/EM64T, but not IA64!
Currently valid CPU tags are: 
 - x86, x64, IA64, PPC, SPARC, SPARC64, RISC, Alpha

1.7) Release.Type can be omitted for Cracked/Regged, it is strongly recommended 
for keygen releases. Possible tags are:
 - Keygen.Only 
 - Keymaker.Only 
 - Keyfilemaker.Only 
 - Keygen.and.Patch.Only
 - Keymaker.and.Patch.Only 
 - Keyfilemaker.and.Patch.Only
 - Incl.Keygen 
 - Incl.Keymaker 
 - Incl.Keyfilemaker
 - Incl.Keygen.and.Patch 
 - Incl.Keymaker.and.Patch 
 - Incl.Keyfilemaker.and.Patch
 - Cracked
 - Regged

1.8) Additional.Tags like READ.NFO, DIRFIX, NFOFIX.. must go as follows:
 - Program.Name.v1.2.Regged.READ.NFO-GROUP
 - Program.Name.v1.2.Regged.DIRFIX-GROUP

1.9) You can use underscores or dots as separator in the releasename, but do not 
mix them if there is no reason for it (e.g. a program name contains underscores 
and your separator is a dot is a valid reason to mix)

The lists in this section may not be complete, but they try to be. You are
expected to follow them whenever possible. Straying from them does however not
necessarily mean the release is a nuke. It is impossible to predict what tags
may be required for future releases.

2) Packaging:
~~~~~~~~~~~~~

2.1) Filenames must be named up to a maximum of 8.3 characters (filename + 
extension).

2.2) 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 must include an extract utility or be a
self-extracting archive.

2.3) The traditional packaging methods (zip/diz) shall be maintained, with a 
diz file being present in each zip. The diz file must contain as a bare minimum 
the number of the current disk and the maximum number of disks. 

Minimal file_id.diz must include: 
 [xx/??]
Where ?? is the total nr of disks in the release. The total number of lines of 
your diz must not exceed 30, each line being no more than 45 characters long.

An nfo must be included in at least the first disk of the release. There is
no limitation to its length, its width is determined at 80 characters max.

2.4) On a side note: using ridiculous compressions that will save 10 disks but 
takes 10 hours to unpack are not an acceptable solution. We leave it up to 
nukers to decide where the line is between reasonable and unreasonable.

3) Release Size:
~~~~~~~~~~~~~~~~

3.1) 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

In the following paragraphs, utils make up for the majority of the releases in 
the 0day scene, namely all applications, shareware games, etc. When we talk of
games, we mean the game-rip scene that releases ripped versions of store-bought
games.

3.2) 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. Volumes 
of 1,444,000 and 2,888,000 bytes are allowed, as long as the release does not 
exceed 99 disks. Oversize releases are allowed when no valid 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 a 
valid (not nuked) iso exists!

3.3) The games disk limit is as of now 80 x 5,000,000 bytes or 40 x 10,000,000 
bytes (or comparable for 1,444,000 and 2,888,000 bytes). This equates to a 
total of 400,000,000 bytes of compressed data. Volumes of 1,444,000 and 
2,888,000 bytes are allowed, as long as the release does not exceed 99 disks.

Any release must 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.

3.4) 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 
 ripped.
 - C++ redistributables, .NET framework, and other common operating system 
 components should 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 
 website.

4) Specific Release Type:
~~~~~~~~~~~~~~~~~~~~~~~~~

4.1) All of these releases must provide functionality identical to that of a 
fully licensed copy.

- 4.2) Cracked: The program file has been altered to register the program. Any 
 nags/trial limitations must be removed. Any remnants of "Trial" in the app 
 need to be removed. Any "phone-home" checks must be disabled, or as bare
 minimum, instructions must be provided how they can be disabled.

- 4.3) 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 must not be put in the
 release nfo. Please name this file carefully, as to deter possible 
 webspiders looking for serial information.

- 4.4) Keygen: A small standalone program which generates valid serials/keys
 which are based on user input or hardware id. A Keyfilemaker is a keygen that 
 generates a file which serves to activate an application or game.

 4.4.1) 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.

 4.4.2) A keygen that generates a system-dependant serial must explicitly warn 
 the user of this fact, either in the nfo or at runtime.

 4.4.3) Windows keygens in java are allowed if 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 must run on a clean
 OS install, introducing no additional dependencies other than those imposed
 by the application being released.

 4.4.4) A console-based application that usually runs on headless systems 
 (servers, etc) requires a console-based keygen.

 4.4.5) 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. Once any application changes its registration scheme, it is 
 allowed to update the generic keygen. Proof is not required, but always
 welcome.

 4.4.6) Keygen.Only releases are releases that only contain the actual keygen, 
 no installation files. They are an addition to previously Cracked/Regged 
 releases. 

 4.4.7) 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
 releases.

- 4.5) 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.

- 4.6) PROPER/WORKING: a proper of a previous scene-release that was not fully 
 working must 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.

- 4.7) 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.

5) Operating Systems:
~~~~~~~~~~~~~~~~~~~~~

5.1) If a developer has not mentioned default or minimum requirements for 
operating system, the default is Windows XP, which is also a minimum. This means 
your release *must* work on every operating system the application was designed
for, with the following exception:

 - If a program supports Windows Operating Systems before WinXP, then your 
 crack *should* work on them aswell.

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.

6) Minor Updates:
~~~~~~~~~~~~~~~~~

6.1) 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 must include some motivation for considering this a major
update (security- and stability-critical hotfixes for instance). Typical major
updates are defined as a version-change for the most significant number in the
version, for instance v9.1 being updated to v10.0. Exceptions are possible,
but must be noted in the nfo.

MU-period of 1 month, disregarding the number of days in a month. Examples:

- 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 ensures no more than a single release of the same application per month.
We use the CET/CEST timezones, as we always have.

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.
A valid release is defined as a release that was not nuked. When multiple
editions of the same application exist and are valid (for instance, they
provide different functionality) they can be considered as different
applications with separate MU-periods.

This MU-rule will go into effect on 31st January. This means any application
released after this date will require the above described MU-period to pass
before a new release is valid. Applications released before this date are
not considered.

7) General Rules:
~~~~~~~~~~~~~~~~~

7.1) 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.

7.2) A group must release the newest version of the software available, with the
following exception: 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 one.

7.3) Releases must provide the same functionality as a retail copy of the
application (where possible and reasonable). Examples:
 - A virus scanner must be able to update its definitions at the time of 
 release, and must do so without any restriction on the number of concurrent 
 licensed users. (i.e. a single-user regged license is inadequate as it will 
 soon be blacklisted)
 - A flexlm application must include every retail license-feature applicable 
 to your release (any feature that is actually checked out in the best 
 edition)
 - A keygen must provide either all, or the best license (watermarked keys 
 are still allowed)

7.4) Your nfo should provide a minimum of useful information. Suggestions
include:
 - (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

7.5) 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.

7.6) Stealing cracks/keygens from P2P, WEB, or other scene groups is clearly 
not allowed!

7.7) 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.

A big thanks to everyone involved in creating this document! 

Last modified: 12 January 2010