diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/crypto/hashcat.txt | 134 | ||||
| -rw-r--r-- | docs/nix/iptables.txt | 147 | ||||
| -rw-r--r-- | docs/nix/proxychains.txt | 10 | ||||
| -rw-r--r-- | docs/pwn/one_gadget.txt | 57 | ||||
| -rw-r--r-- | docs/re/ptrace_not_permitted.txt | 22 | ||||
| -rw-r--r-- | docs/re/radare2_cheatsheet.txt | 88 | ||||
| -rw-r--r-- | docs/re/rep_prefix.txt | 18 | ||||
| -rw-r--r-- | docs/web/api-testing.txt | 7 | ||||
| -rw-r--r-- | docs/web/curl-cheatsheet.txt | 89 |
9 files changed, 572 insertions, 0 deletions
diff --git a/docs/crypto/hashcat.txt b/docs/crypto/hashcat.txt new file mode 100644 index 0000000..2f969aa --- /dev/null +++ b/docs/crypto/hashcat.txt @@ -0,0 +1,134 @@ +hashcat is a hardware accelerated hash cracking tool + +useful one-liners mostly stolen from naive-hashcat: +https://github.com/Kr4ken-9/naive-hashcat/blob/master/naive-hashcat.sh +hashcat -I +hashcat --example-hashes | grep -A2 '\$5\$' +hashcat --show -m <type> <file> +# DICTIONARY ATTACK +hashcat --status -w 3 -m <type> -a 0 <file> dicts/rockyou.txt +# DICTIONARY ATTACK WITH RULES +hashcat --status -w 3 -m <type> -a 0 <file> dicts/rockyou.txt -r rules/d3ad0ne.rule +hashcat --status -w 3 -m <type> -a 0 <file> dicts/rockyou.txt -r rules/rockyou-30000.rule +hashcat --status -w 3 -m <type> -a 0 <file> dicts/rockyou.txt -r rules/dive.rule +# MASK ATTACK (BRUTE-FORCE) +hashcat --status -w 3 -m <type> -a 3 -i -1 ?l?d <file> ?1?1?1?1?1?1?1?1?1?1?1 +hashcat --status -w 3 -m <type> -a 3 -i <file> ?a?a?a?a?a?a?a?a?a?a?a +hashcat --status -w 3 -m <type> -a 3 <file> masks/rockyou-1-60.hcmask +# HYBRID ATTACK (DICTIONARY + BRUTE-FORCE) +hashcat --status -w 3 -m <type> -a 6 -i <file> dicts/rockyou.txt ?a?a?a?a?a?a?a?a?a?a?a +hashcat --status -w 3 -m <type> -a 6 <file> dicts/rockyou.txt masks/rockyou-1-60.hcmask +hashcat --status -w 3 -m <type> -a 7 -i <file> ?a?a?a?a?a?a?a?a?a?a?a dicts/rockyou.txt +hashcat --status -w 3 -m <type> -a 7 <file> masks/rockyou-1-60.hcmask dicts/rockyou.txt +# COMBINATION ATTACK +hashcat --status -w 3 -m <type> -a 1 <file> dicts/rockyou.txt dicts/rockyou.txt +# STDOUT/STDIN (for workload issues) +hashcat --stdout -w 3 -a 6 dicts/rockyou.txt masks/rockyou-1-60.hcmask | hashcat --status -w 3 -m <type> <file> + +general command structure: +hashcat [options] <file with hashes> [wordlist, mask, or mask file] [-r rule file] + +useful options: +-I -- list all installed opencl platforms and devices +--identify -- try to detect what type of hash is in the file +--example-hashes -- print out an example hash for each hash type +-D <num> -- specify a device type to use (1=CPU,2=GPU,3=FPGA) +-d <num> -- specify a device to use +-w <num> -- workload profile (1-4 where 1 is light on resources and 4 should be run headless) +-m <num> -- hash type +-a <num> -- attack type +-i -- enable increment mode for mask attacks +--increment-min <num> -- minimum length for incrementing +--increment-max <num> -- maximum length for incrementing +-1 <charset> -- custom charset 1 +-2 <charset> -- custom charset 2 +-3 <charset> -- custom charset 3 +-4 <charset> -- custom charset 4 +-r <file> -- rules file +-j <rule> -- in combinator attack, use single rule for left dictionary +-k <rule> -- in combinator attack, use single rule for right dictionary +-o <file> -- output file +--status -- automatic update of status screen +--show -- if a hash has already been cracked and saved, print it +--stdout -- don't crack, just print out candidates. useful to generate a wordlist for another program +-g <num> -- randomly generate some number of rules + +Hash Type +You specify what is in your file (e.g. an MD5 hash, an /etc/passwd file, a WPA handshake, etc.) with -m +You can try to use the --identify and --example-hashes flags to figure out what to use. +There is also a list of all of the modes in the man page and help output. +short list of some useful ones: +0 - MD5 +500 - md5crypt ($1$) +1 - SHA1 +1400 - SHA256 +7400 - sha256crypt ($5$) +1700 - SHA512 +1800 - sha512crypt ($6$) +3200 - bcrypt/blowfish ($2*$) +11600 - 7zip ($7z$) +2500 - WPA handshake converted into a .hccapx file +400 - phpass/wordpress/phpbb3/joomla ($P$) +16500 - JSON Web Token (JWT) + +For WPA handshakes, you need to convert the .pcap into a .hccapx +This can be done with the hashcat-utils package (may be in package manager, otherwise git) +$ git clone https://github.com/hashcat/hashcat-utils.git +Or using aircrack-ng (which you probably used to get it in the first place) +$ aircrack-ng -j <out-file> <pcap-file> + +Attack Type +0 - "straight mode" or dictionary attack. you can also specify rule files - https://hashcat.net/wiki/doku.php?id=rule_based_attack +1 - "combinator mode" cartesian product of two dictionaries. can also use a single rule on each side with -j/-k +3 - "mask mode" or brute force mode. uses a fixed length pattern with wildcards - https://hashcat.net/wiki/doku.php?id=mask_attack +6 - "hybrid" wordlist+mask +7 - "hybrid" mask+wordlist +hybrid - basically a combinator attack but one side is a brute force mask instead of another wordlist + +Workload Profiles +The docs claim that 3 and 4 would cause your system to be unusable, but I wasn't seeing that. +I also didn't see a very significant improvement from 3 to 4, though. +The default seems to be around 2, but there was a significant performance increase at 3. + +Tweaking Keyspace for Performance +Straight dictionary attacks will generally be pretty fast, but as you add rules and masks, things grow quickly. +In fact, just a single long mask on its own is often infeasible. +Generally, you don't want to run against rockyou and a huge collection of rules (or even just one complex one). +It's better to either use rockyou with a simple rule or have a limited wordlist and a large collection of rules. +If you're brute forcing, generally you don't want a huge mask. +If you're hybrid brute forcing, you also don't want a huge wordlist with tons of different masks. +Again, you want to pick a limited word list and a collection of simple masks. +One weird gotcha, though, is that hashcat will produce a "base" list of candidates on the CPU +that then gets blown up into more candidates with an amplifier on the GPU. +If, after this amplification, the candidate list is too short, the GPU's parallelization can't be taken advantage of. +For instance, in a hybrid attack with a small wordlist and large list of masks, but some of the masks are very short. +Each mask in the list will generate a separate candidate list via amplification on the GPU. +For the short masks, this candidate list will be very short. This causes a HUGE bottleneck where the GPU can't parallelize. +Fortunately, hashcat will print out a warning when this happens to let you know. +It can be somewhat mitigated by tweaking your lists or by running STDOUT/STDIN mode. +This will generate the candidates as one big batch and pipe them into the main hashcat instance. +Since we're effectively combining the different amplified candidate lists into one, +we have a better chance of have a long enough candidate list for the GPU to be properly utilized. +The main downside is that the main hashcat instance has no idea how long our keyspace is and can't estimate the run time. +https://hashcat.net/faq/morework + +Getting Hardware to Work +Hashcat uses opencl most of the time. It can use CUDA directly as well. +We need to set up all of the drivers and opencl implementations to get it to use our hardware. +Even if we wanted to run on the CPU, we would need the opencl implementation that uses it. +Usually the CPU implementation would be through pocl (portable computing language). +$ apt install pocl-opencl-icd +There are mesa implementations for opencl, but they're kind of shit. +$ apt install mesa-opencl-icd +You can access CUDA through opencl, but it may still need CUDA libraries installed +A better option would be to have hashcat use CUDA directly since you'll be installing the libraries anyways. +https://developer.nvidia.com/cuda-downloads +And make sure hashcat is selecting the direct implementation instead of opencl. +On AMD, there is the ROCM API which is similar to CUDA. +With hashcat, we need an opencl implementation to ROCM. +https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html +As it turns out, ROCM is only supported on dedicated GPUs. +There doesn't seem to be a proper solution for APUs. There is a 3rd party implementation of ROCM for APUs here: +https://apt.bruhnspace.com/ +But I couldn't get it working. + diff --git a/docs/nix/iptables.txt b/docs/nix/iptables.txt new file mode 100644 index 0000000..41912a7 --- /dev/null +++ b/docs/nix/iptables.txt @@ -0,0 +1,147 @@ +iptables is a configuration utility for the Linux kernel's firewall + +useful one-liners: +iptables -t filter -L -v +iptables -t filter -F +iptables -t filter -F INPUT +iptables -t filter -P INPUT DROP +iptables -t filter -A INPUT -s 8.8.8.8 -j DROP +iptables -t filter -A INPUT -p tcp --dport 80 -j DROP +iptables -t filter -A FORWARD -p tcp --dport 22 -j REJECT --reject-with tcp-reset +iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE +iptables -t nat -A POSTROUTING -p tcp --sport 1337 -j MASQUERADE --to-ports 1024-30000 +iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080 +iptables -t nat -D POSTROUTING 1 + +useful options: +-t <table> -- chooses a table to operate on +-L -- print the contents of the selected table +-v -- verbose mode (can give more 'v's for more verbosity) +-F [<chain>] -- flush/clear the contents of the selected table or a chain in that table +-A <chain> -- append a new rule to the selected chain in the selected table +-I <chain> <index> -- insert a rule at specified index in the selected chain in the selected table +-D <chain> <index> -- delete a rule at specified index in the selected chain in the selected table +-R <chain> <index> -- replace a rule at specified index in the selected chain in the selected table +-P <chain> <target> -- change the default policy of the selected chain in the selected table +-p <protocol> -- match on protocol (ICMP,TCP,UDP) +-i <interface> -- match on incoming interface +-s <address>[/mask] -- match on source address +--sport <port>[:<port>] -- match on source port(s) (only works with -p) +-o <interface> -- match on outgoing interface +-d <address>[/mask] -- match on destination address +--dport <port>[:<port>] -- match on destination port(s) (only works with -p) +--to-source <address>[:<port>[-<port>]][-<address>] -- for SNAT target. Sets the source address(es) +--to-destination <address>[:<port>[-<port>]][-<address>] -- for DNAT target. Sets the destination address(es) +--to-ports <port>[-<port>] -- for the MASQUERADE and REDIRECT targets. Sets the port(s) of a packet. +--reject-with <response> -- for the REJECT target. Return an error after dropping a packet. + +It operates on "rules" which are a set of criteria to match a packet by and a "target" which decides what to do with the packet. +The rules are organized into predefined "chains" which apply at different parts of the packet's journey through the system's routing. +The rules in a chain are evaluated and potentially applied in the sequence they were added to the chain. +The chains are organized into "tables" which are mostly just an organization construct. +Each chain also has a default policy that applies if the packet makes it all the way through the chain (no rule applied). + +There are 5 main tables: +-raw configures packets to be exempt from connection tracking +-mangle is used for specialized packet alterations +-security is used for Mandatory Access Control rules +-nat is used for Network Address Translation +-filter is the default table which does the stuff you usually think of when thinking about firewalls + +For the most part, you'll only ever care about the filter and nat tables. +Each table has a predefined list of chains which apply at different times as the packet is routed. +Technically you can jump into a user-defined chain as a target for a rule as well. +These cannot have default policies. If every rule in one fails to match, the packet goes back to the calling chain. +A flowchart from the Arch wiki presents a simplified overview of this: + + XXXXXXXXXXXXXXXXXX + XXX Network XXX + XXXXXXXXXXXXXXXXXX + + + | + v + +-------------+ +------------------+ + |table: filter| <---+ | table: nat | + |chain: INPUT | | | chain: PREROUTING| + +-----+-------+ | +--------+---------+ + | | | + v | v + [local process] | **************** +--------------+ + | +---------+ Routing decision +------> |table: filter | + v **************** |chain: FORWARD| +**************** +------+-------+ +Routing decision | +**************** | + | | + v **************** | ++-------------+ +------> Routing decision <---------------+ +|table: nat | | **************** +|chain: OUTPUT| | + ++-----+-------+ | | + | | v + v | +-------------------+ ++--------------+ | | table: nat | +|table: filter | +----+ | chain: POSTROUTING| +|chain: OUTPUT | +--------+----------+ ++--------------+ | + v + XXXXXXXXXXXXXXXXXX + XXX Network XXX + XXXXXXXXXXXXXXXXXX + +or you can look at a more detailed version: +https://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg +The first routing decision has to do with whether the packet's destination is the local machine or elsewhere. +The other routing decisions have to do with deciding which interface to send the packet to. + +filter chains: +-INPUT +-FORWARD +-OUTPUT + +nat chains: +-PREROUTING +-INPUT +-OUTPUT +-POSTROUTING + +At a high level, +PREROUTING is packets coming in from a network, +POSTROUTING is packets going out to a network, +FORWARD is packets coming from a network out onto a network, +INPUT is packets coming in to a local process, +OUTPUT is packets coming out from a local process + +If you're using the PREROUTING, POSTROUTING, or FORWARD chains, you are probably trying to forward packets from a network onto a network. +If this is the case, you need to enable ip forwarding in the kernel +$ sudo su +$ echo "1" > /proc/sys/net/ipv4/ip_forward + + +A rule's predicate has several conditions that must be met by a packet for it to apply. +For some chains, certain conditions don't make sense and aren't allowed to be set. +For instance, it doesn't make sense to predicate a nat PREROUTING rule on the output interface when that hasn't been decided yet. + +Most rules are predicated on +-packet protocol (ICMP,TCP,UDP) +-input interface +-source host +-source port +-output interface +-destination host +-destination port + +Each rule has a target that will apply if the packet matches the rule's predicate. +These can be a user defined chain, or a built-in target. + +There are quite a few built-in targets, but the vast majority of the time you will be using: +-ACCEPT (stop traversing the current chain and pass the packet to the next chain) +-DROP (stop traversing all chains entirely and drop the packet dead) +-REJECT (same as drop except send back an error specified with --reject-with) +-RETURN (if in a subchain, go back to the superior chain. if in a main chain, use the chain default policy) +-MASQUERADE (forward incoming packets back out, but change the source address to our outgoing interface's. can also specify a new source port for the packet with --to-ports only valid in nat POSTROUTING) +-REDIRECT (forward incoming packets to our own host. can also specify a new destination port for the packet with --to-ports only valid in nat PREROUTING and OUTPUT) +-SNAT (forward incoming packets back out, but change the source address to the specified address(s) via --to-source) +-DNAT (forward incoming packets back out, but change the destination address to the specified address(s) via --to-destination) + +note: for nat rules, only the first packet of a connection is actually mached through the table. the rest of the connection is automatically handled the same (or inverse for responses) diff --git a/docs/nix/proxychains.txt b/docs/nix/proxychains.txt new file mode 100644 index 0000000..3ed6b60 --- /dev/null +++ b/docs/nix/proxychains.txt @@ -0,0 +1,10 @@ +proxychains is a tool that allows us to issue commands over a proxy + +Configure your proxy setup in /etc/proxychains.conf +e.g. +#/etc/proxychains.conf +socks5 172.15.18.117 1080 + +From there we can actually use the proxy with the proxychains command. +$ proxychains nmap -A -p- 127.0.0.1 +$ proxychains wget http://127.0.0.1:8000 diff --git a/docs/pwn/one_gadget.txt b/docs/pwn/one_gadget.txt new file mode 100644 index 0000000..d9a4ff1 --- /dev/null +++ b/docs/pwn/one_gadget.txt @@ -0,0 +1,57 @@ +https://github.com/david942j/one_gadget +$ gem install one_gadget + +Find libc for the target through dependencies or leaking libc version remotely +$ ldd <target> +https://libc.blukat.me +https://libc.rip + +Give this libc binary to one_gadget +$ one_gadget <path_to_libc> + +This will print out multiple offsets that, if jumped into, will call execve("/bin/sh") +These options will also have a list of requirements for them to work. + +Example: +$ one_gadget /lib/x86_64-linux-gnu/libc.so.6 +0xe6c7e execve("/bin/sh", r15, r12) +constraints: + [r15] == NULL || r15 == NULL + [r12] == NULL || r12 == NULL + +0xe6c81 execve("/bin/sh", r15, rdx) +constraints: + [r15] == NULL || r15 == NULL + [rdx] == NULL || rdx == NULL + +0xe6c84 execve("/bin/sh", rsi, rdx) +constraints: + [rsi] == NULL || rsi == NULL + [rdx] == NULL || rdx == NULL + +By setting the requisite registers to the correct values +and jumping to the corresponding offset, you will get a shell. + +For situations where you can overwrite a GOT address, but not leak libc, +you may want to overwrite just the last couple bytes of an address to +a libc function that is close to the one-gadget. This gives a good chance +of jumping into your one-gadget. +You can list one-gadgets that are close to a libc function with +$ one_gadget <path_to_libc> -n <comma separated list of regular expression libc functions> + +You can also give the target binary to "-n" and it will consider the entire GOT +$ one_gadget <path_to_libc> -n <path_to_target> + +By default, one_gadget only shows gadgets with high probability, +but by setting "-l 1", it will show all found gadgets. + +By giving a bash script string, one_gadget can call your script with all found gadgets as an argument. +The following would call 'echo <gadget offset>' for each found one-gadget +$ one_gadget <path_to_libc> -s 'echo' + +This isn't particularly useful with sploit currently since you can't give cli arguments to the script right now. + +Some boilerplate for calling and consuming the output of one_gadget from within Python: +def one_gadget(filename): + return [int(i) for i in subprocess.check_output(['one_gadget', '--raw', filename]).decode().split(' ')] +one_gadget('/lib/x86_64-linux-gnu/libc.so.6') diff --git a/docs/re/ptrace_not_permitted.txt b/docs/re/ptrace_not_permitted.txt new file mode 100644 index 0000000..07ca568 --- /dev/null +++ b/docs/re/ptrace_not_permitted.txt @@ -0,0 +1,22 @@ +If you are seeing errors from your debugger such as +strace: (PTRACE_ATTACH): operation not permitted +ptrace: operation not permitted +ptrace_attach: operation not permitted +etc. + +This is likely because of a linux kernel hardening setting. +/proc/sys/kernel/yama/ptrace_scope +This setting prevents a process from running ptrace on a non-child process. +Even with this on, a can still ptrace another process if it is a child. +Debuggers like gdb and radare2 use ptrace when you attach via PID. + +You can turn this off +$ sudo su +$ echo 0 > /proc/sys/kernel/yama/ptrace_scope + +Turning this off is global, though. +Instead, set the capabilities of just your debugger to override this setting. + +$ sudo setcap CAP_SYS_PTRACE=+eip /usr/bin/gdb +$ sudo setcap CAP_SYS_PTRACE=+eip /usr/bin/radare2 + diff --git a/docs/re/radare2_cheatsheet.txt b/docs/re/radare2_cheatsheet.txt new file mode 100644 index 0000000..7c30b89 --- /dev/null +++ b/docs/re/radare2_cheatsheet.txt @@ -0,0 +1,88 @@ +r2 command cheatsheet + +https://github.com/radareorg/radare2 +https://book.rada.re + +#Install +git clone https://github.com/radareorg/radare2.git +./sys/install.sh + +#Uninstall +sudo make uninstall +sudo make purge + +#Run Command From Shell Without Opening r2 Prompt +r2 -q -c "<r2 command>" <target> + +#Generic +? <expr> expression evaluation/conversions +!<command> run shell command from inside r2 +s <addr> seek to address + +#Useful Operators +<command1>;<command2> do command2 after command1 +"<command>" don't parse r2 operators in the command +<command> `<inner command>` run inner command and use its output in outer command +<command> ~<word> grep output of command for lines matching word +<command> @ <address> temporarily seek to address and run command +<command> @@ <flag>* run command on every flag matching flag* +<command> @@f run command on all functions +<command> @@f:<func> run command on all functions matching name +<command> @@s:<from> <to> <step> run command on each offset from->to incrementing by step + +#Info and Analysis +i print file info (including binary info; e.g. rabin -I or checksec) +ia print binary info, imported symbols, and exported symbols +il print linked libraries +iS print sections (with permissions) +is print symbols +ic print classes +afl print functions +ie print entry points +iM print main's address +iz print strings in data section +izz print strings in whole binary +aaa analyze all +fs list flagspaces +fs <flagspace> set current flagspace +f print current flagspace +axt [<addr>] show references to this address +axf [<addr>] show references from this address + +#Searching +/ <string> search for string +/i <string> case-insensitive search for string +/e /<string>/<options> regex search for string +/R <opcodes> search for opcodes +/R/ <opcodes> regex search for opcodes +/v <value> search for value +/V <min> <max> search for value in range +/x <hex> search for hex string + +#Print Address Contents +pdf print function disassembled +pdc print function in c-like pseudo-code +pv print value +px print hexdump +ps print string +psz print zero-terminated string + +#Tracking Things +afn <func> [<addr>] rename function at address +afvn <arg> [<old_name>] rename variable or function argument + +#Visual Mode +V enter visual mode +VV enter visual graph mode +: open r2 cli +p next screen +P previous screen +g <address> seek to address +[tag next to call] seek to tag (in visual mode) +o[tag next to call] seek to tag (in visual graph mode) +x xrefs to +X xrefs from +m<key> mark offset (in visual mode) +'<key> seek to marked offset (in visual mode) +u undo seek +U redo seek diff --git a/docs/re/rep_prefix.txt b/docs/re/rep_prefix.txt new file mode 100644 index 0000000..23e0cec --- /dev/null +++ b/docs/re/rep_prefix.txt @@ -0,0 +1,18 @@ +The "rep" prefix on a string instruction repeats that string instruction for CX block loads. +e.g. +STOS is "Store String" +It will store the value in AX at the address in RDI +(technically, STOSB, STOSW, STOD, and STOSQ use AL, AX, EAX, and RAX respectively) +If RCX = 0x20, RDI = some buffer, and RAX = 0, + +`rep stosq` + +is equivalent to: + +``` +buf_ptr = buf +for(i = 0x20; i != 0; i--) + *buf_ptr = 0; + buf_ptr++; +``` + diff --git a/docs/web/api-testing.txt b/docs/web/api-testing.txt new file mode 100644 index 0000000..1c9f7b6 --- /dev/null +++ b/docs/web/api-testing.txt @@ -0,0 +1,7 @@ +REST/SOAP API Client +(basically curl or burpsuite but hosted online) +https://reqbin.com/ + +HTTP Request Capture Server +(host an endpoint that captures requests and let's you inspect them) +https://hookbin.com/ diff --git a/docs/web/curl-cheatsheet.txt b/docs/web/curl-cheatsheet.txt new file mode 100644 index 0000000..49dc4d5 --- /dev/null +++ b/docs/web/curl-cheatsheet.txt @@ -0,0 +1,89 @@ +curl common options cheatsheet + +#output control +-v +"verbose" mode which will print lots of other information including the actual headers in the request and response +-o <file> +output file to write the body of the response to + +#emulating a browser +-b <cookiefile> -c <cookiefile> +read and write cookies from the cookiefile +-L +follow redirects (3XX response codes) +The RFC states that the request method shouldn't be modified for the new request, +but for 301-303, most browsers will convert a POST into a GET +--post301,--post302,--post303 +will maintain the request method on redirect + +#request header control +-X <method> +use the specified request method +curl will infer this based on other flags and it is generally not needed +also, it only changes the text in the request, so if other behavior is needed (e.g. HEAD), this won't be sufficient +(-F,-d imply POST, -G forces GET, -I forces HEAD, -T forces PUT) +-I +performs a HEAD request +(if used with -d, the data will be added as a query string) +-G +forces a GET request and appends any -d data as a query string +-T <file> +send the specified file with a PUT request +-H <"Key: Value"> +set a request header +--path-as-is +prevents curl from squashing "/../" and "/./" in the path + +#sending data +both the -d and -F families of flags send POST form data +the -d family of flags uses Content-Type: application/x-www-form-urlencoded +the -F family of flags uses Content-Type: multipart/form-data +-d <data> +sends the specified data in the body of the request +multiple instances of the flag will append them with a '&' character separating them +the special characters '=' and '@' have meaning as interpreted in the format section of this cheatsheet +carriage returns and newlines are stripped +--data-urlencode <data> +same as -d except the content is urlencoded before sending it +--data-binary <data> +same as -d except newlines and carriage returns are preserved and there are no conversions +--data-raw <data> +same as --data-binary except there is no special interpretation of the @ character +-F <name=content> +sends data in key/value pairs similar to how a browser works when submitting a form +content prefixed with '@' or '<' have meaning as interpreted in the format section of this cheatsheet +--form-string <name=string> +same as -F except '@', '<', and ';type=' are have no special meaning +--raw +disables all HTTP decoding of content and transfer encoding and passes them on unaltered + +#various formats for specifying data +For the -d family of flags: +-d <content> +performs any special handling of the content and then passes it on +-d <name=content> +performs any special handling of the content part and then passes it on +-d <=content> +strips the leading '=', performs any special handling of the content, and then passes it on +this is mostly useful if the data contains special characters that should be encoded rather than acted on by curl +-d <@filename> +performs any special handling of the contents of the file and then passes it on +-d <name@filename> +performs any special handling of the contents of the file, prepends it with "name=", and then passes it on + +For the -F family of flags: +-F <name=content> +sends the key/value pair "name=content" as a field of the form +each key/value pair in the form should be specified with their own separate -F flag +-F <name=<filename> +same as a normal plain-text field except the content is read from the specified file +-F <name=@filename> +uploads the file as the content of a named field of a form +the contents of the file are automatically handled the way a browser handles uploading files through a form +-F <name=@filename;meta=data> +by appending ';' after a filename, you can specify various metadata that controls the file upload +for a comprehensive list, check the man page +;type=image/png +set the Content-Type of the file +;filename=foo.bar +give the filename of the uploaded file (otherwise curl automatically gives it as the original filename) |