Their security analysts have a rather direct way of receiving unknown files to analyse: shortly after the first scan, a dialogue popped up:

Neat. Presumably developers creating .exe files need to turn this off eventually…

To fix this:

echo "xen.independent_wallclock = 1" >>/etc/sysctl.conf
echo 1 >/proc/sys/xen/independent_wallclock

(thanks) (thanks)

line='2010-07-20 00:06:08 L5TE67-000BPA-56 <= nagios@nms2.example H=(mail.example) [10.10.10.10] P=esmtp S=22696 id=20100719170632.362CC12EDB7@nms2.example T="NMS Alert - Disk-D on Server2 is WARNING (111)" from <nagios@nms2.example> for admin@example'
re='^....-..-.. ..:..:.. (......-......-..) '
[[ $line =~ $re ]] && echo ${BASH_REMATCH[1]}

Decades ago I worked with Unisys EFTPOS terminals (the type you see at supermarket checkouts). These were of a type which had the PIN-entry keypad on the end of a cable, while the card slot was in the main body of the unit. A perceived risk was that someone could tamper with the unit and install sniffing hardware/software to learn the user’s PIN. To thwart this, the keypads included a DES key stored in supercap-backed-SRAM for encrypting the PIN before it ever left the keypad (the main body of the unit did not have this key; the computer inside it never had access to the plaintext PIN) and a tamper switch in the keypad which would short out the SRAM’s power pins the instant the keypad’s case was opened, thereby destroying its copy of the DES key and rendering the keypad permanently useless if opened.

It would seem that the same approach could readily be applied to terminals embedded in gasoline/petrol pumps; the card-scanner and/or PIN keypad should be in sealed units which are rendered permanently inoperative (by instantly losing/destroying a stored key) if opened.

Naturally, this is just one of dozens of vulnerabilities that such a device has; decisions about which counter-measures to employ are always about trade-offs. Nonetheless, this seems an odd choice.

=mround(amount, 10)

(thanks)

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$prefix /path/to/opensync/source/
make
make install

I have found the following to be more useful. Most importantly, the instructions above imply, incorrectly, that you can use them with an install directory of your choosing (as e.g. in ./configure –prefix in other projects). In fact, you need to use PKG_CONFIG_PATH to cause information about “installed” packages to be generated.

mkdir build
cd build
PKG_CONFIG_PATH=$(realpath ../../install)/lib/pkgconfig/ cmake -DCMAKE_INSTALL_PREFIX=$(realpath ../../install) $(realpath ..)
make
make install

1. Install all necessary Bluetooth drivers from notebook manufacturer.
2. Install BlackBerry Desktop Manager that comes with the Bold.
3. Pair your phone with PC via Bluetooth.
4. Control Panel > Phone and Modem Options > Modems > Standard Modem over Bluetooth Link > Properties > Advanced > Extra initialization commands: set to

   +cgdcont=1,"ip","sunsurf"

5. Control Panel > Bluetooth Devices > My Blackberry Bold > Use your phone to connect to the Internet > Click “Connect”.
6. Dial as follows:
   • User name: 65<phone number>, e.g., 6591234567
   • Password: user123
   • Dial: *99#

UPDATE: The importance of this is that I’d like to take photos with my phone while travelling in The Philippines and Spain shortly and simply post them here, without messing about with logging in to anything. I did test this when the feature was announced and found that it didn’t work, it now does. (cue: Twilight Zone theme) I’ve just noticed that my two tests were separated by almost exactly a year…