Chris X Edwards


My Amazon Piranha Attack

2015-10-23 20:49

Earlier this month I was investigating alternative possibilities for my web hosting needs. It would be hard for someone interested in cloud services to not think of Amazon Web Services. Since my own personal "cloud" service uses roughly the same underlying Linux Xen VM technology as AWS I thought it would be interesting to see how using AWS compared. On Friday night, October 2, I decided to do some tests.

I went to AWS, logged in with my retail Amazon account and set up an AWS account. I spawned a "tiny" instance of a single Amazon Linux AMI 2015.09 virtual machine (paravirtualized). I downloaded an SSH key, logged in to the VM with no trouble and checked out the distro. I did a yum update. I installed lighttpd and served a web page just to test that was possible. (Are they really giving out free, world-routable IPv4 addressess? Really? Free? Yes, they are.) Determining this, I shut the VM down and terminated it. All in all, less than two hours in total. Seemed great. AWS seemed like it would work very well for my needs. My expected cost for a year’s worth of highly efficient minimal usage was $0.00.

Monday morning, an email was waiting for me saying my Amazon account was blocked. After some predictable struggles to reset my password, I logged into the control center to find 180 instances (20 in each of 9 regions) of the largest VMs running! Following the instructions in the email, I stopped all of the VMs immediately. (You can imagine what an absurd pain in the ass it is to actually "terminate" 180 VMs with "Termination Lock" enabled.) In case you were wondering, mining bitcoins was undoubtedly how my stolen VMs were put to use.

When I looked at the billing console it said I owed $6700!



Something horrendously uncool had happened and I needed to know exactly what that was. As someone who takes computer security very seriously, this really was disturbing. I have now spent a lot of time studying the various aspects of security relating to AWS usage. I have done a lot of research and received feedback from a lot of knowledgeable people.

Paradox warning! Note that researching computer security is essential to using computers safely. Note also that researching computer security is fundamentally insecure. While researching computer security topics you will never find a more wretched hive of scum and villainy. We must be cautious.

What follows is a checklist of things to consider when trying to isolate the cause of a situation like this. While this is structured to address a compromise that has already occurred, of course the best time to familiarize yourself with these considerations is before you have the problem.

AWS Compromise Analysis Checklist

  • Password Strength

  • E-mail Phishing

    • Did you respond to dodgy email? Do not be quick to dismiss this. Note that Amazon themselves send out dodgy email solicitations to use AWS; I get genuine unsolicited bulk emails from Amazon with spammy sounding subjects like "Instructions to Redeem Unlimited Cloud Storage".

  • Credentials Compromised "Elsewhere"

    • Do you reuse the same username and password that you use for Amazon anywhere else? That is a terrible idea. Probably worse than you thought. The other party with whom you share this information could have had a data breach.

It seems that someone obtained your personal account and/or financial information elsewhere, and used it to access your Amazon Web Services account.

— From Amazon's first email alerting me to the problem
  • Mishandling API Keys - API keys are cryptographic magic numbers that enable the bearer to control the account using the "application programming interface" instead of the normal web based interactive browser interface.

    • Did you email an API key?

    • Did you use an API key in an unencrypted HTTP connection?

    • Did you leave your API key in the software you develop? This problem seems to generally occur when people leave API keys in software they store publicly on GitHub. This is the programming equivalent to leaving your house key on top of your doormat instead of underneath it. Still, it seems to be quite common, even among otherwise competent professionals. At least Amazon is actively scanning for this now.

  • Identity and Access Management - I am reassured that IAM users/roles are not created by default and security credential settings are sane by default.

    • Did you create an overly permissive "role" or otherwise weaken security through the IAM?

    • Did you use any "security credential" features for your users?

  • AWS Account Access Exotica - AWS Security Best Practices mentions several exotic security features.

    • Did you use "Cross-Account Access" features?

    • Did you use "Identity Broker" features?

  • Environment

    • Is your OS, browser, and third party software (Java, Adobe malware, etc.) up to date?

    • Are you using a phone?

    • Did you set up your computer yourself?

    • Any employer or OEM or ISP provided software or strange modifications?

    • Any strange USB keyboard "adapters", etc.? Are you using a bluetooth keyboard? Got a webcam pointing at your keyboard?

    • Is physical security good? Is the computer completely off limits to untrusted parties?

    • Are you in an unusual network situation (university residence hall, corporate network, etc.)?

    • Are you using wifi, especially public (cafe, hotel, airport, etc.) or unknown open access points? Is someone spoofing your normal AP?

    • Any access to the machine from the outside internet directly or through port forwarding?

    • Are you using a VPN or a proxy to route your internet traffic?

    • Are you using strange browser plugins?

    • Do you have a lot of tabs open? Especially unsavory ones or a watering hole?

    • Do you allow pop-ups? Ads?

    • Did you disable the browser setting "Warn me when web sites try to redirect or reload the page"?

    • Did you "allow" any security exceptions when the browser asked?

  • Malware - While I decry the facile assumption that all computer problems are caused by some nebulous "virus", it is true that malware is a real thing.

    • Do you have risky habits like warez, shareware, pr0n, 1337 hax0r forums, or powerful enemies, etc?

    • Do you use Windows? Especially if you’ve had problems with this kind of thing before. Is your preferred anti-virus magic ritual at least giving the appearance that all is well when correctly deployed?

  • Domain Name System problems

    • Does your DNS come from a reliable provider? A spectacular example of an unreliable provider looks like this.

    • Does your legitimate seeming DNS provider have very shady practices? For example, the DNS server provided to me by Time-Warner Cable’s DHCP reliably hijacks connections to nonexistent domains and sends them to a malware delivery system. This article describes it as a "browser hijacker" and rightly points out, "If you are unfortunately redirected to hijacked websites, Trojans can be automatically dropped on your computer."

    • Anything suspicious in your /etc/hosts or Windows equivalent? (My /etc/hosts has a fake IP for the aforementioned TWC DNS exploit.)

Whew! That’s a lot to consider. It turns out that in order to use AWS safely, understanding all of these things is necessary but unfortunately not sufficient. Since I now know what really happened I can assert a few truths. No mismanagement of the AWS features was required. It also turns out that none of the security weaknesses implied by the listed issues were required for this particular exploit to happen. Imagine the cleanest setup you can think of (something like a brand new iMac or maybe Linux from a boot disk with verified checksums). It turns out that such a pristine system may actually exacerbate the problem!

When I first tried to reconstruct what had happened I thought back to that night and what had transpired… I had the idea to use AWS. I thought about how to get there. Was it or I looked it up and the first hit reminded me that it was Now very often it is my habit to simply type Ctrl-L and just type the entire URL and hit enter. Thinking I had done that I realized that I would not have typed Was this my mistake?

I then found Moxie Marlinspike’s excellent presentation about SSL stripping. This is surely the most impressive discussion of this problem. I felt less foolish when he said this.

"I don’t think anybody types https:// into the URL bar anymore. I think it’s very rare. Just as nobody types http:// into the URL bar anymore."

— 23m30s

I realized that if you connect to a site in an untrusted network (i.e. the internet) with HTTP (not HTTPS) there is no defense. It really is game over. As Mr. Marlinspike says:

"The real fix here is encrypt everything… The fundamental problem is that when you have a secure protocol that depends on an insecure protocol you just attack the insecure protocol. And so the answer is encrypt everything."

— 57m30s

Really, this is an incredible video and worth watching.

I went down this rabbit hole far enough to learn that because of the desperate nature of the problem Firefox actually has very elaborate mechanisms to handle this. If you are a bank, for example, obviously you should never allow unencrypted log ins or even connections. Never. Banks can register their domains with Mozilla’s Strict Transport Security whitelist. Once done, if a customer tries to connect to your bank with HTTP, Firefox will simply upgrade it to HTTPS. Seriously, Firefox keeps a whitelist in its damn source code! I was simultaneously horrified and deeply impressed to learn this. It gives you an idea of the seriousness of the problem.

Ok, is on that whitelist? Turns out, no. I dug deeper to find out why. This list is apparently joined by submitting a domain name to this HSTS preload form. However, to do this one must be serious about security because rule #2 for inclusion says that you must:

"2. Redirect all HTTP traffic to HTTPS - i.e. be HTTPS only".

Unfortunately, Amazon (even high stakes has some reason to think this is not a good idea. Indeed, Amazon seems to be training people to make unencrypted connections to them. On *http*:// I find "To shop at AmazonSmile simply go to from the web browser on your computer or mobile device." There are 6 links to "", all HTTP. I found the same problem on the AWS sign in page which said "Visit for full offer terms." That one wasn’t even linked.

One thing I learned during all this is that you should not assume that the protocol security will be "taken care of for you" in a good way. When visiting very critical sites, you really should type https://host.domain.tld explicitly. This is especially critical the first time your browser ever meets the site (hence why a LiveCD or new install is more problematic). Oh, and don’t mistype it or it’s game over with you being the loser.

What this research did do for me was make me wonder just exactly what I did type for the URL. I don’t know why I didn’t think of it earlier and why no one on the AWS forum (or from Amazon) thought to recommend this, but in hindsight it’s obvious. If something bad happened - check your browser history logs. (Another problem with the ephemeral live CD OS approach to security which I generally endorse.) Normally I think of my overly zealous browser history as a stinking security failure, but I have now seen the light. (This is a good time to thank my professional security analyst friend for this tip and tons of other extremely useful information. He knows who he is and probably doesn’t want his name appearing here, but thanks amigo!)

After some SQLite fiddling to decode the data, one look at the logs told the whole story. It’s hard to remember every keystroke and every reaction from a browser session that transpired many days ago. I remembered what I meant to do and it fit with how I typically do things. I remembered seeing the American Welding Society in the search results and being glad I double checked the URL. I remembered looking at the first link which looked 100% legit. I don’t remember it saying "AD" (AdBlockPlus was active). The URL was clear and told me all I needed to know: "". Although I strongly had feelings about wanting to simply type that in as I often do (no "https://" though) apparently that’s not what I did. Memory is a bad witness. Somehow I activated that link. I may have used a Vimperator key binding. The search engine I was using was DuckDuckGo and, thanks to overly helpful JavaScript, simply pressing enter a second time is enough to activate the first hit’s link. I can’t even rule out just using the mouse like a normal person or being stoned from my neighbors' second hand weed smoke. So let’s look at the record.

Here’s how events unfolded. (Breaks added for readability.)

2015-10-03 04:17:37 |

2015-10-03 04:17:42 |\

2015-10-03 04:17:42 |\

2015-10-03 04:17:43 |

2015-10-03 04:17:43 |\\

2015-10-03 04:18:17 |   (* See below)

Basically this shows that after looking at the search results for "aws" for 5 seconds, I activated the first link which took me on a quick obfuscatory ride through Yahoo and MSN (Bing) search engines. (Were results there also rigged?) Let me stop there to stress that the attackers were in control of the top hit for the search term "aws". I was using DuckDuckGo, but here’s a report of the exact same trick being played on Google. I then was bounced to and then landed at No HTTPS but, of course as we’ve now seen, it doesn’t matter at this point. I timed that it takes me about 14 seconds to type my credentials; I spent another 20 seconds looking at this fake login/registration page and I suspected nothing.

Obviously it’s easy after the fact to criticize my lack of perspicacity in scrutinizing this web page. 20 seconds is actually a long time to look at a log in page. I strongly want to believe that the true URL was not what was shown in my browser’s address bar. I tried to figure out exactly how this supposedly inviolate feature of the browser was tampered with, but I could not replicate it. This paper from some academic security researchers gives plenty of ideas (note especially 1.3.2). Other possibilities involve iframes, HTML5 history manipulation, cross frame scripting (XFS), repositioning what was visible in the address bar to put the correct address in the right place, painting a graphic over the whole thing, etc. If you figure out the details, please let me know! I would like to figure this out because I do not like to think that I let that URL go unnoticed but of course that’s a possibility too.

Speaking of verifying the complete legitimacy of URLs, the Amazon sign in URL which I truncated above is quite interesting. We can presume that the attackers stole my authentication information and then sent me on to the legitimate web site. See how long it takes you to completely verify the full correctness of the AWS log in page’s true legitimate URL which looks like this today (line breaks added).\\

Got that? They keep telling me that web interfaces are "easy". How about an easier one? This one is obviously fake, right?

I was at least proud of myself for catching one bogus URL that night. But no! That’s actually from a valid email from Amazon with the subject, "Your AWS Account is Ready - Get Started Now" (the link has been confirmed real by AWS support but I dared not click it). What about the sketchy domains or or Fake, right? No again. All are essential to the AWS website! Of course you will also need to know all about IDN homographs to play this game sufficiently well.

Got all that figured out? Good because it gets even worse. As I was researching how an attacker could establish a position on a network to execute a man-in-the-middle (MITM) attack, I learned more about BGP problems, specifically BGP IP hijacking. This involves manipulating the routers deep in the internet that control where and how traffic flows. Surely these guys aren’t going to be doing things that exotic and sophisticated, right? Wrong. Here’s a report of BGP hijacking used by bitcoin pirates. And more details. And a nice talk about it (especially at 5min and 14min). Here is a Washington Post article discussing the BGP problem in depth. Is Amazon now relying on my skill at casually spotting forged SSL certificates?

That’s all pretty onerous. It makes one really question the web as a medium for extremely high value transactions. The constant "arms race" problem is nicely described in this great article which illustrates the eternal struggle between security measures and criminals for cases like this. This also mentions multi-factor authentication which was proposed to me many times, including by Amazon. I’m going to save my misgivings about that for another day. If MFA was essential for me to safely use AWS in the most minor way possible, Amazon should not have let me proceed without it. Let’s just say that while generally wholesome, MFA has its own problems too. These problems are related to why "billing alert" settings can only reasonably be considered to apply to legitimate mistakes; if an attacker completely compromises your system, they will simply remove the billing alert. (And intercept the notification emails if they can!)


One thing my research discovered was that I was not alone with this problem. It seems pretty common. Here are some other stories about this kind of thing:

And in all of these stories it seems that Amazon is pretty generous about just eating the cost of the problem. I’ve very rarely had problems with merchandise or shipping from their retail business but they’ve always been very classy about making such problems go away. I’m actually quite an Amazon fan. It was an unnerving few weeks but I am pleased to report that yesterday, October 22, I got word from Amazon that they were waiving the charges for this spurious use. All of the customer service people involved did a very good job and were very professional and sympathetic, even when they basically couldn’t really do much for me or tell me anything substantive.

The Real Problem

While I did fret over the details, I had plenty of opportunity to consider the big picture. Why did this happen? I believe the answer is simple economics.

The first question to ask is why only 180 machines? Why not a million? Well, there is, it seems, a limit. An absurd limit. What if I was a legitimate customer who needed a million machines? The point here is that any legitimate customer who truly needs more than $100/day is willing to talk to an Amazon account representative in person to positively assert that extraordinary situation. Heck, they’d at least be ok with a captcha or confirmation email. One could argue that allowing unconstrained and automated spending is "convenient". I now know this to be false. I believe it is actually a bit shoddy and puts innocent people at risk.

A revealing question is why is multi-factor authentication not required for Amazon retail shopping accounts? This event has really made me think about just what the difference is that makes MFA so essential with AWS and yet an obscure practice among Amazon retail customers. I believe the answer to this question is the fundamental problem here. (Actually, Amazon retail and AWS both do use and require MFA by default, but only the retail side does so in a sensible way - the other factor is called email.)

The real problem as I see it is infinite profit potential for criminals. Perhaps there is a limit but judging by the amounts other people have been hit with the cap on what someone can become liable for is truly absurd. When I walk into a grocery store I never fear that a pickpocket will surreptitiously purchase $39k worth of breakfast cereal in my name. I don’t even fear this walking into a Ferrari or yacht dealership. There are sane controls involving real humans at that scale.

Amazon, however, has made a perfect system for people who want to build a machine that automatically steals untraceable assets. The only way this can be discouraged is to cap the potential loot. Until there is a conceivable limit on what return a criminal can expect they will never stop. Any expense required by the criminal to overcome computer security measures will always be justified. Nobody will be safe.

If Amazon does not fundamentally change something, the value of hacked credentials, currently on the order of about $10, must rise. Even people with no dealings with Amazon will find AWS accounts set up in their name. Criminals will start managing your email and more aggressively hack your phone to block alerts and foil MFA. The inexorable economics of computer crime demand it. The only cure, and thankfully it’s an easy one, is to create a reasonable default spending cap for AWS that can only be expanded by a real discussion with a real human account rep. Until this is done, until there is a reason for a criminal not to do whatever it takes to automate AWS abuse, you’re not safe regardless of who you are or what you do.

Important Lessons Learned

  • LiveOS CD security approaches are good but will have more problems with HTTPS and logging.

  • Assume all search engine results are malicious. This is a subset of never trust any links ever.

  • Always explicitly type sensitive URLs when first visiting them. However, do not misspell them and do not cut and paste them (homographs).

  • Always explicitly type https:// when first using sensitive URLs.

  • is an absurdly sensitive URL for reasons beyond your control.

Nadella's Microsoft Is A Very Different Animal

2015-09-18 10:24

Apparently some people are very surprised to learn that Microsoft has developed its own Linux. I have nothing negative to say about that.

I did find this quote in the article personally satisfying:

However, what [we] find challenging is integrating the radically different software running on each different type of [proprietary vendors' systems]…

Yes. Yes indeed that is a bitch. Something everyone is no doubt tired of me pointing out. At least I’ve always pointed out a potential solution as well. Congratulations to Microsoft for implementing it.

My Favorite Computers #3 - raven05

2015-09-08 07:41

I have been planning to write about my favorite computers of all time and this weekend it became time to write about number three, raven05, which died last week after an incredible 10 years of continuous service.

Back in 2005, when the word "cloud" only meant water vapor in the sky, I came up with the idea of having my own personal computing platform always available to me from anywhere on the internet. I already used a normal web host, but I wanted a server that I controlled completely and that could handle most of my day to day activities.

Since this computer would be on all the time I was concerned about the cost of its power use. Also it was designed to operate where I lived or worked so having it be cool and quiet was a priority. Having already become frustrated with noisy computer equipment, I decided to try to make this computer completely silent. I discovered that some mini-itx motherboards were designed to be passively cooled which means no fan which means no fan noise. Excited at the prospect of a very quiet computer, I built raven05.


Perhaps "assembled" would be a better word since this computer never had a case. It sat on a piece of cardboard on a shelf looking very much like it does here. This computer became my primary computer for ten years.

The mother board is labeled "VIA EPIA-M rev.b" and is a VIA Eden ESP8000 Nehemiah 130nm which means it was released in Feburary 2004. I purchased mine in 2005. It is a silent fanless design and I bought a very small power supply which used a laptop transformer, also silent. The CPU itself is rated at an incredibly low 6 Watts. The total draw of the full system (board, power supply, drives, etc) under normal conditions was about 15W.

This VIA CPU was pretty weak even in 2005 to accommodate the passive cooling. To put in perspective just how weak this machine was, here’s a $34 cell phone with almost as many Bogomips(1024 vs 1200 for raven05). The latest regular desktop computer I built has 6000 Bogomips on each of 16 cores (of course raven05 was a single core).

But I did not consider this machine weak. I used it for:

In short, this was my computer.

Because it was such a critical machine, I took extra care with the data. After using the motherboard for about a year, I decided I would invest in learning how to use two disks simultaneously in a RAID1 mirror set up. This means that anything that is written to disk one is simultaneously written to disk two. If either disk fails, the other should allow operation to continue uninterrupted. What’s critical here is that this is not a motherboard hardware RAID feature but rather Linux software raid. Why this is so important can be seen in how this machine finally died.


Here is a close up of the motherboard, power supply, and one of the drives. I always write the date and warranty term on hard drives when I buy them which here shows this drive was purchased in August 2006 and had a 3 year warranty. But the close up shows that the failure was not the drive pair. Both drives are still 100% functional. What failed is the power supply. I was updating the OS and since this machine has always used Gentoo, this entails compiling every bit of code from source. This can take a full day on this machine. In particular, GCC has become extremely bloated and the requirements to compile it have recently become too much for this machine to handle. While compiling GCC (i.e. compiling the compiler) it froze with an out of memory kernel panic error (yes, it had a whopping 256MB of RAM!) and I had to power cycle it.

Prior to that, it had not been down in over two years of continuous operation. When I tried to power it up, however, the power supply was not up to the job and made pathetic ticking noises. If you look at the photo the arrows point to capacitors on the power supply and the motherboard which have popped their tops. They’re designed with those crosses stamped in them so they pop there and don’t explode more violently. When buying computer hardware for longevity, I believe that high quality capacitors are critical.

Now imagine if my data had used some kind of hardware RAID to mirror those drives. With the drives good but the motherboard dead, I’d have been in a real bind. Of course I make off-site backups too but you get the idea. With Linux software RAID, I was able to mount either of the drives with a USB to IDE adaptor using sysresccd. I can’t really continue to use the drives since it’s not really possible to buy hardware with IDE ports any more.

And so, R.I.P. to raven05, a small heroic computer that reminds us of how much can be done with so little if done well.

This weekend I built the new raven15. I had already put together most of the hardware in anticipation of raven05’s senescence. The new machine was also a mini-itx board and though much more powerful, still fanless and silent. (2000 Bogomips on each of 2 processors.) I had been using it as a Minecraft server to test if it was a suitable replacement. It also runs Gentoo with dual RAID1 mirrored drives. The OS drives are mSATA designed for laptop use. I also ordered another pair of drives just to house the content of raven15. Here’s what it all looks like.


The only moving part in the whole thing is the power supply fan (seen in the lower left image). There are 5 drives in total, 2 mirrored RAID1 sets and a 5th for the Minecraft server and possibly other applications. The reason I can continue to use the other servers is that I set this machine up to use Xen virtual machines. This adds another layer of robustness (and, yes, complexity). Instead of compiling GCC on the raven15 VM, I can use a test VM and if it dies with a kernel-panic, no big deal. I can also more easily boot from the RAID1 drive set from any future situation I find myself in. (In recent years some functionality allowing booting of RAID sets with no initrd image was annoyingly removed from the kernel. And let’s not even discuss UEFI and GRUB2 hassles.)

I had to update the Gentoo images which took a long time. I also had to wait for the new drives to arrive (silent SSD and much faster). Then I had to transfer everything to them and get everything working the way I’m used to it. Also the old raven05 was on a shelf in my work office and raven15 will be in my apartment. This meant struggling with all new SMTP mail server settings (if I write you an email, assume Time-Warner will be reading it now).

When it rains it pours, I also had to deal with a new bug in my mail client related to SSL (I filed a bug). I also installed lighttpd instead of Apache and I learned that while it is a fine web server, weird people with very fancy requirements might need to lower expectations, for example no user_dir cgi-bin directories. But finally I think it’s mostly working. If you are reading this, then a new era in my personal history of cloud computing has begun. Good-bye raven05!

I'm Dreaming Of A White C

2015-09-01 16:37

This summer I’ve been doing something about the fact that I don’t get as much chance to work with C as I would like. One of the problems I’ve had is that I just don’t have enough programming problems that would require the badassery of C. 99% of the time it is much easier for me to dash off a program in Python and be done quickly. Reflecting on why it is that I tend to not use C I realized that Python has a list of features that are so extremely useful that C is hard to justify. Giving this some thought, I realized that I have been missing the point of C. No, C does not come with the features I love about Python, but nor does it come with the "features" I don’t necessarily care for in PHP. What it does come with is a blank slate, the minimum components to express yourself in software (that is portable). And here’s the important part - if something is missing in C that you think is important, you are free to implement it and #include it for the rest of your life. Just the way you like it.

With this new spirit I’ve been merrily attacking problems in C which I normally would expediently solve with Python. I’ve been adding my own strategies for dealing with dynamic memory, strings, data structures, etc. I find C is already extremely good at dealing with Linux calls, file system operations, unvarnished IO, etc. And once into seriously hard stuff (regexp, hard math, etc) C has libraries that are often the last word on the topic.

When I started this agenda, I had hesitated because there was one thing about Python that I loved above all other features in all programming languages I’d ever seen and that was semantic whitespace. I was thinking that it would be a real downer to have to start using all those horribly inscrutable curly braces like sloppy programmers use. I say sloppy programmers because if you are not sloppy, as any Python programmer will tell you, you do not need curly braces to delimit blocks. Basically this horrible syntax element, "{}", rewards you with the license to write sloppy code. No thanks, and no thanks.

I realized that Python is a C program. There is no reason why I couldn’t use C to write a conversion parser that took correctly indented braceless clean code and output compilable C code. This was a great test of C done the Right Way, i.e. my way. Your way may differ. That’s the beauty of C.

Although the details were quite a puzzle, I finally got the core functioning. The main test was to strip down a version of the program to my version of C, convert it with the unstripped version, and then compile that result. Here is what my code looks like for the function that scans a long character array containing the code and printing a valid C program along the way (i.e. this function is an example of input as well as the primary functionality).

The extension for this style is ".cno" as in "C, no braces" or "snow", the white style of C.

int scan_subsection(char *s, int l)
    int n, i, line_end, line_start, in_indent=1, ilevel=0, plevel=0;
    ss *thess= NULL; // A simple stack.
    for (n= 0;n<l;++n)
        if (in_indent)
            if (s[n] != ' ')
                in_indent= 0;
                line_start= n;
        if (s[n] == '\n')
            if (!in_indent)
                line_end= n;
                in_indent= 1;
                if (ilevel > plevel)
                    thess= ss_push(plevel,thess);
                    printf(" \173 \057\057 %d\n",ilevel);
                else if (ilevel < plevel)
                    while (thess && ilevel < plevel)
                        printf("\175 \057\057 + %d\n",plevel);
                        plevel= ss_val(thess);
                        thess= ss_pop(thess);
                    if (plevel != ilevel)
                        printf("Indentation error at %d!\n",line_start);
                for (i= line_start;i<line_end;++i)
                plevel= ilevel;
                ilevel= 0;
    while (thess)
        printf("\175 \057\057  %d wrap-up\n",ss_val(thess));
        thess= ss_pop(thess);
    return -1;

Obviously syntax highlighting doesn’t work (yet). Here is the output, i.e. hopefully normal C.

int scan_subsection(char *s, int l) { // 4
    int n, i, line_end, line_start, in_indent=1, ilevel=0, plevel=0;
    ss *thess= NULL; // A simple stack.
    for (n= 0;n<l;++n) { // 8
        if (in_indent) { // 12
            if (s[n] != ' ') { // 16
                in_indent= 0;
                line_start= n;
            } // + 16
            else { // 16
            } // + 16
        } // + 12
        if (s[n] == '\n') { // 12
            if (!in_indent) { // 16
                line_end= n;
                in_indent= 1;
                if (ilevel > plevel) { // 20
                    thess= ss_push(plevel,thess);
                    printf(" \173 \057\057 %d\n",ilevel);
                } // + 20
                else if (ilevel < plevel) { // 20
                    while (thess && ilevel < plevel) { // 24
                        printf("\175 \057\057 + %d\n",plevel);
                        plevel= ss_val(thess);
                        thess= ss_pop(thess);
                    } // + 24
                    if (plevel != ilevel) { // 24
                        printf("Indentation error at %d!\n",line_start);
                    } // + 24
                } // + 20
                else { // 20
                } // + 20
                for (i=line_start;i<line_end;++i) { // 20
                } // + 20
                plevel= ilevel;
                ilevel= 0;
            } // + 16
        } // + 12
    } // + 8
    while (thess) { // 8
        printf("\175 \057\057  %d wrap-up\n",ss_val(thess));
        thess= ss_pop(thess);
    } // + 8
    return -1;
} // + 4

It turns out that it was pretty hard to get (bootstrap) a program that could repeat the process. I had a version that would convert a cno version to a C program that actually compiled but that executable could not replicate the trick. The problem turned out to be an indentation error in the original C which should never be allowed to happen! That’s a major point of this way of doing things!

You can see that I named the function scan_subsection. This is all very early work and I’ll probably change that name but I point it out because I originally thought to use recursion to do this job. This is also why the function still returns -1 (stop condition) even though that is no longer used. Recursion seemed a reasonable and clever way to use the call stack to store what level was being processed. The problem is that you need so much context from other parts of the code that it became too complex (for me) to do that way. I’m not saying it can’t be done. Cleverer programmers than I could surely do it, but I eventually just implemented my own stack to keep track of indent level and the complexity eased up quite a bit.

This is just a rough prototype at the moment but it serves as a nice proof of concept that C code does not need the suboptimal syntax it was originally planned with. Next I’ll focus on the semi-colons which should be optional in a multi-line program. Also comments need to be nicely handled and there are a few C details that need special treatment such as struct definition. Overall, I am quite pleased with this small bit of progress.

The Linux Unity I Really Wanted

2015-08-26 08:26

Back in March I mentioned that a lot of the big game development engines were relaxing a lot of the licensing fees (becoming free as in "free beer"). That was nice but still not terribly useful for me as an exclusive Linux user. With Android, SteamOS, and other knock-on Linux technologies, bringing games to Linux has very recently become a non-negligible priority in the industry. The problem for me is that until very, very recently, if a game engine had "Linux support" that meant it could create executable games that ran on Linux. That’s wonderful and I’ve supported this with some Steam purchases. (Most gamers don’t take 20 year breaks!) However being able to actually create games in Linux as a development platform using the major engines remained mostly impossible.

I am thrilled to report that this is changing! Today Unity (not to be confused with the painfully stupid desktop environment created for Ubuntu) is announcing that their editor now has a functional Linux build. But this isn’t even the first!

Coincidentally, this past weekend I had just managed to get the editor for the Unreal Game Engine working in Linux. I was able to make and play with a very simple 3d game based on their demos. This is a huge milestone for Linux and for me personally.

With developers free to use a proper OS like Linux for development it’s likely we’ll see a lot more games that actually work well on that platform. And you thought the Glorious PC Gaming Master Race was condescending. Ha! You ain’t seen nothing. This is going to be a lot of fun!


For older posts and RSS feed see the blog archives.
Chris X Edwards © 1999-2015