I Just Ruined My SATA Card!!!

[techknight]

Who knows, but something is checking the chip iD!

the PPC processor in the xbox had whats called "eFuses" which is basically a glorified marketing hooblah of just OTP ROM. If you can get the firmware to boot so the system recognizes the card, what it is, and loads a driver, then its booted way past all the sig checks, sanity checks, etc..

 

[dougg3]

I definitely think you're right That is pretty crazy protection you were talking about there! Wow.

I think the next step is to find a spare Pm39LV040 or MX29LV040QC (both of which are known to actually be used on this card) and see if it works with that. I'm still hesitant to mess with the original known-working chip, I'm not touching it with a 10 foot pole until I have another chip that I can make work.

 

[techknight]

Well you had to have that sort of protection in "piracy" ridden devices such as gaming consoles and STBs. CableCard, Ugh I dont even wanna get into that. RSA/3DES/IDEA. One time a TV programming service used to run ECC post-processing on 56-bit DES odd/even control words, AFTER using a RSA/IDEA/RSA MECM decryption mechanism, ECC = Elliptic Curve Cryptography.

Oh, those control-words would rotate every 8 to 15 seconds with a brand new algorithm with each MECM transmission. This still happens today. Except now, the whole process is wrapped in an MDC2 signature checking to verify MECM authenticity prior to decryption, the unwrapped result contains the keyselect to know which IDEA key to pull. Once its pulled, it undergoes an expansion process that gives you P and Q to build the 1024bit RSA keys. and on and on and on and on... ill stop here. lol.

And the most amazing part about all of this, This all happens on an 8-bit 6805 based core!

But I digress.....

 

[dougg3]

Hehe, pretty crazy how much they can do with a tiny core like that! I always knew CableCARD was pretty crazy. I have a few of those in some TiVos.

Looks like Digi-Key has the MX29LV040 chip. It has a C suffix that CC's card didn't have, but it returns the same chip ID. I'll give the Macronix chip a try, and I'll also grab a few more SST39VF040 chips to make sure I don't just have a weird dud.

http://www.digikey.com/product-detail/en/MX29LV040CQI-70G/1092-1126-ND/2744809

 

[techknight]

Yup. All you can do. I know flash ICs have unique serial numbers too, but thats only on ICs that have heightened security. Most CableCARDs used SLE88 infineon 8051 based microcontrollers, which house the keys to decrypt the MECM. They are VCC and Clock glitch protected, VCC uses a switched capacitor core voltage regulator, prevents VCC sagging. Clock is protected by an isolated oscillator. uses an internal RC oscillator to develop the core clock, the external clock is hooked only to the USART.

The older CableCARDs used the SLE66, which is vulnerable to a clock glitch from initial powerup before the RC Osc kicks in, it will run off the external clock early in the boot process. Proper timing is required, you can get past the transport key check and get into the siemens CardOS backdoor which is accessable only by holding the I/O line at a certain state during power up for around 200mSec.

TWC and im sure other cable companies started swapping thier cablecards and harware to the new powerkey multistream ones which contained the SLE88, and thus better security. and not the single stream cards which were SLE66 based. (vulnerable/hackable).

the non-cablecard digi boxes were running ST16/ST19 which is 68HC05 based and contain NO protections, only protection is the box authorization from the head end. But nothing stops you from using a modified non-provisioned digital cable reciever (like ones used in Tvs to get cable based HD locals), and having the keys. whoops.

nowadays though, cable has become more and more streaming based. the new cable boxes use the cablecard for the VA decoding like before, but the actual video is transported via media stream on request, and not global transmission that anyone can recieve thats connected on the network looking for it. (like sat, or older cable days). Basically a DOCSIS modem on the box, and a "glorified encrypted netflix". So you still have to have a provisioned unit (like a un/pw) to request access to the stream, plus the cablecard has to have the auth key for that particular stream. Double wammy.

 

[onlyonemac]

Maybe it's not the flash chip at all? Perhaps there's something else wrong with the card (ESD perhaps)?

 

[dougg3]

I think ESD is doubtful if the problem happened right after a failed firmware update...I'm pretty sure I'll be able to fix CC's card one way or another. Here's something interesting. I checked my system.log and on successful boots with the chip that works, this message appears:

"FT_ATA_Sil3112::InitialState: integrity check: FlashMemoryVenId = 9D, FlashMemoryDevId = 3E"

(that's the vendor and device ID that the Pm39LV040 chip returns)

There is not a similar message for the crashed boots with the SST39VF040. I think this is just more evidence that the driver is probably checking the chip ID. I looked at the flash dump and some of those strings above appear, but they are compressed with weird characters in between like trag noticed in the other thread. I think the OS X driver is stored inside the flash chip and it's compressed with LZSS or something.

 

[onlyonemac]

Perhaps the failed update caused something to burn out on the card, particularly since it was in use at the time (e.g. an input was reconfigured as an output during a reset procedure, which meant that the input from the hard drive in use caused the pin to burn out or something).

 

[dougg3]

That may be true, but I think it's more likely that the chip just needs re-flashing.

OK, so I made some more progress. Despite UPDFLASH.EXE's instructions claiming that you can run it from Windows 98 when restarted into DOS mode, I don't think it works reliably from there. So I used their other instructions and made a FreeDOS floppy and copied everything to it. With that change, UPDFLASH.EXE was able to perfectly flash the SST chip and verify its contents on the first try.

Then I booted into OS X in verbose mode (holding down command-V) and took a video so I could see the kernel panic scrollback. Here's what I saw as I stepped frame-by-frame in my video DIRECTLY before the kernel panic:

FT_ATA_Sil3112::InitialState: integrity check: FlashMemoryVenId = BF, FlashMemoryDevId = D7

FirmtekCtrllr::start: InitialState() failure

BF and D7 are the manufacturer/device IDs of the SST39VF040 from its datasheet. I'm almost 100% certain now that the driver is crashing on purpose because it's finding a chip they didn't use. Basically they're trying to prevent you from flashing their firmware onto any old PC card that uses a different flash chip. So not only does the chip you use have to be big enough, but it also has to be a chip model that they used.

 

[CC_333]

That's excellent!

This means that your method of flashing using UPDFLASH.EXE in FreeDOS ought to work.

I got your PM, and I'll give it a try tomorrow.

Thanks for your help! I felt like an idiot when I started this, and you've really helped pull me through this endeavor.

c

 

[max1zzz]

Hmm.. It's interesting it seems to be checking the flash chip Id, since I tried flashing it to my PC Card (using a random 2 mbit sst chip I had (39sf020)) and I didn't get any kp's, the card got recognised as a seritek card, but hdds wheren,t reconised.

Flashing it with the webietech firmware got it working, but it keeps makeing my G3 kp.... I gotta try it in a G4 tommrow

 

[dougg3]

Hey no problem CC_333 I saw that you were having a problem with your card and I figured I might be able to help. Hopefully this will help and we'll all benefit from the new knowledge about the firmware.

I just tried the DOS flasher to put ROMFILE.1S2 (the 5.1.3 version) contents onto an SST chip. I padded ROMFILE.1S2 with 0xFF bytes at the end so it is exactly 256 KB in size, as suggested earlier in this thread by jruschme. The verify did fail once, so the DOS flasher still isn't completely reliable...give it multiple chances if the first time doesn't work. I verified again and the second verify was successful. Anyway, it doesn't kernel panic, but it doesn't work either.

max1zzz: it looks like the kernel panic is specific to the new 5.3.1b1 version. Here are my results with OS X 10.4.11 on my B&W G3:

- SST chip, 5.3.1b1: kernel panic

- PMC chip, 5.3.1b1: success

- SST chip, contents of ROMFILE.1S2: successful boot. Apple System Profiler doesn't show the card under PCI, but IORegistryExplorer with the dev tools sees the card. Appears that the driver doesn't load.

In fact, with ROMFILE.1S2 flashed to my SST chip, the system.log file in the Console app shows the FirmTek driver 5.1.3 loading but it bails out. It doesn't have the message about looking at the chip ID, but I'd have to assume that's why it's bailing especially after what 5.3.1b1 does. Probably just doesn't kernel panic when it fails and instead fails silently. So I really, really think that the chip ID is being checked.

Edit: OH, the card extracts its driver kexts (two of them -- FT_ATA_Sil3112.kext and Sil3112DeviceNub.kext) into /System/Library/Caches/com.apple.romextensions. One purpose of FSCAPP is to clear those out after the firmware changes.

So ROMFILE.1S2 appears to have weird encoding because it contains a compressed version of these kexts that are expanded out to the actual computer. ROMFILE.1S2 should definitely be written directly to the flash chip, no special encodings. I'm sure of it now.

 

[dougg3]

Yep. I found a place in the kext in /System/Library/Caches/com.apple.romextensions where the device and chip IDs for MXIC and PMC were next to each other. I changed one of them to my SST chip's ID, manually loaded the kext, and now the driver is working correctly. It's definitely checking the chip ID. It's mixed in with other data so I don't know if there are any other chip IDs present.

As far as I can tell, the chip has to be a Pm39LV040 or an MX29LV040 in order for the driver to load.

Edit: Found a SATA drive to hook up and it works on the SST chip flashed with ROMFILE.1S2! So the chip ID was the problem all along and I'm no longer afraid to mess with the original card. CC_333 should be able to flash ROMFILE.1S2 (or my newer firmware) with the DOS flasher and it should work.

 

[MacJunky]

What about under OS 9 and earlier?

 

[dougg3]

I would assume the OS 9 driver is going to have a similar chip ID check. If the FirmTek firmware is working under OS X, I'm pretty sure it's going to work under OS 9 as well...since it was advertised as OS 9 compatible.

 

[max1zzz]

Dougg3, do you think that modifing the chip I'd would get my generic card working? The card is being seen as a seritek card, and both kexts seem to have extracted themselfs, but it just won't see anything connected to it

Works fine with the webietech firmware (except from makeing my g3 kp) which also seems to extract a driver to the same place

 

[dougg3]

Yep, I would recommend finding one of the two chips I mentioned and putting it on instead. I bet it would work. After the kext is extracted, it loads. Code inside the kext itself decides that it shouldn't succeed because of the chip ID. So if the kext has extracted itself I'm pretty sure your chip has good firmware on it, just it's failing the chip ID check.

The only problem is I believe CC_333 has discovered that the MX29LV040 chip doesn't work with the WiebeTech flasher, so you will probably need to use the DOS flasher (or a chip burner) to get the contents on there initially.

I'm experimenting with a few ideas for how to force the FirmTek flasher to recognize a card with blank or corrupt firmware on it.

Edit: Yep, it works! I force-quit the FirmTek updater in the middle of an update. It no longer loaded a driver or anything, so the firmware was corrupt.

If you save the two kexts in that cache folder, then manually load them with kextload:

sudo kextload -d ~/Desktop/Sil3112DeviceNub.kext ~/Desktop/FT_ATA_Sil3112.kext

Then the FirmTek updater will allow you to run and flash the card. But again, the chip has to be one of the chips that is allowed to be used by the driver.

 

[dougg3]

The strategy I described above doesn't work with an empty chip though. So the DOS flasher is still a good idea.

Anyway...I finally grew a pair and screwed around with the original working chip. Yep, we're all good. ROMFILE.1S2 is a valid file to flash to the chip, either through the DOS flasher or the WiebeTech flasher (except we already know Wiebetech doesn't support Macronix chips in its flasher :-( ) OK, I promise I'm done adding a bunch of random info to this thread! Whew

Edit: I lied, one more update. I started decoding the PCI option ROM. It includes an OS 9 driver as well as an OS X mkext, version 1, which is encoded using LZSS just as I suspected!

 

[CC_333]

All fixed now!

I'd like to thank every one for their help and support, especially dougg3 for his persistence and knowledge.

I will NEVER flash like that again!

WHEW!!

c

 

[dougg3]

Woohoo! Well, glad to hear that UPDFLASH.EXE got you up and running.

I'm pretty sure there's something about that DOS flasher that just completely sucks under the DOS mode you can reboot into from Windows 95/98. FreeDOS on a floppy seems to be the way to make it work.