The fact that Microsoft's stock price has dropped from a high of $120 per share in December of 1999 to around $58 per share today is a pretty good indicator of a company on the ropes, if not dying.
This was modded (Score:5, Insightful) ??? Someone must have found a new supply of three-dollar crack. It sounds more like a troll to me.
Cisco has gone from a high of 82 in March 2000 to a low of under 30 last week. That's a much faster and deeper plunge, and they're hardly "on the ropes".
Dear Decision maker ; We know you are interested in
receiving amazing info ! This is a one time mailing
there is no need to request removal if you won't want
any more . This mail is being sent in compliance with
Senate bill 1622 , Title 6 ; Section 301 . This is
not a get rich scheme ! Why work for somebody else
when you can become rich as few as 85 MONTHS ! Have
you ever noticed how long the line-ups are at bank
machines and people are much more likely to BUY with
a credit card than cash . Well, now is your chance
to capitalize on this ! We will help you process your
orders within seconds & SELL MORE ! You can begin at
absolutely no cost to you ! But don't believe us !
Prof Ames who resides in Alabama tried us and says
"I was skeptical but it worked for me" ! We assure
you that we operate within all applicable laws . We
implore you - act now ! Sign up a friend and your friend
will be rich too . Thanks . Dear Friend , Especially
for you - this hot intelligence . If you no longer
wish to receive our publications simply reply with
a Subject: of "REMOVE" and you will immediately be
removed from our database . This mail is being sent
in compliance with Senate bill 2616 , Title 7 ; Section
303 ! THIS IS NOT MULTI-LEVEL MARKETING . Why work
for somebody else when you can become rich in 22 days
! Have you ever noticed nobody is getting any younger
& the baby boomers are more demanding than their parents
. Well, now is your chance to capitalize on this !
WE will help YOU decrease perceived waiting time by
130% and sell more ! The best thing about our system
is that it is absolutely risk free for you . But don't
believe us . Mrs Ames of Georgia tried us and says
"Now I'm rich many more things are possible" ! This
offer is 100% legal ! So make yourself rich now by
ordering immediately ! Sign up a friend and you'll
get a discount of 60% . Best regards !
Now all we need is a filter which can encode into the typical/. troll post. You know, stuff like "Natalie Portman", "hot grits", "Linux", and "ESR".
And what if your Unix box has a fixed IP? Is it the "shell always available" that you want, or a "dialup shell always available"? The former is easy if you're running your own server somewhere (anywhere) and it has a fixed IP. Just set up SSH and you've got your own shell account.
The latter takes a bit more work, but if you have DSL or a cable modem, and didn't get rid of the second phone line, it can be done. With software like mgetty+sendfax, you can even justify it as a fax line. I've set up my own dial-ups under Linux before, and they could handle shell, PPP, and fax connections. If I'd had a bit more time, I would have figured out how to proxy-arp them to use fixed IPs from my/29 block instead of IP Masquerading.
I like the Q version better because it's all one piece. The IBM one seems to have a "pen cap" to attach to your keychain, and the unit itself snaps out of that. While it will keep the USB port protected, if it falls apart and you have a hole in your pocket, the important half is the one that's going to get lost.
I'd rather have one like the Q, but with an optional cap on the connector end.
And for those of you wondering about Linux support, these things should be just like my PNY Compact Flash/Smart Media reader for USB... it emulates an IDE drive. Actually, the flash cards themselves emulate an IDE drive, and the USB part just acts as a USB to IDE interface.
I used to hide floppies in a river bed (don't ask) and when I needed them I would dig them up, remove the "platter" and put them in a case with dry "pads"
Did you ever hear of this neat new invention they've come up with called "Ziploc Bags"? I think that would have saved you a lot of work.
Once I saw what Eazel was developing was nothing more than Yet Another Browser, I wasn't too impressed.
Jef Raskin refers to the OS as a "program you have to hassle with before you get to hassle with the application." To me, Nautilus seems like just yet another program you have to hassle with before you get to hassle with the application. I don't see how it can make things any easier for me that would make me run Linux as a desktop environment instead of MacOS.
As to the OS itself, I don't really see what it does that gets in your way, aside from maybe requiring you to save your data files in its directory hierarchy. Certainly you can use OS X without having to care that it's running Unix underneath the hood. Much more noticable is that "classic" apps have to run in their own little sandbox, because the OS is different, not because it's there.
Even the Palm OS, which is specifically mentioned as one that doesn't get in your way, is still an OS, and still there. You could run a Palm-like interface on top of Unix and be none the wiser. It seems to me what he has a problem with is the user interface environment, not the OS.
Would such an appliance -- a home browser, word processor, spreadsheet, and game console -- be a popular item that would replace the PC in the household? Wildly so, especially if installing new programs was made simple, such as inserting a disk, selecting its activator key, ejecting the disk and running it, installed on your system until you remove it.
Installing programs under Windoze is a total fuckup because of all the DLLs and inevitable scores of data files that have to be installed along with the application itself. I'm sure InstallShield is making a lot of money off of this. Under MacOS, it is possible to install (properly written) software by simply dragging its icon out of a CD-ROM's Finder window. Such software doesn't even have to be installed; it can usually be run right from the CD-ROM. This used to be common, but nowadays big apps want to be run from an installer because they have so much baggage that goes along with them. OS X will make this easier to do by allowing an application and its files be packaged in a folder that appears to be a single object.
Sure, the Unix basis of OS X can be considered a step backwards when compared to something like BeOS or even the Xerox Smalltalk environment, but the reason to go with it is because it's a solid solution, and it's much better than the ad-hoc design of MacOS, which was never intended to do multitasking. Multitasking the MacOS was an amazing hack.
The scary thing is that I first heard about this yesterday on the cnn.com webpage! (Okay, so I could have heard about it first on Bugtraq if I had been religiously reading it daily, but I hadn't.)
Fortunately I can ssh into my server at home, so I had it upgraded within an hour.
Another scary thing is the CERT graph showing the exploit reports for the NXT bug. I definitely don't want to have an un-upgraded BIND in the peak of that curve.
Besides, if you can launch a spaceship into orbit, then you can launch an ICBM. This is the problem with the technology leaking into China as a result of the laxness of the Clinton administration. Fortunately, so far it looks like right now they'd rather get up into space than threaten everybody with ICBMs.
He means the license on the database itself. Specifically, who owns the rights, etc. Sure would be nice if people undersood what they were replying to before posting meaningless replies on/.
The problem is that the americian public forgot what the space program was for. as exciting as the first moon walk was and as unbelievable the first space shuttle seemed these events where not designed for the public's entertaintment, they where designed to further human knowledge, experience and our reach.
The space program was for one reason. To get up there before the Russians could. There was a rightful fear of what could happen if the Russians established a base in orbit or on the moon and made a nuclear weapons platform up there.
Everything else was just icing.
Besides, if you can launch a spaceship into orbit, then you can launch an ICBM. This is the problem with the technology leaking into China as a result of the laxness of the Clinton administration. Fortunately, so far it looks like right now they'd rather get up into space than threaten everybody with ICBMs.
Lets be honest, the ISS should have been built 10 years ago, it's not as if it couldn't have been, it just wasn't.
Really, we should never have abandoned Skylab after a pitiful three missions. From what I remember seeing of it, it was as spacious as Mir was cramped.
This sounded like a pretty cool hack on the part of DirectTV (whether you agree with them or not), so I decided to take advantage of my ISP's one month news spool of alt.dss.hack to see what was up.
It looks to me like DirectTV (better known to the a.d.h members as "Dave", and not to be confused with "SuperDave", one of the newsgroup regulars) played an ace they've had up their sleeve for a long time. Apparently the boot code (in ROM) of the 8051 in the chip checks one bit in a 32-bit region of PROM (as in you can program it but you can't reset it) and goes into an infinte loop (I think this is what is being referred to as a "looped" card) early during the boot process. Since this is in ROM where it can't be re-programmed, you can't bypass it.
It seems there's also an ASIC in the card that is crucial to the decoding process. I'm guessing that it has to be enabled by the 8051. And if the 8051 "loops" before you can talk to it, you're hosed.
It also seems that there was a recent move to "emulators", which emulated the 8051, but passed commands to the ASIC through to the real card. That way, as long as the card was alive enough to tell it what to do, you would esentially firewall off the card from any nasty code that wanted to do stuff like program write-once bits in the CPU chip. Some people were arguing recently that emulators were overkill, but it seems they have been proven wrong. The only people with hacked cards that still work either had emulators or were lucky enough to pull their cards in time (or the decoder box was unplugged).
Apparently for a couple of weeks now "Dave" has been downloading code to detect illegal cards and test it (by locking up assorted cards and seeing what kind of results they got) before sending down the "ECM" code which caused the card to kill itself.
As to the timing, it is suspected they chose one week before Super Bowl to allow enough time for legitimate users (or those illegitimate users who wanted the better signal in time for The Big Game) to receive new cards.
Here are two messages I found on the newsgroup about all this: (line art removed from the first one because of/.'s lame filter)
From: ump25@aol.com (Ump25)
Newsgroups: alt.dss.hack
Date: 22 Jan 2001 05:38:13 GMT
Subject: EVERYONE READ THIS! INFO FROM MAGICIAN ET. AL.
Message-ID: <20010122003813.16538.00000761@ng-bj1.aol.com&g t;
From Magician and Hypertek comes the following...
As most everybody is aware, the ability of the dynamic code to execute a kill-type ECM was displayed today on "Black Sunday".
First, the bad news: the ECMs wrote 4 bytes to "write once" area of the EEPROM, 8000h-8003h. Unfortunately, one of the bytes that is changed is 8000h, which is checked extremely early in the ROM startup code (003Fh) to see if it contains "33h". These ECMs re-wrote this byte to "00h", which means that it very quickly enters an infinite loop because "P1.7" is not set. Since this area of the H card is "write once", there is no way to reset this byte back to "33h" to allow normal startup to continue, even by way of an unlooper.
Second, for those interested, here are all the EEPROM addresses that were tested to see if they contained modified bytes. Each byte was tested in its own packet (i.e., one address at a time):
code:
- - -
8243 Vector for setting DPTR to ZKT secret vector
8246,8247 Vector for Cmd09 vector
8255 Vector for Ins58 patch vector
8258 Ins44 preprocessing vector
825B Ins44 extras vector
825E Find tier or PPV vector
8264 "EndInsHandling" vector
8273 Cmd1F vector
827C,827D Ins54 vector
8282,8283 Ins18/Ins1A vecotr
8440 First byte of channel blackout data (checked if non-zero)
8582,858C,8593 Cmd60 code
85B7 B7 nano vector
85BE BD nano vector
85C0,85C1,85C2 C0 nano vector
85C3 C3 nano vector
85C6,85C7 C6 nano vector
85E2,85E6,85ED,85EF,85F6 B5 nano code
8606,8608,8611 AddAToDfdNanoBufIfFlOpn code
8630 Deferred Cmd60 processing code
86DD Never-executed portion of old C6 nano code
87A1 Old CF nano jump table
8800 Hash algorithm code
8955 Main loop vector code
8973 Ins18/Ins1A code
8975 Ins54 check code
8982 Setup for Ins38 code
89A0,89A3 Setup for Ins44 code
89A6,89B2,89B9 Setup for Ins4C code
89DF End of main loop vector code
8BFE Cmd0C code
8CC7,8CCA,8CCB Preprocess deferred Cmd60 code
8CD9,8CDE Cmd0B for non-virgin cards code
8CF2,8CFE Ins58 patch code
8D04,8D09,8D0D,8D11,8D14,8D178D1A,8D1D,8D20,8D22 ,8 D24,8D25,8D32 Ins54 code
8D66,8D6A,8D72,8D76 Add ASIC bytes to signature hash code
8DD0,8DD3,8E68 Do 1 hash iteration code
8F2F Preprocess Cmd09 code
8F53 Cmd0C patch 1 code
- - -
Here is an example dynamic code packet (for the 8D1Ah address; all of the addresses were tested using similar packets, except for 8440h which used a JNZ instead of JZ):
code:
- - -
C3 nano used to preset RAM locatiosn 10h-1Fh:
C3 0A 00 20 99 03 AF 01 00 04 00 09 | Seed hash only (using 9 data bytes) results in these bytes at 10h-1Fh:
20 99 03 AF 01 00 04 00 09 CB 29 71 06 19 74 D0
Fourth byte loaded in EEPROM write register
Third byte loaded in EEPROM write register
Hi byte of 1st loop return address and second byte loaded in EEPROM write register
Lo byte of 1st loop return address and first byte loaded in EEPROM write register
Hi byte of 2nd loop return address
Lo byte of 2nd loop return address
Hi byte of 3rd loop return address
Lo byte of 3rd loop return address
What 8D1Ah is compared to
The C9 nano looked like this:
C9 10 20 90 8D 1A E0 47 60 08 90 | Write 15 bytes+RET, execute and hash
80 00 78 15 75 81 16 :
which caused this code to be executed:
893C mov DPTR,#8D1Ah
893F movx A,@DPTR
8940 xrl A,@R1
8941 jz 894Bh
8943 mov DPTR,#8000h
8946 mov R0,#15h
8948 mov SP,#16h
894B ret
- - -
Remember, R1 starts equal to 10h. So the above code does the following:
Compare 8D1Ah to @10h (which contains #20h)
If they match, simply return
Otherwise, set DPTR to 8000h
Set R0 to 15h
Reset the stack to 16h and RET, to resume execution at 0400h to load "00 04 00 09" into EEPROM write register which RETs to 01AFh to enable EEPROM write mode
which RETs to 0399h to write 00 04 00 09 to 8000-8003h.
In addition, there was an ECM to detect an H cards running with non-H CAM IDs, although this packet did not loop the card but simply "locked it up" until the next reset:
code:
- - -
C3 nano used to preset RAM locatiosn 10h-1Fh:
C3 0B 00 FE FC 32 00 00 04 AC 01 68 14 | Seed hash only (using 10 data bytes) results in these bytes at 10h-1Fh:
FE FC 32 00 00 04 AC 01 68 14 8A DF A3 AA 81 34
Hi byte of 1st loop return address
Lo byte of 1st loop return address
Hi byte of 2nd loop return address
Lo byte of 2nd loop return address
Hi byte of 3rd loop return address
Lo byte of 3rd loop return address
Hi byte of 4th loop return address
Lo byte of 4th loop return address
The C9 nano looked like this:
C9 12 20 90 83 74 81 60 07 57 70 | Write 17 bytes+RET, execute and hash
05 09 B9 12 F6 22 75 81 19 :
which caused this code to be executed:
893C mov DPTR,#8374h
893F movx A,@DPTR++
8940 jz 8949h
8942 anl A,@R1
8943 jnz 894Ah
8945 inc R1
8946 cjne R1,#12h,893Fh
8949 ret
894A mov SP,#19h
894D ret
- - -
Remember, R1 starts equal to 10h. So the above code does the following:
If first byte of CAM ID is 00, return (everything OK).
Otherwise, AND first CAM ID byte with byte @10h (#FEh)
If result is non-zero (meaning first CAM ID byte is not 01h), go to ECM routine
Otherwise, AND second CAM ID byte with @11h (#FCh)
If result is non zero, go to ECM routine
Otherwise, return (everything OK)
The ECM routine resets the SP to cause the RET to resume execution at 1468h, which RETs to 01ACh, which RETs to 0400h, which RETs to the infinite loop at 0032h...
From: Spacemonkey Gleep <Fictitious@Dont.Bother.Its.invalid>
Newsgroups: alt.dss.hack
Subject: How Write-Once memory works, or "Why H cards hit by the ECM are never going to be fixed"
Date: Mon, 22 Jan 2001 10:56:12 -0800
Message-ID: <Fictitious-402BA7.10561222012001@news.primenet.com>
In response to the umpty-nine-dozen "Why can't we just..." questions about the corrupted write-once area on the card, here's an explanation that may shed some light. (Note to those "in the know": Yes, I'm simplifying things ridiculously. Not everybody playing in this little sandbox is an EE with the knowledge to understand the inner workings of a chip)
A byte of RAM memory is a set of 8 cells that can hold a one or a zero. Which cells have 1s in them determines the value of the byte when you read it. With RAM, you can change the values any time you like. You can think of that byte as 8 switches that can be turned on or off in different combinations to give you various values.
A byte of ROM is similar, in that it's 8 cells that can each hold a 1 or a 0. Unlike RAM, these 1s and 0s are fixed. Instead of the "switches" that RAM has, you can think of ROM as having either a wire (for a 1) or no wire (for a zero). They can't be changed once made. The wire (or lack of one) is a permanent thing.
A byte of Write-Once memory (Also known as "PROM", or "Programmable Read Only Memory") has characteristics of both RAM and ROM. Like RAM, you *CAN* write to it, under certain circumstances. Like ROM, once written, it's **FOREVER**. Think of a byte of PROM as being 8 microscopic fuses.
When the chip is made, all the fuses are "good". If you could see it at the microscopic level, it would look something like this: ( each | is a fuse that isn't blown )
| | | | | | | |
and would have the value FF, or 255 in decimal.
Now, let's say you want the byte to have the value B7 (That's 183 in decimal, and in binary, it's 10110111) To write that value to it, you deliberately burn out two fuses in the byte, leaving it looking like this: (| = unblown fuse, : = blown fuse)
| : | | : | | |
From that point, it would be possible to write to it again, and change the value, *BUT* there's a catch. You can only "blow" more fuses. You can't "un-blow" fuses that are already blown. This means that a number that needs one of the fuses that's already blown out is going to be impossible to write.
So why is this a problem?
Normally, byte 8000 of the H card holds the value 33 (in Decimal, 51. In binary, 00110011) and the byte looks like this:
: : | | : : | |
But after being hit by DTV's ECM last night, the byte is set to 00 - it looks like this:
: : : : : : : :
There's no fuses left to blow out. They're all gone. That means that forever and always, byte 8000 of your ECMed card is going to say "I'm holding the value 00" when asked.
Why this means the card is permanently dead:
VERY early after the card gets powered up and reset, a check is done:
Does byte 8000 hold the value 33?
If the answer to that question is yes, then all is right with the world, and things start happening. The card gets initialized, spits out the ATR string, and then goes into "wait for a command from the IRD" mode. If, on the other hand, the answer is no, then the card goes into an infinite loop that does nothing. If you program in BASIC, it's the equivalent of the line
10 GOTO 10
NOTHING gets done until the next time the card is reset. And then the same thing happens all over again.
This check is in the card's ROM, so it can't be bypassed or changed.
Reprogramming the card won't do anything useful, since the ROM doesn't even get looked at, let alone messed with, by programmers (or unloopers, for that matter) and even if it did, it wouldn't do anything useful, since ROM can't be changed (short of actually damaging it).
So how can it be fixed?
The simple answer: It can't. Congratulations. Your H card is now an ice scraper. Get used to it. Life sucks.
The more extended answer:
If you've got the micro-tools to "rebuild" the blown fuses on the chip, you could go that route, but unless you're a chip manufacturer, or have access to that type of equipment somehow, you ain't got a prayer. We're talking about electron microscopes, tools for depositing single atoms onto the silicon wafer itself, that sort of thing. In other words, trying to do it is going to mean more money, knowledge, equipment, and effort than most any of us are capable of applying to the problem.
In short, last nights ECM was the ECM to end all ECMs. Any card hit by it is toast, and barring someone developing a cheap way to rebuild chips mat the wafer level (which isn't even remotely likely to happen anytime soon) there isn't a thing that can be done about it. Enjoy your new ice scraper.
Or get in touch with me about shipping it to me. I want to dissect it to get the ASIC out of it for some experimenting I want to do.
--
GLEEEEEP!!!!
PGP KeyID: 0x016B6B53 on the keyservers.
http://www.megsinet.net/~kayo/index.html
This sounded like a pretty cool hack on the part of DirectTV (whether you agree with them or not), so I decided to take advantage of my ISP's one month news spool of alt.dss.hack to see what was up.
It looks to me like DirectTV (better known to the a.d.h members as "Dave", and not to be confused with "SuperDave", one of the newsgroup regulars) played an ace they've had up their sleeve for a long time. Apparently the boot code (in ROM) of the 8051 in the chip checks one bit in a 32-bit region of PROM (as in you can program it but you can't reset it) and goes into an infinte loop (I think this is what is being referred to as a "looped" card) early during the boot process. Since this is in ROM where it can't be re-programmed, you can't bypass it.
It seems there's also an ASIC in the card that is crucial to the decoding process. I'm guessing that it has to be enabled by the 8051. And if the 8051 "loops" before you can talk to it, you're hosed.
It also seems that there was a recent move to "emulators", which emulated the 8051, but passed commands to the ASIC through to the real card. That way, as long as the card was alive enough to tell it what to do, you would esentially firewall off the card from any nasty code that wanted to do stuff like program write-once bits in the CPU chip. Some people were arguing recently that emulators were overkill, but it seems they have been proven wrong. The only people with hacked cards that still work either had emulators or were lucky enough to pull their cards in time (or the decoder box was unplugged).
Apparently for a couple of weeks now "Dave" has been downloading code to detect illegal cards and test it (by locking up assorted cards and seeing what kind of results they got) before sending down the "ECM" code which caused the card to kill itself.
As to the timing, it is suspected they chose one week before Super Bowl to allow enough time for legitimate users (or those illegitimate users who wanted the better signal in time for The Big Game) to receive new cards.
Here are two messages I found on the newsgroup about all this: (line art removed because of/.'s lame filter)
From: ump25@aol.com (Ump25)
Newsgroups: alt.dss.hack
Date: 22 Jan 2001 05:38:13 GMT
Subject: EVERYONE READ THIS! INFO FROM MAGICIAN ET. AL.
Message-ID: <20010122003813.16538.00000761@ng-bj1.aol.com&g t;
From Magician and Hypertek comes the following...
As most everybody is aware, the ability of the dynamic code to execute a kill-type ECM was displayed today on "Black Sunday".
First, the bad news: the ECMs wrote 4 bytes to "write once" area of the EEPROM, 8000h-8003h. Unfortunately, one of the bytes that is changed is 8000h, which is checked extremely early in the ROM startup code (003Fh) to see if it contains "33h". These ECMs re-wrote this byte to "00h", which means that it very quickly enters an infinite loop because "P1.7" is not set. Since this area of the H card is "write once", there is no way to reset this byte back to "33h" to allow normal startup to continue, even by way of an unlooper.
Second, for those interested, here are all the EEPROM addresses that were tested to see if they contained modified bytes. Each byte was tested in its own packet (i.e., one address at a time):
code:
- - -
8243 Vector for setting DPTR to ZKT secret vector
8246,8247 Vector for Cmd09 vector
8255 Vector for Ins58 patch vector
8258 Ins44 preprocessing vector
825B Ins44 extras vector
825E Find tier or PPV vector
8264 "EndInsHandling" vector
8273 Cmd1F vector
827C,827D Ins54 vector
8282,8283 Ins18/Ins1A vecotr
8440 First byte of channel blackout data (checked if non-zero)
8582,858C,8593 Cmd60 code
85B7 B7 nano vector
85BE BD nano vector
85C0,85C1,85C2 C0 nano vector
85C3 C3 nano vector
85C6,85C7 C6 nano vector
85E2,85E6,85ED,85EF,85F6 B5 nano code
8606,8608,8611 AddAToDfdNanoBufIfFlOpn code
8630 Deferred Cmd60 processing code
86DD Never-executed portion of old C6 nano code
87A1 Old CF nano jump table
8800 Hash algorithm code
8955 Main loop vector code
8973 Ins18/Ins1A code
8975 Ins54 check code
8982 Setup for Ins38 code
89A0,89A3 Setup for Ins44 code
89A6,89B2,89B9 Setup for Ins4C code
89DF End of main loop vector code
8BFE Cmd0C code
8CC7,8CCA,8CCB Preprocess deferred Cmd60 code
8CD9,8CDE Cmd0B for non-virgin cards code
8CF2,8CFE Ins58 patch code
8D04,8D09,8D0D,8D11,8D14,8D178D1A,8D1D,8D20,8D22 ,8 D24,8D25,8D32 Ins54 code
8D66,8D6A,8D72,8D76 Add ASIC bytes to signature hash code
8DD0,8DD3,8E68 Do 1 hash iteration code
8F2F Preprocess Cmd09 code
8F53 Cmd0C patch 1 code
- - -
Here is an example dynamic code packet (for the 8D1Ah address; all of the addresses were tested using similar packets, except for 8440h which used a JNZ instead of JZ):
code:
- - -
C3 nano used to preset RAM locatiosn 10h-1Fh:
C3 0A 00 20 99 03 AF 01 00 04 00 09 | Seed hash only (using 9 data bytes) results in these bytes at 10h-1Fh:
20 99 03 AF 01 00 04 00 09 CB 29 71 06 19 74 D0
Fourth byte loaded in EEPROM write register
Third byte loaded in EEPROM write register
Hi byte of 1st loop return address and second byte loaded in EEPROM write register
Lo byte of 1st loop return address and first byte loaded in EEPROM write register
Hi byte of 2nd loop return address
Lo byte of 2nd loop return address
Hi byte of 3rd loop return address
Lo byte of 3rd loop return address
What 8D1Ah is compared to
The C9 nano looked like this:
C9 10 20 90 8D 1A E0 47 60 08 90 | Write 15 bytes+RET, execute and hash
80 00 78 15 75 81 16 :
which caused this code to be executed:
893C mov DPTR,#8D1Ah
893F movx A,@DPTR
8940 xrl A,@R1
8941 jz 894Bh
8943 mov DPTR,#8000h
8946 mov R0,#15h
8948 mov SP,#16h
894B ret
- - -
Remember, R1 starts equal to 10h. So the above code does the following:
Compare 8D1Ah to @10h (which contains #20h)
If they match, simply return
Otherwise, set DPTR to 8000h
Set R0 to 15h
Reset the stack to 16h and RET, to resume execution at 0400h to load "00 04 00 09" into EEPROM write register which RETs to 01AFh to enable EEPROM write mode
which RETs to 0399h to write 00 04 00 09 to 8000-8003h.
In addition, there was an ECM to detect an H cards running with non-H CAM IDs, although this packet did not loop the card but simply "locked it up" until the next reset:
code:
- - -
C3 nano used to preset RAM locatiosn 10h-1Fh:
C3 0B 00 FE FC 32 00 00 04 AC 01 68 14 | Seed hash only (using 10 data bytes) results in these bytes at 10h-1Fh:
FE FC 32 00 00 04 AC 01 68 14 8A DF A3 AA 81 34
Hi byte of 1st loop return address
Lo byte of 1st loop return address
Hi byte of 2nd loop return address
Lo byte of 2nd loop return address
Hi byte of 3rd loop return address
Lo byte of 3rd loop return address
Hi byte of 4th loop return address
Lo byte of 4th loop return address
The C9 nano looked like this:
C9 12 20 90 83 74 81 60 07 57 70 | Write 17 bytes+RET, execute and hash
05 09 B9 12 F6 22 75 81 19 :
which caused this code to be executed:
893C mov DPTR,#8374h
893F movx A,@DPTR++
8940 jz 8949h
8942 anl A,@R1
8943 jnz 894Ah
8945 inc R1
8946 cjne R1,#12h,893Fh
8949 ret
894A mov SP,#19h
894D ret
- - -
Remember, R1 starts equal to 10h. So the above code does the following:
If first byte of CAM ID is 00, return (everything OK).
Otherwise, AND first CAM ID byte with byte @10h (#FEh)
If result is non-zero (meaning first CAM ID byte is not 01h), go to ECM routine
Otherwise, AND second CAM ID byte with @11h (#FCh)
If result is non zero, go to ECM routine
Otherwise, return (everything OK)
The ECM routine resets the SP to cause the RET to resume execution at 1468h, which RETs to 01ACh, which RETs to 0400h, which RETs to the infinite loop at 0032h...
From: Spacemonkey Gleep <Fictitious@Dont.Bother.Its.invalid>
Newsgroups: alt.dss.hack
Subject: How Write-Once memory works, or "Why H cards hit by the ECM are never going to be fixed"
Date: Mon, 22 Jan 2001 10:56:12 -0800
Message-ID: <Fictitious-402BA7.10561222012001@news.primenet.com>
In response to the umpty-nine-dozen "Why can't we just..." questions about the corrupted write-once area on the card, here's an explanation that may shed some light. (Note to those "in the know": Yes, I'm simplifying things ridiculously. Not everybody playing in this little sandbox is an EE with the knowledge to understand the inner workings of a chip)
A byte of RAM memory is a set of 8 cells that can hold a one or a zero. Which cells have 1s in them determines the value of the byte when you read it. With RAM, you can change the values any time you like. You can think of that byte as 8 switches that can be turned on or off in different combinations to give you various values.
A byte of ROM is similar, in that it's 8 cells that can each hold a 1 or a 0. Unlike RAM, these 1s and 0s are fixed. Instead of the "switches" that RAM has, you can think of ROM as having either a wire (for a 1) or no wire (for a zero). They can't be changed once made. The wire (or lack of one) is a permanent thing.
A byte of Write-Once memory (Also known as "PROM", or "Programmable Read Only Memory") has characteristics of both RAM and ROM. Like RAM, you *CAN* write to it, under certain circumstances. Like ROM, once written, it's **FOREVER**. Think of a byte of PROM as being 8 microscopic fuses.
When the chip is made, all the fuses are "good". If you could see it at the microscopic level, it would look something like this: ( each | is a fuse that isn't blown )
| | | | | | | |
and would have the value FF, or 255 in decimal.
Now, let's say you want the byte to have the value B7 (That's 183 in decimal, and in binary, it's 10110111) To write that value to it, you deliberately burn out two fuses in the byte, leaving it looking like this: (| = unblown fuse, : = blown fuse)
| : | | : | | |
From that point, it would be possible to write to it again, and change the value, *BUT* there's a catch. You can only "blow" more fuses. You can't "un-blow" fuses that are already blown. This means that a number that needs one of the fuses that's already blown out is going to be impossible to write.
So why is this a problem?
Normally, byte 8000 of the H card holds the value 33 (in Decimal, 51. In binary, 00110011) and the byte looks like this:
: : | | : : | |
But after being hit by DTV's ECM last night, the byte is set to 00 - it looks like this:
: : : : : : : :
There's no fuses left to blow out. They're all gone. That means that forever and always, byte 8000 of your ECMed card is going to say "I'm holding the value 00" when asked.
Why this means the card is permanently dead:
VERY early after the card gets powered up and reset, a check is done:
Does byte 8000 hold the value 33?
If the answer to that question is yes, then all is right with the world, and things start happening. The card gets initialized, spits out the ATR string, and then goes into "wait for a command from the IRD" mode. If, on the other hand, the answer is no, then the card goes into an infinite loop that does nothing. If you program in BASIC, it's the equivalent of the line
10 GOTO 10
NOTHING gets done until the next time the card is reset. And then the same thing happens all over again.
This check is in the card's ROM, so it can't be bypassed or changed.
Reprogramming the card won't do anything useful, since the ROM doesn't even get looked at, let alone messed with, by programmers (or unloopers, for that matter) and even if it did, it wouldn't do anything useful, since ROM can't be changed (short of actually damaging it).
So how can it be fixed?
The simple answer: It can't. Congratulations. Your H card is now an ice scraper. Get used to it. Life sucks.
The more extended answer:
If you've got the micro-tools to "rebuild" the blown fuses on the chip, you could go that route, but unless you're a chip manufacturer, or have access to that type of equipment somehow, you ain't got a prayer. We're talking about electron microscopes, tools for depositing single atoms onto the silicon wafer itself, that sort of thing. In other words, trying to do it is going to mean more money, knowledge, equipment, and effort than most any of us are capable of applying to the problem.
In short, last nights ECM was the ECM to end all ECMs. Any card hit by it is toast, and barring someone developing a cheap way to rebuild chips mat the wafer level (which isn't even remotely likely to happen anytime soon) there isn't a thing that can be done about it. Enjoy your new ice scraper.
Or get in touch with me about shipping it to me. I want to dissect it to get the ASIC out of it for some experimenting I want to do.
--
GLEEEEEP!!!!
PGP KeyID: 0x016B6B53 on the keyservers.
http://www.megsinet.net/~kayo/index.html
My Pioneer 505 won't play CD-Rs, but my 909 (combo LD/DVD player) will, because it has a laserdisc pickup which not only has a dual laser (so it uses the right wavelength), but is a lot better designed.
The pickups in regular DVD players are built like the ones in CDs and CD-ROMs. Some DVD players (Apex, for instance) actually use regular IDE DVD-ROM drives. The pickups in laserdiscs are big monsters, but they're still smaller than the first generation LD players (before CD came out!) which use HeNe tubes because they didn't have laser diodes back then.
People on rec.games.video.classic have known this for quite a while, since a couple of years before e-bay hit it big.
But what surprises me most is that he managed to sell half of them, even with a few titles that are still common as dirt at Goodwill thrift stores, and even with a bunch of Atari 7800 titles, considering how well that console didn't sell.
If you think that's bad, how about what Atari did with Pac Man and E.T. They actually made more Pac Man cartridges than they did consoles! So in order to take a loss on these things (both written in six weeks or so, instead of the six months that the average 2600 game took to write--and they show it!), they had them buried in a hole in the desert as a tax write-off. The IRS even made them pour concrete into the hole on top of all the cartridges. Anyone for an archaeological expedition to Arizona?
My suggestion? Use them as construction material. Maybe cover a wall with 'em, sort of like a retro Z-Brick theme for the game room.
And at one point, our system was infested by a cabal of teenagers from a nearby prep school, who had broken in by exploiting a bug in the login process. They had their way with the system for several weeks before they were detected, and it took several days of round-the-clock work to eradicate the numerous trap doors and time bombs they had left behind.
Proof that skr1pt k1dd33z are far from a new phenomenon. When I was in high school in the early '80s, I was among the group of hacker kids at my school, but the ones at nearby schools had much more ph33r p0w3r. Of course there was no internet back then, so information was hard to find, and you only had one or two local time-share systems to work with. And this was back when you had to know what the hell you were doing just to log on even when you were supposed to be on a given system. The Internet has significantly lowered the bar on what it takes to be a kiddie.
I'm a Mac and Linux guy at home, but I've gotta use Winders at my new workplace. When I first got the machine, it had a ghosted install of NT 4 that I would have to reboot two or three times a day, usually right as I was finally getting into coding mode. Besides, the C drive was 2GB (thanks to the stupid NT installer that makes it impossible to create a larger C drive unless you know what you're doing and go to a lot of trouble), and it got pretty full pretty quick.
So I took up a co-worker's offer to install W2K off of the MSDN disks (I had to create four boot floppies because the DVD wasn't bootable), and once I got it stable, I haven't rebooted since the last time I switched around some LAN cards.
My uptime (as measured by the Local Area Connection Status for my LAN card) is now 41 days. I have one utility I've found since then that might work after I reboot, but I haven't wanted to try it badly enough to reboot.
I'd say W2K can be pretty stable if you don't rely on some PFY in IT to ghost install it for you.
Slashdot ads are the only ads I intentionally don't filter with my Squid proxy at home. Some of them are even pretty cool. However, a small percentage of the ads they serve up are from doubleclick, and since I'm blocking by URL, they're toast. I wouldn't even know they serve doubleclick ads if I had blocked the/. ads too.
I'm a big fan of the Kensington Orbit. I found an ADB one at a thrift store for six bucks a couple of years ago and fell in love with it right away. Last month I got a USB/PS2 version when I got my new G3 500 Powerbook.
Not only does it feel right, it's symmetrical, so you don't have to worry about which hand to use.
Slashdot Mirror
This was modded (Score:5, Insightful) ??? Someone must have found a new supply of three-dollar crack. It sounds more like a troll to me.
Cisco has gone from a high of 82 in March 2000 to a low of under 30 last week. That's a much faster and deeper plunge, and they're hardly "on the ropes".
Dear Decision maker ; We know you are interested in receiving amazing info ! This is a one time mailing there is no need to request removal if you won't want any more . This mail is being sent in compliance with Senate bill 1622 , Title 6 ; Section 301 . This is not a get rich scheme ! Why work for somebody else when you can become rich as few as 85 MONTHS ! Have you ever noticed how long the line-ups are at bank machines and people are much more likely to BUY with a credit card than cash . Well, now is your chance to capitalize on this ! We will help you process your orders within seconds & SELL MORE ! You can begin at absolutely no cost to you ! But don't believe us ! Prof Ames who resides in Alabama tried us and says "I was skeptical but it worked for me" ! We assure you that we operate within all applicable laws . We implore you - act now ! Sign up a friend and your friend will be rich too . Thanks . Dear Friend , Especially for you - this hot intelligence . If you no longer wish to receive our publications simply reply with a Subject: of "REMOVE" and you will immediately be removed from our database . This mail is being sent in compliance with Senate bill 2616 , Title 7 ; Section 303 ! THIS IS NOT MULTI-LEVEL MARKETING . Why work for somebody else when you can become rich in 22 days ! Have you ever noticed nobody is getting any younger & the baby boomers are more demanding than their parents . Well, now is your chance to capitalize on this ! WE will help YOU decrease perceived waiting time by 130% and sell more ! The best thing about our system is that it is absolutely risk free for you . But don't believe us . Mrs Ames of Georgia tried us and says "Now I'm rich many more things are possible" ! This offer is 100% legal ! So make yourself rich now by ordering immediately ! Sign up a friend and you'll get a discount of 60% . Best regards !
Now all we need is a filter which can encode into the typical /. troll post. You know, stuff like "Natalie Portman", "hot grits", "Linux", and "ESR".
The latter takes a bit more work, but if you have DSL or a cable modem, and didn't get rid of the second phone line, it can be done. With software like mgetty+sendfax, you can even justify it as a fax line. I've set up my own dial-ups under Linux before, and they could handle shell, PPP, and fax connections. If I'd had a bit more time, I would have figured out how to proxy-arp them to use fixed IPs from my /29 block instead of IP Masquerading.
Just wait, 2600.com will get sued for posting a copy of DeWolbachia on their web site.
I'd rather have one like the Q, but with an optional cap on the connector end.
And for those of you wondering about Linux support, these things should be just like my PNY Compact Flash/Smart Media reader for USB... it emulates an IDE drive. Actually, the flash cards themselves emulate an IDE drive, and the USB part just acts as a USB to IDE interface.
Did you ever hear of this neat new invention they've come up with called "Ziploc Bags"? I think that would have saved you a lot of work.
Jef Raskin refers to the OS as a "program you have to hassle with before you get to hassle with the application." To me, Nautilus seems like just yet another program you have to hassle with before you get to hassle with the application. I don't see how it can make things any easier for me that would make me run Linux as a desktop environment instead of MacOS.
As to the OS itself, I don't really see what it does that gets in your way, aside from maybe requiring you to save your data files in its directory hierarchy. Certainly you can use OS X without having to care that it's running Unix underneath the hood. Much more noticable is that "classic" apps have to run in their own little sandbox, because the OS is different, not because it's there.
Even the Palm OS, which is specifically mentioned as one that doesn't get in your way, is still an OS, and still there. You could run a Palm-like interface on top of Unix and be none the wiser. It seems to me what he has a problem with is the user interface environment, not the OS.
Would such an appliance -- a home browser, word processor, spreadsheet, and game console -- be a popular item that would replace the PC in the household? Wildly so, especially if installing new programs was made simple, such as inserting a disk, selecting its activator key, ejecting the disk and running it, installed on your system until you remove it.
Installing programs under Windoze is a total fuckup because of all the DLLs and inevitable scores of data files that have to be installed along with the application itself. I'm sure InstallShield is making a lot of money off of this. Under MacOS, it is possible to install (properly written) software by simply dragging its icon out of a CD-ROM's Finder window. Such software doesn't even have to be installed; it can usually be run right from the CD-ROM. This used to be common, but nowadays big apps want to be run from an installer because they have so much baggage that goes along with them. OS X will make this easier to do by allowing an application and its files be packaged in a folder that appears to be a single object.
Sure, the Unix basis of OS X can be considered a step backwards when compared to something like BeOS or even the Xerox Smalltalk environment, but the reason to go with it is because it's a solid solution, and it's much better than the ad-hoc design of MacOS, which was never intended to do multitasking. Multitasking the MacOS was an amazing hack.
Fortunately I can ssh into my server at home, so I had it upgraded within an hour.
Another scary thing is the CERT graph showing the exploit reports for the NXT bug. I definitely don't want to have an un-upgraded BIND in the peak of that curve.
That's exactly why they rewrote BIND 9 from scratch.
Well, lookie here... it seems at least the Air Force thinks there could be problems if China joins the space race... http://slashdot.org/article.pl?sid=01/01/29/165206 &mode=thread
He means the license on the database itself. Specifically, who owns the rights, etc. Sure would be nice if people undersood what they were replying to before posting meaningless replies on /.
The space program was for one reason. To get up there before the Russians could. There was a rightful fear of what could happen if the Russians established a base in orbit or on the moon and made a nuclear weapons platform up there.
Everything else was just icing.
Besides, if you can launch a spaceship into orbit, then you can launch an ICBM. This is the problem with the technology leaking into China as a result of the laxness of the Clinton administration. Fortunately, so far it looks like right now they'd rather get up into space than threaten everybody with ICBMs.
Lets be honest, the ISS should have been built 10 years ago, it's not as if it couldn't have been, it just wasn't.
Really, we should never have abandoned Skylab after a pitiful three missions. From what I remember seeing of it, it was as spacious as Mir was cramped.
Beware of who you kick when they're down, because they might decide kick you right back when you're down!
It looks to me like DirectTV (better known to the a.d.h members as "Dave", and not to be confused with "SuperDave", one of the newsgroup regulars) played an ace they've had up their sleeve for a long time. Apparently the boot code (in ROM) of the 8051 in the chip checks one bit in a 32-bit region of PROM (as in you can program it but you can't reset it) and goes into an infinte loop (I think this is what is being referred to as a "looped" card) early during the boot process. Since this is in ROM where it can't be re-programmed, you can't bypass it.
It seems there's also an ASIC in the card that is crucial to the decoding process. I'm guessing that it has to be enabled by the 8051. And if the 8051 "loops" before you can talk to it, you're hosed.
It also seems that there was a recent move to "emulators", which emulated the 8051, but passed commands to the ASIC through to the real card. That way, as long as the card was alive enough to tell it what to do, you would esentially firewall off the card from any nasty code that wanted to do stuff like program write-once bits in the CPU chip. Some people were arguing recently that emulators were overkill, but it seems they have been proven wrong. The only people with hacked cards that still work either had emulators or were lucky enough to pull their cards in time (or the decoder box was unplugged).
Apparently for a couple of weeks now "Dave" has been downloading code to detect illegal cards and test it (by locking up assorted cards and seeing what kind of results they got) before sending down the "ECM" code which caused the card to kill itself.
As to the timing, it is suspected they chose one week before Super Bowl to allow enough time for legitimate users (or those illegitimate users who wanted the better signal in time for The Big Game) to receive new cards.
Here are two messages I found on the newsgroup about all this: (line art removed from the first one because of /.'s lame filter)
From: ump25@aol.com (Ump25)
Newsgroups: alt.dss.hack
Date: 22 Jan 2001 05:38:13 GMT
Subject: EVERYONE READ THIS! INFO FROM MAGICIAN ET. AL.
Message-ID: <20010122003813.16538.00000761@ng-bj1.aol.com&g t;
From Magician and Hypertek comes the following...
As most everybody is aware, the ability of the dynamic code to execute a kill-type ECM was displayed today on "Black Sunday".
First, the bad news: the ECMs wrote 4 bytes to "write once" area of the EEPROM, 8000h-8003h. Unfortunately, one of the bytes that is changed is 8000h, which is checked extremely early in the ROM startup code (003Fh) to see if it contains "33h". These ECMs re-wrote this byte to "00h", which means that it very quickly enters an infinite loop because "P1.7" is not set. Since this area of the H card is "write once", there is no way to reset this byte back to "33h" to allow normal startup to continue, even by way of an unlooper.
Second, for those interested, here are all the EEPROM addresses that were tested to see if they contained modified bytes. Each byte was tested in its own packet (i.e., one address at a time):2 ,8 D24,8D25,8D32 Ins54 code
code:
- - -
8243 Vector for setting DPTR to ZKT secret vector
8246,8247 Vector for Cmd09 vector
8255 Vector for Ins58 patch vector
8258 Ins44 preprocessing vector
825B Ins44 extras vector
825E Find tier or PPV vector
8264 "EndInsHandling" vector
8273 Cmd1F vector
827C,827D Ins54 vector
8282,8283 Ins18/Ins1A vecotr
8440 First byte of channel blackout data (checked if non-zero)
8582,858C,8593 Cmd60 code
85B7 B7 nano vector
85BE BD nano vector
85C0,85C1,85C2 C0 nano vector
85C3 C3 nano vector
85C6,85C7 C6 nano vector
85E2,85E6,85ED,85EF,85F6 B5 nano code
8606,8608,8611 AddAToDfdNanoBufIfFlOpn code
8630 Deferred Cmd60 processing code
86DD Never-executed portion of old C6 nano code
87A1 Old CF nano jump table
8800 Hash algorithm code
8955 Main loop vector code
8973 Ins18/Ins1A code
8975 Ins54 check code
8982 Setup for Ins38 code
89A0,89A3 Setup for Ins44 code
89A6,89B2,89B9 Setup for Ins4C code
89DF End of main loop vector code
8BFE Cmd0C code
8CC7,8CCA,8CCB Preprocess deferred Cmd60 code
8CD9,8CDE Cmd0B for non-virgin cards code
8CF2,8CFE Ins58 patch code
8D04,8D09,8D0D,8D11,8D14,8D178D1A,8D1D,8D20,8D2
8D66,8D6A,8D72,8D76 Add ASIC bytes to signature hash code
8DD0,8DD3,8E68 Do 1 hash iteration code
8F2F Preprocess Cmd09 code
8F53 Cmd0C patch 1 code
- - -
Here is an example dynamic code packet (for the 8D1Ah address; all of the addresses were tested using similar packets, except for 8440h which used a JNZ instead of JZ):
code:
- - -
C3 nano used to preset RAM locatiosn 10h-1Fh:
C3 0A 00 20 99 03 AF 01 00 04 00 09 | Seed hash only (using 9 data bytes) results in these bytes at 10h-1Fh:
20 99 03 AF 01 00 04 00 09 CB 29 71 06 19 74 D0
Fourth byte loaded in EEPROM write register
Third byte loaded in EEPROM write register
Hi byte of 1st loop return address and second byte loaded in EEPROM write register
Lo byte of 1st loop return address and first byte loaded in EEPROM write register
Hi byte of 2nd loop return address
Lo byte of 2nd loop return address
Hi byte of 3rd loop return address
Lo byte of 3rd loop return address
What 8D1Ah is compared to
The C9 nano looked like this:
C9 10 20 90 8D 1A E0 47 60 08 90 | Write 15 bytes+RET, execute and hash
80 00 78 15 75 81 16 :
which caused this code to be executed:
893C mov DPTR,#8D1Ah
893F movx A,@DPTR
8940 xrl A,@R1
8941 jz 894Bh
8943 mov DPTR,#8000h
8946 mov R0,#15h
8948 mov SP,#16h
894B ret
- - -
Remember, R1 starts equal to 10h. So the above code does the following:
Compare 8D1Ah to @10h (which contains #20h)
If they match, simply return
Otherwise, set DPTR to 8000h
Set R0 to 15h
Reset the stack to 16h and RET, to resume execution at 0400h to load "00 04 00 09" into EEPROM write register which RETs to 01AFh to enable EEPROM write mode
which RETs to 0399h to write 00 04 00 09 to 8000-8003h.
In addition, there was an ECM to detect an H cards running with non-H CAM IDs, although this packet did not loop the card but simply "locked it up" until the next reset:
code:
- - -
C3 nano used to preset RAM locatiosn 10h-1Fh:
C3 0B 00 FE FC 32 00 00 04 AC 01 68 14 | Seed hash only (using 10 data bytes) results in these bytes at 10h-1Fh:
FE FC 32 00 00 04 AC 01 68 14 8A DF A3 AA 81 34
Hi byte of 1st loop return address
Lo byte of 1st loop return address
Hi byte of 2nd loop return address
Lo byte of 2nd loop return address
Hi byte of 3rd loop return address
Lo byte of 3rd loop return address
Hi byte of 4th loop return address
Lo byte of 4th loop return address
The C9 nano looked like this:
C9 12 20 90 83 74 81 60 07 57 70 | Write 17 bytes+RET, execute and hash
05 09 B9 12 F6 22 75 81 19 :
which caused this code to be executed:
893C mov DPTR,#8374h
893F movx A,@DPTR++
8940 jz 8949h
8942 anl A,@R1
8943 jnz 894Ah
8945 inc R1
8946 cjne R1,#12h,893Fh
8949 ret
894A mov SP,#19h
894D ret
- - -
Remember, R1 starts equal to 10h. So the above code does the following:
If first byte of CAM ID is 00, return (everything OK).
Otherwise, AND first CAM ID byte with byte @10h (#FEh)
If result is non-zero (meaning first CAM ID byte is not 01h), go to ECM routine
Otherwise, AND second CAM ID byte with @11h (#FCh)
If result is non zero, go to ECM routine
Otherwise, return (everything OK)
The ECM routine resets the SP to cause the RET to resume execution at 1468h, which RETs to 01ACh, which RETs to 0400h, which RETs to the infinite loop at 0032h...
From: Spacemonkey Gleep <Fictitious@Dont.Bother.Its.invalid> .com>
Newsgroups: alt.dss.hack
Subject: How Write-Once memory works, or "Why H cards hit by the ECM are never going to be fixed"
Date: Mon, 22 Jan 2001 10:56:12 -0800
Message-ID: <Fictitious-402BA7.10561222012001@news.primenet
In response to the umpty-nine-dozen "Why can't we just..." questions about the corrupted write-once area on the card, here's an explanation that may shed some light. (Note to those "in the know": Yes, I'm simplifying things ridiculously. Not everybody playing in this little sandbox is an EE with the knowledge to understand the inner workings of a chip)
A byte of RAM memory is a set of 8 cells that can hold a one or a zero. Which cells have 1s in them determines the value of the byte when you read it. With RAM, you can change the values any time you like. You can think of that byte as 8 switches that can be turned on or off in different combinations to give you various values.
A byte of ROM is similar, in that it's 8 cells that can each hold a 1 or a 0. Unlike RAM, these 1s and 0s are fixed. Instead of the "switches" that RAM has, you can think of ROM as having either a wire (for a 1) or no wire (for a zero). They can't be changed once made. The wire (or lack of one) is a permanent thing.
A byte of Write-Once memory (Also known as "PROM", or "Programmable Read Only Memory") has characteristics of both RAM and ROM. Like RAM, you *CAN* write to it, under certain circumstances. Like ROM, once written, it's **FOREVER**. Think of a byte of PROM as being 8 microscopic fuses.
When the chip is made, all the fuses are "good". If you could see it at the microscopic level, it would look something like this: ( each | is a fuse that isn't blown )
| | | | | | | |
and would have the value FF, or 255 in decimal.
Now, let's say you want the byte to have the value B7 (That's 183 in decimal, and in binary, it's 10110111) To write that value to it, you deliberately burn out two fuses in the byte, leaving it looking like this: (| = unblown fuse, : = blown fuse)
| : | | : | | |
From that point, it would be possible to write to it again, and change the value, *BUT* there's a catch. You can only "blow" more fuses. You can't "un-blow" fuses that are already blown. This means that a number that needs one of the fuses that's already blown out is going to be impossible to write.
So why is this a problem?
Normally, byte 8000 of the H card holds the value 33 (in Decimal, 51. In binary, 00110011) and the byte looks like this:
: : | | : : | |
But after being hit by DTV's ECM last night, the byte is set to 00 - it looks like this:
: : : : : : : :
There's no fuses left to blow out. They're all gone. That means that forever and always, byte 8000 of your ECMed card is going to say "I'm holding the value 00" when asked.
Why this means the card is permanently dead:
VERY early after the card gets powered up and reset, a check is done:
Does byte 8000 hold the value 33?
If the answer to that question is yes, then all is right with the world, and things start happening. The card gets initialized, spits out the ATR string, and then goes into "wait for a command from the IRD" mode. If, on the other hand, the answer is no, then the card goes into an infinite loop that does nothing. If you program in BASIC, it's the equivalent of the line
10 GOTO 10
NOTHING gets done until the next time the card is reset. And then the same thing happens all over again.
This check is in the card's ROM, so it can't be bypassed or changed.
Reprogramming the card won't do anything useful, since the ROM doesn't even get looked at, let alone messed with, by programmers (or unloopers, for that matter) and even if it did, it wouldn't do anything useful, since ROM can't be changed (short of actually damaging it).
So how can it be fixed?
The simple answer: It can't. Congratulations. Your H card is now an ice scraper. Get used to it. Life sucks.
The more extended answer:
If you've got the micro-tools to "rebuild" the blown fuses on the chip, you could go that route, but unless you're a chip manufacturer, or have access to that type of equipment somehow, you ain't got a prayer. We're talking about electron microscopes, tools for depositing single atoms onto the silicon wafer itself, that sort of thing. In other words, trying to do it is going to mean more money, knowledge, equipment, and effort than most any of us are capable of applying to the problem.
In short, last nights ECM was the ECM to end all ECMs. Any card hit by it is toast, and barring someone developing a cheap way to rebuild chips mat the wafer level (which isn't even remotely likely to happen anytime soon) there isn't a thing that can be done about it. Enjoy your new ice scraper.
Or get in touch with me about shipping it to me. I want to dissect it to get the ASIC out of it for some experimenting I want to do.
--
GLEEEEEP!!!!
PGP KeyID: 0x016B6B53 on the keyservers.
http://www.megsinet.net/~kayo/index.html
It looks to me like DirectTV (better known to the a.d.h members as "Dave", and not to be confused with "SuperDave", one of the newsgroup regulars) played an ace they've had up their sleeve for a long time. Apparently the boot code (in ROM) of the 8051 in the chip checks one bit in a 32-bit region of PROM (as in you can program it but you can't reset it) and goes into an infinte loop (I think this is what is being referred to as a "looped" card) early during the boot process. Since this is in ROM where it can't be re-programmed, you can't bypass it.
It seems there's also an ASIC in the card that is crucial to the decoding process. I'm guessing that it has to be enabled by the 8051. And if the 8051 "loops" before you can talk to it, you're hosed.
It also seems that there was a recent move to "emulators", which emulated the 8051, but passed commands to the ASIC through to the real card. That way, as long as the card was alive enough to tell it what to do, you would esentially firewall off the card from any nasty code that wanted to do stuff like program write-once bits in the CPU chip. Some people were arguing recently that emulators were overkill, but it seems they have been proven wrong. The only people with hacked cards that still work either had emulators or were lucky enough to pull their cards in time (or the decoder box was unplugged).
Apparently for a couple of weeks now "Dave" has been downloading code to detect illegal cards and test it (by locking up assorted cards and seeing what kind of results they got) before sending down the "ECM" code which caused the card to kill itself.
As to the timing, it is suspected they chose one week before Super Bowl to allow enough time for legitimate users (or those illegitimate users who wanted the better signal in time for The Big Game) to receive new cards.
Here are two messages I found on the newsgroup about all this: (line art removed because of /.'s lame filter)
From: ump25@aol.com (Ump25)
Newsgroups: alt.dss.hack
Date: 22 Jan 2001 05:38:13 GMT
Subject: EVERYONE READ THIS! INFO FROM MAGICIAN ET. AL.
Message-ID: <20010122003813.16538.00000761@ng-bj1.aol.com&g t;
From Magician and Hypertek comes the following...
As most everybody is aware, the ability of the dynamic code to execute a kill-type ECM was displayed today on "Black Sunday".
First, the bad news: the ECMs wrote 4 bytes to "write once" area of the EEPROM, 8000h-8003h. Unfortunately, one of the bytes that is changed is 8000h, which is checked extremely early in the ROM startup code (003Fh) to see if it contains "33h". These ECMs re-wrote this byte to "00h", which means that it very quickly enters an infinite loop because "P1.7" is not set. Since this area of the H card is "write once", there is no way to reset this byte back to "33h" to allow normal startup to continue, even by way of an unlooper.
Second, for those interested, here are all the EEPROM addresses that were tested to see if they contained modified bytes. Each byte was tested in its own packet (i.e., one address at a time):2 ,8 D24,8D25,8D32 Ins54 code
code:
- - -
8243 Vector for setting DPTR to ZKT secret vector
8246,8247 Vector for Cmd09 vector
8255 Vector for Ins58 patch vector
8258 Ins44 preprocessing vector
825B Ins44 extras vector
825E Find tier or PPV vector
8264 "EndInsHandling" vector
8273 Cmd1F vector
827C,827D Ins54 vector
8282,8283 Ins18/Ins1A vecotr
8440 First byte of channel blackout data (checked if non-zero)
8582,858C,8593 Cmd60 code
85B7 B7 nano vector
85BE BD nano vector
85C0,85C1,85C2 C0 nano vector
85C3 C3 nano vector
85C6,85C7 C6 nano vector
85E2,85E6,85ED,85EF,85F6 B5 nano code
8606,8608,8611 AddAToDfdNanoBufIfFlOpn code
8630 Deferred Cmd60 processing code
86DD Never-executed portion of old C6 nano code
87A1 Old CF nano jump table
8800 Hash algorithm code
8955 Main loop vector code
8973 Ins18/Ins1A code
8975 Ins54 check code
8982 Setup for Ins38 code
89A0,89A3 Setup for Ins44 code
89A6,89B2,89B9 Setup for Ins4C code
89DF End of main loop vector code
8BFE Cmd0C code
8CC7,8CCA,8CCB Preprocess deferred Cmd60 code
8CD9,8CDE Cmd0B for non-virgin cards code
8CF2,8CFE Ins58 patch code
8D04,8D09,8D0D,8D11,8D14,8D178D1A,8D1D,8D20,8D2
8D66,8D6A,8D72,8D76 Add ASIC bytes to signature hash code
8DD0,8DD3,8E68 Do 1 hash iteration code
8F2F Preprocess Cmd09 code
8F53 Cmd0C patch 1 code
- - -
Here is an example dynamic code packet (for the 8D1Ah address; all of the addresses were tested using similar packets, except for 8440h which used a JNZ instead of JZ):
code:
- - -
C3 nano used to preset RAM locatiosn 10h-1Fh:
C3 0A 00 20 99 03 AF 01 00 04 00 09 | Seed hash only (using 9 data bytes) results in these bytes at 10h-1Fh:
20 99 03 AF 01 00 04 00 09 CB 29 71 06 19 74 D0
Fourth byte loaded in EEPROM write register
Third byte loaded in EEPROM write register
Hi byte of 1st loop return address and second byte loaded in EEPROM write register
Lo byte of 1st loop return address and first byte loaded in EEPROM write register
Hi byte of 2nd loop return address
Lo byte of 2nd loop return address
Hi byte of 3rd loop return address
Lo byte of 3rd loop return address
What 8D1Ah is compared to
The C9 nano looked like this:
C9 10 20 90 8D 1A E0 47 60 08 90 | Write 15 bytes+RET, execute and hash
80 00 78 15 75 81 16 :
which caused this code to be executed:
893C mov DPTR,#8D1Ah
893F movx A,@DPTR
8940 xrl A,@R1
8941 jz 894Bh
8943 mov DPTR,#8000h
8946 mov R0,#15h
8948 mov SP,#16h
894B ret
- - -
Remember, R1 starts equal to 10h. So the above code does the following:
Compare 8D1Ah to @10h (which contains #20h)
If they match, simply return
Otherwise, set DPTR to 8000h
Set R0 to 15h
Reset the stack to 16h and RET, to resume execution at 0400h to load "00 04 00 09" into EEPROM write register which RETs to 01AFh to enable EEPROM write mode
which RETs to 0399h to write 00 04 00 09 to 8000-8003h.
In addition, there was an ECM to detect an H cards running with non-H CAM IDs, although this packet did not loop the card but simply "locked it up" until the next reset:
code:
- - -
C3 nano used to preset RAM locatiosn 10h-1Fh:
C3 0B 00 FE FC 32 00 00 04 AC 01 68 14 | Seed hash only (using 10 data bytes) results in these bytes at 10h-1Fh:
FE FC 32 00 00 04 AC 01 68 14 8A DF A3 AA 81 34
Hi byte of 1st loop return address
Lo byte of 1st loop return address
Hi byte of 2nd loop return address
Lo byte of 2nd loop return address
Hi byte of 3rd loop return address
Lo byte of 3rd loop return address
Hi byte of 4th loop return address
Lo byte of 4th loop return address
The C9 nano looked like this:
C9 12 20 90 83 74 81 60 07 57 70 | Write 17 bytes+RET, execute and hash
05 09 B9 12 F6 22 75 81 19 :
which caused this code to be executed:
893C mov DPTR,#8374h
893F movx A,@DPTR++
8940 jz 8949h
8942 anl A,@R1
8943 jnz 894Ah
8945 inc R1
8946 cjne R1,#12h,893Fh
8949 ret
894A mov SP,#19h
894D ret
- - -
Remember, R1 starts equal to 10h. So the above code does the following:
If first byte of CAM ID is 00, return (everything OK).
Otherwise, AND first CAM ID byte with byte @10h (#FEh)
If result is non-zero (meaning first CAM ID byte is not 01h), go to ECM routine
Otherwise, AND second CAM ID byte with @11h (#FCh)
If result is non zero, go to ECM routine
Otherwise, return (everything OK)
The ECM routine resets the SP to cause the RET to resume execution at 1468h, which RETs to 01ACh, which RETs to 0400h, which RETs to the infinite loop at 0032h...
From: Spacemonkey Gleep <Fictitious@Dont.Bother.Its.invalid> .com>
Newsgroups: alt.dss.hack
Subject: How Write-Once memory works, or "Why H cards hit by the ECM are never going to be fixed"
Date: Mon, 22 Jan 2001 10:56:12 -0800
Message-ID: <Fictitious-402BA7.10561222012001@news.primenet
In response to the umpty-nine-dozen "Why can't we just..." questions about the corrupted write-once area on the card, here's an explanation that may shed some light. (Note to those "in the know": Yes, I'm simplifying things ridiculously. Not everybody playing in this little sandbox is an EE with the knowledge to understand the inner workings of a chip)
A byte of RAM memory is a set of 8 cells that can hold a one or a zero. Which cells have 1s in them determines the value of the byte when you read it. With RAM, you can change the values any time you like. You can think of that byte as 8 switches that can be turned on or off in different combinations to give you various values.
A byte of ROM is similar, in that it's 8 cells that can each hold a 1 or a 0. Unlike RAM, these 1s and 0s are fixed. Instead of the "switches" that RAM has, you can think of ROM as having either a wire (for a 1) or no wire (for a zero). They can't be changed once made. The wire (or lack of one) is a permanent thing.
A byte of Write-Once memory (Also known as "PROM", or "Programmable Read Only Memory") has characteristics of both RAM and ROM. Like RAM, you *CAN* write to it, under certain circumstances. Like ROM, once written, it's **FOREVER**. Think of a byte of PROM as being 8 microscopic fuses.
When the chip is made, all the fuses are "good". If you could see it at the microscopic level, it would look something like this: ( each | is a fuse that isn't blown )
| | | | | | | |
and would have the value FF, or 255 in decimal.
Now, let's say you want the byte to have the value B7 (That's 183 in decimal, and in binary, it's 10110111) To write that value to it, you deliberately burn out two fuses in the byte, leaving it looking like this: (| = unblown fuse, : = blown fuse)
| : | | : | | |
From that point, it would be possible to write to it again, and change the value, *BUT* there's a catch. You can only "blow" more fuses. You can't "un-blow" fuses that are already blown. This means that a number that needs one of the fuses that's already blown out is going to be impossible to write.
So why is this a problem?
Normally, byte 8000 of the H card holds the value 33 (in Decimal, 51. In binary, 00110011) and the byte looks like this:
: : | | : : | |
But after being hit by DTV's ECM last night, the byte is set to 00 - it looks like this:
: : : : : : : :
There's no fuses left to blow out. They're all gone. That means that forever and always, byte 8000 of your ECMed card is going to say "I'm holding the value 00" when asked.
Why this means the card is permanently dead:
VERY early after the card gets powered up and reset, a check is done:
Does byte 8000 hold the value 33?
If the answer to that question is yes, then all is right with the world, and things start happening. The card gets initialized, spits out the ATR string, and then goes into "wait for a command from the IRD" mode. If, on the other hand, the answer is no, then the card goes into an infinite loop that does nothing. If you program in BASIC, it's the equivalent of the line
10 GOTO 10
NOTHING gets done until the next time the card is reset. And then the same thing happens all over again.
This check is in the card's ROM, so it can't be bypassed or changed.
Reprogramming the card won't do anything useful, since the ROM doesn't even get looked at, let alone messed with, by programmers (or unloopers, for that matter) and even if it did, it wouldn't do anything useful, since ROM can't be changed (short of actually damaging it).
So how can it be fixed?
The simple answer: It can't. Congratulations. Your H card is now an ice scraper. Get used to it. Life sucks.
The more extended answer:
If you've got the micro-tools to "rebuild" the blown fuses on the chip, you could go that route, but unless you're a chip manufacturer, or have access to that type of equipment somehow, you ain't got a prayer. We're talking about electron microscopes, tools for depositing single atoms onto the silicon wafer itself, that sort of thing. In other words, trying to do it is going to mean more money, knowledge, equipment, and effort than most any of us are capable of applying to the problem.
In short, last nights ECM was the ECM to end all ECMs. Any card hit by it is toast, and barring someone developing a cheap way to rebuild chips mat the wafer level (which isn't even remotely likely to happen anytime soon) there isn't a thing that can be done about it. Enjoy your new ice scraper.
Or get in touch with me about shipping it to me. I want to dissect it to get the ASIC out of it for some experimenting I want to do.
--
GLEEEEEP!!!!
PGP KeyID: 0x016B6B53 on the keyservers.
http://www.megsinet.net/~kayo/index.html
The pickups in regular DVD players are built like the ones in CDs and CD-ROMs. Some DVD players (Apex, for instance) actually use regular IDE DVD-ROM drives. The pickups in laserdiscs are big monsters, but they're still smaller than the first generation LD players (before CD came out!) which use HeNe tubes because they didn't have laser diodes back then.
But what surprises me most is that he managed to sell half of them, even with a few titles that are still common as dirt at Goodwill thrift stores, and even with a bunch of Atari 7800 titles, considering how well that console didn't sell.
If you think that's bad, how about what Atari did with Pac Man and E.T. They actually made more Pac Man cartridges than they did consoles! So in order to take a loss on these things (both written in six weeks or so, instead of the six months that the average 2600 game took to write--and they show it!), they had them buried in a hole in the desert as a tax write-off. The IRS even made them pour concrete into the hole on top of all the cartridges. Anyone for an archaeological expedition to Arizona?
My suggestion? Use them as construction material. Maybe cover a wall with 'em, sort of like a retro Z-Brick theme for the game room.
That's called "rotoscoping", and it was way overabused in Bakshi's LOTR.
I saw this as a kid, and it was horrible.
<AOL> ME TOO! </AOL>
(like this movie?)
I've been hearing that this is a great movie to laugh at; is it really full of MST3K fodder or what?
Proof that skr1pt k1dd33z are far from a new phenomenon. When I was in high school in the early '80s, I was among the group of hacker kids at my school, but the ones at nearby schools had much more ph33r p0w3r. Of course there was no internet back then, so information was hard to find, and you only had one or two local time-share systems to work with. And this was back when you had to know what the hell you were doing just to log on even when you were supposed to be on a given system. The Internet has significantly lowered the bar on what it takes to be a kiddie.
MCSEs don't come from boot camp, they come from reboot camp!
So I took up a co-worker's offer to install W2K off of the MSDN disks (I had to create four boot floppies because the DVD wasn't bootable), and once I got it stable, I haven't rebooted since the last time I switched around some LAN cards.
My uptime (as measured by the Local Area Connection Status for my LAN card) is now 41 days. I have one utility I've found since then that might work after I reboot, but I haven't wanted to try it badly enough to reboot.
I'd say W2K can be pretty stable if you don't rely on some PFY in IT to ghost install it for you.
Sounds to me like the fucking profanity was as much as anything else a sign that Jobs was fucking serious about being fucking honest.
Slashdot ads are the only ads I intentionally don't filter with my Squid proxy at home. Some of them are even pretty cool. However, a small percentage of the ads they serve up are from doubleclick, and since I'm blocking by URL, they're toast. I wouldn't even know they serve doubleclick ads if I had blocked the /. ads too.
Not only does it feel right, it's symmetrical, so you don't have to worry about which hand to use.