Skip to main content

control.rip

About

Hello there! My name is Stephen. I am very passionate about computer security, privacy, and open-source software. You can typically find me working on security-related projects with a bit of automation sprinkled in.

Table of contents

Project highlights

  • brkit - A Go library that assists in conducting binary research
  • raygun - Securely write to the stdin of a process being debugged by radare2
  • finley - Extends the CLI implementation of ILSpy, making it easy to quickly decompile several .NET libraries concurrently without involving a GUI

Open-source

Social networking

The blog name

Originally, I chose “0x2d13” as the blog name (I leave discovering the meaning of that to the reader). I realized the name was difficult to communicate to people and decided that a new name was needed.

In binary exploitation, one of the main objectives is to gain control of the instruction pointer CPU register (confusingly, this is also known as the program counter, or PC). This register points at the current executing instruction. It is basically game over if you can control the value stored in this register. In 64-bit x86 CPUs, this register is named “RIP” (as opposed to “EIP” on 32-bit x86 CPUs). Hence, “control.rip” is a goal to strive for :)

In fact, the “RIP” acronym can also refer to the memory address that the ret (return) instruction uses to return control flow back to the parent subroutine. If we can overwrite or modify the saved return instruction pointer (RIP), ret will return control flow to code of our choosing. This strategy is known as “return-oriented programming” (ROP) and it is the basis for many modern exploits.

Lastly, the blog name can also hint at someone’s control over a process resting in peace. Like Zack de la Rocha would say: “Yo, we gotta take the power back!"

Editorial policies

While this is a personal blog, I try to hold my writing to a high degree of quality. I will issue corrections for mistakes and incorrect information. In addition, I will cite supporting and referenced works in a consistent format.

The following sections describe these policies in detail.

Updates and corrections

Changes to a blog post after publishing will appear immediately after the blog post’s main content in a section named “Updates and corrections”. This section will consist of a bulleted list of changes, with the most recent change note appearing at the top of the list. Each item in the list will be in the following format:

- <Month-name> <Day-number>, <Year> - <Note describing the change>

Here is an example section updates and corrections section:

Updates and corrections

- January 1, 2021 - Fixed typo in introduction
- December 24, 2020 - Add missing list

Changes will be dated when I make them to the blog post’s source file(s). The date does not reflect when the change appears on the Internet.

Appendices

Additional information that could not fit in the blog post’s main content will appear in a section named “Appendix” after Updates and corrections. The structure of this section may vary from post-to-post.

References

Referenced works that support a blog post will be documented in a section that appears at the very end of the blog post named “References”. This section will consist of a numbered list. Each item in the list will document a reference. The references section format and citation format is a custom style focused on readability. It balances rendering on various screen sizes, limitations of the blog-generation tooling I use, and ease of maintainability in plain text.

The references section formatting is mainly based on Chicago Manual of Style’s author-date system. Generally speaking, each referenced work will consist of the following format:

1. <Author-name-with-optional-hyperlink-to-source>. <Date-published>. "<Work-title>".
2. <Author-name-with-optional-hyperlink-to-source>. Accessed: <Date-accessed>. "<Work-title>".

Here is an example references section:

References

1. developer.apple.com. Accessed: 2020, March 16. "Authorization Services".
2. Wardle, P. 2020, March 16. "Sniffing Authentication References on macOS".

As noted above, URLs of works published on the Internet will appear as an embedded hyperlink in the author portion of the reference. The reasoning for this is because long strings without spaces (such as a URL) can cause web browsers to render the blog post with a long, horizontal scroll area. This makes reading the blog post unpleasant, especially on devices with small screens where scrolling is controlled by touch. For example, scrolling downward with your finger might result in scrolling left or right to an empty area containing no text.

Referenced works mentioned in the blog post will be followed by a footnote reference. This will appear after the end of the associated sentence that mentioned the work. The footnote itself will hyperlink to the references section. This is loosely based on Wikipedia’s footnote citation style. Each footnote follows the end of a sentence with a space - the corresponding reference number is flanked by brackets:

<Sentence-referencing-work>. [Number-of-documented-reference] <Next-sentence>.

Here is an example reference footnote:

In Wardle's "Death by 1000 Installers; it's all Broken!" presentation, he
discussed the unfortunate usage of `AuthorizationExecuteWithPrivileges` by
several installers. Therein, he referred to this vulnerability class as
"user-assisted privilege escalation". [2]

This style aims to make citations readable without interrupting the reader, while still presenting the option for the reader to easily find their way back to detailed information about the referenced work. It also clearly signals what is a reference, and distinguishes itself from blog post content.

Thank you for reading,

  • Stephen