Common pins

Setting up windwos insider/developer after seeing they apparently have and integrated bash version (actually seems to be an integrated linux/posix cygwin/mingw, but I’m still jumping through hoops) and thus, for starters, setting up the annoying non-local password/pin login. Picking a pin, it immediately complained that “1234” is too common (which it is, but if anyone gets physical hardware access it’s game over – nothing about my setup is hardened enough to deal with that).

Now “too common” is a strange kind of concept when it comes to four-digit pins. By computer security standards, they’re almost always all too common – even a four letters/digits/special characters password (more than six thousand times as hard to guess) isn’t enough. That doesn’t mean PINs are bad – falling back to password after three guesses (and the device you guess on not being available by the thousands) they’re fairly reasonable. But it’s hard to mentally downshift into “which ones are extra special *more* common”.

So what, in their wisdom, did Microsoft pick? They tell you up front that “one repeated digit” and “only sequential” are out. So 0000, 1111, 2222.. and 1234, 2345, 3456.. Based on pure personal “what would be my next most obvious” I guessed 1357 – like 1234 but two steps between digits. That, too, was excluded. So was the same backwards. Trying a few more 0001 was ok, and so was 0101, 0102. So it appears “sequential” and “repeating” only counts at single digits and all digits. Attempting to extend 1357, further 2468, 3579.. aren’t allowed as well. In the “by twos, by threes..” direction, they also do not allow 1470 either. Nor 0741. Here, I feel like I’m starting to see numbers most people would have a hard time considering “so obvious” and I test a few on my wife to see if she judges them “clearly a pattern”, which she doesn’t. Each digit increasing by 4 doesn’t fit, but perhaps wrapping around at 10? Indeed wraparounds, 1593, 2604.. count as common.

So that’s large enough to be a hard-to-visualize number set, and it’s time to look at them programatically. Calling the first digit n and the step to next digit k, python would call that ( (n+k*0)%10, (n+k*1)%10, (n+k*2)%10, (n+k*3)%10)) ) i.e. start digit plus ( offset times position ) modula ten, four of them. n, the starting digit, can apparently be any of the ten (0-9, range(10) in python). Offset.. well, we can count 0 as “repeating” (1111, n=1, k=0). k=9 is the same as -1 (we live in mod 10 because of the wraparound, so 5+8->14->4) but that is in fact included too, so.. k is also the full set, 0-9. Expressed as a list, [((n+k*0)%10, (n+k*1)%10, (n+k*2)%10, (n+k*3)%10) for n in range(10) for k in range(10)].

[(0, 0, 0, 0), (0, 1, 2, 3), (0, 2, 4, 6), (0, 3, 6, 9), (0, 4, 8, 2), (0, 5, 0, 5), (0, 6, 2, 8), (0, 7, 4, 1), (0, 8, 6, 4), (0, 9, 8, 7), (1, 1, 1, 1), (1, 2, 3, 4), (1, 3, 5, 7), (1, 4, 7, 0), (1, 5, 9, 3), (1, 6, 1, 6), (1, 7, 3, 9), (1, 8, 5, 2), (1, 9, 7, 5), (1, 0, 9, 8), (2, 2, 2, 2), (2, 3, 4, 5), (2, 4, 6, 8), (2, 5, 8, 1), (2, 6, 0, 4), (2, 7, 2, 7), (2, 8, 4, 0), (2, 9, 6, 3), (2, 0, 8, 6), (2, 1, 0, 9), (3, 3, 3, 3), (3, 4, 5, 6), (3, 5, 7, 9), (3, 6, 9, 2), (3, 7, 1, 5), (3, 8, 3, 8), (3, 9, 5, 1), (3, 0, 7, 4), (3, 1, 9, 7), (3, 2, 1, 0), (4, 4, 4, 4), (4, 5, 6, 7), (4, 6, 8, 0), (4, 7, 0, 3), (4, 8, 2, 6), (4, 9, 4, 9), (4, 0, 6, 2), (4, 1, 8, 5), (4, 2, 0, 8), (4, 3, 2, 1), (5, 5, 5, 5), (5, 6, 7, 8), (5, 7, 9, 1), (5, 8, 1, 4), (5, 9, 3, 7), (5, 0, 5, 0), (5, 1, 7, 3), (5, 2, 9, 6), (5, 3, 1, 9), (5, 4, 3, 2), (6, 6, 6, 6), (6, 7, 8, 9), (6, 8, 0, 2), (6, 9, 2, 5), (6, 0, 4, 8), (6, 1, 6, 1), (6, 2, 8, 4), (6, 3, 0, 7), (6, 4, 2, 0), (6, 5, 4, 3), (7, 7, 7, 7), (7, 8, 9, 0), (7, 9, 1, 3), (7, 0, 3, 6), (7, 1, 5, 9), (7, 2, 7, 2), (7, 3, 9, 5), (7, 4, 1, 8), (7, 5, 3, 1), (7, 6, 5, 4), (8, 8, 8, 8), (8, 9, 0, 1), (8, 0, 2, 4), (8, 1, 4, 7), (8, 2, 6, 0), (8, 3, 8, 3), (8, 4, 0, 6), (8, 5, 2, 9), (8, 6, 4, 2), (8, 7, 6, 5), (9, 9, 9, 9), (9, 0, 1, 2), (9, 1, 3, 5), (9, 2, 5, 8), (9, 3, 7, 1), (9, 4, 9, 4), (9, 5, 1, 7), (9, 6, 3, 0), (9, 7, 5, 3), (9, 8, 7, 6)]

Bam.. Ok, not very readable, lets throw in “%d%d%d%d”%( expression ) so it collapses into strings, like [“%d%d%d%d”%((n+k*0)%10, (n+k*1)%10, (n+k*2)%10, (n+k*3)%10) for n in range(10) for k in range(10)]

[‘0000’, ‘0123’, ‘0246’, ‘0369’, ‘0482’, ‘0505’, ‘0628’, ‘0741’, ‘0864’, ‘0987’, ‘1111’, ‘1234’, ‘1357’, ‘1470’, ‘1593’, ‘1616’, ‘1739’, ‘1852’, ‘1975’, ‘1098’, ‘2222’, ‘2345’, ‘2468’, ‘2581’, ‘2604’, ‘2727’, ‘2840’, ‘2963’, ‘2086’, ‘2109’, ‘3333’, ‘3456’, ‘3579’, ‘3692’, ‘3715’, ‘3838’, ‘3951’, ‘3074’, ‘3197’, ‘3210’, ‘4444’, ‘4567’, ‘4680’, ‘4703’, ‘4826’, ‘4949’, ‘4062’, ‘4185’, ‘4208’, ‘4321’, ‘5555’, ‘5678’, ‘5791’, ‘5814’, ‘5937’, ‘5050’, ‘5173’, ‘5296’, ‘5319’, ‘5432’, ‘6666’, ‘6789’, ‘6802’, ‘6925’, ‘6048’, ‘6161’, ‘6284’, ‘6307’, ‘6420’, ‘6543’, ‘7777’, ‘7890’, ‘7913’, ‘7036’, ‘7159’, ‘7272’, ‘7395’, ‘7418’, ‘7531’, ‘7654’, ‘8888’, ‘8901’, ‘8024’, ‘8147’, ‘8260’, ‘8383’, ‘8406’, ‘8529’, ‘8642’, ‘8765’, ‘9999’, ‘9012’, ‘9135’, ‘9258’, ‘9371’, ‘9494’, ‘9517’, ‘9630’, ‘9753’, ‘9876’]

Looking at it, it can’t repeat (second digit is always one of ten offset from first, first changes only after all second have been tried) and they are in numerical order (we exhaust the each “lowest left” digit, and do so picking the “lowest left” next digit). We can even tell how many there are – 10 first digits w/ 10 permutation options each = 100 – exactly 1% of the total keyspace. Quite elegant.

I’m not 100% sure this is their thinking, but these are indeed excluded, and I can’t find any other “common numbers” being excluded (even though some might say “1000” is more obvious than “7036”). Feel free to show me wrong – I’d actually be intereted :-).

Vivitar Bluetooth Headphones

So these went from checkout impulse item to clearance item. It seems the wave of bluetooth headphones that materialized in a hurry when the iPhones lost the 3.5mm audio plug got a little optimistic – sure, others would launch too, but everyone?

So since they’re in the $5 vicinity, I figured I’d see if perhaps the bluetooth could be hooked up differently. I want to remote control some arduinos. Sure, they sell bluetooth modules, as well as regular RF modules. But I also like opening things, and they’re not that expensive. So I went with it.

The actual device wasn’t so well stuck together. The rubber plugs on the end did hold it a little, but really, people aren’t nice to headphones. Then again, I’m sure it snaps back together well too, so..

Bright LEDs, one blue, one read. Single button, long press to pair, longer to turn off. The insides is pretty predictable – a mass integrated IC, onboard antenna, button, mic.. Nice caps on the ear output. In fact, it looks surprisingly well built. The cords are those “set silicon gel” with what looks like bare wires inside, but which is really varnished wire. It’s thicker than usual though, not like the olden days of audio wire, but not the thinnest humanly possible either. Little postage stamp size Li-ion claimin 70 mAh, which sounds sane. USB micro B.

Peeling off the battery (double stick tape, stuck enough to stay, but not so you start wondering if you’ll crack the battery) there’s a smattering of test pads and a board label, “SH820_BK3254(32pin)_V1.1 2016-09-18”. I’ve desoldered the earbuds for now, again noticing they were actually soldered on with enough solder. Nothing overkill, but this is something that’s usually woefully underkill unless it’s $50-$100-$934,383 “good audio” stuff.

Flipping it over, the IC claims to be a Beken BK3254QN320 CS6324CD. Given the last label, I’m guessing BK3254 for short. The crystal is a 26.00 MHz – slight cause for hope there’s a general purpose CPU here, but perhaps Bluetooth RF needs it for something.

So heading over to BekenCorps page, they do list it. “Highly integrated multimedia device” – yeah, ok, we’ll see – “BT transceiver, FM reciever (!), 1 or 4 wire SD-Card Interface (!!),  USB OTG (!!!) and high performance audio”. Ok, I saw.. Also onboard Vreg, Bluetooth 4.1, what I think are good RF and audio numbers, high signal to noise ratio ADC and DAC, I2C, SPI, UART, all the good BT audio protocols. Clinking around further, they’re sold on alibaba and ebay, and seem to also contain an IR remote module, six switches on individual GPIOs, ability to use anything as a GPIO. Possibly a DSP doing noise cancel or voice recognition – there are a lot of near models. Either way, this really is a “whatever you want” device, with everything that isn’t just plain headphones disabled. It even seems to have separately operating TX/RX BT so that it can set up mesh nets with more of itself. Very neat stuff.

But for all the bragging, I’m not seeing any dev kits. Just reference designs and very broad strokes descriptions. It’s also said to have an AT-command API on the UART interface. Digging around a few Russian hobby board and Chinese trade boards, it appears to be a drop-in pin-compatible option for Cambridge Silicon Radios CS8xxx line (or, possibly, a blatant Shenzen pirate version – depends on whom you ask – but in their defense Beken doesn’t pretend it isn’t compatible nor try to pass it as an actual CSR). What appears to be a near model here (Russian language) a hop away from an even closer model throws out a few names, like Casira Bluelab SDK, and some document names. Chinese boards mention that you’ll find the tools when you start looking for nearby models, and they’ll work mostly across all. Beken has a download page, but it’s passworded (and an ftp). Much of the surrounding forums and blogs seem to be too, usually at least signup, possibly “talk to your sales rep”, and almost always in Mandarin (or almost purely marketing). CSR, it turns out, has been bought by QualComm. Both have support areas, but again kind of keep it marketing unless you’re willing to show you’re a customer. Eventually I sign up at CSR, not claiming to be anything I’m not, but providing a business email address (per request) and phone/address. The modules I see on eBay actually look pretty tempting, if and only if there’s software, so.. really I kind of *am* looking for a rep. Either way, I find a toolkit, BlueSuite 3. No SDK as such, but a flash tool, several settings tools, clients, etc. They work, in fact they connect over the USB port that’s already there – very polite, usually they demand UART/I2C/SPI/whatnot and a lot of boards talk about how to get that up and running with an LPT port or a homebrew USB->SPI/I2C. It does seem that there is no onboard flash on this particular version, although it seems able to boot off an I2C eeprom if connected, and also seems to do flashing for that (fw updates, debugging, etc). Would have been nicer if it wasn’t BYO, but hey, this is still a lot of stuff I didn’t think would be here. Conflicting reports on the CPU (though it is there), but seems like an ARM/STP of some kind. Hopefully I’ll find more later.

One of the included clients connects directly as a console (to, it turns out, a COM presented by the USB device, \\.\csr0) that keeps saying “unknown command” at everything. I find a few one letters, like ‘r’ does a reset, “ar” blurts our “syntax: authentication_requested [ch]”. After some manual hunt and peck, I wrote a small python script that connects to it and tries all two letter combinations. I somehow manage to lose the notes on the *one* letter combinations, but hey.. Here’s a few so far:

“ar”, ‘syntax: authentication_requested [ch]’
“br”, ‘syntax: br t:lsa|mssp s:d|e|…’
“db”, ‘syntax: db Debug output disabled’
“ef”, ‘syntax: enhanced_flush ch pkt_type’
“fs”, ‘syntax: flow_specification ch f fd:o|i st:nt|be|g tr tbs pb al’
“hm”, ‘syntax: hold_mode ch hmmaxi [hmmini]’
“lt”, ‘syntax: lt ch tid:m|s o:… [n]* // lt ch [octet]+’
“pm”, ‘syntax: park_mode ch bmaxi [bmini]’
“qs”, ‘syntax: qos_setup ch f st:nt|be|g tr pb l dv’
“rc”, ‘syntax: read_clock ch wc:l|r’
“rd”, ‘syntax: role_discovery [ch]’
“rr”, ‘syntax: read_rssi [ch]’
“rt”, ‘syntax: rt rt:… [a1 [a2 [a3]]] (see rtfind)’
“sb”, ‘syntax: sb clk’
“sm”, ‘syntax: sniff_mode ch smaxi [smini] sa st’
“sr”, ‘syntax: switch_role ba r:m|s’
“tp”, ‘syntax: truncated_page ba // truncated_page ba psrm:r0|r1|r2 clock_offset’
“d”, “syntax: disconnect (defaults: last user_ended_connection) // disconnect ch
// disconnect ch r:uec|lr|atpo|af|urf|ukns”

Some commands cut the echo, or otherwise change behavior of later commands, so it’s not perfect. Still in the process of organizing it more. Will return! Good times, :-)

It’s the end of the world (of log2 scaling circuits)

A few years ago, I noted that Moores law (transistor density on chips double every 18 months) has expired outside of a looser definition, and that’s about to end as well. So.. now it has. Graphic processors, general purpose massively parallel processors, and DSPs indeed bravely held the torch for a moment, and are still all the rage as we (at last, kicking and screaming) adapt code to occur not just in a few neatly organized threads, but in huge bazooka blasts of thousands to millions of simultaneous actions. The value of accomplishing more with fewer instructions is fading, and it’s becoming more about figuring out how to flatten out an action into as many small things that can occur at the same time. Often by doing a lot that ends up nowhere, just in case – go ahead and start preparing what the intricate 3d view in front of you before checking if there’s a sold colored wall in front of it, because hey, by the time that’s determined, it’s too late. Start processing what you’ll do if the voice activation detects “Yes” and also “No” and “Cancel”. Wasteful? Well, certainly explore other options, but really, during the next 1/800 sec cycle, processor-days of calculations can happen – the only option is to idle. Of course you’d rather put them toward a solid goal you’ll have defined in a few seconds, but they’ll be there then too. There is, quite literally, more power than we can figure out what to do with.

Of course we *can* idle and save power. That’s useful too. And we can throw raw power at stuff. Try every conceivable angle, not just one or two we have time for. Throw in some AIs, boy do they gobble up calculations by the trillions. It’s a good problem to have, and thanks to Moore, we’re used to having it. But, now that we double every four years, down from the earlier two.. things are about to change again.

CMOS isn’t quite hitting battling physics yet, but another five years will take care of that. We can layer harder, fight the cooling issues. But after that, I think we’re about to shift toward the less physical again. Everything used to be about physical action, movement, but then software completely dominated as a way to steer that. Which relied on hardware upping the ante. The next phase will be to take a deep breath and figure out what we actually have here, and how to organize it, at scale. We kind of quit optimizing things that weren’t at the very lowest levels, because there ceased to be much of a point – hardware is fast and cheap – and then it became downright counterproductive. Elegant, fast code doesn’t scale, nor can you trivially apply it to everything the way you can with hardware. It’s hard to maintain, it breaks, and it becomes unwieldy at more than a linear pace. Keep it modular, dot all the i and cross the ts and then dot the ts and cross the is because you can always buy faster hardware, but you can’t buy fixing fragile design.

Well, you’re about to not be able to buy faster hardware either, so buying tighter design is going to start being hip again. Hardware already did that. If you open old devices, they’re very modular. Lots of components, nice and neat, easy to reuse. There’s even little squares of PCB lines off for each little module (so cute!). Now, there’s a half dozen ICs, if that. The speed of light is constant, power input is only sort of scaling.. you can’t split ram, cpu, LED driver, RF receiver, and so on into their own parts, now matter how neat it looks. You can barely even segment them in their own parts of the actual silicon wafer (still cute!). It all needs to meld, and post-68000 (late 80s early 90s) it’s all machine optimized – no more scatterbrained humans who can’t keep track of a billion parts at once.

That’s what is going to have to start happening to software. It’s already scaled past humans for the most part – we compile compilers inside virtual machines inside frameworks – but we’ve been attacking staleability more than efficiency. Well, and occasionally security – just like hardware stacks obfuscations and blocks and self-destructs, software does too. Skype was probably the first high-value target that somehow just won’t reverse engineer. It should, you’d imagine – it’s not a hardware lock – but it isn’t, because software can be treated a lot like hardware. Googles recaptcha is another round. I reversed the first layer (just plain obfuscation – “badly” written code that’s hard to follow) and it turns out it’s a virtual machine. Inside Javascript. With like 50-60 opcodes, all.. strange choices – they do several things at once, kind of like DSP assembler. Then it loaded itself with software (written in said opcodes) and branched to itself. And.. immediately started modifying what the opcodes do. Adding a few, killing off a few, swapping around.. They were very polite – left a little “attaboy” easter egg to congratulate arrivals on making it there, but they didn’t have to say it – *burn*. It’s pretty clear they’re compiling something on their end into this, so their compiler can “unoptimize” all the way, and be self modifying, generating variations of this monstrosity on the fly.

That, I think, is the kind of talent we’ll be aiming at less cloak-and-dagger goals, like optimizing away the separations, but without sacrificing stability.

Or, yaknow, perhaps they invent something better than CMOS, or turn these newly fanged AIs onto writing better AIs and start the singularity. Either way.

Angle approximator

Sometimes, you need to something to be a particular angle. And sometimes, it’s not something that leads itself to using a protractor, so perhaps you measure out some distances that construct it. Like if you’re in Egypt and it’s five thousand years ago, perhaps you measure out a 3 and a 4, then tilt them until there is 5 between them, and you have a right angle.

Or if you’re me and it’s now, you have lots of right angles, and measure r*cos(a) and r*sin(a) along each direction, and you get angle “a”. But what’s a good r? It’s arbitrary, but since I’m not at all building a pyramid, something that makes both sides kinda even would be cool.

So after writing little snipplets to find one, I made an angle approximator:

Just Almost

It’ll take an angle, either entered in the field or by clicking on the little angle graphic, and provide two distance that will (as Pythagorean triangle or any other right angle) produce roughly that angle. It’ll show the best with the starting distance below 10, below 100 and below 1000 (since units are arbitrary, this could be inches, yards, millimeters, whatever, so it’s more about precision). Sometimes the <100 and/or <1000 will repeat one or both of the lower – that means the former level still stands as the best approximation. As a side effect, it’ll also catch exact solutions to some (such as 45 degrees – it’ll suggest 1 in each direction, and stick to it at all scales since 2/2, 34/34, etc will all be exact – two equal sides at a right angle makes a 45 degree angle). It’s not the most useful thing ever, and could be made better by allowing similar suggestions for other things (like slope, or a pre-measured shape, or something) but this is as far as I got before I didn’t really need it again just now.

2D Deltabot

3D Delta bots are very cool. They do pick and place, assembly, platform stabilization/movement, and a ton of things that they aren’t the best design for really. Looking at them, you even get the feeling that you could probably build one. And perhaps you could, but I demonstratively can’t, at least not without using components that aren’t from the crash pile or under a dollar on ebay/alibaba.closeup of a wire/posterboard wrist/knuckle

So after several rounds of totally not building one, I was sketching a little on what the movement would work like on a working one. It turns out that’s also not as cut and dry as I imagined, or perhaps my geometry is a little rusty. To get a bit more of a grip on things, I sketched at an equivalent two-dimensional version – just moving two arms (along a line or through rotating one end) connected to two more, connected to each other. That was still not that trivial, but much easier and should translate into 3d. But then I realized that *building* one would be cool. Not 3d cool, but still cool, and actually sort of skill-appropriate. So I sketched more, trying to figure out the sizing on the arms, and then I wrote up a slightly dirty html5 page to emulate them.

2D Delta Bot simulation

Quick control explanation: top sliders rotate the arms. The four fields are limits on how far they can rotate (click Apply limits and it’ll be pretty obvious). “Draw reachable” colors in the area your contraption can reach within the limits (it’s a on-off thing, starting and stopping continually drawing it, should really be a checkbox). “Sweep” runs it around arbitrarily a bit, drawing a line.
The ‘D’ slider changes distance between the fixed points. The s1/s2 adjusts the length of the two segments. These are the real adjustments of the operation in terms of changing what you can reach and how precisely.
middle bend + tiny servo

I’m planning on driving it with servos (to start), so range of motion for each leg will be around 180 degrees. It’s beneficial to use the whole range, since each “click” along is a long (or as angular) as it is, so mapping more of them to more of the end result is better. It’s also good if it doesn’t pull itself apart, slam into itself, or anything like that. Again, less intuitive than it seems. Eventually, decided on some tentative proportions. I went with 80 and 160 long arm segments, 150 apart. With  the limits -50 deg – 130 deg / 50 deg – 230 deg, but given the arbitrary origin that doesn’t mean much besides 180 degree range – to be determined on non-sim design.

Posterboard and wireAnd here is the meatspace implementation. I decided to consider.. whatever the units that look like pixels but are probably some kind of ninja browser unit.. to be mm in this version. It’s built from posterboard (97c/giant multi-sqare ft), copper wire (reused from junk) and two towerpro sg90 servos . If you don’t recognize them right off, they’re the standard “cheapest china could muster”, around $1.9-$2.1 each in 5-10 packs. They’re very strong, precise, and all around backing up their cost, but a big part of that is being half to price of anything even pretending to be decent quality. None the less, good experimenters. The speed here is my software walking it around randomly and gently – it can swipe the full 180 deg in half a second.

Well, about that.. there’s no positioning around the dial opening up a full 180 without slamming into each other or folding back over itself. I considered the connection points to be the “measure to” place, and was perhaps a little off on the side to side thing. High tolerances too. Either way, it works, but with range limited to around 60 degrees.

It’s controlled by and arduino nano knockoff (I’m sure the real deal would be ok). The only connections, despite the looks of it, is pin 9->signal (orange) on servo 1, pin 10->signal servo2, both reds to +5, both blacks to GND. USB to PC. It’s very rudimentary so far, but here’s a near-nothing sketch:

It was written using the online editor (for no real reason) and is really just the servo library, as demoed in their examples and not much else. I still need to get a more controlled drive with a purpose going. The html5 browser sim is arguably more interesting in terms of software, though it’s pretty simple too. Perhaps I’ll write up the geometry a little better when I get to it. If it advances to something more, it may be going on

looks like a lot of wires, but it's mostly from having too few f-f and m-m ones - it's just pin9-10 -> servo1-2 orange, servo1-2 red/black -> +5/ground

looks like a lot of wires, but it’s mostly from having too few f-f and m-m ones – it’s just pin9-10 -> servo1-2 orange, servo1-2 red/black -> +5/ground. I put two bolts through it, mostly because the breadboard is a bit big and has two bolt holes in it right there..

Some slightly messy notes re: todays JAR report release

This could and should probably be more organized. The report (here first goes over what attack vectors were used in very general terms. Nothing particularly surprising. It then dumps, tersely but importantly, a fat list of what current and historic groups, operations, and malwares are involved, directly or though being otherwise linked. This isn’t really *that* much more than just saying “It’s Fancy/Cozy Bear, aka Advanced Persistent Threat 28 and 29”, but despite being mostly a list of names and aliases, it gives a pretty good chain-of-proof in terms of linking up why, exactly, APT28/29 would be the aggressor here, and why it couldn’t really be anyone else. It’s kind of hard to get around except by claiming the specifics about these intrusions aren’t true, which is sort of possible – there isn’t much released about it nor, really, could there be, since it’d be little snipplets of access logs that can’t really be verified.

So while parsing through them, I jotted down these notes/links on the side. They vary in certainty and accuracy from “It’s been considered pretty much common knowledge among security people for decades” to “it’s the impression I got from reading the top three google hits”. It’s far from the last word, just *a* word, if nothing else to myself, so I have someplace to start if I read more.

<something>Duke (Modular infectors/payloads. Series of variations through the decades using new exploits and paths to infect with any of the Fancy/Cozy/Energetic payloads. Chaning command-and-control, but mostly unified at any point in time, prior to deploying payload (which then has it’s own C&C, if there is one)

BlackEnergy V2/3 (Modular payload/infector, DDoS bot. Has been used by the .ru underground for profit since ’07. It’s unclear if it was coopted by Fancy, allowed by Fancy to be coopted by the underground, or under what other arrangement the botnet(s) operate. v1.0 is very simple and do not look state-sponsored, v3 is advanced enough and gets spread by complicated enough vecorts to almost certainly be.)

Shedding Light on BlackEnergy With Open Source Intelligence

Carberb (Banking trojan/cred steal. Source leaked in 2013, many variants since) (slides – short short version) (more thourough report)

CHOPSTICK/CORESHELL (General purpose payload/payload modules. Overlapping use, closely linked to APT28 aka Fancy. Almost downloaders (download from central, run), but with minimalist inital kits for immediate recon/persistence)

Relentless Sofacy APT Attacks Armed With Zero Days, New Backdoors

Crouching Yei (2010- capaign originally thought to be a Cozy (APT29) creation, but shown to overlap with Fancy. Sometimes called Eneregetic Bear and considered a separate APT. Appears to be a joint operation or an organizationally separate group cooperating with both)

Dionis (Infector, ~2010-, linked to Cozy. Various vectors throughout updates)

Dragonfly (2013 campaign aimed at the western energy grid. Consided a product of Energetic Bear(aka Crouching Yeti), wherever they fit into the sceme of things. Uses a fairly isolated set of payloads and command and control infrastructure, and could probably have remained operational beyond *duke, blackeneregy, et al)

HAMMERTOSS (mid-2015 payload. Very stealthy payload, communicating over twitter/github. Focus on segnaography (hiding hot data inside innocent-looking data) and stealth over efficiency. Otherwise, average small downloader-with-some-bonuses. Attributed to Cozy)

Havex (2014 payload. Remote Admin Tool. Part of the dragonfly campaign, fairly narrowly targeted at US energy systems. The name sometimes includes some of the spreading tactics, such as exploit kits injected into sites likely to be vistited by true targets)

OLDBAIT (2014(ish, long running) payload. Credential stealer. Harvests login/pass/keyfiles from popular browsers/clients (extensible) and sends them back to command and control)

Pawn Storm (2005-ongoing intelligence gathering campain. Very broad, tragets in russia, ukraine, usa, nato at large, gov and media, Includes waves of all Fancy payloads, spearphishing, iOS infections, fake sites, etc. Overly broad term often nearly meaning “anything Fancy is up to at the moment”)

Quedagh (BlackEnergy infector. More like a sub-module to blackenergy v3)

Sandworm (2014 infector. Used a particular set of exploits to spread a variety of payloads. Mostly notable for using enough unpatched exploits at once to be an obviously state-sponsored piece of code)

Seadaddy (+ SeaDuke, part of the infector stream. Hid in python code, which doesn’t compile and stays human readable, a fairly unusual vector)

SEDNIT/SEDKIT (Exploit kit series. Exploits browsers to install payloads when the user visits a site they’re installed at (watering hole exploit). Targeted to stick to infecting likely targets and otherwise do nothing, and mostly loaded on sites likely to be visited by good targets. Fancy product)

Sofancy (alias for Fancy/APT28/Fancy Bear)

SYNful knock (Cisco router plant/backdoor payload. Grants remote control of several Cisco routers. Sometimes confused for an exploit but isn’t – it’s code injected into a router firmware by arbitrary means which then allows remote control of it, just like most payloads (though extremely rarely aimed at routers))

SOURFACE (payload. Downloader/installer. Seems mostly introduced as another layer as getting and installing a larger payload after chopsticks/coreshell became increasingly contested)

Tiny Baron (payload. ~2014 remote control payload)

Waterbug (group of infetors/stage one payloads. Could be an operation or group of people who made them rather than the malware itself depending on who is speaking. Focusing on spearphishing/driveby attacks, with complex payloads. Clearly connected to Fancy/Cozy, but mostly using separate command and control)

How are LED Christmas lights wired?

Straight out the box

Straight out the box, Holidy time warm bright white mini lights

If you’re a bit like me, you may have wondered how Christmas (or any strands) of light are actually connected. I’ve sort of half figured it’s probably super obvious if I decided to actually look at them or take a few measurements, sometimes looked briefly at the mess of wires and realized that it’s not totally obvious from the outside, but I’ll look at it later sometime. Well, today was sometime – playing with microcontrollers I’ve used LEDs from a few strands I got last year after the season (they’re often $1.5-$2/50, or 3-4 cents/LED). So before messing up another one, I looked more carefully.


Rearranged into chunks of like parts

Here they are after untwisting, untangling and generally wrangling all the wire into straight(ish) lines, then re-bunching lengths of wire and lengths of straight lights (light wired to light, no extra wires). Clearer? Well, since it’s still not 100% obvious, here’s some labels.

with labeled parts

with labeled parts

The lights by the green arrows with three wires going into them are probably the least clear part. It’s worth noticing (because it looked odd unraveled) that the two center lengths (cyan arrows) of wire are between two piles of half the lights, as though they were several feet apart rather than end-to-end as they originally appeared. First a peek at the three-wire thing.

Three wire socket closeup

Three wire socket closeup

Without the bulb, it’s pretty easy to see that two of the wires are just connected. It’s a T junction with and LED in on the part heading off toward the rest of the lights. This is the case on all four of them.

xmbulbAs an aside, this is what’s inside the removed bulb, after unbending the legs and pulling out the bulb. It’s, well, and LED. Little dip on top to diffuse it, then a bigger diffuser over that to make it look more like a “normal” bulb, and a little socket to connect the whole thing. The legs are longer on one side to signify polarity (just like normal LEDs bought as components).

as a circuit

as a circuit

So simplifying the 3-wire-lights and drawing the wires as wires, it’ll look like this. The power is connected straight through (potentially to more strands) and in between there are two sets of 25 LEDs connected. Each side is connected in the opposite direction. This is how a normally direct current low voltage LED can run off 110v alternating current straight from the grid. Since there’s 25 of them, they experience a 110/25 = 4.4v drop each, which is fairly appropriate. There are resistors on the legs of a few to cut back on the current (didn’t get a picture, sorry). Those look slightly randomly inserted (soldered onto one of the legs of a bulb) which kinda of makes sense I guess – doesn’t matter where as long as it’s somewhere in each bunch. Since they’re light emitting diodes they only allow current in one direction, so when the AC is turned the other direction, they’re not conducting (or lighting up).

During that phase, the ones in the opposite direction come on instead, then after 1/60th of a second it switches. For a while in between, both are dark. It’s all so fast that I could probably just pretend it’s not noticeable, but actually if you look at them, they actually flicker pretty obviously. If you move a bulb rapidly through the air in front of you so that you see a streak of light, you’ll notice that it’s not actually a streak, it’s a dotted line as it goes on/off while you move it. If you hold one from each bunch next to each other and do the same, you can see that each line is “there” at opposite times, like -_-_-_-_. I tried to get some pictures, but persistence of vision phenomena like that (similar to a tv screen) doesn’t really show up well on camera, especially not one ones without a shutter speed setting..

schema  So what about the lengths of wire? Well, here they are drawn closer to scale/position. As you can see, if we require the power in and out at the ends (rather than the center) we do need another wire going forward, meaning we have to match the length once just to have our ground/zero/cathode to connect it to, and then, as they block opposite-direction flow, also an open vcc/power/anode too to connect the other bunch. in circuit, that means there will be four “spans” of wire, and two are indeed between the lights.

That’s about all of it. In short, yes, it was a pretty trivial circuit once unraveled and looked at. But if you wanted to see without the hassle of untangling one, there you go. Now on to seeing what would be the most reasonable way to individually control them.

Charliplexing LEDs on an Arduino Nano

12 LED charlieplex, 4 pins, Arduino Nano (clone)

12 LED charlieplex, 4 pins, Arduino Nano (clone)

“Charlieplexing” is a way to drive more than one LED per output pin on ports/processors that can set their pins to input in addition to 0 and 1. It’s done by connecting two LEDs in opposite directions between any two pairs of pins from the ones used. Here, four are, so 1<->2, 1<->3, 1<->4, 2<->3, 2<->4, 3<->4 (six pairs). When using them, all pins are set to INPUT (they will not provide nor sink voltage or current) except two. Those final two are 1,0 or 0,1 – i.e. +5v and ground, lighting one of the two LEDs connected to it depending on direction.

In order to appear to have more than one lit, cycle through and quickly light each that should be lit in turn and do it at a fast enough rate to not be seen (50 Hz at least). Here’s brief example code, should work on most Atmega based Arduinos, perhaps others too (dunno about interrupts – it’s usually similar but it’s not standardized).

 * Charlieplexer example
 * Controls 12 LEDs using 4 output pins. This is done using combinations of 0/1/INPUT and the
 * diode behavior of LEDs to selectively power arbitrary single ones, then using a timer
 * interrupt to rapidly cycle through those that should appear lit. The array "bri" determines which should be lit.
 * Circuit:
 * The four pins used are connected to D12-D8 (the leftmost four on an Arduino Nano).
 * Each is connected to a resistor. Two LEDs, in opposite directions, are then connected
 * between each possible two-pin selection, i.e. 1-2 1-3 1-4 2-3 2-4 3-4
 * The current will pass through two resistors and one LED when on. If they're evenly lit
 * ("extra" time from off-LEDs isn't given to on-LEDs) the duty cycle will be ~8% (8% lit, 92% unlit).
 * The resistor should be chosen accordingly. 2.4kOhmn works, but is pretty dim. 240 Ohm would still be
 * well within current limits.
 * Patrik Lundin, 2016
 * This example code is public domain

  // Number of LEDs
#define PL 12
  // "Frequency", but really delay per pre-divisor on the timer interrupt
#define fq 100

  // Display state, i.e. which LED should be lit (or not) this cycle
int ds = 0;

  // Array holding on/ff values for LEDs. byte because I might implement partially lit sometime.
//byte bri[] = { 0,0,0,0,0,0,0,0,0,0,0,0 };
byte bri[] = { 255,0,255,0,255,0,255,0,255,0,255,0 };
//byte bri[] = { 255,0,0,0,0,0,0,0,0,0,0,0 };

  // Values to write to PORTB. Determines which pin is powered
byte pv[] = { 
  // Values to write to DDRB for each LED. Determines High impedence (disconnect) pins.
  // The two selected will be 5v and GND as determined by pv
byte ps[] = { 

  byte ods;

    // check if current LED is lit, if so light it.
  if(bri[ds]) {
    PORTB = pv[ds];
    DDRB = ps[ds];
  } else {
    DDRB = 0;
    PORTB = 0;

    // next LED (for next cycle). Back to 0 at PL
    ds = 0;

/* // This snipplet can replace the above to skip over any unlit LEDs.
   // This gives lit LEDs more time (brightness), but unevenly.
  ods = ds;
  do {
      ds = 0;
  } while(!bri[ds] && ods!=ds);

void setup_int() { // Start timer interrupt
  TCCR1A = 0;
  TCCR1B = 0;

  OCR1A = fq; 
  // Some approximate refresh speeds at an unknown prescaler setting:
    //156 400 hz 125 500 hz 100 625 hz
    //78  800 hz, 69 905 hz, 50 1250 Hz

  TCCR1B |= (1 << WGM12); // CTC mode |8
    // Don't have my notes on the prescaler - uncommenting the bottom |= puts it at "very slow".
  TCCR1B |= (1 << CS12); // |4
  //TCCR1B |= (1 << CS10); // Prescaler |1 
  TIMSK1 |= (1 << OCIE1A); // Enable timer compare 

long sttime; // time storage for the main loop 

void setup() { 
  DDRB = 0; 
  PORTB = 0; 
  sttime = millis(); 

void loop() { 
  int inc; 
  byte ch; 
  long now; 

    // This isn't part of the charlieplexing - it's just a loop that blinks (inverts) all LEDs once per second 
     // so it does at least something even by itself. 

  now = millis(); 
  if(now-sttime>1000) { // if it's been 1000 milliseconds blink
    for(inc=0;inc<=PL;inc++) { 
       // Invert on/off (or opposite brightness if that was implemented) 
      ch = bri[inc]; bri[inc] = 255 - ch; 
  if(Serial.available()>0) { // Does nothing, but here you/I could add actions for chars gotten over serial (debug)
    inc =;
    switch(inc) {
      case 'l':