Moving to Static Content

If my site is looking a little different today, that’s because I’ve redone it from scratch. Gone is WordPress, gone is PHP.

Like many others, I’ve started using a static site generator, in this case Jekyll. Static content makes a lot more sense, and a lot of things I wanted to play around with on my previous blog I didn’t get to do because WordPress fought me most of the way.

Things are simpler here. There is no JavaScript. I’ve abandoned any kind of in-page analytics because I don’t value it more than I value other people’s privacy. Here, all we have is static HTML and CSS.

No JavaScript, dynamic content, or assets from other domains means I can have a plain and simple Content Security Policy, which I effectively couldn’t do with WordPress due to the mess of inline CSS and JavaScript that were thrown around.

It also means I can enable brotli on everything.

Finally, there is a real deploy process for this. No more manually crushing images and creating WebP variants of the image by hand. This all happens automatically, behind the scenes.

Making it Work

The site’s content is now on GitHub. On commit, GitHub notifies AWS CodeDeploy, which pulls down the repository to the EC2 instance and kicks off the build. It starts as a gulp task, which runs Jekyll, then compresses images and creates WebP copies. The repository also contains the NGINX configuration, which CodeDeploy copies to the correct location and then reloads NGINX.

AWS CodeDeploy works pretty well for this. It’s a tad difficult to get started with, which was a bit discouraging, but after reading the documentation through a few times it eventually clicked and I was able to get it working correctly.

The migration has left some things missing, for now, such as comments, but eventually I’ll bring those back.

Authenticode Stuffing Tricks

I recently started a project called Authenticode Lint. The tool has two purposes. The primary one being, “Am I digitally signing my binaries correctly?” and two “Are other people signing their binaries correctly?”

To back up a bit, Authenticode is the scheme that Microsoft uses to digitally sign DLLs, EXEs, etc. It’s not a difficult thing to do, but it does offer enough flexibility that it can be done in a sub-optimal way. The linter is made up of a series of checks that either pass or fail.

When you sign a binary, the signature is embedded inside of it (usually, there are exceptions). The goal of the signature is to ensure the binary hasn’t been tampered with, and that it comes from a trusted source. The former presents a problem.

If I were to take a binary, and computer a signature on it to make sure it hasn’t changed, then embed the signature in the binary, I just changed the contents of the binary and invalidated the signature I just computed by embedding it.

To work around this problem, there are some places inside of EXEs that the digital signature process ignores. The notable one being the place that signatures go. So the section that signatures go is completely ignored, as is the checksum of the file in the optional header.

Now we have tamper-proof binaries that prevent changing the executable after its been signed, right?

Ideally, yes, but unfortunately, no. There are some legitimate reasons to change a binary after its been signed. Some applications might want to embed a per-user configuration. Re-signing the executable on a per-user basis is to costly in terms of time and security. Signing is relatively fast, but not fast enough to scale reasonably. It would also mean that to perform the re-sign, the signing keys would need to be available to an automated system. That’s generally not a good idea, as a signing key should either be on an HSM or SmartCard and always done by one (or more if using m/n) person manually.

It turns out it is possible to slightly modify an executable after its been signed. There are a few ways to do this, and I’ll cover as many as I know.

xchg rax, rax – 0x04

Moving along onto page 0x04, we have something different from our last two. It’s also quite short:

xor      al,0x20

That’s it, in its entirety. The al register is the lower 8 bits of the eax/rax register. Let’s demonstrate with LLDB:

register write rax 0x123456789abcdef0

rax = 0x123456789abcdef0
eax = 0x9abcdef0
ax = 0xdef0
ah = 0xde
al = 0xf0

OK, so now we know what the al register is. Now its a matter of trying to figure out what the purpose of xor’ing it with 0x20 might be. Let’s see how 0x20 might be special. It helps to look at it in a few different base representations. 0x20 is base-16, and in base-10 it’s 32, and in binary it’s b00100000. Exactly one bit. So what the xor is doing is toggling the 6th bit.

That information alone is enough to Google what the intention is. Before you do though, here’s a hint. Take a look at an ASCII table, and look at the letters in binary form.

Thanks to the handy layout of the ASCII table, we can see that the xor toggles whether a letter is uppercase or lowercase.

xchg rax, rax – 0x03

Now we are on to page 0x03. This one has a little bit more going on, but the previous post prepares us for it.

Here is our code:

sub      rdx,rax
sbb      rcx,rcx
and      rcx,rdx
add      rax,rcx

Our first instruction is sub, which is subtract. It subtracts the second operand from the first operand, and stores it in the first operand. It affects quite a number of flags, too, including CF. We know from the previous post that the following instruction, sbb, pays interest to the CF flag.

x86 uses CF as a borrow flag. Meaning, if you do a-b and a is less than b, then CF is set.

Bringing this back around to our original snippet, we can assume that the second instruction will behavior differently depending on if rdx is less than rax.

Again borrowing knowledge from the last page, we know what sbb will do when both operands are the same and if the carry flag is set or not. Let’s start with the first two instructions.

We have two test cases, so we’ll run through it twice.

Here is a case where rdx is greater than rax:

xchg rax, rax – 0x02

Moving on to 0x02, we have another short but more subtle program:

neg      rax
sbb      rax,rax
neg      rax

We have two unique instructions, all dealing directly with the rax register.

Starting with neg, this is a two’s complement negation. It’s functionally equivalent to subtracting the value from zero. It also sets the cf flag (carry flag) if the source is zero to zero, otherwise it sets cf to one.

sbb is the next instruction, or subtraction with borrow. The Intel Instruction Reference has a good description of this, “Adds the source operand (second operand) and the carry (CF) flag, and subtracts the result from the destination operand (first operand). The result of the subtraction is stored in the destination operand. The destination operand can be a register or a memory location; the source operand can be an immediate, a register, or a memory location. (However, two memory operands cannot be used in one instruction.) The state of the CF flag represents a borrow from a previous subtraction.”

Let’s start by observing the affect of just the first two instructions and see how they work. We know from the descriptions of neg that we can expect different behaviors whether or not rax is zero, so let’s try it with one and zero and see what the results are.

Initial:
rax = 0x0000000000000000
rflags = 0x0000000000000202 (CF = 0)

Step (neg):
rax = 0x0000000000000000
rflags = 0x0000000000000246 (CF = 0)

Step (sbb):
rax = 0x0000000000000000
rflags = 0x0000000000000246 (CF = 0)

And let’s try it when rax is 1:

Initial:
rax = 0x0000000000000001
rflags = 0x0000000000000202 (CF = 0)

Step (neg):
rax = 0xffffffffffffffff
rflags = 0x0000000000000297 (CF = 1)

Step (sbb):
rax = 0xffffffffffffffff
rflags = 0x0000000000000297 (CF = 1)

Tip: You can use print/t $rflags to see the individual flags in LLDB. We know that the Carry Flag is bit zero.

rax is zero, and negating zero is zero again, so zero gets set in the destination. We can also see that CF is set to zero. Next is sbb. It adds the source (rax) and the carry flag. Zero plus zero is zero, then zero is subtracted from zero and stored in rax, which is zero.

A whole lot of zeros.

Now for the second example. We start with 1 and negate it, so -1. In two’s complement that’s 0xffffffffffffffff. We also see that the CF is set to 1. Next for sbb, we add -1 and the CF flag, so, back to zero. But we haven’t done the subtraction yet. So subtract zero from -1, and we are still left with -1, which is what we see in rax.

OK, but we still have a final neg left. We can easily determine that the negative of zero is zero for the second example, -1 negated is back to 1.

In both cases, we end up right back to where we started. Doesn’t seem spectacularly interesting. Let’s try a random-ish value for rax, like 89.