Accessing the contents of Goluk T-series dashcams

January 30, 2018


The Goluk T-series – at the time of writing, T1, T2, and T3 – are car dashcams. They are cheaper and arguably better-quality than the popular Blackvue brand.

The cameras are wifi-enabled; each presents as a wifi access point with somewhat-configurable SSID and configurable password. The intended access method is via the Goluk app, which is available for IOS and Android. The user’s smartphone is connected to the camera’s wifi AP and then the app is used to configure and manage the camera, and download videos.

I wanted to be able to download the contents of my dashcam automatically when it came in to range of home. At the moment, there is no published way to do this.

This document assumes some knowledge of the UNIX (Mac/Linux) commandline, basic networking, wifi, and HTTP.


  1. Connect to the camera’s wifi network.
  2. Obtain an IP address from the camera by DHCP.
  3. Empty all of the videos out of the camera:

Note that this step will consume disk space up to the size of the camera’s sdcard on the host where it’s run, and depending on the quality of your wifi link – and the current goluk devices only support 802.11n, not 802.11ac – may take a long time.

$ for i in 1 2 4 ; do for j in `curl -s\
videolist?type=$i\&maxcount=8000|grep id|awk '{print $2}'|\
sed s/\"//|sed s/\"\,//` ; do echo $j ;\
 curl -s http://localhost:9000/api/video?id=$j > $j.mp4\
 ; done ; done

Hints for further investigation

Network setup

The Goluk cameras appear to default to IP; addresses on this subnet are served by the on-board dnsmasq DHCP server, and associated binaries (eg the phone apps) appear to contain the address hardcoded. This is potentially awkward if you want to connect to more than one camera at once.

Other documentation

Goluk provide some API documentation on their github site at – however, this is aimed at the writers of Android and IOS apps, rather than someone who wishes to interact directly with the camera.

It does reveal some clues about the interface to the cameras – particularly, if “strings” is run on the GolukSDK file:

$ strings GolukSDK |grep http\:|grep api {
"MOTION_SW":"http://%s/api/motion_sw" }

Camera API calls

The API calls listed in the “strings” output above are somewhat obscure. Some appear to be GET, others are possibly POST. Some accept or require parameters which are not simple to determine.

I have not researched the majority of the possible API calls.

QueryFileList http://%s/api/videolist

GET request. Serves a list of the available videos on the device.

Requires parameter “type=n” where n is one of the following:

  • 1: “NRM” videos – those produced continuously while the vehicle is being driven. By default these are 3 minutes long.
  • 2: “URG” videos – those produced when motion is detected outside the vehicle while it is parked. By default these are 12 seconds long.
  • 4: “WND” videos – those saved when the hardware button to save video at a time of interesting events is pressed by the camera user. By default these are 12 seconds long.
  • 5: “NRM_TL” videos – timelapse videos created while parked, if the corresponding option in settings (introduced in the 1.7 firmware release during the summer of 2018) is enabled.

Accepts optional parameter “maxcount=n” where n is the maximum number of results (videos) which will be returned. The largest possible value of “maxcount” appears to be 8000.

	"data":	{
		"total":	3,
		"list":	[{
				"id":	"NRM_20180130123812",
				"type":	1,
				"resolution":	"1080p",
				"period":	179,
				"time":	1517315892,
				"timestamp":	"20180130123812",
				"size":	291015449,
				"location":	"NRM_20180130123812.mp4",
				"withSnapshot":	1,
				"withThumb":	1,
				"withGps":	0
			}, {
				"id":	"NRM_20180130124113",
				"type":	1,
				"resolution":	"1080p",
				"period":	179,
				"time":	1517316073,
				"timestamp":	"20180130124113",
				"size":	291067965,
				"location":	"NRM_20180130124113.mp4",
				"withSnapshot":	1,
				"withThumb":	1,
				"withGps":	0
			}, {
				"id":	"NRM_20180130124413",
				"type":	1,
				"resolution":	"1080p",
				"period":	72,
				"time":	1517316253,
				"timestamp":	"20180130124413",
				"size":	117221480,
				"location":	"NRM_20180130124413.mp4",
				"withSnapshot":	1,
				"withThumb":	1,
				"withGps":	0
	"msg":	"OK",
	"result":	0

DownloadDelVideo http://%s/api/video

GET request. Requires a parameter “id=x” where x is an id taken from the “videolist” call above. Retrieves a video from the device and returns it in mpeg4 (h264) format.

SnapshotPic http://%s/api/snapshot

GET request. Requires no parameters. Takes a picture immediately and returns it in JPG format.

GetIPCInfo http://%s/api/systeminfo

GET request. Requires no parameters. Serves the device’s serial number, hardware and software version, and type.

GetSDUsage http://%s/api/sd

GET request. Requires no parameters. Serves a summary of available and used storage on the device.

Camera internals

The cameras appear to run Linux with the nginx web server listening on port 80, dnsmasq listening on port 53, a rtsp server on port 554, and a telnet server on port 23:

$ nmap

Nmap scan report for
Host is up (0.017s latency).
Not shown: 996 closed ports
23/tcp open telnet
53/tcp open domain
80/tcp open http
554/tcp open rtsp

As of software T2U_V1.6.0516.0959 this appears to be nginx 1.9.6 and dnsmasq 2.7.1.

The telnet server gives away the camera OEM, Ambarella:

$ telnet
Connected to
Escape character is '^]'.

Ambarella login:

It’s unlikely that the login details are highly secure, but at the time of writing they are not known to the author. The common suggestion of “root/123456” does not work.


Nissan Leaf data logging

April 24, 2017

The Nissan Leaf is a relatively popular electric car.USC70NIC161C021001

The LeafSpy Android app allows a wealth of data about the car to be extracted from its various onboard computers, displayed on-screen, and logged.

This post details a possible way to set up a permanent data logger on board a Leaf, using the LeafSpy app, and provides some example hardware configurations and scripts for dealing with the logs generated.

You need to be at least somewhat confident with the Linux commandline in order for these notes to be of any use to you.

This post deals with the “gen1” and “gen1.5” Leafs produced from launch until the time of writing, 2017. Later in 2017, Nissan will launch a heavily-revised version of the Leaf, in which LeafSpy will not work (at least initially), and the dimensions of the interior will change.


An Android device

Almost any Android device available is powerful enough to run Leafspy. It needs Bluetooth in order to communicate with the Bluetooth OBD2 device. Internet connectivity is desirable – but this can be Wifi provided by the driver’s phone, or an access point where the car is usually parked, if preferred.

If you plan to conceal the device within the car and simply log data only, then you can choose almost anything. A low-end tablet might be a good choice, in order to gain extra battery life. It could be concealed under one of the front seats.

If you want to leave the device visible in the car, in order to see the on-screen display of data as you drive, then your intended mounting position will determine the dimensions of the device.


The tray underneath the heater controls provides a location in which the screen can be seen, but the device is not obvious from outside the vehicle when parked.


It is convenient for running a cable from the cigarette lighter for power, reachable from the driver’s seat, and has space for a power bank as well (see below). The space is approx 130mm across, and slightly tapered, restricting the choice of devices.
In these photographs, the device is held in with blue-tac. Once happy with the setup, black sugru or silicone could be used and would be almost invisible.

The setup described in this post uses a ZTE A110, aka “ZTE Shout”, “ZTE Zip”, “ZTE Blade A110” and “ZTE Spark Lite”. This is 125mm tall, fitting easily into the space under the heater controls. It supports Bluetooth and LTE, is cheap to SIM unlock, rootable, and at the time of purchase widely available for around $40. It is also easily modifiable (see below) to boot up without intervention when the charger is connected.

5V power adaptor

A 5V power source is required to power the Android device. If concealing the device in the car, then a 12V to 5V converter (example) could be used – giving the option of using a permanent live feed to keep the device running semi-permanently when the car is not in use.
Alternatively, if mounting the device under the heater controls (as described above), a good quality cigarette lighter USB power supply should be used. It’s likely that a pair of 2A outputs will be required at minimum – one for the Android device and one for charging the driver’s “everyday” phone. This and this are both good choices.
The Leaf built-in USB port should not be used – it’s limited to 500mA.

Bluetooth OBD2 adaptor

An ELM327 clone bluetooth OBD2 adaptor is required. These are readily available for under $20.
Leafspy is fussy about which hardware/adaptor revisions it will work with – it’s best to check this forum thread for advice before buying.
In the past, this and this have been reported to work.
The OBD2 adaptor can be plugged directly into the OBD2 port under the steering wheel. If the adaptor is physically large then an extension cable (see below) is recommended.nissan_leaf_tekna_OBD2_connected

Optional: power bank

In this installation, the Android device (above) is only powered when the car is powered-up, the cigarette lighter port being dead otherwise.
Although the device is modified (see below) to power-up when the charging voltage is applied, the time it takes to boot can mean the first couple of minutes of logs are lost while it boots.
This is only a problem if the device’s battery has run down in between uses of the car.
To extent this period, a power bank can be connected between the 5V (USB) output from the charger, and the Android device, to extend the device’s runtime.
The power bank used in this instance is the Zendure A2 6700mAh, which fits neatly out of sight behind the Android device and provides the rare – but vital – feature of being able to charge the phone while it is itself being charged: “pass-through power”.

Optional: OBD2 extension cable

An OBD2 extension cable allows the OBD2 adaptor (above) to be concealed in the vehicle. There are a number of simple reasons why this might be desired:

  • The larger OBD2 adaptors may protrude into the driver’s legroom.
  • The LEDs on the adaptor may be a distraction, or draw unwanted attention to the vehicle.
  • If a protruding OBD2 adaptor is knocked when entering or exiting the vehicle, the OBD2 port may be damaged.
  • A Y-shaped (splitter) cable can be used to provide more than one OBD2 port in the event that an additional OBD2 device, such as a telematics unit, is used alongside the Leafspy bluetooth adaptor.
  • The cable allows the OBD2 adaptor to be moved to a convenient location – in this instance, it is simply pushed into the soft sound insulation beside the pedals, where it is easily held fast against a trim panel.

The reason which drove the use of an extension cable in this system, is the ability to alter the wiring of the OBD2 interface by modifying the cable.

In the normal installation, the Bluetooth OBD2 adaptor (above) will be continuously powered by the permanent 12V feed present on the car’s OBD2 port. A running Leafspy instance connected to the adaptor will continuously query the devices on the car’s CAN buses, causing them to consume additional power and potentially flattening the Leaf’s problematic 12V auxiliary battery.

The Leaf provides the standard permanent 12V live on pin 16, but also provides a non-standard switched live on pin 8. A modified cable is used (with pin 8 on the car wired on pin 16 on the extension cable) to ensure the adaptor is powered off when the car is switched off. This does prevent monitoring of the car during charging, at which time the car is “on” and charging the 12V battery but the switched live is not provided.


Google account

Android devices require a Google account to function usefully. This device will be left permanently in the vehicle, where it is at risk of theft, and is also vulnerable to hacking. Therefore a “throwaway” Google account is used, which does not contain any of the owner’s personal data.

A payment card, or gift voucher, is necessary in order to purchase the paid “Tasker” and “Leafspy Pro” apps (see below) – but if a payment card is used, it should be removed after these purchases have been made.

Dropbox account

For Leafspy (below) to upload its logs to Dropbox, a set of Dropbox login credentials will be required. The free (2GB) tier of Dropbox provides ample space for this purpose.

As with the Google account (above), it’s important to note that the device is vulnerable to theft and hacking, and therefore a “throwaway” Dropbox account should be used, which does not contain any of the owner’s personal data.

Alternative: server

More recent versions of Leafspy contain support for uploading data to a server by making regular HTTP requests containing the log data as parameters to a URL. The author has not investigated this option, but it may prove easier than Dropbox.

Android modification

Screen always on

Open the “settings” app, scroll down to the bottom of the list and pick “About”.

Scroll down to the bottom of the list and tap “Build number” repeatedly until you see a message displayed about enabling developer mode.

Re-open the “settings” app, scroll down to the bottom of the list and pick the new “Developer options” item. Enable the “stay awake” option it offers.



Legal warning: The process of rooting an Android device is illegal in some countries. Obey your local law. If you don’t obey your local law, don’t brag about breaking it.

Practical warning: Automatic updates are likely to be disabled after rooting. A rooted device may never update, and will therefore become vulnerable to an ever-increasing number of exploits as time passes, rendering it dangerously insecure even by Android standards.

Second practical warning: The method shown for gaining root here requires the execution of software written by unknown hackers to exploit security vulnerabilities in the device. It is highly likely that it leaves backdoors, keyloggers, trojans, and advertising malware installed on the device. Be aware that hostile third parties may access any information you store in your device after rooting.

The step below, modifying the device to boot automatically, requires root. If you do not feel the disadvantages of rooting are worth the ability to have the device boot automatically, it can be simply booted manually using the power button before driving.

If you wish to gain root and are using the same ZTE A110 as the author, this xda-developers thread outlines the process. An enhancement to the process, which may or may not remove some of the Kingroot malware, is to replace their “kingroot” app with the standard “supersu” using this process.

Once rooted, a worthwhile precaution is to install Flashify and replace the stock recovery with the usual TWRP.


Automatic boot when charger is connected

This step is not essential, but will allow the Android device to boot automatically when the charger is connected. It requires root (see above), which is a complex and risky process. If you do not carry out this step, you will simply need to power-up the device manually before driving.

This set of steps is not unique to the ZTE A110, and is common to a number of low-end Android devices, but will not work on all. It requires root, and is risky and may brick the device – especially if you are unsure what you are doing.

In essence, what these steps do is replace the program which normally displays a nice animation showing a battery filling up when the charger is connected, with a call to the “reboot” program which will boot the device up.

Either in a terminal app, or (preferably) at the adb shell:

mount -o remount,rw /system
cd /system/bin
mv kpoc_charger kpoc_charger.bak
cp reboot kpoc_charger
chown kpoc_charger
chmod 755 kpoc_charger


The Tasker app is a powerful tool for automating tasks on Android devices, with an unfortunately challenging user interface.

In this case, Tasker is used for two tasks:

  1. To start the Leafspy pro app when the device boots.
  2. To shut down the device automatically when its battery state drops to 25% and the charger is not connected. This is not essential, but preserves the lifespan of the device battery by preventing it from being fully discharged when the vehicle is not used for longer periods.

Neither of these tasks is vital – it is possible to carry out both of these tasks manually or by other means.



This setup uses the paid-for “Leafspy Pro” app, rather than the limited free version of Leafspy.
There is a comprehensive, but slightly out-of-date, page about Leafspy on but the main source of information and updates is this thread
Leafspy is configured with the model year and battery capacity of the size. Some fairly simple options can be set. Crucially, logging to Dropbox is enabled – Dropbox login details are required – and after this, it will log a CSV file to Dropbox every day, with details of the day’s driving in it. It can be configured to upload this file at short intervals, giving almost real-time updates.

Log processing

A github repository, unfortunately poorly-ordered, at contains a number of bash and perl scripts for dealing with leafspy logs and creating graphs.

It may be useful to someone who wished to work on their own log processing or graphing setup.




The most serious security problem this setup poses is that of leaving an Android device in the vehicle where it is vulnerable to theft.

As discussed above, the practice of rooting Android devices has a number of security issues which expose the device to attacks. It’s unwise to root a device which will be used as a normal smartphone, but the risks may be acceptable if the device is dedicated to Leafspy and care is taken not to store important personal information on it.

The Bluetooth OBD2 adaptors allow the car to be remotely-controlled to a considerable degree, as they give full access to CAN bus devices. It’s likely that a determined attacker could cause physical damage to the car by changing the settings of devices on the CAN busses.

The Bluetooth connection between the Android device and the OBD2 adaptor has no useful security; mostly a default PIN (either 1234 or 0000) will be used, and in any case the encryption built-in to Bluetooth is trivially hackable.

This means that an attacker within Bluetooth range of the vehicle can potentially take control of it or damage it, while it’s being driven. If the suggested modification (above) is made, so that the OBD2 adaptor is only live when the car is powered-up, then the risk of attack while the vehicle is parked is removed.

The practice of collecting detailed logs from the vehicle may expose the driver to legal problems in future – for instance if they were to collect data which showed a legal speed limit being exceeded.

Linux and the Toshiba NB10

March 25, 2014

I’ve recently bought a Toshiba NB10 (nb10-a-101) 11.6″ netbook.


This is a “modern” device which uses an Intel Bay Trail-M CPU, the Celeron N2810. These are quite new and there is not a lot of documentation yet about using them with Linux. I’m only really interested in using Debian Linux, but these notes may also be useful for Ubuntu and Ubuntu-based distributions such as Mint

The NB10 ships with Windows 8. UEFI Secure Boot is enabled, and there is no support for legacy BIOS (CSM). 

The first hurdle to overcome is booting a Linux installer. Accessing the BIOS is done by holding F12 down before pressing the power button, until the BIOS splash screen is displayed. Choosing an alternative boot device is done by holding down the escape key before pressing the power button similarly.


The left-hand USB port does not seem to be reliable for booting. Use one of the ones on the right.

Once secure boot is disabled in the BIOS, the NB10 will boot the Debian installer happily. It seems to only be able to boot from a file on the EFI partition named boot/bootx64.efi – which is how the Debian and Ubuntu installers ship.

Issues with older kernels and the new Bay Trail-M chip lead to a crash either immediately after loading the kernel, or a couple of seconds after booting.

The wheezy (Debian stable) installer would boot and run via use of the ‘noapic’ and ‘nolapic’ commandline options, but could not successfully bring up the built-in ethernet interface (r8169), nor detect the wireless interface.

The jessie (Debian testing) installer would boot and run via use of the ‘noapic’ option at the kernel commandline. It could successfully use both network interfaces.

It’s best to remove the ‘quiet’ option from the commandline as well, so that the state of the system when it crashes is visible.

Having successfully installed jessie (Debian testing), a couple of further steps were necessary in order to render the installed system bootable.

The first was (as above) to rename /boot/efi/EFI/debian/grubx64.efi to /boot/efi/EFI/boot/bootx64.efi in the installed system.

The second was to replace the kernel; although the installed kernel was identical to the one used by the installer, it would crash during boot. I replaced it with the 3.14 from Debian experimental, which will boot the system successfully without the use of any extra commandline options. This can be done from the installer either before rebooting, or in rescue mode if you forget.

Things which I have confirmed to work in Debian jessie:

  • USB support.
  • Webcam.
  • Trackpad including multi-touch gestures.
  • Suspend to RAM and resume.
  • Sound output.
  • Wireless.
  • Wired networking – but it appears to fail after a resume from suspend.
  • Battery charging..
  • Internal monitor.
  • Touch sensors on internal monitor (unsure if multi-touch is supported).

Things which I have not tested:

  • Suspend-to-disk (hibernate)..
  • VGA output.
  • HDMI output

Things which do not work:

  • SD card reader (nothing happens when I insert a card).
  • Fan control (no fans detected by lm-sensors, no fan heard operating)

I’m not sure what the state of the fan is. “acpi” and “lm-sensors” don’t detect one, and I can’t hear one operating. Running multiple “stress” instances to keep both CPU cores busy resulted in a peak temperature for me of 49C – which may not be enough to need the fan to run.

  • Odd issue with screen blanking.

I’ve had a few instances of the screen blanking and then not coming back on when a key is touched. Suspending & resuming fixes it. It’s definitely not a crash – ssh access continues to work when this happens.

Student Loan Deferment Application Form – PDF

February 21, 2013

This information relates to the older “mortgage-style” loans, rather than the newer “income contingent” (PAYE) ones, and is relevant to the UK only.

One of the many tactics the Student Loans Company, and its various successors, use to prevent deferment of loan repayments is making the deferment form hard to access.

Here is a PDF copy of a blank deferment form, ready to be filled in, from the Student Loans Company.

Hopefully this download will save a few people from having to go through the farcical annual ritual of telephoning, being cut off, calling back, being lied to, waiting for the form to come in the post, beware of the leopard, etc.

The lenders & Student Loans Company all habitually “lose” (discard) deferment forms, and lie, in order to prevent people who are entitled to defer their loan from doing so. Be persistent, keep copies of all documentation, and never give up. Once you’ve reached the end of their complaints processes, you can open a complaint with the Financial Ombudsman.

So long as you have correctly followed your lender’s own complaints process, a complaint to the Ombudsman will cost your lender a £500 fee. Open official complaints in writing to both your lender (if your loan has been sold on by the Student Loans Company) and the Student Loans Company (who process all deferment requests).

Remember that deferment is your right, if your income falls below the threshold (£2318pcm at time of writing). You’re doing nothing morally or legally wrong by deferring, and your credit history is not impaired by doing so. Once you have successfully gone through the process, you must set yourself a reminder to start the process again in 11 months time, assuming you remain entitled to defer.

Unfortunately, if you cancel your Direct Debit to your lender even after submitting a valid deferment form, your credit history may be affected.

Cloning a FileVault2 encrypted boot disk under OS X Lion

August 24, 2012

It’s taken me a while to produce a working, encrypted, clone of my Macbook boot disk. There don’t seem to be any good instructions out there for this.

These instructions are for producing a bootable, FileVault2-encrypted clone of a Mac’s FileVault2-encrypted boot disk. In order for a FileVault2-encrypted disk to be bootable under Lion, it must contain a valid Recovery partition. These steps will walk you through creating one, and then producing a bootable clone.

The source medium is the existing boot disk in your Mac.  The destination is a USB disk – in my case a surplus SATA disk attached to a cheap USB-SATA converter. I assume these instructions would work equally well for SATA, Thunderbolt or Firewire disks, but haven’t tested this.

We’re running OS X Lion (10.7.4), and using the last free version of Carbon Copy Cloner (3.4.5).

      • First of all, we attach the USB disk. If the Mac complains about it being unreadable, allow it to “Initialize” the disk.
      • Run Disk Utility and find the newly-attached drive.
      • Partition it using the default GUID partition table type, into 2 partitions: one just larger than your source medium, the other free space. It’s OK to create just one partition filling the entire disk, if you’d prefer this, but don’t try to create two formatted partitions – if you do this, the subsequent step of cloning the Recovery partition will fail. You can go back later and format the free space once this process is completed.
      • The first partition’s type doesn’t matter at this point as we’ll re-format it later, except that it must not be encrypted..  If we encrypt the disk now, we’ll be unable to subsequently add the Recovery Partition, as Carbon Copy Cloner is unable to work with the CoreStorage-ified partition layout which adding encryption will create.
      • Give your destination disk’s first partition a meaningful name – it’s going to avoid a lot of confusion if you don’t try to give it the same name as your source disk.
      • Apply these changes and close Disk Utility.
      • Start Carbon Copy Cloner and open “Disk Center” (cmd-2).
      • Pick your target disk from the list on the left, and then pick the “Recovery HD” tab on the right. Press the big button to create a Recovery HD on your destination disk.
        The Recovery partition, once created, is not visible to desktop tools such as Finder – but can be seen in the output from diskutil list
      • Once the Recovery HD has copied, re-open Disk Utility and re-format the target partition with the same filesystem type as your source partition. So if your source/boot disk is “Journalled, case-sensitive, encrypted” then the first partition on your USB disk needs to be “Journalled, case-sensitive, encrypted”. It’s also theoretically possible to carry out this encryption step via the “encryption” tab in Carbon Copy Cloner – but I found this unreliable. Note that you won’t be offered the usual chance to save your keys with Apple, it won’t offer you a “recovery” key, and it won’t give you the opportunity to have the disk be unlockable by any valid user at boot time. I’m fine with this (I just don’t want the burglar who steals the disk to be able to read my data). You’ll need to use a strong password, and not lose it. This will not wipe out the Recovery HD that you have just created, and remains invisible throughout this process.
      • If you want to verify that the partition is indeed encrypted, look at the diskutil cs list output.
      • Quit Disk Utility, return to Carbon Copy Cloner.
      • Clone from your “source” to your “destination” – this will take a while. Chose your favoured combination of settings – but make sure you pick a combination that reports “the destination volume should be bootable”!

Once done, we need to test by booting from the clone:

  • nvram|grep boot-args and if not already set, sudo nvram boot-args="-v" so that if boot fails, we’ll be able to see what went wrong. 
  • Stop and think about whether you have anything on your Mac which will get broken if you boot from a slightly-out-of-date cloned copy of it (eg you’ve updated files in Dropbox, or your Mac is a server for your local network). Take appropriate steps if necessary (mount the cloned “destination” disk and disable apps?).
  • Shutdown your Mac and boot it with the option (alt) key held down. Select the USB disk as boot device. It should boot up as normal (although slow). It will prompt you for the password to decrypt the disk.
  • It might be the case that you’re offered at boot-time a choice between the “Recovery HD” on your internal disk and the “Recovery HD” on your USB disk; this seems to be a firmware bug. If this happens, select either Recovery HD, and run Startup Disk; select the partition on the USB disk and restart. This will prompt you for the disk password and then boot as normal
  • Once booted from your cloned disk, you might want to make sure that things work – particularly you might like to check that your files are present, and your keychain is intact (remembered logins in your browser work, your Mail client works, etc). Before you shutdown again, run Startup Disk and select the internal disk for the next boot.

Richard Whiteley

January 5, 2012

One of my colleagues once worked in the Yorkshire TV buildings in Leeds. He used to walk past the embalmed body of Richard Whiteley in reception there every day, and rub his big toe for luck.

The luck must have held, as he eventually escaped Catherine Zeta Jones’ lair.

The body has now been removed to the ITV Museum, where it sits alongside Dusty Bin. As Dusty Bin has been decommissioned for some years now, it’s speculated that the embalming process may not have been as successful as Lenin’s.

“Cisc Support” telephone fraud

October 19, 2011

I had a phone call today on my ex-directory home phone, from an Indian lady calling herself “Rachel” who claimed to be from “the computer maintenance department”.

TL;DR: an India-based fraud called “Cisc support” using the UK telephone number 01865 589087 and claiming to be based at 256 Banbury Road, Oxford has an interesting telephone patter.

About half the phone calls we get on our home phone are rubbish of one sort or another, and this one had the dead giveaway right at the start – of a silent line, followed by a burst of ringtone, before we were connected.

I expressed polite interest, and snapshotted the Windows XP VM in my home server while “Rachel” connected me to her supervisor “Peter”.

His spiel started with asking me to do windows-key-r (the Windows “run” dialog”) and type “inf”. This opens an explorer window on c:\windows\inf which contains several hundred harmless system files.

“Do you recongise these files?”
“These are the malicious files, these are the corrupted files. These hacking software get into the system without your information. They create problems into your systems. Your computer has downloaded this hacking software and unwanted malicious program”

Similar spiel for several minutes, then he asked me to windows-r again and run Event Viewer (“type eventvwr”), double-click “system” and tell him how many are “errors and warnings”. In a normal Windows system there are dozens-to-hundreds listed – not indicating anything necessarily amiss.
“These are indications that part of your system is getting infected, part of it is getting corrupted” then more spiel about hacking software.

Apparently “my computer is very badly corrupted and very badly infected” and I should close Event Viewer and not click on any of the events as “if you click any of it, it spreads in your computer like a disease.”

Next step (and the excitement in the chap’s voice is evident) is to visit which loads the

[aside – the service is excellent and nothing to do with this fraud. We’re very happy users of their free service for supporting distant parents]

client in a window called “Cisc support”. He takes control and loads this:

screenshot of cisc support fraud website

and guides me to scroll the page, pick a £160 option from it, and enter card details. When I hesitate, he offers as evidence of their bona fides:

  • Their UK telephone number 01865 589087. This does indeed reach them, and their calls present it as CLIP. The 01865 589xxx block of numbers is allocated to Cable and Wireless UK and appears to have legitimate users in it – I’m not sure how this particular fraud has obtained a number from it but presumably there’s a VOIP service.
  • Their company address 256 Banbury Road, Oxford. This appears to be a large office building which has, or has had, numerous small organisations use it as registered office.
  • Google’ing their name “Cisc support”. This is of course auto-corrected by Google to “Cisco support” and the chap then claims to be from Cisco & therefore legit.

“netstat” shows the logmein session connected to an IP address on an Indian ISP Wishnet in Kolkata/Calcutta –

I hang up, and another Indian chap, calling himself “Albert Justin” calls a few minutes later. I say that I’m not going to buy anything, and that’s it. No more calls. At some point in the call he’s taken over the logmein session from another wishnet IP address,

I found a page at which appears to be about the same scam; I have no information about whether the page at a legitimate company or not – it may be that the fraudsters are using their name without permission.