Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

As promised, Jerrold technical expose part 1.

7 views
Skip to first unread message

johnw...@my-dejanews.com

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
Here is the first part of our series of technical documentation on CATV
systems. We will follow up by the end of the week with a full DIY data logger
project, allowing you to monitor head end data streams as well viewing the
data emitted from any cube.

Enjoy.

*** TECHNICAL INTRODUCTION TO THE CONDITIONAL ACCESS ***
*** CONTROL MECHANISM USED BY JERROLD CABLE SYSTEMS ***


Requests / Comments / Corrections to johnw...@my-dejanews.com


PLEASE NOTE:

IN THE UNITED KINGDOM SECTION 297 OF THE 1988 COPYRIGHTS, DESIGNS, & PATENTS
ACT MAKES THE UNAUTHORISED RECEPTION OF ANY PAY TV BROADCAST A CRIMINAL
OFFENCE REGARDLESS OF THE TRANSMISSION MEDIA. PROPOSED EUROPEAN LEGISLATION
WILL ALSO OUTLAW UNAUTHORISED RECEPTION OF PAY TV SERVICES.

IF YOU USE THE INFORMATION CONTAINED IN THIS DOCUMENT OR ANY OTHER TECHNIQUES
TO DEFEAT CONDITIONAL ACCESS SYSTEMS YOU ARE COMMITTING A CRIMINAL OFFENCE.
CLAIMING YOU ARE PLACING THE BOX INTO "TEST" MODE TO "CHECK" CONVERTOR
OPERATION IS NO DEFENCE. ALL TESTCHIPS / CUBES ENABLE ALL CHANNELS THEY DO *
NOT * PLACE THE BOX INTO A "TEST" MODE. SELLING SUCH DEVICES WHOSE PRIMARY
PURPOSE IS TO DEFRAUD THE CATV COMPANY WILL ADD CONSPIRACY TO THE INDICTMENT.

*MY* interpretation of the law is that it is still ILLEGAL TO RECEIVE CABLE
TV SYSTEMS BY DEFEATING THE CONDITIONAL ACCESS SYSTEM EVEN IF YOU INFORM YOUR
CATV COMPANY, THEY MUST *AGREE* (and I'd suggest you get it in writing) TO
YOU USING YOUR OWN DECODER, OTHERWISE YOU ARE STILL RECEIVING THEIR SIGNAL
WITHOUT THEIR AUTHORISATION.

In this document the trademarks GI / Jerrold together with the model numbers
of the cable boxes are only used for product identification purposes and DO
NOT IMPLY any connection with the GI / Jerrold corporation. All trademarks
are acknowledged as the property of their respective owners.

If anybody cares as to the purpose of this document it is to illustrate the
design mistakes made in the implemention of the conditional access system
developed by General Instruments / Jerrold which led to the complete
unrecoverable compromise of their system. Experience gained by the
cryptography / security research community has shown time and time again that
closed design procedures in conjunction with the absence of open public
review lead to the fielding of systems whose primary security objectives are
consistently not achieved.


*** OVER THE AIR DATA FORMAT FOR ENCODING AND TRANSMISSION ***

Jerrold cable systems are addressed over an outband control channel which has
byte data modulated via Frequency Shift Keying onto an RF carrier (122.8Mhz
in the UK, 96.5 / 98.5 or 108.5 Mhz in the USA depending on where you live),
TOGETHER with an inband system carrying information needed to descramble the
picture contained in unused parts of the Vertical Blanking Interval.

Frequency Shift Keying(FSK) is the digital equivalent to analogue FM
transmission, the data bits (ones and zeros) are represented by lowering or
raising the transmission carrier frequency, approximately +- 25 Khz deviation
is used on this system.

At the transport layer of the protocol the data is Manchester encoded to
allow synchronous clock recovery by the decoder.

The Manchester encoding is carried out before transmission. This means that
information neccessary to recover the timing of the data is embedded within
the data. This is achieved simply in practice:

Manchester encoding involves splitting every bit into two bit "cells". The
first bit cell in any bit is set to the OPPOSITE of the preceding bit cell,
to ensure that there are regular transitions within the data for the box to
keep its timing locked to.

IT IS THE SECOND BIT "CELL" WITHIN EACH BIT THAT ACTUALLY CARRIES THE DATA
FOR THAT BIT.

EACH COMPLETE BIT IS 72 MICROSECONDS IN TIME, SO EACH OF THE TWO BIT CELLS
ARE 36 MICROSECONDS LONG. The box is actually fairly lax about the exact bit
length and will accept data a few microseconds too long or short.

The data is transmitted a byte at a time serially. Each byte is sent as:

1) START bit, as a HIGH bit for 1 whole bit period (72 us).
(NOT MANCHESTER ENCODED) - this allows for byte synchronisation.
2) 8 data bits, sent INVERTED with the LEAST SIGNIFICANT BIT first.
3) PARITY BIT, LOW for even parity / HIGH for odd parity.
4) STOP BIT, as a LOW bit.

Thus the complete encoded transmission of a single byte is as follows:

Time in
microseconds

0 Set the output high for the start of the start bit
72 toggle the output to act as the manchester bitcell of the nextbit
108 Send the LSB (BIT 0) of the Data Byte INVERTED.
144 toggle the output to act as the manchester bitcell of the nextbit
180 Send the next lowest bit (BIT 1) of the Data Byte INVERTED.
216 toggle the output to act as the manchester bitcell of the nextbit
252 Send the BIT 2 of the Data Byte INVERTED.

... continue until you've sent all 8 of the data bits in the above manner ...

648 toggle the output as the manchester bitcell of the PARITY bit
684 Send the Parity bit, it is LOW if all the data bits when XOR'd
together are equal to 0, and HIGH if the XOR sum of all data bits
equals 1.
720 toggle the output as the manchester bitcell of the STOP bit
756 Set the output LOW for the STOP bit.
792 FINISHED SENDING BYTE - START SENDING START BIT OF NEXT BYTE !


EXAMPLE MANCHESTER ENCODING TRANSMIT ROUTINE FOR THE PIC :-


The following routine will transmit a byte placed in the W register
as Manchester encoded data out of BIT 0 of the GPIO Port.

This routine is for a pic 12c5xx series PIC but will work happily on most
other PIC's by changing all instances of GPIO to PORTA or PORTB, depending on
the output port you wish to use. THE DATA IS ALWAYS OUTPUT ON THE PIN
CORRESPONDING TO PORT BIT 0. On a PIC 12cXXX series chip this is Pin 7.

Processor clock rate is 4 Mhz, all delays will need recalibrating if clock
speed is changed.

NO TIMING is needed between calls to the routine, correct stop bit length is
internally calculated.

All temporary variables are initiallised inside the code and do not need to
be set to anything before calling, consider them trashed upon return.

--------------- Cut Here ----------------------------------------

cblock 0x07 ; change to last register address + 1
; if using a different PIC processor
xmithreg
xmitbitcount
parity
delaycount
checksum
endc

; byte to be TX in W

xmitbyte ; Encode / Transmit byte
btfsc TMR0,7
goto xmitbyte

addwf checksum,F ;
movwf xmithreg ;
bsf parity,0 ; initialise bit 0 in parity
; register to
movlw 0x08 ;
movwf xmitbitcount ;
bsf GPIO,0 ; set bit -> 1
movlw 23 ; 46 @ 8Mhz, 22 @ 4Mhz

clrwdt
movwf delaycount ; =3w
dlylp1
decfsz delaycount,F ; delay 142 clocks
goto dlylp1

byteloop ;
comf GPIO,F ; complement GPIO store result in
; a file register (rather than W)
movlw 9 ; 20 @ 8Mhz, 9 @ 4Mhz

clrwdt
movwf delaycount ; =3w
dlylp2
decfsz delaycount,F ;
goto dlylp2

rrf xmithreg,F ; rotate right (LSB 1st) into C
movf STATUS,W ; C is status:0 into W
xorwf parity,F ;
xorwf GPIO,W ;
andlw 0x01 ; mask bit 0
btfsc STATUS,Z ; check zero flag
comf GPIO,F ;
movlw 10 ; 21 @ 8Mhz, 10 @ 4Mhz

movwf delaycount ; =3w, 72-4=68 clk needed
dlylp3
decfsz delaycount,F ;
goto dlylp3 ; delay loop

decf xmitbitcount,F ;
btfss STATUS,Z ;
goto byteloop ;
clrwdt
comf GPIO,F ;
movlw 10 ;

movwf delaycount ; =3w
dlylp4
decfsz delaycount,F ;
goto dlylp4 ; 72-6=66 clk needed

movf parity,W ; parity into W
xorwf GPIO,W ; xor parity with output
andlw 0x01 ; mask bit 0
btfsc STATUS,Z ; check zero flag
comf GPIO,F ;
testpoint ;
movlw 11 ; 22 @ 8Mhz, 11 @ 4Mhz
clrwdt
movwf delaycount ; =3w
dlylp5
decfsz delaycount,F ;
goto dlylp5 ; 72-2=70 clk needed

comf GPIO,F ;
movlw 11 ; 22 @ 8Mhz, 11 @ 4Mhz
clrwdt
movwf delaycount ; =3w
dlylp6
decfsz delaycount,F ;
goto dlylp6 ; 72-2=70 clk needed

bcf GPIO,0 ;

movlw 0xE1 ; function overhead - number of cycles
; in 36uS ; BD @ 8 Mhz, E1 @ 4Mhz
movwf TMR0
return ;

--------------- END OF FILE -------------------------------------

*** INTRODUCTION TO COMMAND FORMAT ***


The commands are organised as a series of bytes of variable length, separated
by a padding sequence of 0xFF's (usually 6 or more).

Let's start with the important ones - the channel activate commands :-

04 FD 7F nn CHK
&
04 FD 81 nn CHK

The above two commands are global commands (meaning that they act on every
box on a given system) that turn on the channels in a box. nn is the channel
number from 0 - 7F. CHK is the checksum; every command ends with a checksum
to validate command integrity. The checksum is calculated so that when all
the bytes in a command are added together modulo 8 bits, the result sums to
zero. i.e. CHK = 0 - (sum of all commands MOD 0xFF)

These two commands USED TO BE used by all the first generation cubes in order
to activate all channels. Jerrold realised they constituted an extremely
serious security flaw and removed them from all models numbers starting
(I)CFT.

These commands were replaced by BOX SPECIFIC commands, these commands address
a single box by having the box's ADDRESS in the command.

These two updated commands became :

07 FD 9F LA LA LA LA nn CHK
&
07 FD A1 LA LA LA LA nn CHK

where LA LA LA LA are the 4 byte address of the box. This caused a major
problem for the cube designers, NOTE THAT THE SERIAL NUMBER ON THE BOX IS
*NOT* THE SAME AS THE BOX'S ADDRESS. The cable company uses the box's serial
number (printed on the underside barcode label) to load the box with a
specific address. Since they chose the address and loaded it in to the box,
they are the only ones that know it. And you as the box's owner can't enable
all the channels because you don't know your box's address.

This was perfect EXCEPT somebody soon figured out that if the Cable Co. can
load an address then so can you ! So in came the 2nd generation "serial
number entry cubes". These cubes required you to enter the serial number of
the box under "test" so that the cube could then load in a chosen address and
then activate all channels on that address.

The bad side effect being that IF you tried "testing" a cable co. owned
rented box then you erased your assigned address, and screwed your box up.

0C FD 5F LA LA LA LA SN SN SN SN SN CHK

is the command used by a cube to load in an address from serial number.

LA LA LA LA represent the 4 bytes of your chosen address - cubes commonly use
E0 BF 7F 3E.

SN SN SN SN SN represent the BCD encoded version of the boxes serial number
as obtained by pressing F then 2 on the remote control. The right hand digits
on the display are your serial number displayed in order.

i.e. if you pressed F2 and your box displayed
01 then 19 then 21 then 39 then 41 then 59 then 61 then 79 then 81 then 99.

Then taking the right hand digits in order. Your serial number would be
1919191919 and would be entered into the command as

0C FD 5F E0 BF 7F 3E 19 19 19 19 19 CHK

to give your box an address of E0 BF 7F 3E.


In the latest range of boxes the ICFT 2100's in the UK and CFT2200's in the
USA, the above activation commands were removed again !

This time the remaining working commands changed dramatically - but were soon
discovered again.

07 E9 LA LA LA LA xx CHK
to 07 F7 LA LA LA LA xx CHK

xx now represents a bitfield for a group of 8 channels.
The E9 command controls channels 0 -7, EA controls channels 8 - 15 and so on,
up to command F7 controlling channels 120 - 127

So to activate all channels on a CFT 21xx / 22xx series box :-
we have to cycle through all commands from E9 to F7 with xx being set to OxFF
(hex byte with all bits on).

The same technique of using FD 5F to load in a chosen address and then sending
all activate commands to that address will still work on the CFT2100 and is in
fact still in use by many current cubes.

Now that the activate commands have been covered, the main thing left is the
tricky problem of how to discover the box's cable co. assigned address because
using the serial number entry mode will stop the cable co. being able to
address the box and is a damning flag indicating that fraud has occurred !

New cubes use a variety of methods to find the correct address for the box
without changing it.

Some of them, take the brute force approach and send activate commands to all
possible addresses. This has the advantage of requiring no user interaction
but the main disadvantage of taking forever to activate the box.
Optimisations can and are made to reduce the potentially life threatening wait
in a brute force cube by taking advantage of patterns discovered in the
allocation of box addresses.

The box address is 4 bytes long or 32 bits. This means that there are
theoretically 2^32 possible addresses or a little over 4 billion ! This is
completely impractical for a cube to try and send out 4 billion different
activation commands.
However :-
The addresses in use always start with the first byte set to 0xE0. The 2nd
byte only ranges from 0x80 to 0xBF, The 3rd byte ranges from 0x40 to 0x7F,
and the 4th byte ranges from 0x00 to 0x3F.

The result of all these constraints means that there is no variation in the
first byte and only 6 bits of effective address in the 2nd to 4th bytes. So
the complete EFFECTIVE address is only 3*6 or 18 bits = 262144 possible
addresses.

This is a much more reasonable number and the cube can send the approx.
quarter million activation commands in a little under 4 hours.

The 2nd mechanism used by modern cubes is the intelligent approach to finding
out a box's address. Typically the cube will send out a command that causes a
visible change in the box, and then scan through all possible addresses
quickly until the User notices that the box has been affected and presses a
button to tell the cube that it is near to the correct address.
A recursive method is then used to pin down the exact address used by the box.

An example of this as used by modern cubes is to send a continual stream of
SHUTDOWN (0xF8 command byte) commands to the box, as soon as the box turns
off, the user hits a button.
The cube then slowly counts down addresses sending the TURN ON (0xF9 command
byte) command until the box comes back on, the user hits a button again.
The cube has then found the correct address, and sends the before mentioned
channel activate commands to the newly found address.


Topics to be covered in additional articles :-

Practical data logging - Building your own data logger to examine the
command data channel
Boot sequences - Commented walkthrough.
Subscriber Management - Connection / Disconnection, Global timer
initiallisation and reset.
Architecture of a testchip - 3 wire VS. 4 wire, active filtering VS.
passive coupling.
Advanced cubes - Address extraction, Talkback, Auto Multimode.
Channel Mapping - Look at Channel Mapping commands and parameters.
Multimode - System implementation and countermeasures.
Talkback - Overview, practical use, command protocol.

What do YOU want to see here ?

John
Benedict

Gratefully assisted by many others who are less attention seeking :)

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

magic...@magicboxes.com

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
This is information on my webpage and has been posted by me months ago.

What happened to your super test chip code????

You said you were posting that, not this filler!


Jim

In article <6t8u9v$7bk$1...@nnrp1.dejanews.com>,

magic...@magicboxes.com

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
TWO days ago you promised this:

"I have written an in-depth treatise on test chip/cube construction.

This, along with the details of our new automapping test chips, will be
posted later on today.

Jim may well scoff.

The rest of you would be unwise to miss it.

John." , (POSTED rec.video.cable-tv, johnw...@dejanews.com


and now you provide this garbage?


Why don't you just cut and paste from past posts. You would not have to write
anything then.


Keep your promises JOHN!!

Jim
http://www.magicboxes.com


In article <6t8u9v$7bk$1...@nnrp1.dejanews.com>,
johnw...@my-dejanews.com wrote:

johnw...@my-dejanews.com

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
As per usual more hypocrisy and lies.

Jim this is meant to be a PRODUCTIVE work it is not intended to be a thread
of contention.

If you have some more INFORMATION that you are willing to share with us
please post it and add to this work, If I have made errors then I would
appreciate corrections. However your pitiful attempts at derision contribute
nothing, and merely expose your pathetic point scoring attitude.

SEEING AS YOU KNOW SO MUCH WHY DON'T YOU POST YET MORE INFORMATION AND ADD TO
THE COMMON KNOWLEDGE ?

People can check for themselves whether or not you have posted the same
information we have. I certainly can see no mention on your website of how
the bytes are encoded for transmission, NOR an explanation of how modern
cubes (YES, like your supposed ones) find the correct box address, in fact I
seem to recall you are very cagey on that point and simply claim it to be a
"unique proprietary system". Finally you at no point make any detailed
explanation of any of the channel activate commands that will work on recent
boxes.

I guess it's time for you to update your website pretty damn quick before
sunrise :)

We DID NOT say at any point that we would post the code to our Automappers,
they are a commercial product. What we WILL DO is to post code routines that
people can use to educate themselves and to integrate into their products if
they feel they are suitable.

Furthermore I do not appreciate the fake emails you are claiming to have
received from me at which point I ALLEGEDLY admitted that the automappers
don't exist. The faked quotes from me that you posted have such awful
grammatical construction that it is laughable that you even try to suggest
that I would have written them.

Prove me wrong POST ALL THE EMAILS I HAVE SENT YOU TOGETHER WITH FULL HEADERS
SO THAT THE ORIGINATING IP ADDRESS CAN BE TRACED AND PEOPLE CAN MAKE AN
INDEPENDENT JUDGEMENT FOR THEMSELVES.

I sympathasize with the problem that this faces you with. How could you
possibly fake some email headers from me that will look in the slightest
plausible, when you have never received an email from me to copy ?

John

In article <6t93na$fhr$1...@nnrp1.dejanews.com>,


magic...@magicboxes.com wrote:
> TWO days ago you promised this:
>
> "I have written an in-depth treatise on test chip/cube construction.
>
> This, along with the details of our new automapping test chips, will be
> posted later on today.
>
> Jim may well scoff.
>
> The rest of you would be unwise to miss it.
>
> John." , (POSTED rec.video.cable-tv, johnw...@dejanews.com
>
> and now you provide this garbage?
>
> Why don't you just cut and paste from past posts. You would not have to write
> anything then.
>
> Keep your promises JOHN!!
>
> Jim
> http://www.magicboxes.com

Laurence Taylor

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
In article <6t8u9v$7bk$1...@nnrp1.dejanews.com> johnw...@my-dejanews.com writes:

-> Here is the first part of our series of technical documentation on CATV
-> systems. We will follow up by the end of the week with a full DIY data logger
-> project, allowing you to monitor head end data streams as well viewing the
-> data emitted from any cube.

Now this is the sort of article I like to see - technical information on
the system.

Much more interesting than the usual boring sequence of "How do I get
PPV?" - "Buy one of our boxes" - "rot in hell you criminal scum" etc.

Many thanks for the uplift in quality.

rgds
LAurence


diesc...@painfully.org

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
On Thu, 10 Sep 1998 17:39:15 GMT, magic...@magicboxes.com wrote:

>This is information on my webpage and has been posted by me months ago.
>What happened to your super test chip code????
>
>You said you were posting that, not this filler!

well there is a point here, only thing is that stevieboy and nospam
will make all sorts twists out of it and insist that we are all
thieves (again).

get the ball rolling faster guys, post your info and let the tech
heads here take it to pieces.

the system (GI) has been comprismed years ago as with all new units to
date (DCT the exception). any crud posts will only expose the author
of the fraud that they are.

so in short guys for once and for all, lets end this.

PUT UP OR SHUT UP!

diesc...@painfully.org

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
On Thu, 10 Sep 1998 17:53:47 GMT, magic...@magicboxes.com wrote:

>TWO days ago you promised this:
>
>"I have written an in-depth treatise on test chip/cube construction.

<snip>

>Keep your promises JOHN!!

agreed, for the masses to take any of your code and abilities with a
serious attitude you must follow up on what you say.

this is addressed both to john and jim.

end all of these slugging matches for once and for all.

we are all waiting on you guys.........

johnw...@my-dejanews.com

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
In article <35f8367...@news.indigo.ie>,

diesc...@painfully.org wrote:
> On Thu, 10 Sep 1998 17:53:47 GMT, magic...@magicboxes.com wrote:
>
> >TWO days ago you promised this:
> >
> >"I have written an in-depth treatise on test chip/cube construction.
>
> <snip>
>
> >Keep your promises JOHN!!
>
> agreed, for the masses to take any of your code and abilities with a
> serious attitude you must follow up on what you say.
>
> this is addressed both to john and jim.
>
> end all of these slugging matches for once and for all.
>
> we are all waiting on you guys.........

If you think we haven't lived up to what we said we would offer - then as it
says in the document please tell us what you would like to see. IF WE HAVE
THE INFORMATION OURSELVES WE WILL ANSWER ANY QUESTIONS.,

Posting a single hex file to the group for a test chip is not in my opinion
the best way to stimulate research and development which is the objective of
us releasing information. I think it would have the direct opposite effect of
very effectively killing interest in learning further because very few people
would then explore alternative avenues. Our intentions are not to hand out
pic code on a plate to people who simply want to flog it on with no
comprehension nor interest in how it works.

The information so far released allows anybody with reasonable electronics /
PIC programming skills WHO IS PREPARED TO DO A BIT OF WORK PLAYING AROUND to
build a simple cube that will activate channels.

When we release the data logger then anybody who is interested in
experimenting will be able to look at the command data stream and work out
how to construct a boot sequence to make a testchip.

John Wigley

Zachary Smith

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
Why don't you keep yours?

nospam

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
Who's that? You and the mouse in your pocket?

corrupt1

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
On Fri, 11 Sep 1998 02:06:36 GMT, dl...@hoootomoaoiolo.ocooom (nospam)
wrote:

>Who's that? You and the mouse in your pocket?

Beats the hamster in your arse.


magic...@magicboxes.com

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
What promise haven't I fullfilled?


WHEN EVERYONE said "THERES NO WAY YOU CAN ADDRESS A CFT2200 WITHOUT A SERIAL
NUMBER", I was called every name in the book. But then a weird thing happened
to this newsgroup.

I released the first cube that did. On the day I said I would.

Jim
http://www.magicboxes.com


In article <6t9rht$j...@bgtnsc01.worldnet.att.net>,

John

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
Jim, you are so full of shit......Post the fucking working cube .hex code.
You undercover puke. Don't ignore it, it ain't gonna go away


magic...@magicboxes.com wrote in message
<6tbjvg$uqo$1...@nnrp1.dejanews.com>...

diesc...@painfully.org

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
On Fri, 11 Sep 1998 15:03:57 -0400, "John" <cable...@hotmail.com>
wrote:

>Jim, you are so full of shit......Post the fucking working cube .hex code.
>You undercover puke. Don't ignore it, it ain't gonna go away

to be fair I founnd that Johns post of info on the system to be
accurate, I eckon its your turn now Jim. post at least some different
tech data on the system and then take things from there.

I agree with the idea of not posting PIC codes just for the sake of
posting.

its much beter to find some common ground where any bull can be found
be everyone who knows about the system. I dont really want to break
down hex codes for nights on end only to discover they are crap!

do the right thing Jim, post something tangable. more than whats on
your web site.

nospam

unread,
Sep 12, 1998, 3:00:00 AM9/12/98
to
You've anounced it.

Haven't seen ONE, NOT A SINGLE person post how "great" your unit is.

Must be because it doesn't exsits, cept in your mind.

0 new messages