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

Line 9: Stores the pointer returned from the
callocfunctionLine 11: Store the input from the
__isoc99_scanffunctionLine 12: Passed as argument to the
validate()function.
Lets rename pcVar1 to input_ptr .
b. undefined8 uVar2

Line 12: Return value from the
validate()functionLine 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

Line 13: Stores the value of the logical comparison
Line 14: Used in IF statement (
checkvariable needs to be equals to0) 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
If we input the value flag{HuCf_lAb} into the prompt, we will get the response: Right this way...
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
validate() functionLets 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=0x66)
Analyzing variables
a. Line 27
param_1is 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_50is larger thansVar1(length of the input argument to this function), setuVar2to 1, and return from function with the value ofuVar2Since the value of
uVar2equals 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_10variable, which will be checked right before the program exitscalls 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_1does not matchlocal_48, setuVar2to 0, and goto label LAB_00102b7Since the value of
uVar2equals 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