diff --git a/content/posts/arm-glibc-strlen.md b/content/posts/arm-glibc-strlen.md
index d8b807e..0444f98 100644
--- a/content/posts/arm-glibc-strlen.md
+++ b/content/posts/arm-glibc-strlen.md
@@ -7,7 +7,7 @@ draft: false
 I wanted to get back into ARM assembler so I wrote my own strlen. And then I looked at the strlen() glibc uses and did not understand
 a single thing. So I sat down and figured it out.
 
-XXX IMG HERE XXX
+![side by side comparsion](https://wacked.codes/img/arm-glibc-strlen/strlen-side-by-side.png)
 
 On the left you see a flow diagram of the building blocks of my naive implementation. On the right you see glibc's. You might
 notice that it is more complex. (How much faster it is, and which optimization exactly makes it fast is an interesting topic.
@@ -22,7 +22,7 @@ The first thing I noticed about the inner loop is that it is unrolled. That is a
 because strlen does not clearly unroll as the input is cleanly divisible by word size. So on the end of every basic block there
 is a check which skips out of the loop and to the end where the result is calculated and returned.
 
-XXX IMG HERE XXX
+![side by side comparsion](https://wacked.codes/img/arm-glibc-strlen/strlen-loop.png)
 
 The basic blocks are basically identical. First the registers r2 and r3 are populated with the next two words to be checked for
 the null byte. Now r2 and r3 each contain one word (i.e. 4 bytes). How do you check whether there is a null byte *somewhere* in them?
diff --git a/static/img/arm-glibc-strlen/strlen-loop.png b/static/img/arm-glibc-strlen/strlen-loop.png
new file mode 100644
index 0000000..cc17b8e
Binary files /dev/null and b/static/img/arm-glibc-strlen/strlen-loop.png differ
diff --git a/static/img/arm-glibc-strlen/strlen-side-by-side.png b/static/img/arm-glibc-strlen/strlen-side-by-side.png
new file mode 100644
index 0000000..be6e3d6
Binary files /dev/null and b/static/img/arm-glibc-strlen/strlen-side-by-side.png differ