About Movie TAGs

Original Sources

CAM -

A cam is a theater rip usually done with a digital video camera. A mini tripod is sometimes used, but a lot of the time this wont be possible, so the camera make shake. Also seating placement isn't always idle, and it might be filmed from an angle. If cropped properly, this is hard to tell unless there's text on the screen, but a lot of times these are left with triangular borders on the top and bottom of the screen. Sound is taken from the onboard microphone of the camera, and especially in comedies, laughter can often be heard during the film. Due to these factors picture and sound quality are usually quite poor, but sometimes we're lucky, and the theater will be fairly empty and a fairly clear signal will be heard.

TELESYNC (TS) - A telesync is the same spec as a CAM except it uses an external audio source (most likely an audio jack in the chair for hard of hearing people). A direct audio source does not ensure a good quality audio source, as a lot of background noise can interfere. A lot of the times a telesync is filmed in an empty cinema or from the projection booth with a professional camera, giving a better picture quality. Quality ranges drastically, check the sample before downloading the full release. A high percentage of Telesyncs are CAMs that have been mislabeled.

TELECINE (TC) -

A telecine machine copies the film digitally from the reels. Sound and picture should be very good, but due to the equipment involved and cost telecines are fairly uncommon. Generally the film will be in correct aspect ratio, although 4:3 telecines have existed. A great example is the JURASSIC PARK 3 TC done last year. TC should not be confused with TimeCode , which is a visible counter on screen throughout the film.

SCREENER (SCR) -

A pre VHS tape, sent to rental stores, and various other places for promotional use. A screener is supplied on a VHS tape, and is usually in a 4:3 (full screen) a/r, although letterboxed screeners are sometimes found. The main draw back is a "ticker" (a message that scrolls past at the bottom of the screen, with the copyright and anti-copy telephone number). Also, if the tape contains any serial numbers, or any other markings that could lead to the source of the tape, these will have to be blocked, usually with a black mark over the section. This is sometimes only for a few seconds, but unfortunately on some copies this will last for the entire film, and some can be quite big. Depending on the equipment used, screener quality can range from excellent if done from a MASTER copy, to very poor if done on an old VHS recorder thru poor capture equipment on a copied tape. Most screeners are transferred to VCD, but a few attempts at SVCD have occurred, some looking better than others.

DVD-SCREENER (DVDscr) -Same premise as a screener, but transferred off a DVD. Usually letterbox , but without the extras that a DVD retail would contain. The ticker is not usually in the black bars, and will disrupt the viewing. If the ripper has any skill, a DVDscr should be very good. Usually transferred to SVCD or DivX/XviD.

DVDRip - A copy of the final released DVD. If possible this is released PRE retail (for example, Star Wars episode 2) again, should be excellent quality. DVDrips are released in SVCD and DivX/XviD.

VHSRip -Transferred off a retail VHS, mainly skating/sports videos and XXX releases.

TVRip -TV episode that is either from Network (capped using digital cable/satellite boxes are preferable) or PRE-AIR from satellite feeds sending the program around to networks a few days earlier (do not contain "dogs" but sometimes have flickers etc) Some programs such as WWF Raw Is War contain extra parts, and the "dark matches" and camera/commentary tests are included on the rips. PDTV is capped from a digital TV PCI card, generally giving the best results, and groups tend to release in SVCD for these. VCD/SVCD/DivX/XviD rips are all supported by the TV scene.

WORKPRINT (WP) -A workprint is a copy of the film that has not been finished. It can be missing scenes, music, and quality can range from excellent to very poor. Some WPs are very different from the final print (Men In Black is missing all the aliens, and has actors in their places) and others can contain extra scenes (Jay and Silent Bob) . WPs can be nice additions to the collection once a good quality final has been obtained.

DivX Re-Enc -A DivX re-enc is a film that has been taken from its original VCD source, and re-encoded into a small DivX file. Most commonly found on file sharers, these are usually labeled something like Film.Name.Group(1of2) etc. Common groups are SMR and TND. These aren't really worth downloading, unless you're that unsure about a film u only want a 200mb copy of it. Generally avoid.

Watermarks -

A lot of films come from Asian Silvers/PDVD (see below) and these are tagged by the people responsible. Usually with a letter/initials or a little logo, generally in one of the corners. Most famous are the "Z" "A" and "Globe" watermarks.

Asian Silvers / PDVD -

These are films put out by eastern bootleggers, and these are usually bought by some groups to put out as their own. Silvers are very cheap and easily available in a lot of countries, and its easy to put out a release, which is why there are so many in the scene at the moment, mainly from smaller groups who don't last more than a few releases. PDVDs are the same thing pressed onto a DVD. They have removable subtitles, and the quality is usually better than the silvers. These are ripped like a normal DVD, but usually released as VCD.

Formats

VCD -

VCD is an mpeg1 based format, with a constant bitrate of 1150kbit at a resolution of 352x240 (NTCS). VCDs are generally used for lower quality transfers (CAM/TS/TC/Screener(VHS)/TVrip(analogue) in order to make smaller file sizes, and fit as much on a single disc as possible. Both VCDs and SVCDs are timed in minutes, rather than MB, so when looking at an mpeg, it may appear larger than the disc capacity, and in reality u can fit 74min on a CDR74.

SVCD -

SVCD is an mpeg2 based (same as DVD) which allows variable bit-rates of up to 2500kbits at a resolution of 480x480 (NTSC) which is then decompressed into a 4:3 aspect ratio when played back. Due to the variable bit-rate, the length you can fit on a single CDR is not fixed, but generally between 35-60 Mins are the most common. To get a better SVCD encode using variable bit-rates, it is important to use multiple "passes". this takes a lot longer, but the results are far clearer.

XVCD/XSVCD -

These are basically VCD/SVCD that don't obey the "rules". They are both capable of much higher resolutions and bit-rates, but it all depends on the player to whether the disc can be played. X(S)VCD are total non-standards, and are usually for home-ripping by people who don't intend to release them.

KVCD Thanks for lardo4life for the info

KVCD is a modification to the standard MPEG-1 and MPEG-2 GOP structure and Quantization Matrix. It enables you to create over 120 minutes of near DVD quality video, depending on your material, on a single 80 minute CD-R/CD-RW. We have published these specifications as KVCDx3, our official resolution, which produce 528x480 (NTSC) and 528x576 (PAL) MPEG-1 variable bit rate video, from 64Kbps to 3,000Kbps. Using a resolution of 352x240 (NTSC) or 352x288 (PAL), it's possible to encode video up to ~360 minutes of near VCD quality on a single 80 minute CD-R. The mpeg files created will play back in most modern standalone DVD players. You must burn the KVCD MPEG files as non-standard VCD or non-standard SVCD (depends on your player) with Nero or VCDEasy.

DivX / XviD -

DivX is a format designed for multimedia platforms. It uses two codecs, one low motion, one high motion. most older films were encoded in low motion only, and they have problems with high motion too. A method known as SBC (Smart Bit-rate Control) was developed which switches codecs at the encoding stage, making a much better print. The format is Ana orphic and the bit-rate/resolution are interchangeable. Due to the higher processing power required, and the different codecs for playback, its unlikely we'll see a DVD player capable of play DivX for quite a while, if at all. There have been players in development which are supposedly capable, but nothing has ever arisen. The majority of PROPER DivX rips (not Re-Encs) are taken from DVDs, and generally up to 2hours in good quality is possible per disc. Various codecs exist, most popular being the original Divx3.11a and the new XviD codecs.

CVD -

CVD is a combination of VCD and SVCD formats, and is generally supported by a majority of DVD players. It supports MPEG2 bit-rates of SVCD, but uses a resolution of 352x480(ntsc) as the horizontal resolution is generally less important. Currently no groups release in CVD.

DVD-R -

Is the recordable DVD solution that seems to be the most popular (out of DVD-RAM, DVD-R and DVD+R). it holds 4.7gb of data per side, and double sided discs are available, so discs can hold nearly 10gb in some circumstances. SVCD mpeg2 images must be converted before they can be burnt to DVD-R and played successfully. DVD>DVDR copies are possible, but sometimes extras/languages have to be removed to stick within the available 4.7gb.

MiniDVD -

MiniDVD/cDVD is the same format as DVD but on a standard CDR/CDRW. Because of the high resolution/bit-rates, its only possible to fit about 18-21 mins of footage per disc, and the format is only compatible with a few players.

Misc Info

Regional Coding -

This was designed to stop people buying American DVDs and watching them earlier in other countries, or for older films where world distribution is handled by different companies. A lot of players can either be hacked with a chip, or via a remote to disable this.

RCE -

RCE (Regional Coding Enhancement) was designed to overcome "Multiregion" players, but it had a lot of faults and was overcome. Very few titles are RCE encoded now, and it was very unpopular.

Macrovision -

Macrovision is the copy protection employed on most commercial DVDs. Its a system that will display lines and darken the images of copies that are made by sending the VHS signals it can't understand. Certain DVD players (for example the Dansai 852 from Tescos) have a secret menu where you can disable the macrovision, or a "video stabaliser" costs about 30UKP from Maplin (www.maplin.co.uk)

NTSC/PAL -

NTSC and PAL are the two main standards used across the world. NTSC has a higher frame rate than pal (29fps compared to 25fps) but PAL has an increased resolution, and gives off a generally sharper picture. Playing NTSC discs on PAL systems seems a lot easier than vice-versa, which is good news for the Brits An RGB enabled scart lead will play an NTSC picture in full colour on most modern tv sets, but to record this to a VHS tape, you will need to convert it to PAL50 (not PAL60 as the majority of DVD players do.) This is either achieved by an expensive converter box (in the regions of £200+) an onboard converter (such as the Dansai 852 / certain Daewoos / Samsung 709 ) or using a World Standards VCR which can record in any format.

News Sites -

There are generally 2 news sites for film release for p2p and they are:

nforce - VCD Help

Code:

http://www.vcdhelp.com/

Code:

http://www.nforce.nl.

About Release Files

RARset -

The movies are all supplied in RAR form, whether its v2 (rar>.rxx) or v3 (part01.rar > partxx.rar) form.

BIN/CUE -

VCD and SVCD films will extract to give a BIN/CUE. Load the .CUE into notepad and make sure the first line contains only a filename, and no path information. Then load the cue into Nero/CDRWin etc and this will burn the VCD/SVCD correctly. TV rips are released as MPEG. DivX files are just the plain DivX - .AVI

NFO -

An NFO file is supplied with each movie to promote the group, and give general iNFOrmation about the release, such as format, source, size, and any notes that may be of use. They are also used to recruit members and acquire hardware for the group.

SFV -

Also supplied for each disc is an SFV file. These are mainly used on site level to check each file has been uploaded correctly, but are also handy for people downloading to check they have all the files, and the CRC is correct. A program such as pdSFV or hkSFV is required to use these files.

Usenet Information

Access -

To get onto newsgroups, you will need a news server. Most ISPs supply one, but this is usually of poor retention (the amount of time the files are on server for) and poor completition (the amount of files that make it there). For the best service, a premium news server should be paid for, and these will often have bandwidth restrictions in place.

Software -

You will need a newsreader to access the files in the binary newsgroups. There are many different readers, and its usually down to personal opinion which is best. Xnews / Forte Agent / BNR 1 / BNR 2 are amongst the popular choices. Outlook has the ability to read newsgroups, but its recommended to not use that.

Format -

Usenet posts are often the same as those listed on VCDQUALiTY (i.e., untouched group releases) but you have to check the filenames and the description to make sure you get what you think you are getting. Generally releases should come down in .RAR sets. Posts will usually take more than one day to be uploaded, and can be spread out as far as a week.

PAR files -

As well as the .rxx files, you will also see files listed as .pxx/.par . These are PARITY files. Parity files are common in usenet posts, as a lot of times, there will be at least one or two damaged files on some servers. A parity file can be used to replace ANY ONE file that is missing from the rar set. The more PAR files you have, the more files you can replace. You will need a program called SMARTPAR for this.

Scene Tags

PROPER -

Due to scene rules, whoever releases the first Telesync has won that race (for example). But if the quality of that release is fairly poor, if another group has another telesync (or the same source in higher quality) then the tag PROPER is added to the folder to avoid being duped. PROPER is the most subjective tag in the scene, and a lot of people will generally argue whether the PROPER is better than the original release. A lot of groups release PROPERS just out of desperation due to losing the race. A reason for the PROPER should always be included in the NFO.

SUBBED -

In the case of a VCD, if a release is subbed, it usually means it has hard encoded subtitles burnt throughout the movie. These are generally in malaysian/chinese/thai etc, and sometimes there are two different languages, which can take up quite a large amount of the screen. SVCD supports switch able subtitles, so some DVDRips are released with switch able subs. This will be mentioned in the NFO file if included.

UNSUBBED -

When a film has had a subbed release in the past, an Unsubbed release may be released

LIMITED -

A limited movie means it has had a limited theater run, generally opening in less than 250 theaters, generally smaller films (such as art house films) are released as limited.

INTERNAL -

An internal release is done for several reasons. Classic DVD groups do a lot of .INTERNAL. releases, as they wont be dupe'd on it. Also lower quality theater rips are done INTERNAL so not to lower the reputation of the group, or due to the amount of rips done already. An INTERNAL release is available as normal on the groups affiliate sites, but they can't be traded to other sites without request from the site ops. Some INTERNAL releases still trickle down to IRC/Newsgroups, it usually depends on the title and the popularity. Earlier in the year people referred to Centropy going "internal". This meant the group were only releasing the movies to their members and site ops. This is in a different context to the usual definition.

STV -

Straight To Video. Was never released in theaters, and therefore a lot of sites do not allow these.

OTHER TAGS -

*WS* for widescreen (letterbox)

*FS* for Fullscreen.

RECODE -

A recode is a previously released version, usually filtered through TMPGenc to remove subtitles, fix color etc. Whilst they can look better, its not looked upon highly as groups are expected to obtain their own sources.

REPACK -

If a group releases a bad rip, they will release a Repack which will fix the problems.

NUKED -

A film can be nuked for various reasons. Individual sites will nuke for breaking their rules (such as "No Telesyncs") but if the film has something extremely wrong with it (no soundtrack for 20mins, CD2 is incorrect film/game etc) then a global nuke will occur, and people trading it across sites will lose their credits. Nuked films can still reach other sources such as p2p/usenet, but its a good idea to check why it was nuked first in case. If a group realise there is something wrong, they can request a nuke.

NUKE REASONS :: this is a list of common reasons a film can be nuked for (generally DVDRip)

** BAD A/R ** :: bad aspect ratio, ie people appear too fat/thin

** BAD IVTC ** :: bad inverse telecine. process of converting framerates was incorrect.

** INTERLACED ** :: black lines on movement as the field order is incorrect.

DUPE -

Dupe is quite simply, if something exists already, then theres no reason for it to exist again without proper reason.

About FTP

Setting Up A Ftp:

Well, since many of us have always wondered this, here it is. Long and drawn out. Also, before attempting this, realize one thing; You will have to give up your time, effort, bandwidth, and security to have a quality ftp server.

That being said, here it goes. First of all, find out if your IP (Internet Protocol) is static (not changing) or dynamic (changes everytime you log on). To do this, first consider the fact if you have a dial up modem. If you do, chances are about 999 999 out of 1 000 000 that your IP is dynamic. To make it static, just go to a place like h*tp://www.myftp.org/ to register for a static ip address.

You'll then need to get your IP. This can be done by doing this:

Going to Start -> Run -> winipcfg or www.ask.com and asking 'What is my IP?'

After doing so, you'll need to download an FTP server client. Personally, I'd recommend G6 FTP Server, Serv-U FTPor Bullitproof v2.15 all three of which are extremely reliable, and the norm of the ftp world.

You can download them on this site: h*tp://www.liaokai.com/softw_en/d_index.htm

First, you'll have to set up your ftp. For this guide, I will use step-by-step instructions for G6. First, you'll have to go into 'Setup -> General'. From here, type in your port # (default is 21). I recommend something unique, or something a bit larger (ex: 3069). If you want to, check the number of max users (this sets the amount of simultaneous maximum users on your server at once performing actions - The more on at once, the slower the connection and vice versa).

The below options are then chooseable:

-Launch with windows

-Activate FTP Server on Start-up

-Put into tray on startup

-Allow multiple instances

-Show "Loading..." status at startup

-Scan drive(s) at startup

-Confirm exit

You can do what you want with these, as they are pretty self explanatory. The scan drive feature is nice, as is the 2nd and the last option. From here, click the 'options' text on the left column.

To protect your server, you should check 'login check' and 'password check', 'Show relative path (a must!)', and any other options you feel you'll need. After doing so, click the 'advanced' text in the left column. You should then leave the buffer size on the default (unless of course you know what you're doing ), and then allow the type of ftp you want.

Uploading and downloading is usually good, but it's up to you if you want to allow uploads and/or downloads. For the server priority, that will determine how much conventional memory will be used and how much 'effort' will go into making your server run smoothly.

Anti-hammering is also good, as it prevents people from slowing down your speed. From here, click 'Log Options' from the left column. If you would like to see and record every single command and clutter up your screen, leave the defaults.

But, if you would like to see what is going on with the lowest possible space taken, click 'Screen' in the top column. You should then check off 'Log successful logins', and all of the options in the client directry, except 'Log directory changes'. After doing so, click 'Ok' in the bottom left corner.

You will then have to go into 'Setup -> User Accounts' (or ctrl & u). From here, you should click on the right most column, and right click. Choose 'Add', and choose the username(s) you would like people to have access to.

After giving a name (ex: themoonlanding), you will have to give them a set password in the bottom column (ex: wasfaked). For the 'Home IP' directory, (if you registered with a static server, check 'All IP Homes'. If your IP is static by default, choose your IP from the list. You will then have to right click in the very center column, and choose 'Add'.

From here, you will have to set the directory you want the people to have access to. After choosing the directory, I suggest you choose the options 'Read', 'List', and 'Subdirs', unless of course you know what you're doing . After doing so, make an 'upload' folder in the directory, and choose to 'add' this folder seperately to the center column. Choose 'write', 'append', 'make', 'list', and 'subdirs'. This will allow them to upload only to specific folders (your upload folder).

Now click on 'Miscellaneous' from the left column. Choose 'enable account', your time-out (how long it takes for people to remain idle before you automatically kick them off), the maximum number of users for this name, the maximum number of connections allowed simultaneously for one ip address, show relative path (a must!), and any other things at the bottom you'd like to have. Now click 'Ok'.

**Requested**

From this main menu, click the little boxing glove icon in the top corner, and right click and unchoose the hit-o-meter for both uploads and downloads (with this you can monitor IP activity). Now click the lightning bolt, and your server is now up and running.

Post your ftp info, like this:

213.10.93.141 (or something else, such as: 'f*p://example.getmyip.com')

User: *** (The username of the client)

Pass: *** (The password)

Port: *** (The port number you chose)

So make a FTP and join the FTP section

Listing The Contents Of A Ftp:

Listing the content of a FTP is very simple.

You will need FTP Content Maker, which can be downloaded from here:

ht*p://www.etplanet.com/download/application/FTP%20Content%20Maker%201.02.zip

1. Put in the IP of the server. Do not put "ftp://" or a "/" because it will not work if you do so.

2. Put in the port. If the port is the default number, 21, you do not have to enter it.

3. Put in the username and password in the appropriate fields. If the login is anonymous, you do not have to enter it.

4. If you want to list a specific directory of the FTP, place it in the directory field. Otherwise, do not enter anything in the directory field.

5. Click "Take the List!"

6. After the list has been taken, click the UBB output tab, and copy and paste to wherever you want it.

If FTP Content Maker is not working, it is probably because the server does not utilize Serv-U Software.

If you get this error message:

StatusCode = 550

LastResponse was : 'Unable to open local file test-ftp'

Error = 550 (Unable to open local file test-ftp)

Error = Unable to open local file test-ftp = 550

Close and restart FTP Content Maker, then try again.

error messages:

110 Restart marker reply. In this case, the text is exact and not left to the particular implementation; it must read: MARK yyyy = mmmm Where yyyy is User-process data stream marker, and mmmm server's equivalent marker (note the spaces between markers and "=").

120 Service ready in nnn minutes.

125 Data connection already open; transfer starting.

150 File status okay; about to open data connection.

200 Command okay.

202 Command not implemented, superfluous at this site.

211 System status, or system help reply.

212 Directory status.

213 File status.

214 Help message. On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user.

215 NAME system type. Where NAME is an official system name from the list in the Assigned Numbers document.

220 Service ready for new user.

221 Service closing control connection. Logged out if appropriate.

225 Data connection open; no transfer in progress.

226 Closing data connection. Requested file action successful (for example, file transfer or file abort).

227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).

230 User logged in, proceed.

250 Requested file action okay, completed.

257 "PATHNAME" created.

331 User name okay, need password.

332 Need account for login.

350 Requested file action pending further information.

421 Too many users logged to the same account

425 Can't open data connection.

426 Connection closed; transfer aborted.

450 Requested file action not taken. File unavailable (e.g., file busy).

451 Requested action aborted: local error in processing.

452 Requested action not taken. Insufficient storage space in system.

500 Syntax error, command unrecognized. This may include errors such as command line too long.

501 Syntax error in parameters or arguments.

502 Command not implemented.

503 Bad sequence of commands.

504 Command not implemented for that parameter.

530 Not logged in.

532 Need account for storing files.

550 Requested action not taken. File unavailable (e.g., file not found, no access).

551 Requested action aborted: page type unknown.

552 Requested file action aborted. Exceeded storage allocation (for current directory or dataset).

553 Requested action not taken. File name not allowed.

Active FTP vs. Passive FTP, a Definitive Explanation

Introduction

One of the most commonly seen questions when dealing with firewalls and other Internet connectivity issues is the difference between active and passive FTP and how best to support either or both of them. Hopefully the following text will help to clear up some of the confusion over how to support FTP in a firewalled environment.

This may not be the definitive explanation, as the title claims, however, I've heard enough good feedback and seen this document linked in enough places to know that quite a few people have found it to be useful. I am always looking for ways to improve things though, and if you find something that is not quite clear or needs more explanation, please let me know! Recent additions to this document include the examples of both active and passive command line FTP sessions. These session examples should help make things a bit clearer. They also provide a nice picture into what goes on behind the scenes during an FTP session. Now, on to the information...

The Basics

FTP is a TCP based service exclusively. There is no UDP component to FTP. FTP is an unusual service in that it utilizes two ports, a 'data' port and a 'command' port (also known as the control port). Traditionally these are port 21 for the command port and port 20 for the data port. The confusion begins however, when we find that depending on the mode, the data port is not always on port 20.

Active FTP

In active mode FTP the client connects from a random unprivileged port (N > 1024) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.

From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened:

FTP server's port 21 from anywhere (Client initiates connection)

FTP server's port 21 to ports > 1024 (Server responds to client's control port)

FTP server's port 20 to ports > 1024 (Server initiates data connection to client's data port)

FTP server's port 20 from ports > 1024 (Client sends ACKs to server's data port)

In step 1, the client's command port contacts the server's command port and sends the command PORT 1027. The server then sends an ACK back to the client's command port in step 2. In step 3 the server initiates a connection on its local data port to the data port the client specified earlier. Finally, the client sends an ACK back as shown in step 4.

The main problem with active mode FTP actually falls on the client side. The FTP client doesn't make the actual connection to the data port of the server--it simply tells the server what port it is listening on and the server connects back to the specified port on the client. From the client side firewall this appears to be an outside system initiating a connection to an internal client--something that is usually blocked.

Active FTP Example

Below is an actual example of an active FTP session. The only things that have been changed are the server names, IP addresses, and user names. In this example an FTP session is initiated from testbox1.slacksite.com (192.168.150.80), a linux box running the standard FTP command line client, to testbox2.slacksite.com (192.168.150.90), a linux box running ProFTPd 1.2.2RC2. The debugging (-d) flag is used with the FTP client to show what is going on behind the scenes. Everything in red is the debugging output which shows the actual FTP commands being sent to the server and the responses generated from those commands. Normal server output is shown in black, and user input is in bold.

There are a few interesting things to consider about this dialog. Notice that when the PORT command is issued, it specifies a port on the client (192.168.150.80) system, rather than the server. We will see the opposite behavior when we use passive FTP. While we are on the subject, a quick note about the format of the PORT command. As you can see in the example below it is formatted as a series of six numbers separated by commas. The first four octets are the IP address while the second two octets comprise the port that will be used for the data connection. To find the actual port multiply the fifth octet by 256 and then add the sixth octet to the total. Thus in the example below the port number is ( (14*256) + 178), or 3762. A quick check with netstat should confirm this information.

testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2

Connected to testbox2.slacksite.com.

220 testbox2.slacksite.com FTP server ready.

Name (testbox2:slacker): slacker

---> USER slacker

331 Password required for slacker.

Password: TmpPass

---> PASS XXXX

230 User slacker logged in.

---> SYST

215 UNIX Type: L8

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> ls

ftp: setsockopt (ignored): Permission denied

---> PORT 192,168,150,80,14,178

200 PORT command successful.

---> LIST

150 Opening ASCII mode data connection for file list.

drwx------ 3 slacker users 104 Jul 27 01:45 public_html

226 Transfer complete.

ftp> quit

---> QUIT

221 Goodbye.

Passive FTP

In order to resolve the issue of the server initiating the connection to the client a different method for FTP connections was developed. This was known as passive mode, or PASV, after the command used by the client to tell the server it is in passive mode.

In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1024 and N+1). The first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command. The result of this is that the server then opens a random unprivileged port (P > 1024) and sends the PORT P command back to the client. The client then initiates the connection from port N+1 to port P on the server to transfer data.

From the server-side firewall's standpoint, to support passive mode FTP the following communication channels need to be opened:

FTP server's port 21 from anywhere (Client initiates connection)

FTP server's port 21 to ports > 1024 (Server responds to client's control port)

FTP server's ports > 1024 from anywhere (Client initiates data connection to random port specified by server)

FTP server's ports > 1024 to remote ports > 1024 (Server sends ACKs (and data) to client's data port)

In step 1, the client contacts the server on the command port and issues the PASV command. The server then replies in step 2 with PORT 2024, telling the client which port it is listening to for the data connection. In step 3 the client then initiates the data connection from its data port to the specified server data port. Finally, the server sends back an ACK in step 4 to the client's data port.

While passive mode FTP solves many of the problems from the client side, it opens up a whole range of problems on the server side. The biggest issue is the need to allow any remote connection to high numbered ports on the server. Fortunately, many FTP daemons, including the popular WU-FTPD allow the administrator to specify a range of ports which the FTP server will use. See Appendix 1 for more information.

The second issue involves supporting and troubleshooting clients which do (or do not) support passive mode. As an example, the command line FTP utility provided with Solaris does not support passive mode, necessitating a third-party FTP client, such as ncftp.

With the massive popularity of the World Wide Web, many people prefer to use their web browser as an FTP client. Most browsers only support passive mode when accessing ftp:// URLs. This can either be good or bad depending on what the servers and firewalls are configured to support.

Passive FTP Example

Below is an actual example of a passive FTP session. The only things that have been changed are the server names, IP addresses, and user names. In this example an FTP session is initiated from testbox1.slacksite.com (192.168.150.80), a linux box running the standard FTP command line client, to testbox2.slacksite.com (192.168.150.90), a linux box running ProFTPd 1.2.2RC2. The debugging (-d) flag is used with the FTP client to show what is going on behind the scenes. Everything in red is the debugging output which shows the actual FTP commands being sent to the server and the responses generated from those commands. Normal server output is shown in black, and user input is in bold.

Notice the difference in the PORT command in this example as opposed to the active FTP example. Here, we see a port being opened on the server (192.168.150.90) system, rather than the client. See the discussion about the format of the PORT command above, in the Active FTP Example section.

testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2

Connected to testbox2.slacksite.com.

220 testbox2.slacksite.com FTP server ready.

Name (testbox2:slacker): slacker

---> USER slacker

331 Password required for slacker.

Password: TmpPass

---> PASS XXXX

230 User slacker logged in.

---> SYST

215 UNIX Type: L8

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> passive

Passive mode on.

ftp> ls

ftp: setsockopt (ignored): Permission denied

---> PASV

227 Entering Passive Mode (192,168,150,90,195,149).

---> LIST

150 Opening ASCII mode data connection for file list

drwx------ 3 slacker users 104 Jul 27 01:45 public_html

226 Transfer complete.

ftp> quit

---> QUIT

221 Goodbye.

Summary

The following chart should help admins remember how each FTP mode works:

Active FTP :

command : client >1024 -> server 21

data : client >1024 <- server 20

Passive FTP :

command : client >1024 -> server 21

data : client >1024 -> server >1024

A quick summary of the pros and cons of active vs. passive FTP is also in order:

Active FTP is beneficial to the FTP server admin, but detrimental to the client side admin. The FTP server attempts to make connections to random high ports on the client, which would almost certainly be blocked by a firewall on the client side. Passive FTP is beneficial to the client, but detrimental to the FTP server admin. The client will make both connections to the server, but one of them will be to a random high port, which would almost certainly be blocked by a firewall on the server side.

Luckily, there is somewhat of a compromise. Since admins running FTP servers will need to make their servers accessible to the greatest number of clients, they will almost certainly need to support passive FTP. The exposure of high level ports on the server can be minimized by specifying a limited port range for the FTP server to use. Thus, everything except for this range of ports can be firewalled on the server side. While this doesn't eliminate all risk to the server, it decreases it tremendously.

Advanced Shellcoding Techniques

Introduction

This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper. I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes. I do not claim to have invented any of these techniques, except for the one that uses the div instruction.

The multiplicity of mul

This technique was originally developed by Sorbo of darkircop.net. The mul instruction may, on the surface, seem mundane, and it's purpose obvious. However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful. First some background information on the mul instruction itself.

mul performs an unsigned multiply of two integers. It takes only one operand, the other is implicitly specified by the %eax register. So, a common mul instruction might look something like this:

movl $0x0a,%eax

mul $0x0a

This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10. The result is then implicitly stored in EDX:EAX. The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).

So, now comes the ever-important question. How can we use these attributes to our advantage when writing shellcode? Well, let's think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode. It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication. Let's put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0? The answer, as you may have guessed, is 0. I think it's about time for some example code, so here it is:

xorl %ecx,%ecx

mul %ecx

What is this shellcode doing? Well, it 0's out the %ecx register using the xor instruction, so we now know that %ecx is 0. Then it does a mul %ecx, which as we just learned, multiplies it's operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX. So, regardless of %eax's previous contents, %eax must now be 0. However that's not all, %edx is 0'd now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax. Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.

The div instruction

Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax. Also like, mul it stores the result of the divide in %eax. Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction. But first, let's think about what is normally stored in the %eax register. The %eax register holds the return value of functions and/or syscalls. Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur). So, if we know that after a syscall is performed, %eax will have a non-zero value, and that the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax. So...how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80. It just so happens that the syscall that corresponds to the value 1 is exit(). Now for an example:

xorl %ebx,%ebx

mul %ebx

push %edx

pushl $0x3268732f

pushl $0x6e69622f

mov %esp, %ebx

push %edx

push %ebx

mov %esp,%ecx

movb $0xb, %al #execve() syscall, doesn't return at all unless it fails, in which case it returns -1

int $0x80

divl %eax # -1 / -1 = 1

int $0x80

Now, we have a 3 byte exit function, where as before it was 5 bytes. However, there is a catch, what if a syscall does return 0? Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero. Some people say that exit's are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly. They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn't worth keeping. However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system. So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can't wipe all the logs, at least this part of your presence will be clear.

Unlocking the power of leal

The leal instruction is an often neglected instruction in shellcode, even though it is quite useful. Consider this short piece of shellcode.

xorl %ecx,%ecx

leal 0x10(%ecx),%eax

This will load the value 17 into eax, and clear all of the extraneous bits of eax. This occurs because the leal instruction loads a variable of the type long into it's desitination operand. In it's normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts. However, since ecx is 0'd and 0+17=17, we load the value 17 into eax instead of any kind of actual address. In a normal shellcode we would do something like this, to accomplish the same thing:

xorl %eax,%eax

movb $0x10,%eax

I can hear you saying, but that shellcode is a byte shorter than the leal one, and you're quite right. However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn't counted. Here's an example:

xorl %eax,%eax

xorl %ebx,%ebx

movb $0x17,%al

int $0x80

xorl %ebx,%ebx

leal 0x17(%ebx),%al

int $0x80

Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8. Again, I hear you saying but that's only one byte it doesn't make that much of a difference, and you're right, here it doesn't make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.

Conclusion

I hope you all learned something, and will go out and apply your knowledge to create smaller and better shellcodes. If you know who invented the leal technique, please tell me and I will credit him/her.

8 People Can Use The Same Msn Dial Up Account

8 People Can Use The Same Msn Dial Up Account

its easy really. want to have an entire family on dial-up with just one bill?

step one. purchase 20 dollar a month subscription to MSN unlimited access dial up. This will include an MSN 9 cd which you will need. With the software installed, fill up your secondary account slots with new users. Make sure you pick @msn if it gives you the choice, hotmail email addresses will not work..

say the secondary account is johnsmith@msn.com type in the Dial up connection

USER : MSN/johnsmith

PASS: ******* (whatever)

connect to your local msn phone number and the other people you gave secondary accounts to will be able to do the same, while you are connected. Its a sweet deal considering everyone is paying about 2 bucks a month for internet access, especially if you cannot get broadband. if you wanted to sell off the access to people you could actually make money doing this.. but i do not suggest it.

I used to be an msn tech and this was a little known secret even to most of the employees.

After you do this you do not need the software any more. I would suggest keeping it on to micromanage everyone else's accounts. and for the simple fact that if they don't pitch in, cut them off HEHEHE

i'm on broadband now so i dont care if i tell you my little secret. anyone else knew of this?