Wednesday, July 25, 2012

Obfuscated C Code Contest

The international obfuscated c code contest (ioccc) went away for a few years.  But now it's back.  My earliest/fondest memories of learning programming are exchanging bits of C code from IOCC entries with friends as we'd try and stump each other.  Maybe that's why I love programming in perl so much, a language more timid engineers consider unreadable and difficult to maintain.  My retort typically being that unorganized code in any language is difficult to maintain.  I even hesitate to use the words "poorly written" because I think that any code which accomplishes it's primary goals in a stable manner is well written in my book, regardless of how pretty it is.  Although, I now consider perl a guilty pleasure that I'm trying to quit.  I still fall back into it while data munging and can move mountains in moments with it.  There's something deeply satisfying about accomplishing a task in 30 minutes that a colleague has been manually working through for days/weeks or had given up attempting.

The code below isn't pretty, but it illustrates a point I plan to make in a latter blog post.  Automated code scans don't protect against an insider threat.  General purpose languages which are essential to making anything allow unlimited obfuscated representations of functionality.  It's trivial to hide true functionality by obfuscating code.

Compile and run it... the output is all 12 verses of "The 12 Days of Christmas".

main(t,_,a )


main(-86, 0, a+1 )


main( t+1, _, a )

main ( -94, -27+t, a )
&&t == 2 ?_
<13 ?

main ( 2, _+1, "%s %d %d\n" )

main( _, t,
"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+,/+#n+,/#;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# }'+}##(!!/")
_==*a ?

main((*a == '/') + t, _, a + 1 )


main ( 2, 2 , "%s")


main(-61,*a, "!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry")


Monday, July 23, 2012

Scarce to superabundant

Good article to reference when conversing about the growth of digital data.  It's one of those trends that can be so glaringly obvious that it almost goes unnoticed.

"All these examples tell the same story: that the world contains an unimaginably vast amount of digital information which is getting ever vaster ever more rapidly. This makes it possible to do many things that previously could not be done: spot business trends, prevent diseases, combat crime and so on. Managed well, the data can be used to unlock new sources of economic value, provide fresh insights into science and hold governments to account."

h/t Richard Heimann

Friday, July 20, 2012

Program Management Art of War

Good articles on program management within the government.

"The Rogue Program Management Art of War"
"So you’re a program manager with a problem. You’ve got no money, no support, your senior leadership doesn’t know who you are, your subordinates want to quit, your peers want to get you fired, you get no respect and no travel budget"

This article on trust in program management was referenced in the first article.
"The Program Manager’s Dilemma Trust, Cooperation, and Competition in the Acquisition Community"

Wednesday, July 18, 2012

RIP Time division multiplexing

I recently had the opportunity to play with land mobile radio technologies and integrate them with VOIP software. While doing it I was reminiscing about how just a few years ago before widespread green side deployment of IP technologies we had to multiplex signals and conduct intricate planning. I searched online for a piece of multiplexing hardware that I used to have a love/hate relationship with, the FCC-100. Looks like they are finally killing it this year and retiring the technology in favor of IP specific tech. Rest in pieces my little signal multiplexing frienemy. I hope they have conditioned diphase for you to time division multiplex in multiplexer heaven.

More concerning is the amount of hesitation I've seen some of the engineers in training here display over having to diagram networks before deploying them. The systems we are working with include land mobile radio nets, cellular phones, voip phones, servers, and desktop computers all communicating in various ways to each other. A person can't just start installing things and start configuring a system like that without creating some serious discord and spawning network gremlins that will haunt you as long as the system lives. Kill the gremlins early. Learn how to draw a diagram and spot the system gremlins before you give them life. The FCC-100 taught me that lesson years ago, and it was relatively simple (albeit less self-correcting) when compared to modern technology. 

Here's an idea. Ask your engineers to draw a diagram of the network or produce one. If they can't, consider it an opportunity to pursue the next time you make a system addition or change. You can reduce your cost and increase your network reliability when you understand how everything is interacting. It's almost like a gift... cash is always the best gift. But beware attempting the diagramming endeavor without a catalyst. That is normally a waste of time. If you start out trying to do such a thing with a non-discreet hypothesis it's impossible to tell when you're done. People get frustrated, both the managers who expect magical results and the engineers who are left to run on an impossible wild goose chase. Any effort needs to be tied to a discreet goal. i.e. "show me in detail how new technology x impacts or interfaces with our systems."

Wednesday, July 11, 2012

Wednesday, July 4, 2012

Lost a rock

So, my new hobby of flint knapping has made me a bit of a hobby geologist in search of lithic sources of obsidian, jasper, chert and whatnot. So I looked at my trip to AFCEA San Antonio as a chance to get out in the desert and find some good southwest material. It rained almost all week. Finally today I get to run around and dodge cactus and rattlesnakes while I gleefully examined rocks with he hammer I drug 2500 miles with me to do so with. Not much luck. I found a few pieces of Edwards plateau chert. I get to the airline and my collected rocks have pushed my check bag 5lbs over the weight limit and I'm informed that I have to pay 100$ for the extra weight. The look on the face of the desk attendees was classic as I reached in my luggage, pulled out a large rock and asked her to re-weigh it. It came in 0.63 lbs under the weight limit. It was only half a victory because I soon discovered TSA regulations classify rocks this size as blunt weapons and had to discard it in the trash. Back in DC tonight to nurse my cactus wounds...

Monday, July 2, 2012

Proprietary cryptography algorithms

Great article on why to be suspicious of "proprietary" crypto algorithms.
"Suppose your doctor said, “I realize we have antibiotics that are good at treating your kind of infection without harmful side effects, and that there are decades of research to support this treatment. But I’m going to give you tortillachip powder instead, because, uh, it might work.” You’d get a new doctor. Practicing medicine is difficult. The profession doesn’t rush to embrace new drugs; it takes years of testing before benefits can be proven, dosages established, and side effects cataloged. A good doctor won’t treat a bacterial infection with a medicine he just invented when proven antibiotics are available. And a smart patient wants the same drug that cured the last person, not something different. Cryptography is difficult, too."

As for implementation... there are ways to do that too.