Harald Welte's blog
   

RSS

Categories

Archives

Harald's Web
gnumonks.org
hmw-consulting.com
dunkelromantik.org

Projects
netfilter/iptables
ulogd
asis
gspc
opentom.org
librfid
openmrtd
gpl-devices.org
gpl-violations.org
OpenPCD
OpenBeacon
OpenMoKo

Other Bloggers
Rusty Russell
David Miller
Martin Pool
Lawrence Lessig
Sirtaj Singh Kang
Jeremy Kerr
Atul Chitnis
Frank Rosengart (German)
Tim Pritlove
fukami
Michael Lauer
Stefan Schmidt
Kalyan Varma

Aggregators
kernelplanet.org
planet.netfilter.org
planet.openezx.org
planet.openmoko.org
planet.foss.in

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.


blosxom

       
Wed, 24 Sep 2008
Things I learned about GSM, STK revisited.

During the least couple of days I've had some pretty intense conversations with a number of people on various aspects of GSM, leading me to [re]reading some of the interesting bits of its specification.

There are a number of observations that I don't want to talk about right now, and which will likely be part of my work during the next couple of months.

One thing that ever so often gives me the creeps is STK (Sim Toolkit). To those people involved with GSM, it is no news that with STK an operator can basically remote-control your phone. He can, among other things

  • make your phone send SMS
  • initiate outgoing calls without your interaction
  • initiate outgoing calls and terminate any existing call
  • open data connections (GPRS/EDGE)
  • launch a browser to any URL
  • play tones on your speaker
  • access and modify any information (contact, SMS, dial history, even IMSI) stored on the SIM

And the worst thing of it all: You don't even know which of those features your phone implements (most likely all of them). I'm happy to still use a SIM that predates the GSM11.14 (STK) specification.

Now in the advent of projects like OpenBTS, where we can emulate a GSM network side, and in combination with either supplying your own SIM card (or emulating it using a PC), we will finally see a faint possibility of actually testing (and demoing) the never-ending security nightmares caused by this evil monstrosity.

[ /electronics/gsm | permanent link ]

Sat, 30 Aug 2008
Photographs of disassembly and PCB of a e-ten glofiish X800

Heh. You could say I'm now among other things a professional hardware reverse engineer. This mostly started as a kid, where I always had to take everything apart. In more recent years, I've mostly been doing hardware reverse engineering as part of the gpl-violations.org effort, or projects like openezx.org.

Now, I've actually been asked by a company to buy a device on their expense to disassemble and photograph it, to find out about the components it uses, etc. And no, before you start to wonder, I don't work for Openmoko anymore. So they are not that company ;)

The device in question is the E-TEN glofiish X800, a full-vga 3.5G Windows Mobile PDA-Phone with AGPS, Wifi and bluetooth. You can find the pictures of the disassembly process and PCB photographs here.

As you can see, the device employs the following major components / chipsets:

  • Samsung S3C2442B SoC with integrated SDRAM and NAND (same like Openmoko GTA02)
  • CSR4 based Bluetooth (same like Openmoko and many other devices)
  • microSD slot, must be connected to S3C2442 SD/MMC controller
  • WiFi Module using a Marvell 8686 chipset (you actually can't see that, I had to peel open the shielding of the module and the angle didn't allow any good photographs)
  • TD028TTEC1 LCD module, exactly the same as the OpenMoko GTA01/GTA02
  • AKM 4641 audio codec, reportedly used in HP iPAQ and HTC Universal
  • Two cameras of unknown type, must be using the S3C2442 camera interface
  • Ericsson based quad-band GSM and tri-band 3.5G chipset centered around the DB3150, which is used in many Sony-Ericcson 3G/3.5G phones. Sony-Ericsson has excellent public documentation on their AT-commandset for their phones. Since they are likely to use the same firmware base, the AT commandset should thus be known.
  • A Xilinx CPLD

So now what does all this mean? Setting aside the CPLD and the unknown camera modules, this device (and its keyboard-enabled brother the M800) should be a very attractive target for porting Linux to it. Known SoC, wifi with driver already in mainline, GSM/3.5G modem with documented AT commands, etc.

Big question is the power management. It looks like they're using a lot of discrete regulators rather than an integrated PMU. Also, the CPLD is likely to cause a lot of trouble since neither the external connection nor the internal logic is known...

[ /electronics | permanent link ]

Thu, 27 Mar 2008
Schiphol airport uses active millimeter wave screening

I was quite surprised that Amsterdam airport is beginning to introduce active millimeter wave screening instead of the good old metal detectors. The specific device seen in operation at one of the queues between the international and the Schengen area of the airport was L3 Communications ProVision(TM).

While doing some research about this subject on the net, I discovered cargo X-ray solutions such as those described in this article. You can mount a mobile unit onto a track and then go as deep as 200mm of steel to x-ray through the metal plating of a cargo container. This is really scary stuff...

[ /electronics | permanent link ]

Thu, 03 Jan 2008
Repairing VIA EPIA-ME6000 busted capacitors

Just before Christmas, my vdr powered diskless Linux-based digital video recorder went bust. A bit of testing revealed that the VIA EPIA-ME6000 main board itself must be dead.

I immediately ordered a replacement mini-ITX board without further investigating the broken one, expecting that the replacement might actually arrive before the Christmas holidays. Unfortunately this didn't happen. While replacing the board, I discovered that six of the 1000uF electrolytic capacitors went bust.

So today I finally found a bit of time (it's great to be able to find time to do things again) to try and replace the broken capacitors. Despite the new ones being slightly larger, the board now works again like a charm. And that at a total cost of 1.62 EUR.

So now I have two working mini-ITX boards. Guess I have to either find some use for it, or sell the new one again...

[ /electronics | permanent link ]

Mon, 04 Dec 2006
Petition against obnoxious WEEE implementation in Germany

There is now an official Petition to re-work the obnoxious WEEE implementation in Germany (see my detailed posting earlier in this blog. This is good, and definitely a step forward in getting regulations in place which are supportive of small and medium-sized companies, rather them getting them out of business. I've spoken to lawyers about the current regulations, and they e.g. have severe doubt that they are even constitutional.

If you are German, and/or operate a business in Germany, please consider signing the above-mentioned petition!

btw: I'm planning to start a petition against hosting petitions of the German Bundestag at a University in the UK, anybody interested in joining it?

[ /electronics | permanent link ]

Mon, 02 Oct 2006
Obnoxious RoHS/WEEE rules and their German implementation

You might have heard about RoHS (Reduction of Hazardous Substances) before. I always thought it is a well-meant and important contribution of the European Union to reduce the amount of hazardous substances in electronic waste. As a supporter of many environmental groups, and an occasional voter for the Green party, I definitely support such a goal.

If I was to manufacture electronic equipment, then certainly I would consider it as my moral duty to pay for the cost of processing ('recycling', how they call it, if that was ever possible)the resulting waste. No debate on that at all.

Now I actually am involved with producing small quantities of electronic equipment, and suddenly those issues come up again. The product obviously only uses RoHS compliant components, no question on that. We do want to reduce the environmental impact, after all.

Now enter EU and German bureaucracy, combined with lobbying of large industrial electronics manufacturers, and you end up with the German implementation called "ElektroG" (Gesetz ueber das Inverkehrbringen, die Ruecknahme und die umweltfreundliche Entsorgung von Elektro- und Elektronikgeraeten [Law about distribution, withdrawal and eco-friendly disposal of electrical and electronic devices]). That law basically regulates and delegates the administration of the RoHS/WEEE guidelines to an authority called EAR (Stiftung Elektro-Altgeraete Register [Foundation for Registry of Electrical Devices]).

The way how this system works is:

  • All manufacturers and importers have to register themselves with EAR
  • They also have to register the quantity (weight) of produced/imported goods every month
  • They furthermore have to produce proof of having made a deposit on the amount of money required to "recycle" the resulting electronic waste, even in the case of bankruptcy of the producer/importer
This all sounds very reasonable and well-thought. Given the facts stated until here, I would still be an avid supporter of such a system.

Now enter the disaster: The minimum quantity that this system can deal with is the metric ton. This is very suitable for large manufacturers, but what about a small company that produces 100 units of 180grams of weight every year? It will take more than 55 years to fill up that metric ton. Now, if they actually allowed you to pay for one ton every 55 years, then that would be great. Obviously, they don't. Rather they employ an undisclosed lottery algorithm, which elects one registered producer/importer who has to take care of recycling one specific container that was filled last at the electronics waste collection station. Yes, every time one container is filled, they elect another lucky lottery winner. And in order to make sure that every possible "winner" could actually afford the disposal of that container, EAR has the "proof of bankruptcy-safe deposit".

You might think: Well, quite a fancy system, but assuming that algorithm was tuned right, there still is no problem, even for small producers, since the probability of them being chosen by the lottery is very low. And in fact it is. An EAR person has publicly stated in an interview that only producers having produced more than 3.5 metric tons of electronics are eligible to win that lottery. Great, since in our example that would be in 194 years. Son nothing to worry about, right?

Wrong. The administrative fees of EAR.

  • 155 EUR one-time fee for registration is still quite acceptable.
  • 85 EUR per product that is put on the market is fine, too.
  • 100 EUR for each notice of change in production quantity is a bit steep, given the inevitable flux of that figure.
  • 455 EUR for the validation of the proof of having made the deposit
  • 215 EUR annually for the re-validation of the proof of having made the deposit

Now what kind of bull**it is this? This means that during those 55 years we would fill one metric ton, we'd have to pay 12066 EUR only in administrative fees for validation and re-validation of the bankruptcy-save deposit? All that for the disposal of one ton of electronic waste, which costs [now] between 200 and 400EUR ?

I would be very surprised if such fees would not violate anti competition rules of the EU somewhere at some point. This is the creation of a serious market entrance barrier for small manufacturers of electronic equipment and nothing else.

[ /electronics | permanent link ]

Mon, 25 Sep 2006
OpenPCD press release, online shop

Ok, after a painful day full of shippin rates, insurance, taxation issues, etc. Milosch finally worked out how to ship our product to about any country of the wokld. This means that the OpenPCD shop is now online, and we're accepting orders from those people who don't want to fabricate the four-layer PCB themselves ;)

We also sent out the Press Release, in the hope that some press actually might be interested in free hardware project.

On OpenPCD.org we now also published the first binary firmware images (source code has always been in svn), including full USB DFU (device firmware upgrade) support.

If I manage to resolve some of the problems I still have with the SAM7 SSC controller, then the PICC simulator should also get working some time soon.

[ /electronics | permanent link ]

Thu, 06 Jul 2006
Visiting armzone.com in Shanghai

Today I had the pleasure of visiting armzone.com in Shanghai. Now if that was like visiting any other hardware or electronics store, I wouldn't be blogging about it. It might actually be that visiting any shop like this in China is a similar experience. But I'll write it anyway, you don't have to read it.

So we were there to buy some S3C2410 based development boards (full-featured, basically PDA development boards, including 65MB SDRAM, 64MB NAND Flash, Ethernet, USB host and device, a CPLD, IDE, 2xSerial, JTAG, SD-Card, ..). The first thing to notice was the price. Including a touch screen LCD panel they were something like USD 180 each. Actually less than any PDA based on them would cost in the western world. Aren't devel boards usually at least one order of magnitude more expensive than the actual systems you're going to design with them?

Then we were looking for some JTAG adaptor compatible with that devel board. The boards ship with a wiggler, which is supported by OpenOCD and also some s3c2410 version of JFlash, but which is slow as hell. Sort of the least interesting option. They had a number of USB and parallel port models available, some of them clones of well-known modules such as MultiICE, some others being developed by themselves.

The main problem was that they all seem to require some RDI server to run on a windows box. Hey, If I'm doing Linux target development on a Linux host system, they ask me to run a windows box just for that daemon? They must be kidding me. So my Chinese contacts engaged in some almost two hour debate on whether he couldn't release the source code to their own RDI server so I can port/re-implement that code on Linux, and why it might be a benefit to them to get that Linux version back to ship with further products. The debate also seems to have included all kinds of other options. Going as far as to the shop wanting to sell us a Raven compatible device, to which we almost agreed, only to learn that he needs a week to produce some more apart from the engineering sample.

One other thing we'd need for the parallel port versions is a PCMCIA parport card. Yes, such things actually exist, and you can buy them even on some Chinese eBay like site whose name I forgot. Rather than buying that, armzone offered us to wait two weeks, until then they will have built (!) their own parport adaptor for only a part of the price. Yes, they would have gone all the way down to molding a case for the parport connector sticking out of PCMCIA, etc. And that for us buying a max of 5 of those cards. Hey, we're talking about electronics / PCB / case design here, not about whether I want ketchup with my french fries!

This seriously made me wonder whether when you buy a car in China they also ask you if they should be personally just for you build a different car radio from scratch. These guys are crazy...

[ /electronics | permanent link ]

Mon, 26 Jun 2006
Ridiculous fees for USB Vendor ID

Sometimes you happen to find yourself starting a DIY electronics project, much like a Free Software project. And if that hardware is actually to be plugged into one of the standard interfaces such as the various PCI variants, or USB, then you'll need to give it a USB Vendor and Device ID. Vendor ID's are 16bit, and allocated by the USB Implementers Forum (IF).

Unfortunately, applying for a Vendor ID costs you USD 2,000. Yes, two-thousand bucks US for creating an entry in a table. This might be peanuts for large hardware companies, but it's an awfully large amount of money for any of the many USB hardware projects that people tend to experiment with. Especially since micro-controllers with embedded USB device controller are quite commonplace these days.

In the software / Internet world, there also are unique ID's that need to be applied for. I'm talking about protocol numbers, port numbers and the like. I've already applied for a number of them at bodies such as IANA. Obviously they are for free. This way you can ensure not to use values that get later assigned to other organizations/projects, and everything is clean.

Ridiculous fees such as the USB IF fee for a Vendor ID are just leading to the situation when independent developers will chose random ID's, which will sooner or later clash with other vendors and his devices.

If the USB IF was really interested in stability and unique assignments, they would

  • reserve a couple of vendor ID's for experimental/ organization internal use
  • create a hand full of vendor ID's which are not assigned to any vendor, but where hobbyists and Free Hardware developers can have individual device ID's assigned to themselves, e.g. like the IANA protocol/port number process works

[ /electronics | permanent link ]

Wed, 10 May 2006
Developing a 2.4GHz active RFID system

Together with Milosch from bitmanufaktur.de, I've spent a couple of days and nights working on building our own 2.4GHz active RFID system. The parameters are: Battery powered, small transponders based on the Nordic Semiconductor nRF24L01 and a ultra-low-power PIC micro-controller. Base-stations have the same nRF chip, plus an Ethernet-enabled micro-controller. Operational range is ~10 meters, we even made it through two walls in our preliminary tests.

So what's the point of all this? The goal is to have that system in operation at the HOPE Nr.6, and to give a practical demonstration on how feasible it is to track people, make protocols on who has spent how much time in which lecture hall, etc.

I'm not involved with HOPE at all, but was only involved in writing firmware and higher-level code for the two embedded systems involved, as well as some testing.

I'm looking forward to learn how the system will perform with several hundreds/thousands of transponders at its first real-world test at HOPE. With some luck, we can have the same system at 23C3 in December this year in Berlin.

Until then I'm certainly going to try to implement my idea for peer-to-peer time slot synchronization of the transponders. I had that idea as a solution to avoid collisions between transponders while working on the project. Unfortunately, the current transponder hardware doesn't have a low-power timing source that is precise enough for such a protocol. Adding a 32.768kHz low-power quartz should do the trick - but will inevitably also make the transponder more costly.

Kudos to bitmanufaktur. I wouldn't even dare to try to design a PCB for 2.4GHz RF...

[ /electronics | permanent link ]