This is a stub! This article is just a stub since a working solution via JTAG so far seems only available for HTC Dream / Magic. You may search for software-based debricking solutions, maybe it can solve your problem.

Creating “open source phones”. The background to this experiment is that I want to have “open source phones”: phones that you can operate and repair fully on your own with open source hardware and software tools, needing the manufacturer no longer after manufacturing the device. The tools needed for this are very different for different phones, so I specialize here on JTAG enabled smartphones, esp. HTC Desire HD and HTC Desire S. (Note that JTAG is quite a universal standard in modern smartphones, so it does not make much sense to deal with older, even more proprietary devices.) This article is immediately applicable to these models only, but will work for other HTC models and mostly also generically for JTAG enabled devices.

Now the toolbox for maintaining and repairing most HTC phones consists of (gratis or free) software tools to be found via famous XDA Developers, but not all tasks can be done by software. Esp. for some variants of unbricking, a hardware device is needed because the JTAG port has to be accesses. The task of this article is to explore this JTAG-related part of the toolbox, which seems to be so far the biggest gap for a fully open source toolchain for operating and repairing modern (Android based) smartphones.

Desired features of the open source JTAG tools. For the concept of “open source phones”, it is not really necessary that all tools involved in rooting, setting S-OFF, SIM unlocking etc. are open source. Because a phone is an “open source phone” only once being in this freed condition, so it does not matter if the tools to free it are as proprietary as those used to lock it down in the first place. However all tools needed at any point of the life cycle of a “freed phone” have to be open source software and hardware. This means, additionally to all the custom ROMs available and the techniques to apply them, the following:

  • open hardware JTAG adapter (this is just the hardware to connect a computer to the phone’s JTAG interface)
  • open source software and instructions for debricking / resurrecting the phone
  • open source boundary scan test software for identifying hardware damages to the phone via JTAG
  • open source software for changing IMEI, CID and model ID (however, be sure to respect the legal boundaries in your jurisdiction regarding these operations)

This also means that only those phones can become “open source phones” for which all challenges of freeing it have been solved (for HTC phones: S-OFF, radio S-OFF, permanent rooting, flashing a custom ROM). Simply ignore other models, as they’re not yet part of the free world 😉

Component: open source JTAG hardware adapter

This is just an idea list of principal alternatives so far. I did not investigate them more than detailed below.

  1. Bus Blaster v2. An open source hardware piece for just 35 USD that can cooperate with lots of open source JTAG debugging and flashing software, including Open OCD and urJTAG. At first sight, seems like the first solution to try.
  2. Open JTAG. This is an open source hardware project for a JTAG adapter. It is available fully assembled for ca. 80 EUR as of 2013-01.
  3. GoodFET. Another JTAG interfacing open source hardware that can flash chips, also including client software. However I could not find out so far if it can be used to access HTC phones; this should probably start by looking at their list of supported chips.
  4. Proprietary hardware (for use with open source software). Might be a good first step: finding or creating open source software to use in collaboration with an existing commercial JTAG box like the RIFF box. Notes: I do not know yet if and which means the RIFF box uses to secure access from other software.
    1. RIFF box. This is a great (widespread and recommended) choice. Ca. 130 USD [example]. It is possible to unbrick many devices [list], including HTC Desire HD and Desire S. Their software is proprietary and for Windows XP / Vista / 7 only [source]. Also see their manual and support documents and an additional official support forum.
    2. ORT-JTAG. The Omnia Repair Tool, a JTAG flasher and emulator that supports various CPU types and platforms, including the HTC Desire HD and HTC Desire S [source]. It is possible to unbrick the HTC Desire HD with this tool [instructions]. Price is 150 USD as of 2013-01 [source].
    3. XTC Clip. This is an unlocking device, not an unbricking device. However, as I do not know if RIFF box can do S-OFF for all models it supports, and as there are models where S-OFF can not be done by software only, you may need the XTC Clip for some purposes.
    4. Some other boxes. Not all available boxes used for phone service are based on the JTAG interface. It seems that JTAG is only available on newer phones, so a box like the Saras Twister cannot be hacked to do JTAG stuff.

Component: open source JTAG software

  1. goJTAG. A free and open source software package developed by universities that makes exhaustive use of JTAG capabilities, including your own boundary scan tests. [TODO: Find out if it is capable of flashing to devices as well.] It normally is meant to work with the commercial PicoTAP JTAG hardware adapter, but the great news is that now you can use the open source Bus Blaster v2 as well.
  2. OpenOCD. The “Open On-Chip Debugger” project, a mature, sophisticated, flexible software suite for dealing with all things JTAG. Esp., it can be adapted to work with several JTAG debug adapters [source], but you may have to write an own config.
  3. UrJTAG. An open source project to create a universal JTAG library, server and tools. From superficial impression, it seems that OpenOCD is more mature and more active in development, however. But UrjTAG has great documentation with interesting background infos.

Creating a solution

There is no ready-made solution for unbricking most phones with these open source tools so far. But I found one great example process, based on OpenOCD: JTAG Softboot for HTC Dream / Magic. It shows that several security measures have to be dealt with in order to flash, and the development of that process shows a strategy how to develop it for other phones like (in my case here) the HTC Desire HD and Desire S.

This knowledge about security workarounds etc. is what the authors of commercial tools (RIFF box, ORT-JTAG) have developed, and guard in their software and firmware. So maybe the simplest solution is to reverse engineer it from there.

Anyway, getting these tools to work for unbricking phones is a lot of work. The first few steps, in my view:

  1. Get a JTAG cable adapter for the phone in question, like this for HTC Desire HD or this for HTC Desire S.
  2. Get yourself an open source JTAG hardware interface, such as the Bus Blaster v2.
  3. Find out the JTAG pinout for the phone in question.
  4. Find working OpenOCD / UrJTAG / goJTAG configurations for the phone in question. One can also create them oneself, but it’s not a straightforward job as even with the same processor, devices have other configurations for access with JTAG [source, example for HTC Wildfire S].
  5. Find every piece of information about debricking the phone in question, incl. the security measures to deal with in order to flash a working bootloader again. This may include the reverse engineering just mentioned, which you would carry out by sniffing and looking at the live communication between commercial software, its JTAG hardware interface, and the actual phone.
  6. Create a script or instructions that use a suitable open source JTAG software package to execute the proper debricking method for the device.

This manual lists all the steps, in logical order, to go from a physically broken phone to a great working, free and open source phone. It links to several other articles on this blog for detailing individual aspects.

Hardware

(1) Getting your hardware repair tools ready

A good toolset is demonstrated in HTC Desire HD Disassembly Video. Not all of these are needed though. I recommend these:

  • Safe-open pry tool.
  • Small torx T5 screw driver. 
  • Small cross screw driver. 
  • Scissors. For cutting the adhesive tape to size. I recommend good chirurgical scissors, for cheap from eBay.
  • Hair dryer. For heating the adhesive below the display edges to safely open the phone.
  • Clear double-sided adhesive tape. This is the only type of tape you really need, as it can replace resp. used to DIY produce the other types mentioned below. I recommend a good quality tape from 3M. I usually buy the 25 mm wide variant, which is wide enough for all jobs, and cut it to size as needed.
  • Touchscreen mount tape. This is 2 mm wide double-sided adhesive tape that is offered specifically for phone display repairs, and is useful for many models. Alternatively, you can use more standard, wider clear double-sided adhesive tape (see above) and cut it to size; this is ok if you do one or a few phones. Potential sources for the narrow tape:
  • Metal-shielded Mylar tape. Used for shielding some connectors etc.. After taking these off, they normally have to be replaced or reworked. Potential sources:
    • It is possible to remanufacture these tape pieces. Use a double-sided adhesive tape that has a plastic film inside, similar to the original black tape, as else the metalized fabric will cause shorts. A good idea (to be tested) is to use 3M doublesided detachable adhesive tape 3M 4658 F, for simplifying future repairs. A good source for the metalized fabric is also the large sheet of metal-shielded mylar tape from the back of the display unit, after detaching it from the frame. It can be backed with new adhesive, then cut to size.
  • Double-sided adhesive sheet. Some use it to glue the touchscreen to the LCD and the LCD unit to the chassis [source]. However, it is very thin and too delicate to handle for these purposes. You may find it useful for some other re-glueing jobs on the phone, but I did not miss it when having the film-based clear double-sided adhesive mentioned above. The source mentioned refers to a 3M Adhesive Transfer Tape with the 200MP adhesive, which is available in multiple variants, differing by thickness and backing material. They are sold both in sheets and rolls (and 70 mm wide rolls would fit the HTC Desire HD) but not all are easily available in small quantities. Currently I use the 3M 467MP variant (it's the thin variant, while 3M proposes that for glueing two hard surfaces together it may be necessary to use the thicker variant). Some sources:

(2) Identifying problems with the hardware

Known failure modes by frequency, according to my subjective impressions. It includes only failures for which there is at least one practical example. This is of course an incomplete list.

  1. Cracked display from falling.
    1. Only touchscreen cover glas broken, touchscreen works, display works. It is sufficient to just exchange the touchscreen digitizer unit. Separating it from the display unit is however a bit difficult [instructions]. Maybe it is even possible to just replace the cover glas, maybe even with a self-cut polycarbonate sheet (the glas breaks too easily in my view!). Did not try yet.
    2. Only touchscreen cover glas broken, touchscreen does not work, display works. It is sufficient to just exchange the touchscreen digitizer unit. Separating it from the display unit is however a bit difficult. [instructions]
    3. Only touchscreen cover glas broken, touchscreen and display broken. You need to exchange the complete touchscreen and display unit. That saves some work, as you don't need to separate these both then [instructions].
  2. Water damage.
  3. Display background light does not work.  In this case, the screen itself shows an image, which can be seen with a flashlight [instructions]. To repair, try to replace the LCD unit first, and if that does not help you can try to reflow or else exchange a certain IC [source, with image]. You will also find some generic tips in a guide for a Nokia phone's backlight. In some cases, it is possible to get the backlight back while exerting some pressure below the menu button near the HTC logo [source].
    1. But touch key backlight work. [source, in German]
    2. Touch key backlight does not work either. I had this case myself.
  4. Intermittent wifi and 3G connection loss. There seem to be lots of different causes for this, but in many causes it is because of bugs in the firmware (incl. stock firmwares). In these cases, installing a custom ROM without such issues will help.
  5. Broken loudspeaker. In this case, the loudspeaker will not work, but the internal speaker and headset will work. Fix: Replace the loudspeaker. This is a small press-fit device at the back of the mainboard and is replaced easily.
  6. Poor or no GPS reception. This seems to be quite a frequent with the Desire HD, kind of its weak point. Fix: If GPS never worked properly with your current ROM, try updating the Raio image first (see below). If it worked before with your ROM, try to re-seat the GPS antenna by pushing on the lower part of the plastic cover that also contains the flashlight LED lenses [source]. By doing this while having the "GPS Status & Toolkit" app running, you get immediate feedback when the condition improves. If this does not help, take out that plastic piece and clean the contacts. If that does not help either, replace that piece with the GPS antenna.
  7. Humidity from hand sweat made stains in the display. It was reported that through using the phone in summer (holding it in the hand), sweat got between the display and the light dispersion film and caused stains / irrgular lighting. These stains are only visible when the background light is on, and are most visible on white backgrounds. [source, in German]
  8. Losing GSM signal sporadically or bad reception. Fix: Try cleaning the contacts of the GSM antenna (it's in the SIM / SD card cover) and ensure proper connection [source]. If it does not help, look for problems with the currently installed Radio version and try a newer and better one. If that does not help, exchange the main board.
  9. Losing wifi signal sporadically or bad reception. Fix: Try cleaning the contacts of the wifi antenna (it's in the battery cover) and ensure proper connection. If it does not help, look for problems with the currently installed Radio version and try a newer and better one. If that does not help, reflow the wifi chip if you can, or simply exchange the main board.
  10. Proximity sensor not working properly. The proximity sensor is that little piece looking like a clear LED, to the right of the earpiece speaker. Its task is to detect if you are holding the phone to your ear during a call; it will then switch off the screen for you. In a combination with many custom ROMs, this sensor does not work as expected because of improper calibration data. There is a handy tool called DHD Proximity Sensor Recalibrator to fix this – see there also for hints on usage. The tool is alread included on CyanogenMod 11 for Desire HD (as installed below), as an app under the name Proximity Recalibrator (com.leppie.dhd).

(3) Repairing hardware defects

Software

(4) Getting your software tools ready

TODO

(5) Freeing the phone: ENG S-OFF, Radio S-OFF, SuperCID, SIM unlock, permaroot

There are several guides available:

So I recommend here using the above Advanced Ace Hack Kit tool and procedure. This will result in: ENG S-OFF (mostly called just "S-OFF"), Radio S-OFF, SuperCID, carrier SIM unlock, rooting ("permaroot" type), Busybox installation, ClockworkMod Recovery installation [source]. So, nothing left to do then.

While still you're encouraged to read their effin-manual.html (in the downloaded package) and follow the steps in there, I want to add one crucial step of help: To get the PASS KEY, start the AAHK software (on Linux sudo ./hack-ace.sh), then look up the key in ./tools/txt/CAJUN.txt. It is generated new each time you start that software. (Sorry attn1, I understand your nerdy humor but I'm so used to fly through docs without harming myself that … well … you got me a little upset with that forced effin manual consumption 😉 )

 (6) Installing a Recovery solution

Finally, I like 4EXT Recovery Touch pretty much, so let's install it over the ClockworkMod recovery provided by Advanced Ace Hack Kit.

The first nine steps from the following list are only needed for the first phone where you want to install 4EXT Recovery Touch.

  1. Make sure USB debugging is enabled (Settings -> Applikations -> Development options) and Fastboot mode is disabled (Settings -> Power). That may seem counterintuitive as we want to use a tool called fastboot, but that tool and the startup speed improvement share nothing but the name. Also, disabling Fastboot mode may or may not be necessary [source].
  2. Connect the phone by USB cable and select "Charge only" for the connection mode.
  3. Set up Google Play. We need it for installing BusyBox.
  4. Install the BusyBox app via Google Play, then start this app and install actual BusyBox with it. BusyBox It is a set of Linux core utilities needed by 4EXT Recovery Updater below.
  5. Download 4EXT Recovery Updater from here, and install it with:
    adb install 4EXTRecoveryUpdater.apk
    (Alternatively, you can support the developer by purchasing 4EXT Recovery Control via Google Play, which you can also use here.)
  6. Start 4EXT Recovery Updater and instruct it to "just download" the latest version of 4EXT Recovery Touch for the HTC Desire HD. That would be version 1.0.0.6 RC3 as of 2014-08. (After that, you can also install it from right there, saving you the remaining steps below. We only do the download step here because it saves you all preceding steps for the second and following installations of 4EXT Recovery.)
  7. Transfer the 4EXT Recovery Touch installation file to your computer:
    adb pull /sdcard/download/4EXT_Recovery_Touch_v1.0.0.6_RC3.zip 4EXT_Recovery_Touch_v1.0.0.6_RC3.zip
  8. Unzip this archive and change to its directory:
    unzip 4EXT_Recovery_Touch_v1.0.0.6_RC3.zip -d 4EXT_Recovery_Touch_v1.0.0.6_RC3
    cd 4EXT_Recovery_Touch_v1.0.0.6_RC3
  9. Check the MD5 sum:
    1. Edit recovery.md5 and append "  recovery.img" (two spaces plus filename) to the first line to make it a proper md5sum file.
    2. Execute md5sum -c recovery.md5
  10. Boot into bootloader, which is the mode we need to be in to use any fastboot command [source]:
    adb reboot bootloader
    The phone should show a line indicating the mode as "Fastboot plus USB" or "Fastboot USB".
  11. Flash 4EXT recovery to the phone:
    sudo fastboot flash recovery recovery.img
  12. Reboot into recovery mode to test 4EXT Recovery Touch. For that:
    1. Power the phone off.
    2. Hold "Volume Down" and then press "Power". It will boot you into the bootloader.
    3. In the bootloader, select "Recovery" by pressing "Volume Down", and start it by pressing "Power".

(7) Updating the Radio image

The "Radio" is a second computer (CPU, RAM) inside the phone that operates just the various radio communication devices so that phone calls etc. are not affected by any malfunctioning app on the main processor. There is an image called the "Radio" containing the "operating system" for this mini computer, and the manufacturer also relases differnet versions of this that fix issues with old versions etc..

Updating the Radio can fix GPS, wifi, GSM and 3G connection issues, improve reception and battery life and also fix freezes and call drops caused by a buggy Radio firmware. For example, GPS reception won't work at all in new Android versions (like 4.4.2) with too old a Radio (like 14.04.28_M – source; or 26.10.04.03_M – own experience). The newest (and generally recommendable, it seems) Radio as of 2014-05 is Radio 26.17.14.11_M.

Flashing a proper RIL (Radio Interface Library) is not necessary and not even working with CyanogenMod 10.1 or 11, as it is only for HTC Sense based ROMs [source].

For flashing instructions, use "The Google Way" in the first post of "The HTC Desire HD Radio Thread" or a longer version in its own thread. Short version of this, which can be used with Linux (but be careful and read what you must, you can brick your phone):

  1. Preconditions. We met these above already, but keep the accumulator in mind:
    • phone is rooted
    • phone has Radio S-OFF
    • phone has ENG S-OFF
    • PC has adb installed
    • PC has fastboot installed
    • phone has USB debugging mode enabled
    • phone is connected to PC in USB debugging mode
    • charged accumulator
  2. Download and extract. Download the Radio image and extract that ZIP anywhere on your PC. It will have a file radio.img in it.
  3. Go into the target directory. That is, where you just extracted the file.
  4. Check the MD5 sum. For the latest Desire HD Radio (PD98IMG_12.69.60.29_26.17.14.11_M.zip), the MD5 sum of its radio.img is b3c3fe8dd79e933cc60a16d6d3c3a13f [source]. So create a file radio.img.md5sum with the content (note the double space in the middle)
    b3c3fe8dd79e933cc60a16d6d3c3a13f  radio.img
    and execute, to check the MD5 sum: md5sum -c radio.img.md5sum.
  5. Reboot to bootloader. In a terminal on your computer, execute: adb reboot bootloader. Your phone should go into bootloader mode now.
  6. Flash the Radio image. For that, execute in the terminal of your PC: fastboot flash radio radio.img (on Ubuntu, you may need to do sudo fastboot flash radio radio.img in case of getting a "< waiting for device >" error).
  7. Reboot to normal mode. For that, execute in the terminal of your PC: fastboot reboot (again, on Ubuntu sudo fastboot reboot).

(8) Installing a custom ROM

This and the following step (installing apps) can also be replaced by just restoring a full backup (created by 4EXT Recovery on the same device or a different device of the same model). It will restore the operating system, all apps, apps settings, and apps data, and works very well for "mirroring" one device to another one (of the exact same model of course). So if you set up certain devices regularly, you can save time by preparing such an image once and installing it on all the devices you set up.

For manually installing a custom ROM, do it like this:

  1. First, download your favorite custom ROM. I like the brand new unofficial CyanogenMod 11 Nightlies for Desire HD. Download both the ZIP and the MD5SUM file for it.
  2. Download the Google Apps package. Available here, including a nice "Minimal" version that only includes "essential" Google Play.
  3. Put your Google Apps package on the phone (no MD5 sum checking needed because it uses code signing):
    adb push GApps_Minimal_4.4.4_signed.2014-07-29.zip /sdcard/GApps_Minimal_4.4.4_signed.2014-07-29.zip
  4. Put your custom ROM on the phone. Most comfortably done like this:
    1. Fix cm-11-xxxxxxxx-UNOFFICIAL-ace.zip.md5sum by removing non-existing directory names.
    2. adb push cm-11-yyyymmdd-UNOFFICIAL-ace.zip /sdcard/cm-11-yyyymmdd-UNOFFICIAL-ace.zip
    3. adb push cm-11-yyyymmdd-UNOFFICIAL-ace.zip.md5sum /sdcard/cm-11-yyyymmdd-UNOFFICIAL-ace.zip.md5sum
    4. Check the MD5 sum: mount the SD card, and execute in the directory of its mountpoint:
      md5sum -c cm-11-yyyymmdd-UNOFFICIAL-ace.zip.md5sum
      Alternatively, you can check the MD5 sum with the app 4EXT Recovery Control, or later within 4EXT Recovery Touch itself.
  5. Reboot into recovery mode:
    adb reboot recovery
  6. Follow ral's 4EXT Recovery Howto step for installing a custom ROM. Do not forget to also flash the Google Apps package.

(9) Installing apps

See my list of recommendable Android apps, using open source ones where available. For the first phone you prepare, you will have to install them on the phone directly (or remotely via adb), but can then use the backup solution for apps and data proposed below to quickly transfer them between ROM upgrades and to other phones.

Management

Setting up a backup system

Backups of an Android phone serve several purposes:

  • Restoring apps after ROM upgrade. Installing a new ROM that includes a major Android system upgrade requires a full wipe, meaning that you would lose all the apps and app data stored in the internal partitions [source]. (Moving apps to the SD card is not a general solution either, since that does not work for all apps [source].) To work around this, we need a proper backup and restore solution for apps and data.
  • Snapshots to restore the phone to. We want full-system backups that can restore the phone to a snapshot in case something breaks severly (mostly due to a failed ROM upgrade). 4EXT Recovery already contains a Nandroid backup-and-restore feature for that.
  • Restoring to a new phone after theft, loss or hardware defect. With the Nandroid backup-and-restore solution integrated in 4EXT Recovery, we can also restore these backups on a second device of the exact same model. So when travelling, take an identical spare phone with you, and create a Nandroid backup daily (then copy the SD card to your computer, to also include the non-backuped card data like in-app downloads, photos, music etc.). When you lose your phone, have it stolen or broken, you can be up and running again in 15 minutes with the exact same data you had a day before.

Doing a full backup that affords all of the above will look like this, then:

  1. Nandroid backup. Create a new backup with 4EXT Recovery to your SD card.
  2. System app data backup. Since restoring this data into a new version of a ROM can cause problems, use specialized backup solutions for call logs, SMS etc..
  3. App2zip for user apps. Use App2zip to back up your user apps and their data to a ZIP file on your SD card. You can later install them via 4EXT Recovery into a new ROM when needed.
  4. rsync. rsync your complete SD card to your PC. This will copy over all backups created above, plus the files on the SD card not included in them (in-app downloads, photos, music etc.) to a secure location.

To set up the same phone or another phone of the same model with the same ROM, apps and settings is then simply about restoring a Nandroid backup with 4EXT Recovery from the SD card.

To set up a different phone with the same ROM, apps and settings, or a same or different phone with a different ROM (while keeping apps and settings), the restore process looks like this:

  1. rsync from your PC to a SD card.
  2. If necessary, put the desired ROM ZIP file on the SD card.
  3. Wipe the phone via 4EXT Recovery.
  4. Flash the ROM's ZIP file.
  5. Flash the Google Apps ZIP file.
  6. Flash the ZIP file containing your user apps and apps data.
  7. Restore SMS, call logs and other system apps data using their special backup solutions.

Knowledge resources

This manual lists all the steps, in logical order, to go from a physically broken phone to a great working, free and open source phone. It links to several other articles on this blog for detailing individual aspects.

Hardware

(1) Getting your hardware repair tools ready

Please see the corresponding section in my HTC Desire HD manual.

(2) Identifying hardware defects

Symptoms, by broad symptom, then split into sub-cases. This only includes symptoms for which I had at least one practical case. So of course it's an incomplete list.

  1. Cracked screen glas.
    1. Cracked screen glas, touchscreen works, display works. It is sufficient to just exchange the touchscreen digitizer unitbut it involves re-glueing it to the screen unit.
    2. Cracked screen glas, touchscreen does not work, display works. It is sufficient to just exchange the touchscreen digitizer unit, but it involves re-glueing it to the screen unit with small stripes.
    3. Cracked screen glas, touchscreen does or does not work, display does not work. Fix: Exchange the complete touchscreen and display unit. That saves you work, as you don't need to separate these both.
  2. Does not power on. 
    1. Water damage. Aas indicated by the water indicator or by what happened to the device. Fix: Immediately dry the device by storing it in rice for some days. Exchange the main board. If display is also affected, you need to also exchange it (but maybe can keep the touchscreen unit).
  3. Sweeping sound when plugging in or powering on. A high-frequency sweeping sound of ca. 0.5 s duration. In case of plugging in, it only apeared when the phone was off. Diagnosis: bad connection of earpiece speaker. It probably has only one of its two contacts connected, the other might be bent. Fix: Bend earpiece speaker contact to correct postion. Else, exchange earpiece speaker. It can be pushed out from the front after disassembly to the bare screen unit.
  4. Touchscreen problems. 
    1. Intermittent touch button function. Sometimes, the touchscreen will work, but the touch buttons will not. Putting the phone into standby and waking it up again (by pressing power button twice) can fix this for a time, and it mostly stops working at one of the nest wakeups from standby or reboots. Flexing the phone durng standby, or better compressing the display unit in the touch button area somewhat, will help to fix the problem more often on wakeup. But since the display unit is a closed unit with too much space below the touch buttons to compress the contacts, this is not a well-working recipe. Diagnosis: Connection issues at the flex cable's glued connection to the touchscreen film. Alternatives may exist. In my case, this happened when I accidentally lifted a bit of the glued touchscreen film before mounting it as I though there has to be a protection film as my other touchscreen spares. Fix: Replace touchscreen unit. (It may also be possible to repair the affected connection with conductive glue or similar; I did not try that yet.) Note that, from looking at the touchscreen construction, it seems that the touch buttons are just part of one big touchscreen area and will be interpreted as buttons by firmware, not by the hardware. The touchscreen buttons might be more sensitive to malfunction because of (probably) an added software test on wakeup for iniializing them, but if you have problems with them, it's also probable you have other touchscreen problems as well.
    2. Intermittent touchscreen function. The symptoms are the same as with intermittent touch button function, just that this time, the touchscreen itself will either work or not work at all. It is however most often fixed temporarily by a standby cycle. Diagnosis: Connection issues at the flex cable's glued connection to the touchscreen film. Alternatives may exist. Fix: Replace touchscreen unit.
    3. Top line-shaped area of touchscreen stopped working. Diagnosis: Connection issues (loose contact) at the flex cable's glued connection to the touchscreen film. Or a broken wire connectiob that is responsible for the top part, of the touchscreen's printed circuit. It was not clear in my case. More alternatives may exist. Fix: Replace touchscreen unit.
    4. One point of the touchscreen does not work. This might be as small as one letter of the keyboard, while all other areas of the touchscreen work flawlessly. Diagnosis: Touchscreen broken. No more detailed explanation at the moment. Fix:  Replace touchscreen unit.
    5. Intermittent touch button lighting. They should normally switch on right when you wake up the device from standby. Or maybe not and this is controlled by the ambient light sensor? Because they would sometimes switch on some seconds later, sometimes not at all (tested inside, artificial lighting.) Diagnosis: None yet. But might be a software-caused side effect of a malfunctioning touchscreen, which was present at the same time. Fix: None yet.

(3) Repairing hardware defects

  • Complete screen unit replacement. See How to replace HTC Desire S LCD screen, which is a special disassembly video for this task.
  • Touchscreen replacement. This is quite a difficult operation. My unfinished set of experience values:
    • Wear protective glasses when pulling off the damaged touchscreen. Glas splinters may fly around.
    • Be very careful when pulling out the damaged touchscreen. Be sure to read through TechRadar: How to fix a broken touchscreen, which are the best instructions for the heating part as per my experience. You have to heat the touchscreen edges to ca. 60° C, then pull or push out the touchscreen slowly. The best idea is to start at the lower edge, pushing with a plastic pin through the button backlight holes [video]. I then use a safe open pry tool to go along the edges and slowly pry it open. If you do not heat it before, and pull with too much force so that strong pull or shear forces occur, you will damage the display itself beyond repair by pulling apart its internal makeup from films. This happens because the narrow glue stripes around the touchscreen are attached to plastic film that is glued to the back of the display and then wrapped around its edge, and also glued to its front. If the glue is not melted enough, or esp. if this wrapping film ruptures at the edge but keeps sticked to the screen, pulling out the touchscreen will exert too much force on the display's surface, and pull apart some internals. This results in large blackened screen areas, which shrink temporarilywhen pressing on them (showing that the defect happened by pulling some internal layers apart).
    • It is possible to identify displays which have been damaged in this way when pulling the touchscreen off. Normally the display has a complete uniform color, but the borders of damaged areas will appear in greenish or reddish color when watching the reflection of a light source in the display. This test is only possible when the touchscreen is not mounted, as the color differences are barely noticable. But, when testing the display with a working phone before the touchscreen replacement, and then ensuring that the display has not been damaged by pulling the touchscreen, you prevent the unnecessary work of finishing this "repair".
    • You have to pull off the four little light-guide elements for the touch buttons, and re-glue them to the new touchscreen as this is not part of spare parts. For that, you may need a template built from a broken display unit's frame, or (less optimal) you can place them into the receptives on the display unit with the glue side up. I do glue them all on a common stripe of double-sided adhesive though, not four individual ones as in the original.
    • Remove protection film carefully. When buying a spare touchscreen, there is normally a protective film on top, and sometimes also one at the bottom. These are just sticky, while all other layers are glued. So be very careful to never try removing a bottom protective film when there is none. I damaged two touchscreens of me by lifting the glued flex cable contacts, as there was no protective film to lift resp. it was hard to catch. The best test is to use a small screwdriver and to try scratching very slightly in one corner and comparing with a spare part that has a bottom protective film: the protective film is software and will keep the scratch permanently. The best way to get a protective film off (that does not have a protruding corner to pull) is to add such a corner with a piece of tape. Never use a knife etc. to separate this film at the lower edge where the glued flex cable contacts are: when these get separated by accident, the touchscreen is broken.
    • ​Use narrow stripes of good double-sided adhesive tape (with film) to re-glue. They are offered specifically for phone display repairs, see the tool list at the top; but you can also cut your own of course. Cutting holes in a screen-sized layer of double-sided adhesive is more secure to ward off dust, and was done by HTC originally, but seems very wasteful for a repair. Be careful to leave no gaps between the stripes, and you should be okay.
    • You can glue also at the side edges of the screen, different from how it was done originally. By folding slightly oversized the double-sided adhesive stripes at the left, right and top screen edge by 90° while pushing the screen in. You can cut off the protruding tape afterwards. This will seal the screen more tightly against dust, and should compensate for the use of narrow tape stripes instead of full-sized tape with holes for the actual screen.
    • Be careful to not let dust come between touchscreen and display. However, carefully cleaning both before putting them together, and storing them face-down, is normally sufficient. You don't need a special dust-free cabin.
    • For cleaning touchscreen and display, I wipe them with ethanol (wiping the dirt to one side), and then dry-polish the ethanol's residue with a Q-tip. This worked surprisingly well.

Software

(4) Getting your software tools ready

 

(5) Freeing the phone: rooting and S-OFF

See: Schritt für Schritt von S-ON zur CustomRom (step-by-step instructions, German).

 (6) Installing a Recovery solution

 

(7) Installing a custom ROM

 

(8) Installing great applications

 

(9) Creating backups and a backup solution

 

Knowledge resources

Link Collection

Hardware Q&A

Is it possible to exchange just the display glas while keeping the touchscreen? In theory, yes. In practice, I doubt somebody can get these two full-face glued parts apart without damaging the touchscreen, because it has a film with printed wires on the surface directly below the glas. Also, youd have to remove shattered glas from a full-area glued surface, then remove the glue and re-glue with special glue film like 3M 467 MP. As touchscreens are just 13 EUR incl. glas, this isn't worth the effort. I never tried.

How is the touchscreen built up? From the top, it consists of: glas; flex cable with contacts on the bottom side, glued to the following two layers (enabled by gaps in the following one); one layer with a circuit printed on top for the bottom edge of the touchscreen (and one wire going full round); one very thin layer with another circuit printed on top for the left and right edge of the touchscreen; one bottom layer with seemingly just the function of mechanical protection. With this buildup, the touchscreen seems to use the mutual capacitance capacitive touchscreen technology.

This is just an idea I explored today – I have not done this.

The idea is to attach a pico projector to the side of your head, and hack its optics to provide a small heads-up display for you.

Available commercial models for the pico projector:

For hacking the optics, I would look into something from old VHS cameras. Or from normal digital cameras.

The trick is that these pico projectors have HDMI input, and many Android smartphones have MHL output [list], which can be converted to HDMI with an adapter. Some have even HDMI output directly.

For example, this is possible with the HTC Sensation and HTC Sensation XE, even with custom ROMs [instructions].

However when thinking a bit more about this all, it appears to me that hacking a HUD device for a smartphone is not really a good idea:

The biggest need they would solve is having a bigger screen on the smartphone. However, while the display will appear larger, it will have a lower resolution (640 x 480 px with the Aiptek A50P). Other problems are the added need for power, plus that you need a different input device instead of "touch". The resolution problem can be ignored, or you can go for the Zeiss Cinemizer video goggles, providing 870 x 500 px but costing however 700 USD. But you will not wear such video goggles in public or all day while working, and taking them on and off will also be a nuisance. Likewise, a HUD will be a strange sight and you will not want to wear it in many situations.

So what we want is just: a bigger screen and faster access to the phone. This would give it the main functions of a HUD / wearable computing. And for that, I propose to use loupe goggles (tip: ESCHENBACH Maxdetail) and mounting your phone to your left wrist (if you are right-handed). The ESCHENBACH Maxdetail glasses will give a 2.0x magnification, with sharp sight at 40-60 cm distance, and a viewing field of 15×15 cm at 40 cm distance. That's just decent for example for a 4.3" smartphone, which will appear visually the same size as a 12" notebook display then.

For HUD / augmented reality, I really can wait until Google Glass is selling and I can get one for cheap enough …

The following PHP-based frontends for git were found from looking at the "official" list of git web interfaces. Evaluations were superficial and subjective, by looking at specs, demos (where available), project history. GitList and Indefero have been installed and tested as well.

Requirements were:

  • Written in PHP.
  • Features for viewing git repos on the web and downloading files and zipballs / tarballs.
  • Features for repository-based access control, both for accessing the web interface of that repository and the git repository itself (via git:// or http:// protocol).
  • Free & open source software.
  • In active development (non-maintained projects are a potential security risk).
  • Nice to have: Debian / Ubuntu packages. Good for comfortable updating, and in some sense, this is also security relevant … we're all a bit lazy and might postpone updates that take more time than running apt-get upgrade.

Results by adequacy, best first: (all projects listed here are free software)

  1. Indefero. Very nice tool, and at least somewhat in active development. Selected here because it is the only PHP based, lightweight solution that allows to have per-repository access rights on the web interface out of the box. Also managing these access rights is sufficiently comfortable (without double effort for git itself and the web interface), as both can be done through the web interface [source]. Might be too heavyweight for those who look for just a small repository viewer, as this has also issue tracking, SVN / Mercurial / hg / monoton support and more.
  2. GitList. In active development as of 2013-01. Clean looking code structure. Clean interface (using Twitter Bootstrap). This is however just a sweet repository viewer at the moment, without a way to restrict or manage access rights view the web interface. You can add that with .htaccess Basic HTTP authentication or other mechanisms (see this starting point). But it seems this will always need a double effort: managing access rights for the git client on the command line, and additionally for GitList. The only exception would be Basic HTTP authentication for both, but getting that to work for git when you also want to use it for push operations is difficult, and it also required a .netrc configuration file for all clients [instructions]. See also the installation instructions by Kulbir Saini.
  3. GitPHP. In active development. Simple interface that aligned to the original Perl based Gitweb tool included with git. Demo site available.
  4. pgkiss. A very simple, small minimalist PHP web interface for git. In active development. When needing access control, you have to use HTTP Basic authentication in Apache, or similar measures.
  5. git-php. Seems to be no longer in active development.
  6. ViewGit. The web interface looks similar to that of GitPHP (and a bit nicer, for my taste). However, this tool seems to be no longer in active development. Demo site available.

Note that, from an end user's perspective, GitLab plus gitolite would be the nicest way to go: it looks nice and has very powerful features. But the combo is a mix of Ruby (for GitLab) and Perl (for gitolite), and quite difficult to configure.

Now for one more interesting git web application, which is not a repo browser a class of its own:

git-webcommit. A web-based interface to make git commits. It is not specilalized for viewing and downloading repositories (though it also allows to display files and diffs of changed files). But its main task is on the other end: you get a web interface to stage files and commit these changes (compare the screenshot). git-webcommit will internally call the commandline git tools (which means easy installation and guaranteed compatibility for the user), but it provides a form-based web interface rather than a command-based one. Finally, it's written in PHP. I've not yet tried the tool for myself, but if I ever need a self-hosted alternative to GitHub Gist, I will consider it.

The symptom is that KMail won't fetch mails for one of your IMAP accounts anymore, and if you open Akonadi Console (akonadiconsole), it shows there "Connection established" for the resources in question, rather than "Ready" as it should say.

To fix this (until it recurrs), open the Akonadi Console (akonadiconsole) and restart the akonadi server via "Server -> Restart Server" in the menu. It's also possible to restart the akonadi server from the command line.

This issue is related to KDE bug 257969, and as explained there in comment #8, it's a common symptom of several other issue reports. See there for more information if restarting the akonadi server did not help you.

There is no such thing as perfect security. And in practice, the time resourced needed for hardening a server are an additional limitation for the security level you can reach. That's why I searched for adequate security principles to guide us when securing a web server. Here's my proposal, feel free to discuss.

To develop a meaningful set of principles, we have to start with a risk assessment. My set of principles is for what I consider a "typical webserver" (presenting publicly accessible information, enabling private messaging, maybe containing secret sourcecode of SaaS applications, secret but not sensitive custoemr data connected to these SaaS apps, and maybe paywall-protected downloads.)

So we develop the security principles for the this worst-case damage: "Combined financial and worktime loss equivalent to a one-month." This also includes financial losses by fines and charges resulting from leaked data. The leaking of paywall-protected downloads, with or without an integrated licencing mechanism, is not considered a financial loss here because they're "leaked" to a paying customer anyway.

My current proposal for security principles is this – feel free to discuss:

  1. Limit damage by proper access rights when non-root access is compromised.
  2. Do not even try to limit damage for a case of compromised root access. It would only complicate day-to-day work, and all user data is compromised anyway. So if other passwords are also compromised or not is not of much additional importance, so we won't care about key-stretching, salting etc. in that context. Only to detect root logins.
  3. Care to detect root access immediately.
  4. Assume that the server, before starting the hardening, is an uncompromised setup. Everything else would mean to completely re-setup the server, to get rid of root kits etc..
  5. Harden against everything but high-profile hackers. The server is to be hardened against automatic attacks of botnet operators, against (D)DoS attacks, and against targeted attacks of moderately sophisticated hackers (who use known tools and techniques remotely and at most 10 days of work). Do not try to secure against high-profile hackers who might use new ingenious combinations of tools and techniques, zero-day exploits, and a lot of time and energy. This also means, do not try to secure against attack types that require physical proximity or physical access to either the server or a server user's location – these are highly unlikely to happen for servers that contain only moderately valuable information.
    This protects against the ubiquitous dangers of the web, and against low-profile targeted hacking attempts against sites hosted on the server (as they could be executed by personal enemies or competitors of customers hosting their site there). But this also means, it could be broken by high-profile hackers (which will only happen if the server contains valuable data of course).
  6. Do not store high-value data on the server. The server should withstand 10 person days worth of high-profile hacker attacks, but might break with some bad luck at an undetermined point afterwards. Everybody using the server (including customers, if it's a commercial webhost) should know about that security level, and based on that they should decide what kind of data to entrust the server with. Some simple rules for that:
  • Don't store something that could cause bigger damage than shown in the risk profile above. For example, do not store Bitcoins worth more than a few thousand USD.
  • If you have to store high-value data, decrease its value by the mode of storing it, if possible. For example, store your company's SaaS application not as plaintext source, but obfuscated.
  • Do not store information on these servers that might lead to a criminal conviction. This esp. refers to sensitive e-mails, which should not be stored permanently in IMAP except in encrypted form. Not storing such information on a server in unencrypted form is advisable anyway, as the biggest danger to such information is not hackers but law enforcement agents.