514 lines
20 KiB
HTML
514 lines
20 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<title>2010_0DAYr.nfo</title>
|
|
<style type="text/css">
|
|
@font-face {
|
|
font-family: nfo;
|
|
font-style: normal;
|
|
font-weight: normal;
|
|
src: url(nfo.eot);
|
|
}
|
|
.nfo {
|
|
padding: 12px;
|
|
font-family: nfo, courier new;
|
|
font-size: 11px;
|
|
line-height: 1em;
|
|
}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<pre class="nfo"> ______ _______ ______ _______ _____ _____ _______
|
|
_/ _ )__ _/ _ /_\ \ _/ _ /_ _/ \_ / _/_ _/ _ /__
|
|
\ _/ \\ -\___\ \\ \\ -\___\ \\ _\ \--\___ \\ -\___\ \
|
|
/ \ └ _/ └ └ _/ └ \ └ :/ └ _/ _\
|
|
└/_____:\_____/____________\ \________/____:\_____\_______/___________\
|
|
/______/
|
|
_______
|
|
_______ _____ _____\ \ __________ _____
|
|
/ __ )__\ \\ \\ \ / _ / / _/____
|
|
/ /_ \ \ \ \\ -\____\---\___ \ 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
|
|
SHOCK SSG TBE UNLEASHED VACE ZWT
|
|
|
|
These rules will go into effect starting January 31st, 2010.
|
|
|
|
* Release Name
|
|
~~~~~~~~~~~~~~
|
|
|
|
[<Developer.name>.]<Program.name>.v<Version>[.<Language>][.<OS>][.<CPU>]
|
|
[.<Release.Type>][.<Additional.Tags>]-<Groupname>
|
|
|
|
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
|
|
ripped.
|
|
- 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
|
|
website.
|
|
|
|
* 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
|
|
releases.
|
|
|
|
>>>
|
|
>>> "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
|
|
releases.
|
|
|
|
- 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
|
|
one.
|
|
|
|
>>>
|
|
>>> 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
|
|
allowed!
|
|
|
|
>>>
|
|
>>> 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".
|
|
>>>
|
|
</pre>
|
|
</body>
|
|
</html>
|