AP Cybersecurity Command Line Guide

This guide collects the command-line patterns you may need to read or write on the AP Cybersecurity Exam. When a free-response task uses the verb Write, you must express in print form a proper command that produces the indicated effect, so knowing exact syntax matters.

These commands map directly to defensive tasks from Units 4 and 5: setting file permissions, encrypting and decrypting data, generating keys, and verifying file integrity with hashes. You will also need to read command output as evidence when analyzing a device.

Where Commands Show Up on the Exam

The Section II Device Security Analysis question gives you several sources from one device, such as file-system permissions, firewall configurations, and log files. You analyze those sources to identify security issues and describe how permission or configuration changes affect users and the device.

Skill Categories 2 and 3 are assessed in the FRQ, which means you focus on mitigating risk and detecting attacks. Multiple-choice items also include technical artifacts like file-permission strings and hashing function outputs, so you need to read these fluently.

The Write task verb is the one that requires you to produce a command yourself. The other verbs (Identify, Explain, Describe, Determine) ask you to analyze sources and reason in prose.

Reading File Permissions with ls -l

Before you change permissions, you need to read them. The ls -l command lists files in long format and shows the permission string for each one.

</>Code
$ ls -l
-rwxr-xr-  1 root  randd   4096  research.txt

drwxrwx--  2 lead  randd   4096  Formula

Read the permission string from left to right. The first character is the file type: - for a regular file, d for a directory. The next nine characters are three groups of three: owner, group, and others.

So -rwxr-xr-- means the owner has read, write, and execute, the group has read and execute, and others have read only. That maps to the octal value 754.

Changing Permissions with chmod

The chmod command changes file or directory permissions. You can use octal numbers or symbolic notation, and the AP scenarios often describe access in terms of who gets read, write, and execute.

Each permission has a value: read is 4, write is 2, and execute is 1. Add them per group to build each digit.

For a worked example, take Scenario 5A's /RandD/Formula directory: the head researcher (owner) gets read, write, execute; the R&D team (group) gets read and execute; everyone else gets no access. That is 7 for owner, 5 for group, 0 for others.

</>Code
$ chmod 750 /RandD/Formula

Symbolic notation works too when you only want to adjust one group. For example, chmod g+x file.sh adds execute for the group without touching other permissions.

When you write a chmod command on the exam, translate the described access into the correct digits and confirm the path matches the source. A common slip is reversing group and others.

Viewing Detailed Permissions with getfacl

Standard permissions only cover one owner, one group, and others. When a system uses access control lists for finer-grained control, getfacl displays the full list of named users and groups with their permissions.

</>Code
$ getfacl /RandD/Research
## file: RandD/Research
## owner: lead
## group: randd
user::rwx
group::r-x
other::--

Use getfacl to read what access exists, then reason about whether it matches the security policy. If a source shows other::--, users outside the owner and group have no access, which supports confidentiality goals.

Verifying File Integrity with Hashing Commands

Hashing helps you detect whether a file has been altered, which is learning objective 5.6.D. A hash function produces a fixed-length digest; if even one byte changes, the digest changes.

Common commands compute a file's hash so you can compare it to a known-good value.

</>Code
$ sha256sum research.txt
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08  research.txt

To verify integrity, compute the hash and compare it to the expected digest. If they match, the file is unaltered. If they differ, the file changed, which is an indicator of compromise worth reporting.

You can also use openssl to produce a digest:

</>Code
$ openssl dgst -sha256 research.txt

When you read hashing output on the exam, remember that hashes verify integrity, not confidentiality. A matching hash tells you the file was not changed, but it does not encrypt anything.

Encrypting and Decrypting with openssl

The openssl tool also handles symmetric encryption, which protects the confidentiality of stored data (objective 5.3.B). Symmetric encryption uses the same key to encrypt and decrypt.

To encrypt a file with a symmetric cipher:

</>Code
$ openssl enc -aes-256-cbc -in secret.txt -out secret.enc

To decrypt, add the -d flag and reverse the input and output:

</>Code
$ openssl enc -d -aes-256-cbc -in secret.enc -out secret.txt

The -in flag names the source file and -out names the destination. The cipher name, such as aes-256-cbc, must stay the same for both encryption and decryption.

Generating Asymmetric Keys

Unit 5 Scenario 5B has you generate an asymmetric key pair so two parties can communicate securely. Asymmetric cryptography uses a public key to encrypt and a matching private key to decrypt.

You can generate a key pair with openssl:

</>Code
$ openssl genrsa -out private_key.pem 2048
$ openssl rsa -in private_key.pem -pubout -out public_key.pem

The number 2048 is the key length in bits. Longer keys are harder to break, which is why key length impacts security (objective 5.4.B).

Remember the rule for asymmetric keys: you share your public key freely, and you keep your private key secret. To send someone an encrypted message, you use their public key; they decrypt with their private key.

Command Quick Reference

Common Mistakes to Avoid

Do not reverse the permission groups. The order is always owner, then group, then others, so chmod 740 gives the group read only, not full access.

Do not confuse hashing with encryption. Hashing verifies integrity and is one-way; encryption protects confidentiality and is reversible with the right key. Saying you will hash a file to keep it secret is a conceptual error.

Do not mix up the asymmetric keys. Encrypt with the recipient's public key and decrypt with the matching private key, and never share a private key. Mixing these up breaks the whole scenario.

When decrypting with openssl, remember the -d flag and keep the same cipher you used to encrypt. Leaving out -d or changing the cipher means the command will not produce the indicated effect.

Finally, match the exact file path from the source. A correct command pointed at the wrong directory will not earn the indicated effect, so copy paths carefully from the provided sources.