> For the complete documentation index, see [llms.txt](https://ret2basic.gitbook.io/ctfnote/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ret2basic.gitbook.io/ctfnote/web3-security-research/secureum/epoch-0/slot-6-auditing-techniques-and-tools-101/quiz.md). # Quiz {% embed url="" %} Slot 6 Quiz {% endembed %} **Q1 Which of the below is/are accurate?** * [ ] A) Audits identify all security vulnerabilities and guarantee bug-free code * [ ] B) Audits cover only smart contracts but never the offchain code * [x] C) Audits suggest fixes for issues identified and aim to reduce risk * [ ] D) None of the above **Q2 Audit reports from audit firms typically include** * [x] A) Finding likelihood/difficulty, impact and severity * [x] B) Exploit scenarios and recommended fixes * [ ] C) Formal verification of all findings with proofs and counterexamples * [ ] D) All of the above **Q3 These audit techniques are especially well-suited for smart contracts (compared to Web2 programs)** * [x] A) Formal verification because contracts are relatively smaller with specific properties * [x] B) Fuzzing because anyone can send random inputs to contracts on blockchain * [x] C) Static source-code analysis because contracts are expected to be open-source * [x] D) High-coverage testing because contract states and transitions are relatively fewer **Q4 The following kinds of findings may be expected during audits** * [x] A) True positives after confirmation from the project team * [x] B) False positives due to assumptions from missing specification and threat model * [x] C) False negatives due to limitations of time and expertise * [ ] D) None of the above **Q5 Which of the following is/are true?** * [ ] A) Audited projects always have clear/complete specification and documentation of all contract properties * [x] B) Manual analysis is typically required for detecting application logic vulnerabilities * [ ] C) Automated tools like Slither and MythX have no false negatives * [ ] D) The project team always fixes all the findings identified in audits **Q6 Automated tools for smart contract analysis** * [ ] A) Are sufficient therefore making manual analysis unnecessary * [ ] B) Have no false positives whatsoever * [ ] C) Are best-suited for application-level vulnerabilities * [x] D) None of the above **Q7 Which of the following is/are true?** * [x] A) Slither supports detectors, printers, tools and custom analyses * [ ] B) Echidna is a symbolic analyzer tool -> This is a fuzzing tool * [x] C) MythX is a combination of static analysis, symbolic checking and fuzzing tools * [ ] D) None of the above **Q8 Which of the following is/are correct about false positives?** * [x] A) They are findings that are not real concerns/vulnerabilities after further review * [ ] B) They are real vulnerabilities but are falsely claimed by auditors as benign * [x] C) They are possible with automated tools * [ ] D) None of the above **Q9 Audit findings** * [x] A) May include both specific vulnerabilities and generic recommendations * [x] B) May not all be fixed by the project team for reasons of relevancy and acceptable trust/threat model * [ ] C) Always have demonstrable proof-of-concept exploit code on mainnet * [ ] D) None of the above **Q10 Which of the following is/are typical manual review approach(es)?** * [x] A) Asset flow * [ ] B) Symbolic checking * [x] C) Inferring constraints * [x] D) Evaluating assumptions **Q11 Access control analysis is a critical part of manual review for the reason(s) that** * [ ] A) It is the easiest to perform because smart contracts never have access control * [ ] B) It is the fastest to perform because there are always only two roles: users and admins * [x] C) It is fundamental to security because privileged roles (of which there may be many) may be misused/compromised * [ ] D) None of the above **Q12 Which of the following is/are true about vulnerability difficulty and impact?** * [ ] A) Difficulty indicates how hard it was for auditors to detect the issue * [ ] B) Difficulty is an objective measure that can always be quantified * [x] C) Impact is typically classified as High if there is loss/lock of funds * [ ] D) None of the above **Q13 Application-level security constraints** * [ ] A) Are always clearly/completely specified and documented * [x] B) Have to be typically inferred from the code or discussions with project team * [x] C) Typically require manual analysis * [ ] D) None of the above **Q14 Which of the following is/are typically true?** * [ ] A) Static analysis analyzes program properties by actually executing the program * [ ] B) Fuzzing uses valid, expected and deterministic inputs * [ ] C) Symbolic checking enumerates individual states/transitions for efficient state space traversal * [x] D) None of the above **Comment:** > Static analysis: is a technique of analyzing program properties without actually executing the program. from point 23 of [Security Audit Techniques & Tools 101 - by Secureum](https://secureum.substack.com/p/audit-techniques-and-tools-101) > Fuzzing: or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. from point 24 of [Security Audit Techniques & Tools 101 - by Secureum](https://secureum.substack.com/p/audit-techniques-and-tools-101) > Instead of enumerating reachable states one at a time, the state space can sometimes be traversed more efficiently by considering large numbers of states at a single step. from point 25.4 of [Security Audit Techniques & Tools 101 - by Secureum](https://secureum.substack.com/p/audit-techniques-and-tools-101) **Q15 Which of the following is/are generally true about asset flow analysis?** * [x] A) Analyzes the flow of Ether or tokens managed by smart contracts * [x] B) Assets should be withdrawn only by authorized addresses * [ ] C) The timing aspects of asset withdrawals/deposits is irrelevant * [ ] D) The type and quantity of asset withdrawals/deposits is irrelevant **Q16 Which of the following is/are generally true about control and data flow analyses?** * [x] A) Interprocedural control flow is typically indicated by a call graph * [x] B) Intraprocedural control flow is dictated by conditionals (if/else), loops (for/while/do/continue/break) and return statements * [x] C) Interprocedural data flow is evaluated by analyzing the data used as argument values for function parameters at call sites * [x] D) Intraprocedural data flow is evaluated by analyzing the assignment and use of variables/constants along control flow paths within functions **Comment:** > Evaluating control flow: Interprocedural (procedure is just another name for a function) control flow is typically indicated by a call graph which shows which functions (callers) call which other functions (callees), across or within smart contracts from point 93.1 of [Security Audit Techniques & Tools 101 - by Secureum](https://secureum.substack.com/p/audit-techniques-and-tools-101) > Evaluating control flow: Intraprocedural (i.e. within a function) control flow is dictated by conditionals (if/else), loops (for/while/do/continue/break) and return statements. from point 93.2 of [Security Audit Techniques & Tools 101 - by Secureum](https://secureum.substack.com/p/audit-techniques-and-tools-101) > Evaluating data flow: Interprocedural data flow is evaluated by analyzing the data (variables/constants) used as argument values for function parameters at call sites from point 94.1 of [Security Audit Techniques & Tools 101 - by Secureum](https://secureum.substack.com/p/audit-techniques-and-tools-101) > Evaluating data flow: Intraprocedural data flow is evaluated by analyzing the assignment and use of (state/memory/calldata) variables/constants along the control flow paths within functions. from point 94.2 of [Security Audit Techniques & Tools 101 - by Secureum](https://secureum.substack.com/p/audit-techniques-and-tools-101)