Ghidra: names and comments that record a decision
A placeholder name means you have not decided yet. A name you assign, and a comment you attach, are decisions stored in the program database. They should say what you know, at the size you actually know it.
Rename when the decision is real
Press L on a label in the Listing, or on a name in the decompiler, to edit it. The same action renames a function, a parameter, a local, or a data label, depending on the cursor. Choose a name you could defend from the bytes: load_config, path, port, status_text, default_config_path. Include a unit or a role if the role is not obvious. Avoid names that smuggle in a conclusion you have not shown, and avoid names copied from a blog about a different program.
If the binary was not stripped, many names are already real. They came in with the symbol table, and their source is imported rather than user-defined. Keep them. Add a comment if you want to record something the symbol does not say. Replacing an imported main with a clever nickname throws away the strongest fact in the file. On a stripped copy, main is gone and the name you assign is explicitly your conclusion. Say so in the plate comment: “named from the __libc_start_main argument and the config string.”
What survives another analyzer pass
A rename from the L action is stored as a user-defined symbol. Auto-analysis is built to leave those alone and to feel free to replace its own placeholders. If a script or a bulk action sets names with an analysis source type, the next pass can overwrite them. When a name disappears, open the symbol and look at its source before you assume the tool discarded your work. The fix is to set the name again as a user name.
Comments survive analysis too. They do not survive a failure to save the program, which is a later lesson and an easy way to lose an hour. The names in this lesson live in memory until you save. The habit is to rename a small batch, check that the decompiler still reads cleanly, and save.
Lab: three names and a plate comment
In harbor-check, rename the function that chooses the config path, the function that opens the file, and the string label for the default path. Use the names from the diagram if your reading matches them, or better names if your build inlined one of the functions. Add a plate comment on the file-opening function that states the status codes you can actually see: what 0, 1, and 2 mean, in a single sentence each, only for the codes the branches return.
Run Analysis > Auto Analyze with the defaults and confirm the three names are still there when it finishes. Then close the program without a detour into other files, and answer the prompt about saving by saving. Reopen the program. The names and the plate comment should greet you. If they do not, the save did not include this program, and that is the fact to sort out before any more reading.
Diagram
From a placeholder to a sentence someone else can use
- Placeholder
FUN_, DAT_, LAB_, param_1, and local_14 are the tool’s way of saying “unnamed.”
- Decision
You rename when you can say what the address is for. L edits the label under the cursor.
- Comment
The semicolon opens a comment. Plate comments sit on a function. Repeatable comments travel to references.
- Keep
A user-defined name is kept when analyzers run again. The name is still only in the database, until you save the program.
load_config the function that fopen()s the path path the char* that receives the config path status_text the function that returns "ok" / "missing" / ... default_config_path the string "/etc/harbor/check.conf" Skip names like fixed, bypassed, or main_maybe_hacked. Those record a wish. A name records a decision you can point at.
load_config the function that fopen()s the path path the char* that receives the config path status_text the function that returns "ok" / "missing" / ... default_config_path the string "/etc/harbor/check.conf" Skip names like fixed, bypassed, or main_maybe_hacked. Those record a wish. A name records a decision you can point at.
Check yourself
1. You understand the function that calls fopen on the config path. What is a sound name to assign with L?
2. You want a one-line summary to appear above the function in the Listing, and also to be readable as the function’s own note. Which comment?
3. You rename a function, run Auto Analyze again, and the new name is gone, replaced by a fresh FUN_ label. What is the likely cause?
Five places a comment can sit
The semicolon opens the comment dialog. Ghidra distinguishes plate, pre, end-of-line, post, and repeatable comments. Plate is the banner on a function, the right place for a one-sentence summary. Pre sits just above an instruction, useful for a branch’s purpose. End-of-line sits on the row. Post sits just after. Repeatable is stored on a code or data unit and is shown again at the places that reference that unit, which makes it the right comment for a constant or a string whose meaning you want at every use.
A comment that restates the mnemonic helps no one. “This calls fopen” under a call to fopen is noise. “Returns 1 when the file is missing, 2 when the line does not parse” is a decision. Tie the comment to evidence you have, and keep it short enough that the Listing can still be read. Long reasoning belongs in the lab notebook. The database holds the conclusion.