It’s a fascinating story of how Bitcoin came to be and follows the paths of the different persons around the cryptocurrency from the very beginning of it. The book covers the story, specifically, and is not a technical guide to blockchain or whatever. It starts from the Nakamoto’s paper and how he tried to get people interested in it and goes through the early years of development, the people behind it, the firms spun up for it, legislative reception, and also the whole Silk Road case with Dread Pirate Roberts and so on. Also, it covers lots of different products multiple firms made for the Bitcoin ecosystem and how they were received, what problems they had, and where they are now (if they still are, that is).

It’s a very nice read and gives you thorough understanding of the whole thing. I had had a small itch for understanding Bitcoin better but never took the time to truly study the inner-workings of it. This book got me very excited about it and gave a very good introduction to it via the history. Now I’ve got my hands on Blockchain Revolution, which is not a story but a true technical book that covers what’s next in the blockchain world. If you’re not interested in Bitcoin’s history, I recommend this one.

Amazon listing, Goodreads

The post Bitcoin book recommendation appeared first on Pietari Heino's personal website.

So back in the day CPU architectures introduced the stack in order to allow better control of the programs’ execution flow and for instance make recursion possible (if it’s not clear for you, read this post and try to come up with the reason why you cannot have recursion without the stack!). Nowadays stack is a must and you cannot find a piece of hardware executing software without a stack (as far as I know). The stack is interesting. It grows with the push operations and decreases with the pop operations. Every time the CPU calls a new function the stack is grown and every time the execution of a function is over the stack is decreased. What goes in there, specifically, are the local variables for a function and the return address to use after the execution. So lets say the CPU calls a void function called count that is supposed to print numbers from 0 to 10. What we push to the stack is the return address which is the address of the next instruction that is supposed to be executed right after the function is done and space for the count’s local variables (it supposedly needs a loop and a loop variable). When count is done, we decrease the stack with pop operation which then gets rid off the count’s local variables and returns the execution to the location pushed to the stack earlier. It grows dynamically, so to say, and the whole thing is really interesting, the way it works and the cleverness of it. It’s automatically grown and decreased and always keeps each functions’ environments intact and stores the addresses for continuing execution. It’s very simple but really powerful at the same time.

Stack exploiting trampoline, (c) Ars Technica

The problem is… what if an adversary party could write some malicious code into your stack and override the bits that holds the information where to go next? Specifically, overwrite the return address from the stack with a return address of the party’s own. That would inherently make the control flow jump to execute whatever the malicious party wanted. That’s what bad guys started doing and which lead to DEP and ASRL. DEP stands for Data Execution Protection, a technology which separates the dynamic, software written data from the instructions that the CPU is going to execute. ASRL stands for Address-Space Layout Randomization, which changes the location of the software, the kernel code, the operating system’s libraries, and so forth, in the RAM so that the malicious party cannot know where certain pieces of software logic lies in the address-space which makes the use of known locations of useful code a no-go for execution. DEP and ASRL are both themselves really fascinating stuff and if you’re interested, go check them out in more detail, my few words here don’t really get you covered on them at all.

Return-Oriented Programming (ROP) is a way of getting control of the stack and changing bits and pieces of software logic towards the end of subroutines so that the CPU would then execute code that would diverge the program flow to an adversary route. That would of course, done correctly, lead to takeover of the operating system since the malicious party could execute whatever it wishes. Now Intel and Microsoft have come up with a new piece of fascinating technology called Control-Flow Enforcement Technology that adds more protection specifically to the stack operations. There are two new things to fight the problem:

1. ENDBRANCH instruction is added to the new x86/x64 architecture instructions sets. When the software is compiled with a CET supporting compiler that targets new CPUs, all legal (valid) calls and jumps are directed to an endbranch instruction. That is to say that whenever a subroutine is called, the first instruction to be found inside the subroutine must be an endbranch. If it’s not, the CPU throws an exception and the hell breaks loose. So the program gets compiled in a way that the subroutine/call/jump flow is enforced to obey the original intent of the programmer – thus the name Control-Flow Enforcement. Today’s processors can return to any valid place the kernel lets them to return to no matter what instructions lie there, but that’s going to be changed with CET. That makes it impossible for an attacker to redirect the program flow for example into middle of a library or so that could then lead to overtake. The brilliance of the endbranch instruction is that it’s implemented as a NOP in all the current Intel chips so it’s 100 % backwards compatible and requires no tricks from the software programmer.
2. Shadow stack which is a separate, hidden, you-cannot-touch-me stack living along the usual stack. For all the calls and jumps the software makes the return addresses are pushed to the stack but on the new chips they are also pushed to a new shadow stack – which happens automatically. Then when the pop op comes and it’s time for returning to a previous location, the CPU checks whether both the shadow stack and the normal stack have the same return address or not. If they match, ok, continue execution. If they don’t match, it means that someone has had their fingers on the normal stack’s return address and that all execution should be stopped. The programmer has no any sort of control over the shadow stack, it just operates in the background and is implemented in the hardware so that you cannot trick it nor touch it.

Together these two additions will make it absurdly hard to alter the execution flow.

If you found any of this interesting, do your homework for DEP, ASRL, CET and before that, take a look at Ars Techinca’s brilliant article How security flaws work: The buffer overflow. That’s a really nice piece on the whole stack and the security questions around it and gives you many pointers for more things to discover.

Some links: Intel’s blogposting, ROP on Wikipedia, TWIT.tv episode of Security Now

The post Control-flow Enforcement Technology to fight against ROP appeared first on Pietari Heino's personal website.

This struck me as something extraordinary wicked. No kidding.

In the past:

1. Your friend sends you a link to a website / you read about something interesting and head to a website
2. The website has a dedicated app… which is compulsory to install in order to view the content
3. You freak out, you get angry, you shake your head
4. If the content was interesting enough, you might install the required app
5. After a minute or so, you get to the content inside the app
6. … just to realize you probably lost the original link and you have to get to it again from search, messaging etc.
7. Afterwards, you have to get rid off the app
8. During the uninstallation process you realize you might have given the app a vast amount of personal information by the required permissions you had to agree to in order to get to the goddamn content you wanted to see in the first place

That, above, is horrible. Rubbish. The flow is pathetic.

Enter Android Instant Apps…

1. You get a link from somewhere
2. You click it
3. Android automatically opens the dedicated app but *only* downloads the needed pieces of software in order to display you the content you were after
   1. You can use the app more, you can go to other sections etc.
   2. Android seamlessly downloads the needed pieces on the go
   3. No installation, no uninstallation, no nothing, just pure… something
4. When you’re ready, just exit

From my personal experience I really do vouch for this sort of features. The barrier to get into the actual content lowers so much when you are not required to waste your time, bandwidth and nerves downloading and installing useless one-shot applications that this should convert to vastly superior user experience (and more revenue, I suppose).

Ahh how I love Android.  Ps. This goes back to Android 4.2.

Ars Technica coverage, Android dev docs

The post Android Instant Apps: the best new feature in any platform appeared first on Pietari Heino's personal website.

Six months ago my work buddy wanted to hack something together and he started out with Ractive since I knew it and I could help him a bit. There was something he didn’t like about in Ractive (documentation being one) and he searched for something else. He ended up doing his exercise with Vue which has a couple of things in common with Ractive, eg. {{Mustache}} templating. Vue.js, as the man behind it puts it, is a front-end framework that consists of a core view layer and accompanying tools & supporting libraries.

During the past couple of months I got really interested in Vue and have had this longing feeling of a need to learn something new. Enter Vue 2.0 announcement, a couple of hours of weekend hacking for an MVP, and I’m hooked. It plays nicely with the way I think and seems to be a rich framework with a massive community. They have all the bells and whistles one could ask for and they’re moving forward at a constant pace. Their documentation is good, too.

My plan now is to hop on to the Vue 2.0 train as it nears arrival in late May or early June. I’m sure I cannot hold my fingers of the keyboard until then so I’ll probably have a bit of experience when 2.0 beta ships and the accompanying tools are upgraded. I’m really excited and I already have one little project and an idea (that still needs some working on the edges) for another one in mind.

Bring it on.

The post Excited about Vue.js 2.0 appeared first on Pietari Heino's personal website.

Zero-bullshit. Faster than a bullet. Surge is perfect.

Looking for a reliable, easy to use, and free hosting provider for your static web pages or single page app (SPA)? Or are you one of those people who would like to see GitHub Pages support HTTP 200 response for client-side routing instead of spoiling your urls with !#? I urge you to try surge.sh.

Very shortly, surge.sh gives you:

• static site hosting (single-page or the old way, you decide)
• automatic cache-busting
• your-nickname.surge.sh or custom domain
• free SSL/TLS *
• clean URLs
• custom 404 not found and 200 fallback pages
• by far the easiest and fastest deploying straight from the terminal

If you know your way around, just npm install -g surge and surge /path/to/the/site-dir/ and you’ll be setup sooner than ever before.

Surge also has a paid-plan for 13 $ / month which gives you even more features. One of those things is securing your custom domain with an HTTPS connection (SSL/TLS). If you don’t want to pay, you can still use CloudFlare’s Universal SSL for your custom domain. That, of course, doesn’t give you HTTP Strict Transport Security (HSTS) or force-redirects from HTTP to HTTPS, but is better than nothing.

Surge works so nicely that I suggest you to check out their tour and deploy even a sample app if you don’t have anything at your fingertips – for you will be hooked in no-time…

If you have something to add or know of another no-bullshit provider, drop a comment.

The post Static site hosting with custom domain, clean URLs, and deploying in <6 seconds: Surge.sh for the win appeared first on Pietari Heino's personal website.