Ghidra | NSA Ghidra | Reverse Engineering library

You can only do rename in a fully defined function. The grey background means that Ghidra didn't properly create a function at this point. You can see this also in a disassembly where you only have a label at this location. If you think this is a function you can type F and define a function. It should enable all the edit options.

In regular C code, execlp("tidy","tidy","-asxml",0); is incorrect as execlp() expects a null pointer argument to mark the end of the argument list.

0 is a null pointer when used in a pointer context, which this is not. Yet on architectures where pointers have the same size and passing convention as int, such as 32-bit linux, passing 0 or passing NULL generate the same code, so sloppiness does not get punished.

In 64-bit mode, it would be incorrect to do so but you might get lucky with the x86_64 ABI and a 64-bit 0 value will be passed in this case.

In your own code, avoid such pitfalls and use NULL or (char *)0 as the last argument for execlp(). But on this listing, Ghidra produces code that generates the same assembly code, and in 32-bit mode, passing 0 or (char *)0 produce the same code, so no problem here.

In your context, execlp("tidy","tidy","-asxml",0); shows another problem: it will look for an executable program with the name tidy in the current PATH and run this program as tidy with a command line argument -asxml. Since it changed the effective uid and gid, this is a problem if the program is setuid root because you can create a program named tidy in a directory appearing in the PATH variable before the system directories and this program will be run with the modified rights.

Another potential problem is the program does not check for failure of the system calls setreuid() and setregid(). Although these calls are unlikely to fail for the arguments passed, as documented in the manual pages, it is a grave security error to omit checking for a failure return from setreuid(). In case of failure, the real and effective uid (or gid) is not changed and the process may fork and exec with root privileges.

This:

I think I found something.. In the "Listing" view the used local-variable layout is shown as a comment under the function's header. It seems that by right clicking on a respective local-var line in that comment, "set data type" can be applied to a respective local variable. Ah, and then there is what I've been looking for under "Function/"Edit stack frame" :-)

Seems it is some variation of a pow(x,y) implementation (see How can I write a power function myself? ). Ghidra just made a total mess of it in the decompiled code view.

Tracing the results in the debugger the performed functionality is indeed:

pow((float10)DOUBLE_00430088, (float10)param_1[0x58])

Issue happened because I removed the decompile file while installing ghidra for the first coz gatekeeper in my Mac prompted me to remove it as it was from github. Solution to this issue is to allow it in the Security & Privacy . Thank you @Robert for ur inputs and ur time. U saved me ton of time.

Clicking "Allow Anyways" without removing decompile fixed the issue for me.

You can tweak the Ghidra reverse result by edit variable type. Based on scanf const string %32s your local_38 should be char [32].

Before the first if, there are some char swap.

And the first if statment give you a long constrain of flag

At this point, you can confirm part of flag is FARADAY{d0ubl3_@nd_f1o@t, then is ther main part of this challenge.

It print x, y, z based on the flag, but you'll quickly find x and y is constrain by the if, so you only need to solve z to get the flag, so you think you need to bruteforce all double value limit by printable ascii.

But there are a limitaion in if statment says byte0 of this double must be _ and a math constrain there, simple math tell dVar2 - 4088116.817143337 <= 1.192092895507813e-07 and it comes dVar2 is very close 4088116.817143337 And byte 3 and byte 7 in this double will swap

By reverse result: dVar2 = y*y*x*x/z, solve this equation you can say z must near 407.2786840401004 and packed to little endian is `be}uty@. Based on double internal structure format, MSB will affect exponent, so you can make sure last byte is @ and it shows byte0 and byte3 is fixed now by constrain and flag common format with {} pair.

So finally, you only need to bureforce 5 bytes of printable ascii to resolve this challenge.

I think what you are referring to are the questions mark like in this screenshot:

This just means that the datatype of the data at this address is not yet defined in any way. For example, if you specify the data at this address to be of the type QWORD it will state dq and look like this:

if it is a string it will contain ds and look like this

You can, but you'll have to change some of the types to be standard C, or just add typedefs like so: