+-----------------------------------------------------------------------------------------------------+
ª OFFiCiAL.NULLED.SCRiPT.RULES.2010-DRAFT2 ª
ª ª
+-----------------------------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------------------------------+
ª Requirements: Notepad with terminal font or any other ascii viewer. ª
+-----------------------------------------------------------------------------------------------------ª
ª Date: 04.05.2010 - 20:00 GMT+1 ª
+-----------------------------------------------------------------------------------------------------+
ª To all 0Day groups that are interested: This ruleset is only a draft
ª if someone wants to fix something, or add a rule then you can
ª reach us under our email adress (on the bottom of this NFO)
ª
ª If no one reacts to this Ruleset until 10.05.2010 (DD.MM.YYYY) we will pre it 1:1 as final.
ª
ª PS: Help at translating in other languages (ES/FR i.e.) is always wanted.
+-----------------------------------------------------------------------------------------------------+
ª
ª-ENGLiSH-
ª
ªiNDEX:
ª 0: General Rules
ª 1: Packaging / NFO
ª 1.1: Examples
ª 1.2: NFO
ª 2: Naming
ª 2.1: Themes/Addons
ª 2.2: Updates
ª 3: NULLiNG Rules
ª 3.1: KEYGEN Rules
ª 4: NUKE RULES / REASONS
ª
ª Prolog:
ª Since the last PHP Nulling group faded away long time ago there were no rules for PHP scripts...
ª So we decided to write new ones so that we, and other groups, can start releasing scripts
ª with a basic ruleset that provides help at cracking and releasing.
ª
ª In general the actual 0Day Rules apply for all not discussed themes.
ª
+-----------------------------------------------------------------------------------------------------+
ª
ª 0. General Rules
ª -NULLED dupes KEYGEN -NOT- (and vice versa), both has good sides.
ª because of this there are 2 releases per script allowed (excluding PROPER/REPACK etc.)
ª -BETA/ALPHAs need no INTERNAL tagging
ª -CRACK.ONLY / KEYGEN.ONLY / KEYFiLEMAKER.ONLY is only allowed if the software
ª (i.e. as Full, Unlockable Demo version)
ª is downloadable for free and without registration at the manufacturers website
ª Usualy it is better to include the files for Archive reasons, and because it does not
ª dupe NULLED anyway.
ª -On-the-Fly Patches are allowed if the script needs a system variable (ID i.e.)
ª to work, but Pre-Patched (to all IDs for example) is preffered over that.
ª
ª This has to be tagged in the following format:
ª <incl.KEYFiLEMAKER.and.PATCH|incl.KEYGEN.and.PATCH>
ª
+-----------------------------------------------------------------------------------------------------+
ª
ª 1. Packaging
ª -Standard 0Day Packing, Filenames max. 8.3 Characters (Name.typ - 12345678.123)
ª Releases are needed to be RARed - Compression is allowed but not mandatory.
ª Each ZIP should be 5000000 Bytes (5Mb).
ª Therefore the size per RAR is around the same.
ª Bigger filesizes are allowed, look at actual 0Day Rules.
ª
ª
ª 1.1: Example
ª 12 Files - 26Mb
ª -5x 5Mb RAR + 1x 1Mb RAR -> grprls.rXX
ª (The RARs can also be only named <grpname>.rXX)
ª --Each RAR in a ZIP
ª --5x 5Mb ZIP + 1x 1Mb ZIP -> grprls<a|b|c|etc>.zip
ª (The actual naming is the groups decision (a|b or 001|002, 01|02, 1|2) )
ª
ª Each ZIP needs to include:
ª xxxx.rXX - file_id.diz - <group>.nfo
ª
ª Wrong naming of RARs/ZIPs is no Nuke reason, unless some other reason applys to:
ª (dupe.filenames, special.chars u.a.)
ª
ª
ª 1.2: NFO
ª The NFO needs to contain:
ª -Release Date
ª -Size (or Diskcount)
ª -Developer Website
ª -Version
ª -Short description (Copy & paste)
ª -Languages (if MULTi)
ª -Short usage description
ª
ª In the NFO wanted is:
ª -Price (Currency does not matter - Copy from website)
ª
+-----------------------------------------------------------------------------------------------------+
ª
ª 2: Naming
ª Naming under following scheme:
ª <> = needed | [] = additional
ª Language tag is only needed on non-english only Releases.
ª For the rare case that only 2 languages are available
ª it has to be tagged BiLiNGUAL.
ª
ª <Name>.[Edition].v<ersion>.[Language|MULTi|BiLiNGUAL].
ª <NULLED|incl.KEYGEN|incl.KEYFiLEMAKER|KEYFiLEMAKER.ONLY|KEYGEN.ONLY|CRACK.ONLY>.
ª [Beta|Alpha|RETAIL|REAL].[iNTERNAL|iNT|DiRFiX|NFOFiX|PROPER|REPACK|READ.NFO].
ª <PHP|ASP|etc>-GRP
ª
ª Examples (fictional):
ª
ª Vbulletin.v5.1.NULLED.PHP-GRP = Vbulletin 5.1 English, Nulled
ª Vbulletin.v5.1.KEYGEN.ONLY.PHP-GRP = Vbulletin 5.1 English, Keygen Only
ª Vbulletin.v5.1b3.NULLED.BETA.iNTERNAL.PHP-GRP = Vbulletin 5.1 Beta, English, iNTERNAL, Nulled
ª Vbulletin.PRO.v5.1.NULLED.PHP-GRP = Vbulletin 5.1, Pro Edition, English, Nulled
ª Vbulletin.v5.1.MULTi.incl.KEYGEN.PHP-GRP = Vbulletin 5.1, Multilanguage (Notes in NFO!), Keygen
ª Gallerypro.v2.1.GERMAN.NULLED.ASP-GRP = Gallerypro 2.1, German, Nulled, ASP
ª
ª
ª If the script is sold with no protections at all (no Callbacks or similar)
ª then instead of NULLED/KEYGEN there shall be no tag used:
ª Somesoftware.v1.5.PHP-GRP
ª
ª In this case even only decoding of protected files (Ioncube for example)
ª is counted as NULLED.
ª (Better for dupe searches and historical background)
ª Releases with Key in NFO and nulled backend (no Callbacks/Security Checks)
ª should be labeled as .NULLED.
ª
ª
ª 2.1: Themes/Addons
ª Themes/Addons for Wordpress/Joomla/Vbulletin etc.
ª
ª <Name>.<version>.for.<for>.<version>.[Language|MULTi].
ª <NULLED|incl.KEYGEN>.[Beta|Alpha|RETAIL].
ª [iNTERNAL|DiRFiX|NFOFiX|PROPER|READ.NFO].<PHP|ASP|etc>-GRP
ª
ª Examples (fictional):
ª Dark.Theme.v3.for.vBulletin.5.X.GERMAN.NULLED.PHP-GRP
ª = Dark Theme Version 3, for Vbulletin Version 5.X, German, Nulled
ª Sidebar.Rotation.2.for.Wordpress.2.1.incl.KEYGEN.PHP-GRP
ª = Sidebar rotation 2 Addon for Wordpress 2.1, with Keygen
ª
ª 2.2.: Updates
ª Updates are allowed 4 weeks after the last Pre
ª (same MU rules as in 0Day Rules)
ª
+-----------------------------------------------------------------------------------------------------+
ª
ª
ª 3: NULLiNG Rules
ª -All Callbacks need to be removed or patched
(i.e. Serial Check over Developer Server)
ª -No Group Watermarks (also not in script comments).
ª -If files of the release are encoded all files need to be decoded.
ª (i.e. Ioncube, Sourceguardian, eval() etc.)
ª
ª 3.1: KEYGEN Rules
ª -Keygens need to be in the same format as the Release
ª (Release is PHP - Keygen needs to be in PHP too)
ª -The Language of the keygen needs to be selectable on MULTi (i.e. DE,EN,PL)
ª or the keygen needs to be completely in english.
ª At specific releases (i.e. GERMAN) the keygen can be english or
ª in the language of the release (in this case German)
ª -Group comments in Keygen Sourcecodes are allowed if the group
ª wants to explain the code, but this is in not mandatory.
ª -Encoded Keygen code is allowed, as long is it does not use an external
ª loader (Example: Ioncube is forbidden, eval() is allowed)
ª -ASCii Art / Pictures are allowed but should be used thrifty.
ª -Pictures in keygens shall not affect the code
ª (i.e. Picture missing = Keygen not loading = Nuke/Proper reason)
ª -Pictures need to be included and can not be mapped from websites
ª (Security risk)
ª
+-----------------------------------------------------------------------------------------------------+
ª
ª 4: NUKE and PROPER RULES / REASONS
ª NUKEs are possible for:
ª -bad.pack (i.e. RARs instead of ZIP) - stolen.from.[web|p2p|etc] - missing.files
ª -bad.crack (= bad nulled) - keygen.not.working
ª -Common Sense Nukes (dupe.filename, mislabeled.<|>, etc.)
ª -This is NOT a complete list.
ª
ª PROPER/DiRFiX/REPACK follows the normal scene rules.
ª
ª
+-----------------------------------------------------------------------------------------------------+
ª SiGNED: ª
ª YET TO BE SIGNED ª
ª CONTACT: contactye@hush.com
+-----------------------------------------------------------------------------------------------------+