Simple TDR

I have a handful of RJ45 (ethernet wires) that are electrically questionable.  Rather than plugging each between a network device and an ethernet switch, I thought it might be better if use software to test the continuity for each of the wires.

I selected an unused Arduino for the hardware that had 16 free analog and/or digital pins free.  (Yes you can run Digital over Analog Arduino pins).  I wired up the first RJ45 jack to pins 2-9 and the second RJ45 jack to pins A0-A7.  If your Arduino doesn't have those pins, you can change the PORTS definition in the source code.

I ended up calling it simpletdr.  (It isn't actually a time domain reflectometer, its more of a high speed continuity checker, but if you remove the delay(1) in the code it will associate pairs instead of individual wires instead of just checking DC continuity).

You can find the code here on GitHub.  

C64 Shirt

My wife and I made a shirt.

Flight Over

Second drone flight

First Drone Flight with my Holystone HS700. (better color version)

Testing 5V Power Adapters

I got a new oscilloscope a few weeks ago and I thought I might take a few moments to investigate just now noisy some 5V power adapaters that I might use on some Raspberry PI projects in the future.  The first unit I tested was an Ikea Nordmärke wireless Qi charger that also includes a USB port.  I have found it does a nice of charging anything I plug into it such as phones and even tablets.  It also seems to perform well with Raspberry PI's and by far is my favorite USB power supply, so I thought I would include it as part of my testing.

Note that all the tested units below had no load on them.

Here is the screenshot of the first test: (Ikea Nordmärke).  It by far has the cleanest output of a pretty nice sawtooth wave my a quick count of waveforms shows something like 266Hz with a 4% ripple.

The second test I did was on an inexpensive dual port Nokoko17.  The first port is labelled "2.1A For iPad" and the second "1.0A Others".  I have used these in the past for Raspberry PI's with varying results and the multiple times I have had problems with the outer cases falling off leaving high voltage parts still plugged into the wall.  I wouldn't recommend purchasing these again, but here is the traces on both ports.  Note that although the amplitude of the ripple is similar, the max voltage is 5.54 (out of USB spec) and both outputs ring in the 3-6 kHz range.

The third unit tested is a Tech&Go model TJD242 dual output unit.  The ports are not labelled but it does have an LED that stays lit for more than 10 seconds after unplugging it from the wall.
Here are its traces of each port.  I apologize that I was unable to get the hardware frequency counter to kick in.  There does seem to be two sources of noise and the ripple is closer to 9% with 440mV of noise.

So in summary, if you have really cheap 5v power converters, they will be noisy and although they might be great for charging phones at 1-2A current rate (where voltage noise doesn't matter as much), on older raspberry PI's where you need a cleaner signal, consider using a cleaner power supply.

Flipping bits on encrypted Streaming Cipher output to modify encrypted content.

I've been taking a Computer Science class on Cryptography and I was told that Streaming Ciphers have the vulnerability that someone can bit-flip the ciphertext to produce changes to the plaintext in predictable ways.

So I thought I would do a simple test to verify this.  I chose RC4 as my cypher and the plaintext "plaintext" and the password "password".  Also I'm using the builtin hex editor "xxd" to allow me to flip the bits.  Below shows the resulting ciphertext dumped in Hex.  The first 16 bytes are the header with a salt.  The remaining file is the bytes encrypted on at a time.

$ echo plaintext | openssl rc4 -k password | xxd | tee cipher.hex0000000: 5361 6c74 6564 5f5f efda 26bb cb8c aa61 Salted__..&....a0000010: e467 a17c df3e 4a0b 7864 .g.|.>J.xd

To verify it decrypts:
$ xxd -r < cipher.hex | openssl rc4 -d -k passwordplaintext

Now on to test the exploit.  Using a text editor, I modified 'cipher.tex'.  I'm going to try to capitalize every other letter in the exploit by using XOR 20h on the ciphertext.  I've bolded the changed digits below.

0000000: 5361 6c74 6564 5f5f efda 26bb cb8c aa61 0000010: c467 817c ff3e 6a0b 5864

And sure enough the exploit works:

$ xxd -r < cipher.hex | openssl rc4 -d -k passwordPlAiNtExT


And by the way, this appears to also work for Block ciphers in CBC (Cipher-Block-Chaining) Mode.One can tamper with the Initialization Vector (IV) which is often stored next to the ciphertext in some systems. Again I've bolded the changed digits below:
For Example:
$ echo plaintext123456 | > openssl aes-256-cbc -e -k password -nosalt -nopad -iv 9F98E917B9ACEA58DFAD3CB2FAD6331E |> openssl aes-256-cbc -d -k password -nosalt -nopad -iv BF98C91799ACCA58FFAD3CB2FAD6331E PlAiNtExT123456