Sage SmartProbe FAQ


What’s a Sage SmartProbe?

See previous articles,
A Complete Pill for the Sage SmartProbe.
The Care and Feeding of the Sage SmartProbe.


Where do I get a Sage SmartProbe?

Possibly here — while supplies last. (Warning: I have no relation with this vendor and have no idea whether they still include the probe with “Gizmo 1″ kit. I do know for a fact that their latest “Gizmo 2″ product does not include it.)

SmartProbe is no longer made and at some point will only be available secondhand.


Who is selling devices comparable to SmartProbe ?

AFAIK nobody! Several vendors offer similar products but they do not support plain old GDB interface, and instead require you to buy multi-thousand-$ MS Windows closed shitware — sometimes with a mandatory maintenance contract !


Can anyone help me with sage_pill.py? When I run it, it gets through programming the FPGA, but then dies

This is the correct behaviour. The probe resets itself after it is cured by the pill and your serial connection to it will break.


How do I verify that the pill worked?

screen /dev/ttyACM0
(Or wherever your probe is connected) and hit return key a few times. You will see the string SmartProbe: 3.2_3743 (the last firmware revision released before the manufacturer went out of business.) And your probe will no longer die after N hours of use.


Do you have a pill for the Sage EDK software?

The EDK is rubbish, Java shitware, forget about it; use plain old GDB.


I got GDB working with the probe, but I can’t seem to get the probe to work with the board. If I plug in the probe to the board, the board hangs. If I try to continue I just get a bunch of ffffffs. If I do “monitor run” it says the probe is not connected ?

You plugged the cable into your motherboard backwards!


Help! GDB does strange things instead of working !

You must use version 7.8 of GDB or above, for the probe to work. Earlier versions had problems with the switches between 16, 32, and 64-bit modes of the AMD CPU.


Will Sage SmartProbe work with a PcEngines APU1 computer ?

Yes. Though you will have to solder the debug connector on yourself. (It is a 5 minute job. The header is a metric-spaced one, however, make sure to buy the right kind.)


Will Sage SmartProbe work with the recently-released PcEngines APU2 computer ?

No! on account of AMD’s PSP NSA-mandated Fritz Chip.


Does the Sage SmartProbe work with Intel CPU and motherboard?

No.


Will you help me with Intel’s XDP debugger for Intel CPU and motherboard?

No.


Why did Sage go out of business?

I don’t know. But AMD’s successful campaign of docs-withholding, stonewalling, and Fritz-chipping, to strangle Coreboot — probably did not help Sage’s life expectancy. Sage was a consultancy mainly specializing in Coreboot and custom third-party BIOS work.


Were you affiliated with Sage? Can you put me in touch with ex-Sage people ?

No. And no.


I have questions!

Try asking — politely — here.


Practical Lead to Gold Conversion; or an Intro to Opteron Resurrection.

It so happens that AMD resisted the informal NSA ban on the manufacture of LinuxBIOS-capable x86 CPUs slightly longer than Intel did. Or perhaps they were simply slower to succumb to Microsoft’s Fritz chip decree. Whichever may be the case, vintage (pre-2011, with some caveats, inquire within) AMD Opteron motherboards are a precious and increasingly scarce non-renewable resource. Is it possible to prolong the life of these devices? And when they finally die, to bring them back to life? Turns out, in some cases, the answer is yes!

Our patient today is a Tyan S2915 with nearly 11 years of continuous service. A true champ — but the sad day came: it would not come back up after a scheduled reboot; then, a week later, already staring at the dumpster, it deigned to switch on if “asked nicely”, sporadically. The culprit, in this case, was the same as in nearly every other “smoked” mobo: aluminum electrolytic caps. But which?

One useful fact to remember: wet-electrolytic capacitors age in direct proportion to temperature.

So we take a cheap thermal camera:

And, unsurprisingly, we find a bulging and slightly-leaky electrolytic near the hot (~80C, if running on a desk, 70C or so in well-ventilated case) northbridge:

And another, similarly-sad one near the PCI-E slot where the video card was mounted:

Now, this board is a vintage one, but unfortunately the lead-free solder scam was already in full swing at the time it was made:

And so what would otherwise have been a kindergarten-level repair job — desoldering and replacing two large capacitors — turns into a somewhat tricky and quite time-consuming exercise.

Even setting the iron to its maximum temperature (~250C):

… I found that the solder on the leads would not visibly begin to melt at all !

The melting point of Pb-free solder is considerably higher (how much higher — varies, by particular composition) than of traditional alloys, and a commonplace adjustable soldering iron simply will not work. (And if you were to use a specially-made, hotter iron, you would quite possibly damage the surrounding tracks on the PCB.)

So now let’s try a cheap but effective pill against the Eurocrat idiocy. We take a tube of good, old-fashioned pre-ban leaded solder, some wick, new capacitors:

Now add leaded solder, repeatedly, then wick it away. Again, and again. We end up slowly adding lead to the alloy until the melting point is manageable. It took me four shots of this, per capacitor leg, before either of the two sad caps would budge.

Now it is possible to install the new ones:

And we’re back in business! Here’s to another 11 years, old friend.

Still Tenser, Said the Censor.

Stay classy, YCombinator.

The Care and Feeding of the Sage SmartProbe.

Note: Please read the FAQ!!!

If you cured your Sage SmartProbe of its congenital disease as per the last article on the subject, you may now be wondering what to do with it.

The vendor supplied a massive Java shitware with the thing, which does not merit any discussion whatsoever. Instead, we will use the probe’s very spiffy GDB-compatible interface. Configure your GDB as follows:

gdbinit.txt:

### log all instructions
set logging on
set logging file gdb_out.txt
 
### only if you want to see the raw gdb packets...
#set debug remote 1
 
### if you're debugging the BIOS
set architecture i386
 
### if you are debugging a warmed-up OS
# set architecture i386:x86-64
 
### where the probe is:
target remote /dev/ttyACM0
 
### or, if it is connected to your LAN,
### let's say at 192.168.1.111,
# target remote 192.168.1.111:2159
 
# Show instructions on single-step
set disassemble-next-line on
 
# Disable evil, heretical GAS syntax
#set disassembly-flavor intel
 
### if you want the ncurses gui in gdb
# layout asm

So, for instance, let’s connect to a freshly-booted AMD G-series box spinning in Coreboot’s boot selector menu,

$ gdb --command=gdbinit.txt
GNU gdb (Gentoo 7.8.1 vanilla) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
The target architecture is assumed to be i386
(gdb) si
0x001015ae in ?? ()
=> 0x001015ae:  c3      ret
(gdb)
0x001035a9 in ?? ()
=> 0x001035a9:  29 f0   sub    %esi,%eax
(gdb)
0x001035ab in ?? ()
=> 0x001035ab:  19 fa   sbb    %edi,%edx
(gdb)
0x001035ad in ?? ()
=> 0x001035ad:  39 ea   cmp    %ebp,%edx
(gdb)
0x001035af in ?? ()
=> 0x001035af:  72 f3   jb     0x1035a4
(gdb)
0x001035b1 in ?? ()
=> 0x001035b1:  77 04   ja     0x1035b7
(gdb)
0x001035b3 in ?? ()
=> 0x001035b3:  39 d8   cmp    %ebx,%eax
(gdb)
0x001035b5 in ?? ()
=> 0x001035b5:  72 ed   jb     0x1035a4
(gdb)
0x001035b7 in ?? ()
=> 0x001035b7:  83 c4 0c        add    $0xc,%esp
(gdb)
0x001035ba in ?? ()
=> 0x001035ba:  5b      pop    %ebx
(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x001035b5 in ?? ()
=> 0x001035b5:  72 ed   jb     0x1035a4
(gdb) q
A debugging session is active.
 
        Inferior 1 [Remote target] will be killed.
 
Quit anyway? (y or n) y

I will add that the probe also works great with IDA Pro’s GDB interface. Or whatever other, similar front-end you might fancy.

But! In order to make proper use of the probe, you will need the vendor-specific command set for manipulating the DC power, PCI bus, JTAG chain, and so forth. These were at one point published on the vendor’s site, which has vanished without a trace. I have made a cleaned-up HTML version:

Sage Smartprobe GDB Command Manual.

Note that I have discovered certain undocumented commands. These will be the subject of a later article!

How to Make Your Own Lamport Parachute from Common Household Materials.

The thought began, as many good things begin, in #trilema.

Users of the WOT, of V, and other systems where your cryptographic identity is wholly in your own hands1 live with a certain risk of “cryptographic death” – i.e. the compromise of one’s signing key. A conscientious user of public key crypto might keep the thought of this calamity somewhere in the back of his head, filed right next to “piano falling on my head” and other misfortunes from which there can be no return.

A correctly-generated RSA key is unlikely to be broken via cryptoanalytic means within the owner’s lifetime. But “never say never!” And there is always the possibility of a mass slaughter of keys, a “cryptocalypse”, where the public key cryptosystem of your choice is broken (or, via whatever mathematical advances, weakens, and the cost of deriving your private key from your public key becomes tractably low.)

The popular notion of key revocation is a questionable business because it attempts to impose a political structure onto an uncooperative mathematical reality — in the jargon of #trilema, it is “promisetronic, not protocolic.” Someone who takes possession of your signing key can walk around and befoul your reputation, ‘Who steals my purse steals trash; ’tis something, nothing; ‘Twas mine, ’tis his, and has been slave to thousands; But he that filches from me my good name…’ without regard to time or space – he can sign whatever he likes and attribute it to you. And those who have not received your revocation signal will accept the forgeries as the genuine article. Nothing whatsoever can be done to rescue a compromised signing key. But might it be possible to rescue its owner from WOT death by establishing an unforgeable continuity of identity ?

The answer is: “possibly.” The Bitcoin blockchain2 gives us a very strong mechanism for cryptographic timestamping3 – i.e. the act of certifying, to a skeptical observer, that some particular string of bits had indeed been in existence at a particular point in time. The current state-of-the-art implementation of this concept is called Deedbot, and the reader is invited to become familiar with it. If you make an arrangement with your associates in advance that a certain public key Deedbotted at a certain time is to be regarded as your emergency fallback, you have a kind of “parachute” on which you may conceivably float safely to the ground in the event of your plane’s wings, if you will, breaking off — i.e. a signing key compromise.4

However, the obvious caveat is that the “parachute” keypair must exist at the time of the Deedbotting, and its public key must be, well, public. This can be a problem in the scenario where the cryptosystem itself- e.g., RSA – is publicly broken. The enemy can now do as he pleases with your primary and fallback keys, and you – the cryptographic you – have died a permanent death. And all known public key signature schemes rely on unproven5 number-theoretic conjectures, and may conceivably fall this very night. All except for one…

L. Lamport’s 1979 “one time signature” algorithm rests on no number-theoretic conjecture, but merely on the strength of a collision-resistant hash of the operator’s choosing. On account of certain disadvantages which will soon become apparent to the reader, it is used virtually nowhere. But it so happens that it is entirely perfect for our “parachute” scenario.

A complete and usable implementation of this “Lamport parachute” is presented in this article. It is written in 68 69 lines of Bash and makes use strictly of commonplace userland utilities, such as may be met with on a typical Linux box. This somewhat strange choice of implementation language (it certainly does not shine, for instance, speedwise) is deliberate: the user is expected to understand each individual part, so that the function of the whole becomes unambiguously apparent, like 2+2. As the field of cryptography is slowly reconquered from the Schneiers and other scumbags presently maggoting on top of it, expect this type of didactic presentation to become ordinary practice.

A Lamport public key consists of two lists, let’s call them A and B, of randomly-generated bitstrings that have been hashed with a collision-resistant hash and thereafter published. To make use of such a key, the owner hashes the payload being signed, and for each bit that is equal to 0 in the resulting hash, reveals the original pre-hash string from column A, whereas if it is equal to 1 he reveals a pre-hash string from column B. For reasons which I hope are quite obvious to the alert reader, a Lamport public key is to be made use of only once. And such a key is quite bulky, as is the signature resulting from its use.6

But enough words! It is time for the deeds!

We shall generate7 our Lamport Parachute like this:

lamport_mkpriv.sh

#!/bin/bash
 
if [ $# -lt 2 ]
then
  echo "Usage: ./`basename $0` PAYLOADBITS STRENGTHBITS"
  exit 1
fi
 
for i in $(seq 1 $(($1 * 2))) ; do
    echo `od -N $(($2 / 8)) -An -t x1 -v /dev/random | tr -d " \n"` ;
done | xargs -n 2

All this does is to give us two columns of STRENGTHBITS-sized random integers, times PAYLOADBITS rows.

Specifically:

$ ./lamport_mkpriv.sh 256 512 > privkey.txt

This will create a parachute private key suitable for use with sha256 – i.e. it is able to sign a 256-bit payload. The strength – or length of the random strings – in this example is 512 bits. It is pointlessly suicidal to use a strength value below the output length of your chosen hash algorithm, but otherwise the choice is unconstrained, so long as it byte-aligns.8

Now we would like to generate the corresponding public key:

lamport_priv2pub.sh

#!/bin/bash
 
if [ $# -lt 1 ]
then
  echo "Usage: ./`basename $0` HASHUTIL < PRIVKEY.TXT > PUBKEY.TXT"
  exit 1
fi
 
for x in $(cat) ; do
    echo -n $x | xxd -r -p | $1 | cut -d ' ' -f1 ;
done | xargs -n 2

We simply apply the HASHUTIL of choice to the bitstrings produced by lamport_mkpriv.sh.

And it is done like this:

$ ./lamport_priv2pub.sh sha256sum < privkey.txt > pubkey.txt

Now we have the public key.

If you are generating a “battlefield”9 key, it is now time to consider its intended usage scenario. If the payload of the signature is known in advance – e.g., a “warrant canary”, or some other such thing – you will generate its signature immediately, and the private key may then be destroyed immediately.10

Otherwise the private key is to be retained, shielded stegatronically from prying eyes, and hidden safely far away from your usual places of business or habitation, or other locations liable to be searched by the enemy.

Let’s make a second public/private keypair of the same type:

$ ./lamport_mkpriv.sh 256 512 > another_privkey.txt
$ ./lamport_priv2pub.sh sha256sum < another_privkey.txt > another_pubkey.txt

And now we should like to make use of our Lamport Parachute.

Let’s sign a message:

lamport_encode.sh

#!/bin/bash
 
if [ $# -lt 1 ]
then
  echo "Usage: ./`basename $0` PRIVKEY.TXT < HEXPAYLOAD > ENCODED.TXT"
  exit 1
fi
 
payload=$(cat | tr '[:lower:]' '[:upper:]')
len=$((${#payload} * 4))
bits=$(printf "%*s" $len $(echo "ibase=16;obase=2;$payload" | bc | tr -d '\\\n') | tr ' ' 0)
 
while IFS= read -r p; do
    bit=${bits:0:1};
    bits=${bits:1};
    echo $p | cut -d ' ' -f$(($bit + 1));
done < "$1"

Here we simply iterate over the bits of the payload, choosing the unhashed original private strings from column A or B as discussed earlier.

Remember, we generated a private key that can carry a 256-bit payload. It does not necessarily have to be a hash, but in this example we will take one, e.g.:

$ echo "Attack at dawn." | sha256sum | cut -d ' ' -f1
 
1d6c270d7cc7e82a816ffb7bc3797d213b24d9d17af48f4b3b8d01fb43ed15c3
 
echo "Attack at dawn." | sha256sum | cut -d ' ' -f1 | ./lamport_encode.sh privkey.txt > encoded.txt

And we get a signature.

NOW YOU MUST DESTROY THE PRIVATE KEY! IT SHALL NEVER BE USED AGAIN!

Quite analogously to a Vernam "One Time Pad" -- the re-use of a Lamport private key is cryptographically suicidal.

And now some counterparty, with whom you have taken care to share your parachute's public key, wishes to verify the signature. It happens like this:

lamport_decode.sh

#!/bin/bash
 
if [ $# -lt 2 ]
then
  echo "Usage: ./`basename $0` HASHUTIL PUBKEY.TXT < ENCODED.TXT > HEXPAYLOAD"
  exit 1
fi
 
bits=""
while read -u 3 pkl; do
    if ! read el
    then
        break
    fi
    bits="$bits$(
        case $(echo -n $el | xxd -r -p | $1 | cut -d ' ' -f1) in
            $(echo $pkl | cut -d ' ' -f1)) echo "0" ;;
            $(echo $pkl | cut -d ' ' -f2)) echo "1" ;;
            *) exit 1; break ;;
            esac)"
    if [[ $? == 1 ]]
    then
        echo False >&amp;2;
        exit 1
    fi
done 3< $2
 
padlen=$(od -N 1 /dev/zero | $1 | cut -d ' ' -f1 | tr -d " \n" | wc -c)
printf "%*s\n" $padlen $(echo "ibase=2;obase=10000;$bits" | bc  | tr -d '\\\n' | tr '[:upper:]' '[:lower:]') | tr ' ' 0

Here we simply take each bitstring from an encoded parachute message (the signature) -- hash it with the pre-agreed hashing algo; and determine which column of each respective row of the public key the result is found in. (If the answer is "neither", the decoder terminates and warns us.)

So, for instance:

$ ./lamport_decode.sh sha256sum pubkey.txt < encoded.txt
 
1d6c270d7cc7e82a816ffb7bc3797d213b24d9d17af48f4b3b8d01fb43ed15c3

We have decoded a payload. If we had agreed, in advance, that this payload is the sha256 hash of a document, e.g.:

$ diff < (./lamport_decode.sh sha256sum pubkey.txt < encoded.txt) <(echo "Attack at dawn." | sha256sum | cut -d ' ' -f1)

We are able to verify it.

Now let's try the same, but with the wrong public key:

$ diff < (./lamport_decode.sh sha256sum another_pubkey.txt < encoded.txt) <(echo "Attack at dawn." | sha256sum | cut -d ' ' -f1)
 
False
0a1
> 1d6c270d7cc7e82a816ffb7bc3797d213b24d9d17af48f4b3b8d01fb43ed15c3

Observe that it is possible to make use of any hashing algorithm11 you may happen to like, so long as you have it available as a command-line program.


Epilogue.

A V-genesis for these didactic examples is available12 here; Seal - here..



  1. As opposed to... the other kind. Where your self-appointed masters could impersonate you at their leisure if they so choose. 
  2. There exists, and can exist, precisely one blockchain.
  3. All other cryptographic timestamp schemes currently known rely on a "trusted third party." And a sane user trusts "third parties" no further than he can throw them! 
  4. If it so happens that you learn of your private key having been compromised before the consequences become irreparably grave, you should consider yourself extraordinarily lucky. Just ask, e.g., Admiral Isoroku Yamamoto. 
  5. The "hardness" -- i.e. the amount of computation required to break an RSA key, of whatever length, is unknown. And if your university professor taught you that it is known, or -- more egregiously -- that "it is equivalent to integer-factoring", then he is not merely an ignoramus but a particular kind of liar
  6. There exist certain questionable schemes to somewhat reduce this bulk, but I have deliberately eschewed them in light of the gravity of the task at hand. Good men may well die from your "reasonable" optimizations, your "negligible" losses of strength, loathesome hucksters
  7. Chances are that Lamport key generation, being an entropy-hungry affair, will take an unacceptably long time on your box. The temptation to replace "/dev/random" with "/dev/urandom" will be great. Needless to say that if the key is being generated for battlefield use, such a substitution is impermissible. But if you are following along simply for study, go ahead. Just remember to switch it back before crafting that missile launch key... 
  8. I.e. a multiple of 8. 
  9. I.e. for use in practice. 
  10. Along, if your situation is sufficiently grave to merit this, you will also cremate the very machine used in these operations! 
  11. One interesting tidbit is that public key signatures are only possible if trapdoor functions exist -- see Rompel, 1990. So, today, or 100 years from now, you're stuck choosing a hash algo. 
  12. Strictly under Popescu's License

Phuctored SSH Public Keys.

Phuctored SSH Public Keys to date.

Keys were obtained from a scan of the complete IPv4 space. We have gone approximately 20% of the way through the data set at the time of this writing.

Click on the IP addresses to view a key in Phuctor, or on the SSH hello string to view pertinent discussions.

A snapshot of ALL Phuctored keys at the time of writing can be viewed here, if the main site is slow under load.

(Feel free to ask questions !)


IP SSH Hello SSL Hello

112.16.4.21

SSH-1.99-Comware-5.20

112.16.65.245

112.16.65.247

112.16.95.66

SSH-1.99-RGOS_SSH_1.0

177.234.0.97

SSH-1.99-HUAWEI-1.5

177.234.11.229

SSH-1.99-HUAWEI-1.5

177.234.13.179

SSH-1.99-DOPRA-1.5

177.234.13.241

SSH-1.99-HUAWEI-1.5

177.234.15.27

177.234.1.73

SSH-1.99-HUAWEI-1.5

177.234.1.91

SSH-1.99-DOPRA-1.5

177.234.4.97

SSH-1.99-HUAWEI-1.5

177.234.6.21

SSH-1.99-HUAWEI-1.5

177.234.9.13

SSH-1.99-HUAWEI-1.5

183.246.69.24

SSH-1.99-Comware-5.20

187.188.126.28

187.72.155.221

SSH-2.0-AudioCodes
subject=/CN=ACL_3353352

187.72.216.78

SSH-2.0-AudioCodes
subject=/CN=ACL_3353177

189.112.138.254

189.203.181.149

SSH-1.99-DOPRA-1.5

189.203.181.7

SSH-1.99-DOPRA-1.5

189.203.72.147

SSH-1.99-DOPRA-1.5

190.39.56.107

197.221.61.38

SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4

197.221.63.150

200.146.242.241

SSH-2.0-AudioCodes
subject=/CN=ACL_3348823

201.101.37.44

SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2

201.16.189.38

201.249.207.150

SSH-1.99-HUAWEI-1.5
subject=/name=AR157-Self-Signed-Certificate-210235384810E4001320

202.166.221.118

2.116.209.1

SSH-1.99-DOPRA-1.5

217.57.196.177

SSH-1.99-DOPRA-1.5

217.57.196.179

SSH-1.99-DOPRA-1.5

223.94.78.217

SSH-1.99-Comware-5.20

59.21.182.242

SSH-2.0-OpenSSH_5.9
subject=/C=US/ST=California/L=Sunnyvale/O=Aerohive/OU=Default/CN=HiveAP

66.233.213.117

SSH-2.0-OpenSSH_5.2

68.14.242.210

SSH-2.0-OpenSSH_6.6
subject=/C=US/ST=Florida/L=Orlando/O=Creative Manager – AZ Office/CN=gnatbox.creative-manager.com/emailAddress=support@iccsllc.com

71.39.252.162

74.45.0.60

SSH-2.0-OpenSSH_4.1
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.228.159

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.228.160

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.228.49

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.228.86

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.228.97

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.229.217

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.231.125

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.231.136

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

74.45.231.156

SSH-2.0-OpenSSH_5.2
subject=/C=US/ST=California/L=Sunnyvale/O=Tropos Networks/OU=Manufacturing/CN=Tropos Router/emailAddress=support@tropos.com

78.188.162.184

SSH-2.0-ROSSSH

85.14.248.152

SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u3

85.218.41.103

SSH-2.0-OpenSSH_5.9
subject=/C=US/ST=California/L=Sunnyvale/O=Aerohive/OU=Default/CN=HiveAP

91.229.251.116

SSH-2.0-ROSSSH

94.141.150.121

SSH-2.0-ROSSSH

96.24.7.172

SSH-2.0-OpenSSH_5.2

On the Matter of Brian Krebs.

The WWW of Brian Krebs, perhaps the second-most-worshiped1 patron saint to all English-speaking “computer security” charlatans — is sitting sadly offline today on account of a ~TB/sec DDOS flood.2

His titanic bandwidth, it turns out, was provided gratis by Akamai – spamatronicists par excellence and industrial-scale enablers of everything that makes the modern-day WWW a rancid sewer. Until it wasn’t. As soon Krebs began to cost them serious coin, he was dropped like a discarded candy wrapper.

And I’m expected, apparently, to see the misadventures of Krebs as a lamentable thing. But I do not — and am quite ready to explain why not to the patient and curious reader.

Krebs is renowned for his investigations of “cybercrime”, which in his eyes consists of Russian (for some… reason – almost exclusively Russian) spammers, malware artists, and “carders”.

Now, spam as we know it exists largely for two purposes: to mooch, by various means, from the great gas giants of advertising-crapolade, e.g., Google; and to spread malware. The latter exists mainly to facilitate “carding.” 3

And if we listen to Krebs and his ilk, we might believe that these problems are problems because there is a faraway country, full of evil untermenschen, who like nothing more than to steal the last penny from every honest American Joe, and to pollute his Precious Bodily Fluids. And who decided that the best way to do this is to write virii and send spam.

And Krebs would also have us believe that the pill against such headaches is to make a pompous WWW site, with many flow charts, containing some names of especially-uppity untermenschen who are then to be kidnapped by NATO gauleiters and shipped, bound and gagged, to American prisons..

Now apparently, if we listen to Krebs et al., writing virii is a “cybercrime” — but forcefeeding Microsoft’s sorry excuse for an operating system to the ~entire planet, for decades, somehow is not.

And stealing credit card numbers is a “cybercrime” — but forcing people to use a financial system where someone can drain your account by learning a constant string, printed in plain text4 on a piece of plastic in your pocket, somehow is not.

And guess what else – distributing amateur-hour “spyware” is a “cybercrime” — but artfully sabotaging open source software somehow is not. When you’re the NSA.

Because it is not about “crime”. It is about the hegemony of a particular set of crowned criminals whom Krebs shills for.

When I wrote to Krebs regarding the Mahmood Khadeer bombshell – the most recent and spectacular of a series of discoveries proving the existence, in the wild, of sabotaged PGP clients – there was no response.

Which, in retrospect, ought to have been no sort of surprise. Because the mass5 sabotage of RSA implementations was not a crime authored by any criminal Krebs is interested in prosecuting, but by his beloved masters. Who hung him out to dry today. “The world’s smallest violin plays.”


Edit:

The next day, Krebs was taken under the wing of Google’s “Project Shield”:

Project Shield welcomes applications from websites serving news, human rights, or elections monitoring content. We do not provide service to other types of content, including gaming, businesses, or individual blogs. See our User Content and Conduct Policy for more details.

Say hello to The Internet of the Future! Where USG shills are hosted on an “infrastructural”, one-way TV-style “Internet”, and everybody else gets to inhabit the remains of the old, DDOSable kind.


  1. After Schneier, of course. 
  2. The DDOS-enabling design of the Internet as we know it is no accident.
  3. “Carding” is a crime which happens at the pleasure of certain banks, who profit handsomely from it. This is not an especially well-kept secret. 
  4. Public-key cryptography has been around for quite a while. 
  5. We’ve found, one can surmise, only the tip of the Birthday Theorem iceberg thus far. 

A Complete Pill for the Sage SmartProbe.

Note: Please read the FAQ!!!

The Sage SmartProbe was a very spiffy “Hard ICE” debugger, one of the few ever manufactured for use with modern (2010s) AMD x86-64 processors, and – as far as I’m aware – the only one ever sold on the mass market, rather than as part of “favourite son” deals (as, e.g., Intel’s, and Arium’s similar products were, and perhaps still are.)

Probe (right hand side) and "GizmoBoard" AMD G-series motherboard (left hand side.)

Quite a few of these things ended up bundled with various dev boards, saddled with time-limited demo expiration (yes, a time-limited hardware peripheral! don’t ask me…) The vendor perma-re-enabled an expired probe for a small fee.

Sage Eng. LLC, it appears, is long dead. Leaving no trace! How and why it died is unknown to me.

So now, instead of being unique tools in the development of, e.g., Coreboot, or whatever other attempts at sane utilization of x86-64 iron, the demo probes are stuck in limbo, working as so many peculiar paperweights.

This is a crying shame. Now you cannot unbrick the expired probes for any price. (At least not by buying the magic code from the original maker…)

So, without further delay, let us get one of these patients onto the operating table:

JTAG Test Points. (Click for full size.)

JTAG Test Points. (Click for full size.)

Now you could connect the thing to your favourite OpenOCD-compatible JTAG probe, and play around with the internals. E.g., this GDB script will give you an instruction trace. There are many interesting things to be learned, re: the command set (most of which is GDB-compatible, but there are a few interesting sharp edges.)


Or you could skip straight to the pill:

sage_pill.py
(SHA256: 2f9ce44fe069705a7ee83c0f4c733a6a0cc374613429c5c1f47a8481aa464b60)

sage_last_public_fw.tar.gz
(SHA256: 30c005febfbff531a2b9d06ef8c2c41fedb2c8993a2992a373fbeb66900fbaf8)

1) Download the pill and the fw image.
2) Check the SHA256 sums.
3) Unpack the firmware image.
4) Plug in the probe.
5) ./sage_pill.py sage_last_public_fw.bin /dev/ttyACM0

You may have ended up with some device other than ttyACM0 when you plugged it in. Find out which.
The script will need to run with sufficient privileges to talk to the “modem”.
It will ask for a final confirmation prior to firing.

6) Enjoy a 100% working x86-64 “Hard ICE”.


This article is continued here.

Tears of the Phucked.

Grumman Hellcat.

Grumman Hellcat.

Phuctor – rewritten and revved up on new hardware in April – is presently eating SSH RSA keys from a scan of the complete IPv4 space.

And, on occasion, breaking some.

And generating other laughs as well.  In today’s server logs:

134.223.116.158 - - [22/Jul/2016:15:54:57 +0000] "GET /gpgkey/50840391E5677882196999C9AE77F3177E6CBF8D35FB4F1FEF848CFADF9088B1 HTTP/1.1" 200 3425 "http://134.223.116.149:15871/cgi-bin/blockpage.cgi?ws-session=2010817170 "

What’s that? A ‘Websense’ censortron control panel, apparently.

Who might it belong to ? Could it be:

Isn’t it just a little bit too late for this nonsense? Plus, your monkemployees can still read the page when they clock out and go home. Or on their phones, in the toilets, etc.  Why bother with this nonsense ? Phuctor isn’t even a ‘wikileak’ or the like, it is merely one of the public whipping posts to which you have been tied, by your own hands, long ago.

Terraforming the “MyCloud Mini” : TTY.

“MyCloud Mini” is a ~$50, dual-core ARM, 256M RAM, 256M Flash, dual SATA box, in various respects similar to the famous PogoPlug.

Use a standard (e.g., CP1202) TTL converter. And you will get:

Stage-1 Bootloader    1  28 10:36:29 CST 2011
Attempting to set PLLA to 750MHz ...
  plla_ctrl0 : 0x0000000A
  plla_ctrl1 : 0x000F0000
  plla_ctrl2 : 0x001D01A0
  plla_ctrl3 : 0x00000017
PLLA Set
 
Setup memory, testing, Image 0
  Hdr len: 0x0001AC3C
  Hdr CRC: 0xB931AD17
 OK
 
U-Boot 1.1.2 (Oct 28 2011 - 10:44:29)
 
U-Boot code: 60D00000 -&gt; 60D1AC3C  BSS: -&gt; 60D1F2F4
RAM Configuration:
        Bank #0: 60000000 256 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:256 MiB
*** Warning - bad CRC, using default environment
 
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Reading upgrade flag from NAND address 0x01ec0000 : 0
Hit any key to stop autoboot:  0
$
Posted in: Bitcoin, Cold Air, Hardware, NonLoper by Stanislav 2 Comments