Monday, November 30, 2015

Ethernet Funnies

Sometimes it is very hard to connect to an embedded system, because the designers cut some corners to simplify the system and keep memory use down, or simply because the system is prehistoric and full of bugs.

One such device worked fine provided that there was a little ethernet switch between the laptop machine and the target, but a direct connection between the laptop machine and target device only worked about half the time.  Even the little switch sometimes could not connect.


An ethernet interface device consists of three main parts: The Media Access Controller (MAC), the Physical Interface (PHY) and a set of transformers - the Magnetics.  When you plug a cable in, the PHY sends out little pulses to figure out what is going on and then swaps the wires around internally and changes the speed and duplex settings to make the interface work.

The trouble was that the target only supports 100 Mbps, while the laptop machine wanted to run at 1 Gbps and the two just could not reach agreement.


The ethtool program can be used to configure the ethernet interface device manually:
# ifconfig em0 up
# ethtool em0
# ethtool -s em0 speed 100 duplex full autoneg off
# ethtool em0
# ifconfig em0 netmask

That forced the laptop machine to the correct speed and duplex settings, turned the broken auto negotiation off and then life was good.

Shortly after writing the above, I ran into a case where the embedded system works better with a 100 Mbps half duplex connection, but the auto-negotiation usually resulted in a full duplex connection.

# ethtool -s em0 speed 100 duplex half autoneg off

Problem fixed.

These weird issues are usually due to a bad board layout around the ethernet chip set.


More information here:

La voila!


Wednesday, November 18, 2015

Compile The Latest ffplay From Source

Compile latest version of ffplay from source

Note that this script doesn't overwrite the existing ffmpeg installation:

The gotcha in the above guide is the SDL-devel package without which ffplay will not build.

#! /bin/bash
yum install autoconf automake cmake freetype-devel gcc gcc-c++ git libtool make mercurial nasm pkgconfig zlib-devel SDL-devel

mkdir ~/ffmpeg_sources

cd ~/ffmpeg_sources
git clone --depth 1 git://
cd yasm
autoreconf -fiv
./configure --prefix="$HOME/ffmpeg_build" --bindir="$HOME/bin"
make install
make distclean

cd ~/ffmpeg_sources
git clone --depth 1 git://
cd x264
PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" --bindir="$HOME/bin" --enable-static
make install
make distclean

cd ~/ffmpeg_sources
hg clone
cd ~/ffmpeg_sources/x265/build/linux
cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="$HOME/ffmpeg_build" -DENABLE_SHARED:bool=off ../../source
make install

cd ~/ffmpeg_sources
git clone --depth 1 git://
cd ffmpeg
PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib" --bindir="$HOME/bin" --pkg-config-flags="--static" --enable-gpl --enable-libx264 --enable-libx265 --enable-ffplay
make install

cd /usr/lib
ln -s /home/username/bin/ffplay fffplay

Play Video With Low Latency Using ffplay

This is the fastest I can make ffplay:

$ ffplay -threads 2 -flags low_delay -fflags nobuffer -rtbufsize 32768 -fast -probesize 800000 -analyzeduration 800000 -ss 1 -framerate 50 udp://

Play Video With ffmpeg

This also quite fast, just to show that you can play video directly with ffmpeg using SDL output:

$ ffmpeg -i udp:// -f sdl -

Play Video With gstreamer

Just because it also pertains to playing video, here are a couple tricks with gstreamer:

$ gst-launch -v playbin uri=udp://

First try a video test pattern though:

$ gst-launch-0.10 videotestsrc ! ffmpegcolorspace ! autovideosink

If the test pattern doesn't work, then there is no point in continuing - you got to fix it.

La Voila!


Friday, November 13, 2015

Windows Insanity

Unsolicited Advertisements

To add insult to injury, Microsoft Windows 10 now displays advertisements right in the File Explorer. 

I'll leave it to you to figure out why that is a very bad security problem.


Rusted Sieve

Windows 10 is about as secure as a rusted sieve, with a few deliberate holes poked in it for good measure.  Microsoft essentially tries to convert your Personal Computer into a cell phone, which is a purpose built blabbing and tracking device.  They don't seem to understand the word 'personal' in 'PC' though.

Examples of data we collect include your name, email address, preferences and interests; browsing, search and file history; phone call and SMS data; device configuration and sensor data; and application usage.

Recently, the Diagnostics Tracking Service (DiagTrack) service was renamed to the Connected User Experiences and Telemetry service.  Sigh...

Microsoft, in their infinite wisdom, hooked up a plethora of tracking systems and tunnels, to capture your keystrokes, your voice, every address you visit on the web, your WiFi router passwords and your disk drive encryption keys.  I guess they figured that your camera is already captured by Skype, so they didn't need to add that to the list.  I can see many a giant law-suit lurking on the horizon because of this.

To further rub salt into the wounds, a long laundry list of CIA exploits have been published by WikiLeaks - these are mostly for Windows.  The point being that Windows already has enough holes and it doesn't need Microsoft deliberately adding more.

Irresponsible Use

At this point, all I can say is that using MS Windows for anything except maybe playing games, is irresponsible.

You should not risk using MS Windows for shopping, banking, business or government.  It is not suitable for that.

Here is a list of utilities that can be used to attempt to clean Windows 10 and try to prevent it from blabbing to all and sundry about everything you do with your computer.





GWX Control Panel

Spybot Anti-Beacon

Evil Addresses

A list of evil hard coded addresses I found, that should be blocked in a router:

I have no idea what these addresses are and there may be many more.  These are hard coded connections in Windows, that cannot be blocked with a domain name server or hosts file.

Domain Names

My hosts file that I made after looking at packets with tcpdump:

How Many More?

If the above lists haven't convinced you to shun this super quality spying system, then consider that there may be many more leaks that we haven't found yet and as soon as Microsoft figures out that most holes are plugged by the above tools, then they are sure to add new ones to keep the data flowing - as evidenced by the recent rename and rework of their networked sniffing service.  It is bound to keep happening to throw off the defenders.

Therefore I still think that the only somewhat secure way to use Windows 7, 8 and 10 is in a virtual machine with networking disabled.  The trouble is that you cannot analyze encrypted tunnels with packet inspection in a router, so you have to unplug the network cable.

The only real solution is to use UNIX - buy a Mac, install Red Hat Linux Fedora or BSD, since securing MS Windows is a futile game of Whack a Mole.

In addition, Windows also has a low level exploit in the UEFI BIOS, that allows a perpetrator to install WPBT code that will run before the system starts up.  This was supposed to be used for an anti-theft system, but MS botched it.

Amusing use of WGA Remover

The most amusing fix, is to install Windows 7 and then run WGA Remover instead of registering it.

Microsoft will then think that you are running an illegal copy and out of sheer spitefulness will not offer you any unsolicited Windows 10 bugs, adware and downgrades, but you will get security updates.  I recently tried it and it seems to keep Win7 Pro from morphing into Win7.10 Shopping Channel Edition.

I like this approach, since it reflects their attack upon our sensibilities right back to them.

A Simple Fix for the Windows 7 Black Screen Annoyance

You don't normally need to download any special tools to fix Windows Annoyance problems, but you need to be aware that there is a user higher than Administrator, called Local User.  So you need to take ownership of a couple of files in the system32 directory, then zap them.

Click Start, All Programs, Accessories, Right Click on Command Prompt and select Run As Administrator, then:

You can use slmgr to input the key if the machine is online or if you have a phone and the right number and depending on where you are in the world, that may be a tall order.

Zap a couple files in the system32 directory:C:\> cd \windows\system32

Take ownership of the sppcomapi.dll file and rename it:
C:\> takeown /f sppcomapi.dll
C:\> ren sppcomapi.dll sppcomapi.dll.bad

(If the above doesn't work due to the file being in use - restart and try again and if that doesn't work either, get the Microsoft 'handle' utility:
Run 'handle filename' to list all matching handles, then 'handle -c id -p pid' to release it.

Make an empty file to replace it:
C:\> nop > sppcomapi.dll

Take ownership of the slui.exe file and rename it:
C:\> takeown /f slui.exe
C:\> ren slui.exe slui.exe.bad

Make an empty file to replace it:
C:\> nop > slui.exe

Now the Windows Annoyance system cannot run.

Reboot Windows
Log in

Right click on desktop, personalize:
Reset the desktop background to something pretty.

Once you turned all the junk off, Windows starts up and runs significantly faster.

-. --- / .-- .. -. -.. --- .-- ... --..-- / -. --- / -.-. .-. -.--



Tuesday, November 10, 2015

Dropbear - Embedded SSH Daemonology

A Bear of Very Little Brain

The name Dropbear is intriguing since it makes me think of grizzlies and gummy bears. Real Aussies know that a Drop Bear is a carnivorous marsupial with a particular taste for foreign hikers.  I love sugar - who doesn't - but I should not eat it anymore.  I found that cinnamon makes a good substitute in most things, but I digress, this is not supposed to be a treatise on sugary treats or scary marsupials.

The Dropbear SSH daemon can be compiled with various options, but when one is faced with an existing system that cannot easily be changed, then one has to make do with what one got.
I was trying to download log files and video off an ARM based system and it took forever.  So I experimented with the SSH encryption and compression options to speed it up.  Since a typical embedded system has a dinky little processor, selecting a simpler encryption algorithm can make a huge difference.

AES vs Blowfish

The standard copy command "scp user@target:~/data ." ran at all of 6 Mbps.   I could see the grass growing, which is really special, since I live in a desert.

The default algorithm is AES256, which has special instructions on a X86 type processor to speed it up, but not on an embedded ARM based target.  When I tried Bruce Schneier's Blowfish "scp -c blowfish-cbc user@target:~/data ." it immediately ran at more than double the speed, clocking 13.5 Mbps.  It felt like flying compared to the previous.

Arcfour would run even faster, but Dropbear doesn't have it by default and some people are concerned that Arcfour is not secure anymore, though that is actually a Windows implementation problem.  IMHO Arcfour is not much worse than Blowfish - sorry Bruce...

Header Compression

I then tried header compression (the -C option) and it halved the speed again.  So this poor ARM processor really doesn't like the Zip algorithm either.

Process Control

Finally, I checked to see what the target processor was doing with 'top' and found that one running process was consistently sapping 25% of the processor power, so I thought I would hit the jackpot if I simply suspend that process while downloading.

A bit of remote job control using pidof and kill:
$ PID=$(ssh user@target "pidof -s processname")
$ ssh user@target "kill -SIGSTOP $PID"

Then I did my download test again and disappointingly found that the resulting speed-up was only 5% from 13.5 Mbps to 14 Mbps - where did the other 20 go?  Oh well, I'll take that little bit too thanks.

After the download one can resume the suspended task with:
$ ssh user@target "kill -SIGCONT $PID"

SSH Password Scripting with ssh-askpass

Another disappointment with this version of Dropbear was that it doesn't seem capable of public key authentication, only passwords and typing a password all the time gets boring really quickly, but OpenSSH is not particularly script friendly.

Fortunately there is a utility on Red Hat systems called ssh-askpass.  Users of Debian distributions will have to compile it from source, since it is not in the repositories, due to some misplaced concerns with protecting evil users of SSH against themselves.

Save your target password in a variable called SSHPASS, then use a command like this:
$ SSHPASS=password
$ ssh-askpass -e ssh user@target "remotecommand"

Zenity has a password entry dialogue that is useful for this type of problem.  Later in a script, I'd blank out the password so it doesn't hang around in memory too long, to salve my conscience.

La voila!