Setting up windwos insider/developer after seeing they apparently have and integrated bash version (actually seems to be an integrated linux/posix a.la. 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 :-).

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, :-)

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.

Been thinking about how bezier curves, like what’s often used in svg:s and fonts, might lead to neat looking animations if tweaked while still curves. Here’s a quick test using a plain  circle (actually four bezier curves approximating a circle).

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.

This could and should probably be more organized. The report (here https://www.us-cert.gov/sites/default/files/publications/JAR_16-20296.pdf) 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)
https://cdn.securelist.com/files/2014/07/themysteryofthepdf0-dayassemblermicrobackdoor.pdf

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.)
https://www.sentinelone.com/wp-content/uploads/2016/01/BlackEnergy3_WP_012716_1c.pdf

Shedding Light on BlackEnergy With Open Source Intelligence

Carberb (Banking trojan/cred steal. Source leaked in 2013, many variants since)
https://www.rsaconference.com/writable/presentations/file_upload/ht-t06-dissecting-banking-trojan-carberp_copy1.pdf (slides – short short version)
http://delaat.net/rp/2012-2013/p42/report.pdf (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)
https://tools.cisco.com/security/center/viewAlert.x?alertId=39835

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)
https://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/Dragonfly_Threat_Against_Western_Energy_Suppliers.pdf

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)
https://www2.fireeye.com/rs/848-DID-242/images/rpt-apt29-hammertoss.pdf

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))
https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.html

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)
https://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/waterbug-attack-group.pdf

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[] = { 
    0b00001000, 
    0b00000100,
    0b00010000, 
    0b00001000,  
    0b00010000, 
    0b00000100,
    0b00000010,
    0b00000100,
    0b00000010,
    0b00001000,
    0b00000010,
    0b00010000,
    0
  };
  // 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[] = { 
    0b00001100, 
    0b00001100,
    0b00011000, 
    0b00011000,
    0b00010100,
    0b00010100,
    0b00000110,
    0b00000110,
    0b00001010,
    0b00001010,
    0b00010010,
    0b00010010,
    0 
  };

ISR(TIMER1_COMPA_vect){
  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
  if(ds==PL)
    ds = 0;
  else
    ds++;

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

void setup_int() { // Start timer interrupt
  cli();
  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 
  sei(); 
} 

long sttime; // time storage for the main loop 

void setup() { 
  DDRB = 0; 
  PORTB = 0; 
  Serial.begin(9600); 
  Serial.println("Go"); 
  setup_int(); 
  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
    sttime+=1000;
    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 = Serial.read();
    switch(inc) {
      case 'l':
      break;
      default:
      break;
    }
  }
}