Skip to content

Latest commit

 

History

History
49 lines (32 loc) · 1.87 KB

restaurant.md

File metadata and controls

49 lines (32 loc) · 1.87 KB
description
08/25/2023

🍽 Restaurant

Challenge

{% embed url="https://app.hackthebox.com/challenges/restaurant" %}

Description

Welcome to our Restaurant. Here, you can eat and drink as much as you want! Just don't overdo it..

Enumeration

file:

{% code overflow="wrap" %}

restaurant: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=34d48877c9e228a7bc7b66b34f0d4fa6353d20b4, not stripped

{% endcode %}

  • 64-bit
  • Dynamically linked to the libc library
  • Non-stripped binary (makes our life easier to reverse)

checksec:

[*] '/home/xyco/Projects/HTB/Restaurant/pwn_restaurant/restaurant'
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

The only memory protection put in place is the No Execute (NX) bit. This means that we do NOT have an executable stack and therefore cannot execute custom shellcode on the stack.

This sounds more than likely to be a possible ret2libc challenge. Let's dig in some more.

Why do I think this challenge is a ret2libc one?

The reason I say ret2libc is because a common bypass for the NX bit set on a binary is to divert execution into the libc library as long as the file is dynamically linked, which it is!

Reversing