# Converting a USB BUB II to use a 3.3V regulator

Anyone who works with Arduino for any length of time will become familiar with the FTDI USB to Serial bridges. These convert the USB interface found on all modern computers into a simple serial interface, required by many Arduino boards for their bootloader.

There are many FTDI cables and boards available. A lot of Arduino boards have a built-in FTDI chip (the older ones with a USB port). Many vendors sell FTDI cables which have USB on one end and a pin header on the other (the chip is embedded in the USB connector). There are also a lot of breakout boards available.

There are two important voltage specifications on each cable:

• Signalling voltage – they are generally available in 5V or 3.3V signalling. It is possible to damage some 3.3V boards using 5V signalling. With the ATmega microcontrollers, you should never exceed 3.8V on any pin with Vcc at 3.3V, but it doesn’t seem to cause damage. Conversely, a ATmega running with Vcc at 5V will pick up 3.3V as logic high with no issues. If in doubt, go with the 3.3V cable.
• Power supply voltage (Vcc) – the normal FTDI pin out provides a power supply on one of the pins. Generally you get either 5V or 3.3V. The 5V versions often supply VUSB direct – so you can draw 500mA. Most of the 3.3V ones however use the pin 3V3OUT on the FTDI chip, which cannot supply more than 50mA (and the FTDI chip gets very hot when doing so!). This often isn’t enough to power a project. Again, a lot of boards don’t really care, but some ancillaries like radio chips will die if given 5V instead of 3.3V. The ATmega is a very forgiving chip.

There’s one big thing to catch you out here. A lot of the 3.3V cables still provide 5V on the Vcc pin. I didn’t realise this until I frazzled a CC1110 board with 5V.

So there are a lot of combinations of voltages available. Rather than have a four or more FTDI cables handy, I’ve found one particular board is versatile enough to use in all situations, with a bit of modification.

The USB BUB II is available from Jeelabs and Modern Device. It’s a small board, and by default it has 3.3V signalling with a 5V power supply. With a few small changes, it can be a lot more versatile.

It has a some good points that many other solutions don’t have. A small polyfuse protects your computer from over-current (although most machines seem fairly tolerant of this nowadays). It also has RX/TX lights, which are absent on many DIY and smaller boards.

Onto the modifications.

1. There are two pairs of small solder bridges on the front of the board, one labelled VOUT and the other LGLV. Use solder braid to remove solder from whichever combination is currently soldered.

2. Solder a pair of 3-pin headers into the space next to VOUT and LGLV. This allows you to chose between 5V from USB or 3.3V from 3v3OUT using jumpers.

3. Turn the board over and cut the 3v3_OUT trace using a scalpel. Bridge the VR_OUT pads using solder.

4. Finally, solder on a 3.3V regulator on the back of the board. Modern Devices suggest a MCP1703 which can provide 250mA. I used a MCP1825 which can provide 500mA as it was what I had lying around.

Now you have a FTDI board which will work for all of your 5V and 3.3V boards, as well as being able to provide power for most small projects.

# Publishing 1-Wire temperature sensors to Emoncms via a Raspberry Pi part 3

Last time, we installed OWFS to read the DS18B20 sensors connected to the 1-Wire bus and represent the temperatures as a file system. We now need to be able to publish them to the Emoncms to log and display the data.

Publishing to Emoncms is very easy - it has been designed to work with lightweight embedded devices with limited memory. A simple Python, Perl or C program could form a JSON request and post the data periodically. However, my Raspberry Pi is already using an RFM12Pi to receive data from my network of sensors. This uses a demon-ised Python script called oem_gateway to listen to the RFM12Pi and send the data to Emoncms.

You can install oem_gateway by following the instructions supplied on the github page.

I decided to modify oem_gateway instead of rolling my own script. The changes can be seen here, in my github repo.

A new OemGatewayListener called OemGatewayOWFSListener was created. This requires a number of settings in oemgateway.conf:

These are relatively self-explanatory, probably with the exception of “Dummy” sensors. oem_gateway sends all sensor values using numerical indices i.e. {1:18.7,2:18.6,3:19.2} by iterating through a list of values. There are no names or explicit indices, so if one of the data values isn’t present, the indices change, and Emoncms has issues. Rather than change all listeners to have named sensor values, I decided to allow “Dummy” sensors to be placed in the list of DS18B20 IDs.

This means that we can unplug a sensor without impacting the indices, so that Emoncms shifting all the values incorrectly.

This has been publishing temperatures to Emoncms for a number of weeks with no issue now.

Whilst this is neat, I would much prefer to use an Arduino to poll the DS2482 and send the data wirelessly to this node – for next time!

# Publishing 1-Wire temperature sensors to Emoncms via a Raspberry Pi part 2

Last time, we setup the Raspberry Pi so it could read the values from some DS18B20 sensors using the command line tool owfs. We’re a still few steps away from publishing these temperatures to Emoncms at the moment – namely getting owfs to start automatically, reading the values in Python, and then publishing them.

## Running owfs automatically

When building owfs from source, you don’t get automatic startup as an option. It is quite easy to setup though.

First, let’s build a config file to store settings:

And copy and paste this in:

It is important to note that this setup means that only owfs can access the 1-Wire bus. The default configuration is to run owserver and then have all other ow* processes connect to owserrver – i.e. it distributes the data. I want to keep my setup as simple as possible, so owfs connects directly to the bus.

Let’s test this config out:

Now we need to create an init script:

And then copy and paste this into the file:

This is totally barebones, but I always use this form of init script and it works well.

Now make it executable:

Then use the very convenient tool, update-rc.d to add links so that this script runs at the appropriate times and runlevels:

Then restart your Pi:

Once restarted, check everything is running and you can still see the devices:

# Publishing 1-Wire temperature sensors to Emoncms via a Raspberry Pi part 1

There are a number of sensors that can be used to monitor temperature using a microcontroller. RTDs, thermistors, LM35s, thermocouples and so on. These are all analog output sensors, and this introduces a few problems:

• You need to use a single analog input (ADC) for each temperature sensor, and this might also include additional buffer/amplifier circuitry, Wheatstone bridges or horrible stuff like cold junction compensation on thermocouples. ADCs also tend to be power hungry and slow in small microcontrollers.
• Each sensor needs it’s own cable running back to the microcontroller.
• As cable runs increase in length, you end up with all sorts of nasty analog issues like voltage drop, noise, etc.

There is a way to avoid these issues – using digital temperature sensors like the Dallas DS18B20. These solve the above problems.

• You only need to use a small number of digital IOs to interface to the sensors (either directly, or via a bridge chip). This can be as little as a single pin.
• Tens or hundreds of sensors can be on the same bus, massively reducing the number of inputs used, and simplifying cabling especially when you are reading more than a few sensors.
• Driving a bus digitally is much easier than reading analog values. Many of the bridge chips have quite advanced features to deal with the analog gubbins (slew rate control, power active pull-ups etc.)

It’s for these reasons that I much prefer using DS18B20 sensors when I can. They do have some disadvantages though:

• They are slow to respond and slow to read. With 9-bit precision, a reading takes at least 100ms. At 12-bit this increases to 750ms. You can sleep your microcontroller during this period, so this is more a latency than a power issue.
• They have a narrow temperature range compared to a lot of sensors – only -55degC to 125degC. But this is more than enough for domestic heating flow/return and ambient air temperatures.
• They are costly – about £4 a go through big suppliers (though closer to £1 if you buy 10 on eBay), possibly offset by other advantages like less circuitry and cabling.
• They are only readily available in the bare TO-92 package. There are waterproof versions, there are stainless steel pocketed versions, but they are much harder to find than PT100 waterproof sensors.

In balance though, I feel they are ideal for this project.

Previously I have driven the DS18B20 sensors directly off a pin on the Arduino, bit-banging the 1-Wire protocol using the excellent 1-Wire and DallasTemperature libraries. This works – mostly. However, as soon as cable runs get longer or network topologies get non-ideal, you start getting errors – the dreaded 85degC readings.

The Raspberry Pi has far weaker IO drive than the Arduino (16mA per pin vs 40mA on an ATmega328), and is far less resilient to ESD and mishandling. I was really concerned that directly using an IO pin in a real world application would cause problems, so started looking for a add-on driver board. I quickly found the Sheepwalk Electronics RPI2 I2c to 1-Wire bridge. This is a small plug-on board, with a DS2482-100 1-Wire master, PCA9306 I2C voltage level converter, and a DS9503 1-Wire ESD protection IC. This takes the hard work out of doing 1-Wire, and is supported by lots of software. I also ordered a passive hub and a number of RJ45 connected DS18B20 sensors.

The I2C->1-Wire bridge

So, how do we get these working with a Raspberry Pi?

## Make sure you can communicate with the I2C device

The I2C module is blacklisted by default on Raspbian. You need to edit a file to stop this happening by removing it from the mod probe blacklist file:

and comment out the line with a hash.

You also need to make sure the i2c-dev module is loaded. This isn’t dev=development but dev=/dev i.e. access the i2c device via /dev. To do this, edit modules.conf:

And add the line

right at the end.

You can now either restart, or issue the following commands to make sure the modules are loaded:

And you can confirm they have loaded using:

We’re good to start communicating with the DS2482-100 bridge chip now, and to do so, we are going to use i2cdetect, which is part of the i2ctools package. Issue the following command to install this

Now run i2cdetect:

This shows the device at i2c address 18 – you can alter this to another value using some jumpers on the RPI2 board. You can see my i2c bus isn’t exactly jam packed, so we will stick with 18.

## Communicate with the 1-Wire bridge

Now we need to communicate with the 1-Wire bridge. There are a number of pieces of software that can do this, but for simple temperature monitoring, OWFS (1-Wire file system) seems popular.

The standard package available from normal repos is 2.8p15, and the latest code is 2.9p1. There are enough changes that I wanted to build from scratch.

There are a few bits and pieces that need installing for this to work on the default Raspbian install.

This won’t build PHP etc. libraries for OWFS but I am not very likely to be using PHP.

Next we need to get the source and unpack it.

Then we need to configure:

You need to make sure this confirms that it will build with the options you need.

You need i2c and owfs support in there for what we are doing.

Now you need to build and install, expect this to take a long time on the Pi (30-60m):

owfs allows us to access the i2c devices using the file system. To set this up, first create a directory for the devices to show up in:

owfs uses something called fuse to allow it to create the filesystem representing the 1-Wire bus and devices. I don’t fully understand what it does, but you need to change one of the options by editing fuse.conf:

and then uncomment this line by removing the #:

And last, at least for this part, we are going to start owfs manually and check that everything is working:

This starts owfs, looking at all available i2c bus masters, and mounts the result in /mnt/1wire. So we take a look in /mnt/1wire

The directories starting 28. are the temperature sensors. Four connected to the hub and one on the hub itself. The other directories and files control settings and provide information about the bus and communication.

Now we can read the ttemperature off all of the sensors:

Yes, our front room is that cold. I broke the heating last night.

The passive hub with additional DS18B20 sensor

In the next part I am going to get owfs starting automatically with the Pi and then read the sensors in a simple Python program.

# Investigating a tricky network problem with Python, Scapy and other network tools

We’ve had a fairly long-term issue at work with connectivity to one of our application servers. Every now and then you can’t login or connect and it has seemed fairly random. This finally annoyed myself and a customer enough that I had to look into it.

The connection is made to the server on port 1494 – Citrix ICA. Initially we suspected that the .ica file downloaded and opened by the Citrix Receiver software was incorrect or corrupt, but inspection and testing of this showed that it was OK. It really did look like the connection was just being randomly rejected.

It seemed that myself and a single customer were having far more frequent issues that other users. Of course it could just be my tolerance for whinging is lower than my colleagues.

Note that nearly all of the below was done on OS X – syntax of some of these commands differs under Linux and Windows. I have changed the host IP for security reasons.

## telnet

Most applications that listen on a TCP port will respond to telnet, even if they don’t send anything back. Telnet is almost raw TCP – it has some control and escape sequences layered on top, but it is very simple at a protocol level.

ICA responds when connecting by sending back “ICA” every 5s:

But every now and then I was getting nothing back:

Oddly, whenever the Citrix Receiver failed to launch, I wasn’t always having problems with telnet, and vice versa. This is good – we’ve replicated the issue with a very simple utility using raw TCP rather than having to look into the intricate details of Citrix and whatever protocol it uses.

## tcpdump

So let’s fire up tcpdump to see what happens when the connection is working. tcpdump is a command line packet analyser. It’s not as versatile or as easy to use as Wireshark, but it is quick and easy. You can use tcpdump to generate a .pcap file which can then be opened in Wireshark at a later date – this is good for when you are working on systems with no UI.

I filtered the tcpdump output to only show traffic where one of the two IPs was the server.

This all looks fairly normal – my laptop is sending a SYN to the server, which responds with SYN-ACK, and then I respond with an ACK. You can see this in the “Flags” part of the capture. S, S., . (. means ACK in tcpdump). Everything then progresses normally until I close the connection.

However, when the connection fails:

I get nothing back at all – it’s just telnet trying the connection again and again by sending SYNs. I was expecting part of the connection to succeed, but this looked like the host just wasn’t responding at all. This might indicate a firewall or network issue rather than a problem with Citrix.

I used Wireshark on the server side to confirm that no traffic was getting through. I could see the successful connections progressing fine, but I could see nothing of the failing connections. I wanted to check both sides because there were a number of potential scenarios where a client could send a SYN and not get a SYN-ACK back:

1. Client sends SYN, server never sees SYN.
2. Client sends SYN, server sees SYN, server sends SYN-ACK back which is lost.
3. Client send SYN, server sees SYN, choses not to respond.

It seemed that 1 was happening here.

So what was causing this? Sometimes it worked, sometimes it didn’t. Did it depend on what time I did it? Was there another variable involved?

## mtr

Let’s check for outright packet loss. ping and traceroute are useful for diagnosing packet loss on a link, but it can be hard work working out which step is causing problems. Step in mtr, or my trace route. This provides a tabular, updating output which combines ping and traceroute with a lot of useful information.

I let this run for a while and observed virtually no packet loss. It’s important to note that it is using ICMP pings – not TCP as Citrix uses. ICMP messages can be dealt with differently to TCP. mtr does support TCP pings but I can’t get it to work under OS X.

## Python and telnetlib

So wrote a small Python program using the telnetlib module to periodically connect to the port using telnet and indicate when there were problems. The output was simple graphical representation so that I could spot any timing patterns.

So this prints a . for a successful connection and * for unsuccessful. After every 16 packets, the number of failures/total is printed.

What can we note?

• There is some vague pattern there, often repeating every 8 packets.
• The rate of failed to successful connections is nearly always 25%.
• Varying the WAITTIME (the time between connections) had some interesting effects. With short times, the patterns were regular. With longer times they seemed less regular.
• Using the laptop for other things would disrupt the pattern but packet loss stayed at 25%. Even with very little other traffic the loss was 25%.

What varies over time, following a pattern, but would show behaviour like this?

The source port.

Every TCP connection not only has a destination port, but a source port – typically in the range of 1025 to 65535. The source port is incremented for each connection made. So the first time I telnet it would be 43523, the next time 45324, then 45325 and so on. Other applications share the same series of source ports and increment it as they make connections.

When I run the test program with a short wait time, there is very little chance for other applications to increment the source port. When I run it with a longer wait time (30s or so), many other applications will increment the source port, causing the pattern to be inconsistent.

It really looked like certain source ports were failing to get through to the server.

## netcat

I had to test this theory. You can’t control the source port with telnet, but you can with the excellent netcat (or nc, as the command is named). “-p” controls the source port:

As you can see – connections from 1025 and 1027 always succeed and 1026 always fail. I tested many other ports as well. We have our culprit!

## Python and Scapy

Now, can we spot a pastern with the ports that are failing and those that are succeeding? Maybe. I needed something to craft some TCP/IP packets to test this out. I could use netcat and a bash script, but I’ve recently learnt about Scapy, a packet manipulation module for Python. It’s incredibly flexible but also very quick and easy. I learnt about it after reading the book Violent Python, which I would recommend if you want to quickly get using Python for some real world security testing.

The script needs to connect to the same destination port from a range of source ports and record the results. With Scapy, half an hour later, I have this (note, I did have some issues with Scapy and OS X that I will need to go over in another post):

This produced really helpful output. The failed packets are highlighted in the excerpt below:

At this point in the port range it appears that packets ending in 001 or 110 are failing.

Move further down the port range and packets ending 000 and 111 are failing.

In fact, at any given point it seems that the packets failing are either 000/111, 001/110, 010/101, 011/100 – complements of one another. Higher order bits seem to determine which pair is going to fail.

Curious!

What makes this even stranger is that changing the destination port (say, from 1494 to 80) gives you a different series of working/non-working source ports. 1025 works for 1494, but not 80. 1026 works for both. 1027 works only for 80.

All of my tests above have been done on my laptop over an internet connection. I wanted to test a local machine as well to narrow down the area the problem could be in – is it the perimeter firewall or the switch the server is connected to?

## hping3

The local test machine is a Linux box which is missing Python but has hping3 on it. This is another useful tool that allows packets to be created with a great degree of flexibility. In many respects it feels like a combination of netcat and ping.

What does all this mean?

• First parameter is the IP to connect to.
• -s is the start of the source port range – hping3 will increment this by 1 each time unless -k is passed
• -S means set the SYN flag (similar to the Scapy test above)
• -i u100000 means wait 100000us between each ping
• -c 20 means send 20 pings
• -p 1494 is the offending port to connect to

And what do we get back?

The same sort of packet loss we were seeing before. Oddly, the source ports that work differ from this Linux box to my laptop.

Here’s where it gets even stranger. I then decided to try padding the SYN out with some data (which I think is valid for TCP, though I’ve never seen a real app do it and mtr’s man page says it isn’t). You use -d 1024 to append 1024 bytes of data. I first tried 1024 bytes and had 20% packet loss as before. They I tried 2048 bytes:

Wait? All the packets are now getting through?

Through a process of trial and error I found that anything with more than 1460 bytes of data was getting through fine. 1460 bytes of data + 20 bytes TCP header + 20 bytes IP header = 1500 bytes – this is the Ethernet MTU (Maximum Transmit Unit). Anything smaller than this can be sent in a single Ethernet frame, anthing bigger needs to be chopped up into multiple frames (although some Ethernet networks allow jumbo frames which are much bigger – this one doesn’t).

I then ran the hping3 test from my laptop and found that altering the data size had no impact on packet loss. I strongly suspect that this is because a router or firewall along the way is somehow modifying or reassembling the fragmented frames to inspect them, and then reassembling them in a different way.

At this point I installed the Broadcom Advanced Control Suite (BACS) on the server to see if I could see any further diagnostics or statistics to help. One thing quickly stood out – a counter labelled “Out of recv. buffer” was counting up almost in proportion to the number of SYN packets getting lost:

This doesn’t sound like a desirable thing. It turns out the driver is quite out of date – maybe I should have started here!

## Conclusion

I’m still not sure what is going on here. The packets being rejected do seem to follow some kind of pattern, but it’s certainly not regular enough to blame it on the intentional behaviour of a firewall.

At this point we are going to try upgrading the drivers for the network card on the sever and see if this fixes the issue.

The point of all of the above is to show how quick and easy it can be to use easily available tools to investigate network issues.

# Programming a Texecom Premier Elite 12-W using a FTDI cable

The Texecom Premier Elite series of alarms can be programmed using Windows software called Wintex. This makes setting up these alarms far easier than using the keypad menus – they have hundreds of options and settings.

Texecom sell two products to connect to these alarms using Wintex – PC-COM (a serial port adapter ~£20) and USB-COM (a USB to serial adapter ~£35) . I strongly suspected these were just serial TTL converters, but I was concerned that there might be some jiggery pokery stopping this from working. Some software requires very specific VID (vendor ID) and PID (product IDs) on the USB device. Some software uses custom drivers. Others use microcontrollers and obfuscation to make sure you buy the genuine product.

As an avid hardware hacker, I have a lot of USB to TTL serial converters. The most useful (and reliable, in terms of drivers) are FTDI cables based on the FT232R chips. Genuine cables are ~£14, breakout boards can be as low as £2 on eBay. So let’s try and get connected to the Premier Elite 12-W using this cable.

There are two ports on the Premier Elite board – Com Port 1 and Com Port 2. These are 5 pin Molex connectors with only 4 pins populated. There didn’t seem to be a direct pin-out in the manual, so from the manual and with a multimeter we have:

Pin 1 – 12V

Pin 2 – nothing

Pin 3 – GND

Pin 4 – Receive

Pin 5 – Transmit

Com port 1 and 2

Signalling appears to be 5V. So, get out the 5V FTDI cable (they come in different voltages):

A 5V FTDI cable

Pin 1 – GND

Pin 2 – Don’t care

Pin 3 – Don’t care

Pin 4 – Transmit

Pin 5 – Receive

Pin 6 – Don’t care

We then need to connect transmit to receive, receive to transmit, and common ground. This terminology might be at odds with alarm equipment – RS485 buses often label one wire “T” and it means transmit on the master, receive on the slave. I suspect this simplifies wiring as you just connect all “T” wires.

So, to connect the two:

Texecom – FTDI

Pin 3 GND – Pin 1 GND

Pin 4 Receive – Pin 4 Transmit

Pin 5 Transmit – Pin 5 Receive

Just be cautious of the 12V on pin 1 of the alarm board – sending this up the chuff of your PC will result in damage.

Using jumper cables, you could make up a proper cable

Find out which COM port the FTDI cable is using (generally go into Device Manager, and it will be listed there).

COM6 is my FTDI cable

Go into Wintex and change the PC-COM port to this COM port:

Change Wintex to use COM6

Connect, receive settings, change settings, and monitor Ricochet devices to your heart’s content!

And start setting things up

# First look at the TI MSP-SA430-SUB1GHZ spectrum analyser

TI are running a “Back to school” promotion, and as part for this they are selling a simple sub-1GHz spectrum analyser for $25 (with free shipping to the UK). It uses a CC430 chip, which is an MSP430 microcontroller plus an RF front-end. Seems like a deal, and could be used for something like RFCat. It turned up in a couple of days, marked as a “Sample” so no duty or VAT to pay. It’s in a nice plastic case, which I immediately ripped off. Construction is good quality – the SMA connector is bolted on, big ground planes. It connects to a PC using USB, with cable supplied. There is also a SMA antenna provided: You can download the spectrum analyser software from the TI site, although it does come with a CD as well. This is our baby monitor transmitting white noise: I’ve only had a quick play about with it… it works, sort of. It’s buggy though and certainly not as good as the software that comes with the RF Explorer. Key points: • Covers 300-348MHz, 389-464MHz and 779-928MHz – quite gappy but covers ISM. • Relatively quick to update on the screen. • Can configure frequency, span, RBW and FSW. Minimum span is 0.2MHz, minimum RBW is 58kHz, minimum FSW is 1kHz. It seems that a lot of values here cause no display – span of 0.5MHz stops the display working. • Does realtime, max, average display. • Numeric entry validation is really irritating – it limits you whilst entering the value rather than after. • A lot of the UI doesn’t seem to like Windows 8 with scaling set to <>100%. • Crashes relatively frequently. • Mentions firmware and calibration data in the app, so it might be relatively well calibrated. • Source code for the app is available. I’d be annoyed if I spent$250, but it’s great for £25. There is a lack of documentation on the hardware – there are a lot of passives between the SMA and CC430. It would be nice if this could be used for transmit as well as receive but I expect the passives will get in the way.

# Straight Pride UK having a shot at the Streisand effect

A blogger called Oliver Hotham emailed a set of questions to an organisation called “Straight Pride UK”. They responded, Oliver blogged about it, and then was served with a DMCA takedown notice. WordPress generally just give in to these.

Oliver decided he didn’t want trouble – WordPress said his whole blog would be suspended if he posted it again. Ian at Technovia made the content available again. I’m mirroring it here. It would be great if more people could do the same – the more people that share this, the less can be done.

## Oliver’s original post

There has never been a better time to be gay in this country. LGBTI people will soon enjoy full marriage equality, public acceptance of homosexuality is at an all time high, and generally a consensus has developed that it’s really not that big of a deal what consenting adults do in the privacy of their bedrooms. The debate on Gay Marriage in the House of Commons was marred by a few old reactionaries, true, but generally it’s become accepted that full rights for LGBTI people is inevitable and desirable. Thank God.

But some are deeply troubled by this unfaltering march toward common decency, and they call themselves the Straight Pride movement.

Determined to raise awareness of the “heterosexual part of our society”, Straight Pride believe that a militant gay lobby has hijacked the debate on sexuality in this country, and encourage their members, among other things, to “come out” as straight, posting on their Facebook page that:

“Coming out as Straight or heterosexual in todays politically correct world is an extremely challenging experience. It is often distressing and evokes emotions of fear, relief, pride and embarrassment.”

I asked them some questions.

First of all, what prompted you to set up Straight Pride UK?

Straight Pride is a small group of heterosexual individuals who joined together after seeing the rights of people who have opposing views to homosexuality trampled over and, quite frankly, oppressed.

With the current political situation in the United Kingdom with Gay Marriage passing, everyone  is being forced to accept homosexuals, and other chosen lifestyles and behaviours, no matter their opposing views. Straight Pride has seen people sued, and businesses affected, all because the homosexual community do not like people having a view or opinion that differs from theirs.

Are your beliefs linked to religion? How many of you derive your views from scripture?

Straight Pride aims are neutral and we do not follow religion, but we do support people who are oppressed for being religious. Only today, Straight Pride see that two homosexual parents are planning to sue the Church because they ‘cannot get what they want’. This is aggressive behaviour and this is the reason why people have strong objections to homosexuals.

You say that one of your goals is “to raise awareness of the heterosexual part of society”. Why do you feel this is necessary?

The Straight Pride mission is to make sure that the default setting for humanity is not forgotten and that heterosexuals are allowed to have a voice and speak out against being oppressed because of the politically correct Government.

Straight Pride feel need to raise awareness of heterosexuality, family values, morals, and traditional lifestyles and relationships.

Your website states that “Homosexuals have more rights than others”. What rights specifically do LGBTI people have that straight people are denied?

Homosexuals do currently have more rights than heterosexuals, their rights can trump those of others, religious or not. Heterosexuals cannot speak out against homosexuals, but homosexuals are free to call people bigots who don’t agree with homosexuality, heterosexuals, religious or not, cannot refuse to serve or accommodate homosexuals, if they do, they face being sued, this has already happened.

Straight Pride believe anyone should be able to refuse service and speak out against something they do not like or support.

There is a hotel in the south of England, called Hamilton Hall which only accepts homosexuals – if this is allowed, then hotels should have the choice and right to who they accommodate.

What has been the response to your campaign?

The response to Straight Pride’s formation has been as expected; hostile, threatening, and aggressive. Homosexuals do not like anyone challenging them or their behaviour.

We have had support from many people saying that if homosexuals can have a Pride March, and then equality should allow Heterosexuals to have one too. After all, the homosexual movement want everyone to have equality.

Why would you say that heterosexuality the “natural orientation”?

Heterosexuality is the default setting for the human race, this is what creates life, if everyone made the decision to be homosexual, life would stop. People are radicalised to become homosexual, it is promoted to be ‘okay’ and right by the many groups that have sprung up.

Marriage is a man and a woman, homosexuals had Civil Partnerships, which was identical to Marriage with all the same rights, they wanted to destroy Marriage and have successfully done so.

If you could pick one historical figure to be the symbol of straight pride (just as figures like Alan Turing, Judith Butler or Peter Tatchell would be for Gay Pride) which would you choose?

Straight Pride would praise Margaret Thatcher for her stance on Section 28, which meant that children were not  taught about homosexuality, as this should not on the curriculum.

More recently, Straight Pride admire President Vladimir Putin of Russia for his stance and support of his country’s traditional values.

How do you react to anti-gay attacks and movements in Russia and parts of Africa?

Straight Pride support what Russia and Africa is doing, these country have morals and are listening to their majorities. These countries are not ‘anti-gay’ – that is a term always used by the Homosexual Agenda to play the victim and suppress opinions and views of those against it.

These countries have passed laws, these laws are to be respected and no other country should interfere with another country’s laws or legislation.

We have country wide events which our members attend, and ask people their opinions and views, on such event at Glastonbury this year was very positive with the majority of people we asked, replied they were happily heterosexual.

For the record, Straight Pride did not respond to these questions:

“Pride” movements such as Gay Pride and Black Pride were making the argument that the stigma against them meant that proclaiming their “pride” was an act of liberation from oppression. Can being heterosexually really compare?

A problem that Gay rights activists cite is the issue of bullying, and the effect this can have on young LGBT people. Do you think a similar problem exists with straight children being bullied by gay children?

I will obviously add to this if they do respond.

You can follow Straight Pride on Twitter here and see their Facebook page here.

# Reverse engineering Megamos Crypto?

Some of you might have read the stories going around a few weeks ago – “Scientist banned from revealing codes used to start luxury cars“. The short of it is that a security researcher has had a injunction imposed on him, preventing him from publishing a paper. The paper reveals security problems in the Megamos Crypto system used in the immobiliser system of many cars. Volkswagen are not happy – it really seems they want this shut down.

(As an aside, I hate the way that mainstream media refers to “codes” – it can mean source code, executables, an algorithm, or even a secret key. Often used interchangeably in the same article)

Details were a little scant, but last night the EFF passed comment, based on the court’s decision.

I am not a lawyer – I’m not going to pass judgement on the legal side. But what is interesting is how the researchers got hold of the Megamos Crypto algorithm. It wasn’t by decapping the chips in the transponders, it wasn’t from observing them black-box, it wasn’t from looking at an embedded software implementation – they took a Windows program used to clone car key transponders and reverse engineered that.

In terms of working out how Megamos was implemented, someone else had already done the hard work. This left the researchers to perform detailed cryptanalysis of the algorithm and – rumour has it – find some serious problems.

The piece of software is called “Tango Programmer“, a third party tool (software and hardware) used to make transponders. This has been available since at least 2009.

Tango Programmer is readily available, but it appears that it needs to be bought alongside a physical programmer. I strongly suspect that the software would be available on file sharing sites illegally, or possibly even legitimately on another site if you look hard enough.

Another company, Bicotech, produce a similar tool called RwProg. The software is downloadable from their website. The executable is packed, but I am sure it would be perfectly possible to reverse engineer the algorithm from the binary.

The court decision itself contains valuable information on Megamos as well, notably from paragraphs 4 and 5:

In detail the way this works is as follows: both the car computer and the transponder know a secret number. The number is unique to that car. It is called the “secret key”. Both the car computer and the transponder also know a secret algorithm. That is a complex mathematical formula. Given two numbers it will produce a third number. The algorithm is the same for all cars which use the Megamos Crypto chip. Carrying out that calculation is what the Megamos Crypto chip does.

When the process starts the car generates a random number. It is sent to the transponder. Now both computers perform the complex mathematical operation using two numbers they both should know, the random number and the secret key. They each produce a third number. The number is split into two parts called F and G. Both computers now know F and G. The car sends its F to the transponder. The transponder can check that the car has correctly calculated F. That proves to the transponder that the car knows both the secret key and the Megamos Crypto algorithm. The transponder can now be satisfied that the car is genuinely the car it is supposed to be. If the transponder is happy, the transponder sends G to the car. The car checks that G is correct. If it is correct then the car is happy that the transponder also knows the secret key and the Megamos Crypto algorithm. Thus the car can be satisfied that the transponder is genuine. So both devices have confirmed the identity of the other without actually revealing the secret key or the secret algorithm. The car can safely start. The verification of identity in this process depends on the shared secret knowledge. For the process to be secure, both pieces of information need to remain secret – the key and the algorithm.

In standard cryptography terminology:

A car $\text{C}$ and a transponder $\text{T}$ share a secret key $K$. A pseudo-random function family $\textsf{PRF}$ is keyed using key $K$ i.e. $\textsf{PRF}_K$. The output from this PRF is split into two parts $F$ and $G$.

1. $\text{C}$ generates a random number $r$.
2. $\text{C}$ calculates $(F,G) = \textsf{PRF}_K(r)$
3. $\text{C} \to \text{T}: r, F$
4. $\text{T}$ calculates $(F',G') = \textsf{PRF}_K(r)$
5. $\text{T}$ checks that $F = F'$
6. $\text{T} \to \text{C}: r, G$
7. $\text{C}$ checks that $G = G'$

This process means that the transponder believes the car knows the key and PRF, and the car believes the transponder knows the key and PRF. They should have authenticated themselves with each other.

What is a PRF? A pseudo-random function is similar in many respects to a psuedo-random number generator (PRNG), except instead of sequentially generating output, you can randomly access any of the outputs using an index (r in the example above). The key is analogous to the seed of the PRNG. Using a certain key, a given input will map to a determined output.

Importantly, the output of a PRF should be indistinguisable to an observer from a random function, and by extension you should not be able to derive the key even if inputs, outputs, or free access to the function is given. You should also not be able to tell which PRF is in use even if you can control the inputs and read the outputs.

So – if this is a secure, solid, verified PRF, the protocol should be secure, even if we know what the PRF is. The only thing that needs to be kept secret is the key.

But the court decision says:

The verification of identity in this process depends on the shared secret knowledge. For the process to be secure, both pieces of information need to remain secret – the key and the algorithm.

This suggests a few things:

1. The PRF used is not secure
2. They don’t know what they are talking about

Both are entirely possible, but I would strongly suspect that the PRF has issues and they want to keep it secret. This would be a clear example of “security through obscurity”.

How could a PRF be insecure?

• Using one or more input/output pairs, it might be possible to derive the key.
• You might not need a key to derive the output given the input.
• The key length might not be long enough to prevent bruteforcing.
• F and G might not depend on the whole key i.e. you might be able to calculate G given part of the key.

The protocol itself might suffer from further issues:

• There does not appear to be any protection from replay attacks (prevented from being used as a direct vulnerability because the authentication is bidirectional).
• Is the random nummber actually random? Does it matter if it isn’t? If they are re-used (i.e. it’s not a nonce), it probably does matter.
• The transponder can bypass the check for F = F’ – it can be a “yes” key. If we don’t need the entire key to compute G, this matters.
• The key might be constant across an entire line or make of cars. Recover the key from one transponder and there would be no secrets left.
• The key might be derived from an open piece of information like the car VIN number
• The key might be derived from something like the manufacture date/time of the car, massively reducing keyspace
• Probably a million more things

Let’s look at the attacks described in the court decision.

Firstly, note:

The attacks are not, themselves, trivial things to do. However, they allow someone, especially a sophisticated criminal gang with the right tools, to break the security and steal a car.

This makes it sound like some of these attacks are practical i.e. it won’t take 2 weeks of effort after decapping and reading the key from EEPROM.

Attack 1:

One attack relies on weaknesses in the secret keys that are used in certain cars. That “weak key” weakness arises because certain car makers have used weak secret keys which are easier to guess than they need to be. In effect, it is a bit like using the word “password” for a password.

As I mentioned above, there are a number of situations where the keys chosen might be poor. It might be the case that the researchers need 2 weeks to work out the key given a car and transponder, but then if the same key is used across all cars, it doesn’t really matter.

Attack 2:

Another is concerned with key updates. The details do not matter.

This is very vague.  Maybe you can alter or add keys easily if you already have access to the car?

Attack 3:

The third attack relates to weaknesses in the Megamos Crypto algorithm itself. The academics explain this attack in the paper, and, as I say, the paper also sets out the whole of the algorithm. It is these two elements that the claimants seek to prevent publication of. The claimants wish to remove the Megamos Crypto algorithm and information about the attack based on the weakness in it from the paper.

This is where we get to the point that it sounds like the PRF is not secure. It sounds like this attack may take days of work with access to both the car and transponder.

This could be like the insecurities found in Keeloq. The first step was determining the details of the algorithm. The first few papers detailed weaknesses that meant the protocol was insecure, but the weakness could not practically be exploited. After this, papers were released that detailed faster, more effective attacks, until finally we are at the stage where Keeloq can be called “broken”.

A quick look at some of the software

I haven’t got hold of Tango Programmer, but I do have RwProg up and running. Here is a screenshot:

What can we tell from this? Well, the crypto key looks to be 96bits long – too long to bruteforce.

There are a few videos as well:

Nothing really groundbreaking. I can’t see how the software reads and then writes the crypto key.

## Conclusion

Regardless of the court decision, it looks like there is enough information out there for other people to start work on this. Download the software, maybe buy Tango Programmer, reverse the algorithm and then let the world loose on it!

# A remedy to the anti-NHS bile…

Last year, I was suffering from serious anxiety around my infant son getting ill. It was stopping me sleeping and eating. I had a couple of panic attacks. I ended up speaking to a psychotherapist to help me control these feelings. In retrospect, it feels like a part of this anxiety centred around a lack of confidence in the medical help available to us. My confidence had been eroded by the media picture of the NHS.

Day after day I see the NHS being attacked at every level. The people running it are useless. The nurses lack compassion. The doctors can’t speak English. It goes on and on.

A big thing that helped my anxiety was following doctors, nurses, paramedics and other healthcare professionals on twitter. That might sound trite, but I really think it helped. I could see that there are a huge number of people in the NHS who are really passionate and involved in their jobs.

This post is probably just going to become a hugely involved version of a “follow Friday”, but I thought I would highlight some of the best NHS twitter accounts out there. If I have missed you, I am sorry. If I have got your title a bit wrong, also sorry!

• @DrRanj - a paeds doctor who does a lot of really good TV and media work. Comes across as personable and honest.
• @Dr_Ayan - a GP who is also the BBC World News medical expert. Heavily into evidence based medicine, never afraid to say what he means.
• @kiershiels - peads doctor who you might remember from the first series of “Junior Doctors” on the BBC. Clearly passionate about his work. The most middle class man in the UK.
• @SepsisUK – The UK Sepsis Trust – the account is run by Dr Ron Daniels, an ITU doc. Always willing to engage. Sepsis kills more than 37k people each year in the UK, and for each person it kills it can destroy another person’s life. I urge everyone to take a look at what sepsis is and how to recognise it. Don’t rely on doctors and nurses to pick it up! My partner was admitted to hospital with suspected sepsis and because she was treated promptly and correctly, it was nipped in the bud.
• @DoctorChristian - I might not always agree with him or his shirts, but he does an awful lot to make the public aware of problems and how to solve them.
• @DrCJohn - anaesthetist who seems to need to learn something new each day. Less celeb that the ones above, but just as involved.
• The paramedics – @meditude@HewettChris, and @StretcherMONKEY. These three accounts couldn’t be any more different to each other, but there is no doubt they all have the same goals.
• And finally, the ambulance control room, @AmbControl999. Honest and informative.

Give these guys a go. Or any of the other NHS staff on twitter. I’m almost certain it will leave you impressed rather than saddened.

Don’t blame what is happening to the NHS on these guys – blame it on our ridiculous government.

Thanks also has to go to the West Middlesex UCC which has seen me and my son several times, and seen us quickly and given us the best possible standards of care.