[HTC Wildfire S] no.human.being:
The "files" in "/dev" are not "ordinary" files, but so-called "device files". They are not files stored in the file system, but represent an interface to an underlying kernel device driver. It's the way POSIX systems handle hardware ("everything's a file" is one of the core concepts of Unix). You won't be able to do "standard file operations" (like copying them around) on them, so not sure what you want to do with root explorer. They are an interface to a hardware driver.

When you "fopen" such a "device file", the operating system connects you to the device driver that has registered for this device and all read/write/seek calls executed on this file handle are subsequently forwarded to the driver. For device files, there's an additional ioctl (I/O control) call for device functionality that does not intuitively map to read/write operations, like control register access.

For example, "/dev/urandom" is an interface to the system random number generator. When you read from it, this read will return an endless stream of random numbers. This does not mean, that there is really a file containing lots of random numbers though. The operating system simply informs the "driver" (in this case the random number generator) that there is a process that wants to "read" from its device file at a specific location, the RNG generates random numbers on-the-fly and returns them. The operating system then makes it look like they were in this file. Of course, the random numbers never touched the platters (or the NAND in case of a phone). It's just an abstraction the operating system provides to the applications so that hardware access can be done just like ordinary file access.

The "/dev/block/mtdblock*" device files are owned by root, so temproot is a precondition that has to be met before access to these devices can occur. However, I'm currently having the impression, that we cannot open the "/dev/block/mtdblock*" device files at all on Android. This has nothing to do with S-ON/S-OFF or permissions though. A fellow student has an S-OFF permarooted phone and cannot access these files either. I'm not sure why they cannot be opened. It doesn't make any sense. However, possibly it's just a bug in the Android utilities, not a problem with the device files themselves. I just need a possibility to compile C code for the phone now in order to figure this all out. If the devices can be opened and the offsets are right, then the C code I posted on page 12 should do the trick.

The "SIM" of xtc clip is a flex cable that connects to GPIO pins of a microcontroller inside the "black box" that comes along with the clip. What it does depends on the microcontroller's firmware, but I think it will use the SIM card slot as a "communications bus" to the phone, so it won't be a simple ground or impedance, but it will send some kind of "data" and "clock" over it in a timed fasion. Remember, SIM cards are microcontrollers themselves. They do the encryption of the data that goes over the air. The xtc clip may make all sorts of stuff over this cable. In the end it tries to emulate an HTC "whitecard" (some kind of "engineering SIM"), which is a microcontroller itself.

I think there is an electronic schematic of xtc clip's circuit board somewhere on the internet. It will contain the ICs used along with their manufacturer and part number, the wiring scheme, etc. It already has been reverse-engineered. It's a microcontroller and even its firmware has been dumped and is floating around somewhere on the net, but this will be of no use. You will have to etch the PCB, get the controller and a programming interface to "burn" the microprogram on it. It will all be freaking expensive and you will be better off just buying an xtc clip. What we all need is a software S-OFF (like Revolutionary), that can be distributed for free, not another hardware S-OFF (like xtc clip) that can't be free because of manufacturing costs. This is why I'm working on the former, not the latter.