Helithumper RE (64-bit)

strings

strings rev
/lib64/ld-linux-x86-64.so.2
libc.so.6
puts

...

Welcome to the Salty Spitoon
, How tough are ya?
Right this way...
Yeah right. Back to Weenie Hut Jr
 with ya
;*3$"

...

Ghidra

1. Decompiled "main"

  • With basic comments

2. Steps in cleaning up the "main" code

2.1 Variables

a. char *pcVar1

  1. Line 9: Stores the pointer returned from the calloc function

  2. Line 11: Store the input from the __isoc99_scanf function

  3. Line 12: Passed as argument to the validate() function.

Lets rename pcVar1 to input_ptr .

b. undefined8 uVar2

  1. Line 12: Return value from the validate() function

  2. Line 13: Compared with the value 0

  • Since this value is compared with an integer (value 0), we can change its type to int

Lets rename it to check too.

c. bool bVar1

  1. Line 13: Stores the value of the logical comparison

  2. Line 14: Used in IF statement (check variable needs to be equals to 0) to pass the test condition

We can simply remove this variable and merge the IF statement:

2.2 Function calls/arguments

a. Line 10: puts(&DAT_00102008)

  • Address from "Listing" view at DAT_00102008, we can see the string Welcome to the Salty Spitoon ... :

b. Line 11: __isoc99_scanf(DAT_001203b, pcVar1)

The variable &DAT_001203b variable simply points to a memory address which stores the value %s .

c. Line 12: validate(input_ptr)

Refer to the section below for the analysis of this function.

d. Line 15: puts(&DAT_00102050)

Address from "Listing" view at DAT_00102050, we can see the string Yeah right Back to Weenie Hut Jr ... :

From this, we have the following information

  1. If we input the value flag{HuCf_lAb} into the prompt, we will get the response: Right this way...

  2. If we input an invalid value (not the flag), we will get the response: Yeah right. Back to Weenie Hut Jr™ with ya

Final refined code

Taking a look into the validate() function

Lets take a look into the validate() function:

Right off the bat, we notice an interesting variable: local_48 . It seems to be assigning each pointer index of the variable with a hexadecimal value, to form a string.

The final string is: 0x66, 0x6c, 0x61, 0x67, ... which forms the value flag{HuCf_lAb} . (https://www.rapidtables.com/convert/number/hex-to-ascii.html?x=0x66arrow-up-right)

Analyzing variables

a. Line 27

  • param_1 is the argument to the validate function

b. Line 28

Analyzing IF statements

Looking at the do-while loop, we can see 2 outer IF statements.

1st IF statement:

a. Outer IF statement

  • When the value of local_50 is larger than sVar1 (length of the input argument to this function), set uVar2 to 1, and return from function with the value of uVar2

    • Since the value of uVar2 equals 1, this will NOT match the first IF statement in the main function, and go into the ELSE block

b. LAB_001012B7 goto statement definition

  • The goto definition which will be called later on (refer to the 2nd IF statement section below)

c. Logic defined within the LAB_001012b7 goto defintion

Before we discuss this line, we need to take a look at 11 from the validate function before:

  • IN_FS_OFFSET: a compiler-generated variable that points to the FS register (x86-64 Linux), that is used to access multiple data. In our case, this value would be the stack canary (or stack guard)

    • the stack canary is accessed with fs:[0x28] in assembly

  • Purpose of this line of code: loads the value in the stack canary to the load_10 variable, which will be checked right before the program exits

    • calls the __stack_chk_fail() function which will force the program to exit

  • The corresponding assembly code (retrieved from Ghidra) is:

2nd IF statement:

a. Outer IF statement

  • If any of the pointer index integer value (character) in param_1 does not match local_48 , set uVar2 to 0, and goto label LAB_00102b7

    • Since the value of uVar2 equals 0, this will match the first IF statement in the main function

b. goto LAB_001012b7

  • Call the goto statement definition discussed above

GDB

In this section, I aim to outline the basic commands used in GDB to disassemble and play around with the registers and memory addresses

Last updated