Merge pull request #213 from crytic/ahpaleus_master

montyly · web-flow · commit c04429f58dd8 · 2023-02-15T16:02:22.000Z
Fix broken links
diff --git a/.github/workflows/check_links.yml b/.github/workflows/check_links.yml
@@ -0,0 +1,20 @@
+name: Check Markdown links
+
+on:
+  push:
+    branches:
+      - master
+      - dev
+  pull_request:
+  schedule:
+    # run CI at 09:00, on day 1 of the month even if no PRs/merges occur
+    - cron:  '0 9 1 * *'
+
+jobs:
+  markdown-link-check:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@master
+    - uses: gaurav-nelson/github-action-markdown-link-check@v1
+      with:
+        use-quiet-mode: 'yes'
diff --git a/development-guidelines/workflow.md b/development-guidelines/workflow.md
@@ -21,9 +21,9 @@ Visually inspect critical security features of your code:
 
 Document critical security properties and use automated test generators to evaluate them:
 
-- [ ] Learn to [document security properties for your code](/program-analysis/). It's tough as first, but it's the single most important activity for achieving a good outcome. It's also a prerequisite for using any of the advanced techniques in this tutorial.
+- [ ] Learn to [document security properties for your code](../program-analysis/). It's tough as first, but it's the single most important activity for achieving a good outcome. It's also a prerequisite for using any of the advanced techniques in this tutorial.
 - [ ] Define security properties in Solidity, for use with [Echidna](https://github.com/crytic/echidna) and [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html). Focus on your state machine, access controls, arithmetic operations, external interactions, and standards conformance.
-- [ ] Define security properties with [Slither's Python API](/program-analysis/slither). Focus on inheritance, variable dependencies, access controls, and other structural issues.
+- [ ] Define security properties with [Slither's Python API](../program-analysis/slither). Focus on inheritance, variable dependencies, access controls, and other structural issues.
 
 Finally, be mindful of issues that automated tools cannot easily find:
 
diff --git a/not-so-smart-contracts/cairo/consider_L1_to_L2_message_failure.md b/not-so-smart-contracts/cairo/consider_L1_to_L2_message_failure.md
@@ -1,8 +1,8 @@
 # Consider L1 to L2 message failure
 
-In Starknet, [Ethereum contracts can send messages from L1 to L2, using a bridge](https://starknet.io/docs/hello_starknet/l1l2.html#messages-from-l1-to-l2). However, it is not guaranteed that the message will be processed by the sequencer. 
+In Starknet, [Ethereum contracts can send messages from L1 to L2, using a bridge](https://docs.starknet.io/documentation/architecture_and_concepts/L1-L2_Communication/messaging-mechanism/). However, it is not guaranteed that the message will be processed by the sequencer. 
 For instance, a message can fail to be processed if there is a sudden spike in the gas price and the value provided is too low. For that reason, Starknet developers provided a 
-[API to cancel on-going messages](https://docs.starknet.io/docs/L1-L2%20Communication/messaging-mechanism/#l1--l2-messages)
+[API to cancel on-going messages](https://docs.starknet.io/documentation/architecture_and_concepts/L1-L2_Communication/messaging-mechanism/#l2-l1_message_cancellation)
 
 # Example
 
diff --git a/not-so-smart-contracts/cairo/replay_protection/README.md b/not-so-smart-contracts/cairo/replay_protection/README.md
@@ -12,7 +12,7 @@ Consider the following function that validates a signature for EIP712-style perm
 
 ## Mitigations
 
-- Consider using the [OpenZeppelin Contracts for Cairo Account contract](https://github.com/OpenZeppelin/cairo-contracts/blob/main/docs/Account.md) or another existing account contract implementation.
+- Consider using the [OpenZeppelin Contracts for Cairo Account contract](https://github.com/OpenZeppelin/cairo-contracts/blob/main/docs/modules/ROOT/pages/accounts.adoc) or another existing account contract implementation.
 
 ## External Examples
 
diff --git a/not-so-smart-contracts/cairo/view_state/README.md b/not-so-smart-contracts/cairo/view_state/README.md
@@ -1,6 +1,6 @@
 # State modifications in a view function
 
-StarkNet provides the @view decorator to signal that a function should not make state modifications. However, this is [not currently enforced by the compiler](https://starknet.io/docs/hello_starknet/intro.html). Developers should take care when designing view functions but also when calling functions in other contracts as they may result in unexpected behavior if they do include state modifications accidentally.
+StarkNet provides the @view decorator to signal that a function should not make state modifications. However, this is [not currently enforced by the compiler](https://www.cairo-lang.org/docs/hello_starknet/intro.html). Developers should take care when designing view functions but also when calling functions in other contracts as they may result in unexpected behavior if they do include state modifications accidentally.
 
 ## Example
 
diff --git a/not-so-smart-contracts/cosmos/broken_bookkeeping/README.md b/not-so-smart-contracts/cosmos/broken_bookkeeping/README.md
@@ -53,7 +53,7 @@ A malicious user can screw an exchange rate in two ways:
 * by force-sending Tokens to the module, changing the `tokensHeld` value
 * by transferring uTokens to another chain via IBC, chaning `uTokensInCirculation` value
 
-The first "attack" could be pulled of by sending [`MsgSend`](https://docs.cosmos.network/main/modules/bank/03_messages.html#msgsend) message. However, it would be not profitable (probably), as executing it would irreversibly decrease an attacker's resources.
+The first "attack" could be pulled of by sending [`MsgSend`](https://docs.cosmos.network/main/modules/bank#msgsend) message. However, it would be not profitable (probably), as executing it would irreversibly decrease an attacker's resources.
 
 The second one works because the IBC module [burns transferred coins in the source chain](https://github.com/cosmos/ibc-go/blob/48a6ae512b4ea42c29fdf6c6f5363f50645591a2/modules/apps/transfer/keeper/relay.go#L135-L136) and mints corresponding tokens in the destination chain. Therefore, it will decrease the supply reported by the `x/bank` module, increasing the exchange rate. After the attack the malicious user can just transfer back uTokens.
 
diff --git a/not-so-smart-contracts/cosmos/unregistered_msg_handler/README.md b/not-so-smart-contracts/cosmos/unregistered_msg_handler/README.md
@@ -1,8 +1,8 @@
 # Unregistered message handler
 
-In the legacy version of the [Msg Service](https://docs.cosmos.network/v0.44/building-modules/msg-services.html#implementation), all messages have to be registered in a module keeper's `NewHandler` method. Failing to do so would prevent users from sending the not-registered message.
+In the legacy version of the `Msg Service`, all messages have to be registered in a module keeper's `NewHandler` method. Failing to do so would prevent users from sending the not-registered message.
 
-In [the recent Cosmos version manual registration is no longer needed](https://docs.cosmos.network/v0.44/architecture/adr-031-msg-service.html#pros).
+In [the recent Cosmos version manual registration is no longer needed](https://docs.cosmos.network/v0.47/building-modules/msg-services).
 
 ## Example 
 
diff --git a/not-so-smart-contracts/substrate/randomness/README.md b/not-so-smart-contracts/substrate/randomness/README.md
@@ -4,7 +4,7 @@ To use randomness in a Substrate pallet, all you need to do is require a source
 1. `random_seed`: This function takes no arguments and returns back a random value. Calling this value multiple times in a block will result in the same value.
 2. `random`: Takes in a byte-array (a.k.a "context-identifier") and returns a value that is as independent as possible from other contexts. 
 
-Substrate provides the [Randomness Collective Flip Pallet](https://paritytech.github.io/substrate/master/pallet_randomness_collective_flip/index.html) and a Verifiable Random Function implementation in the [BABE pallet](https://paritytech.github.io/substrate/master/pallet_babe/index.html). Developers can also choose to build their own source of randomness.
+Substrate provides the [Randomness Collective Flip Pallet](https://docs.rs/pallet-randomness-collective-flip/latest/pallet_randomness_collective_flip/) and a Verifiable Random Function implementation in the [BABE pallet](https://paritytech.github.io/substrate/master/pallet_babe/index.html). Developers can also choose to build their own source of randomness.
 
 A bad source of randomness can lead to a variety of exploits such as the theft of funds or undefined system behavior. 
 
diff --git a/program-analysis/echidna/Exercise-8.md b/program-analysis/echidna/Exercise-8.md
@@ -39,7 +39,6 @@ We recommend to first try without reading the following hints. The hints are in
 
 - The invariant that we are looking for is "an attacker cannot get almost whole amount of rewards"
 - Read what is the [multi abi option](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/common-testing-approaches.md#external-testing)
-- A template is provided in [contracts/the-rewarder/EchidnaRewarder.sol](https://github.com/crytic/damn-vulnerable-defi-echidna/blob/hints/contracts/the-rewarder/EchidnaRewarder.sol)
 - A config file is provided in [the-rewarder.yaml](https://github.com/crytic/damn-vulnerable-defi-echidna/blob/solutions/the-rewarder.yaml)
 
 ## Solution
diff --git a/program-analysis/manticore/adding-constraints.md b/program-analysis/manticore/adding-constraints.md
@@ -2,11 +2,14 @@
 
 **Table of contents:**
 
-- [Introduction](#introduction)
-- [Operators](#Operators)
-- [Constraints](#constraints)
-- [Checking Constraint](#checking-constraint)
-- [Summary: Adding Constraints](#summary-adding-constraints)
+- [Adding Constraints](#adding-constraints)
+  - [Introduction](#introduction)
+  - [Operators](#operators)
+  - [Constraints](#constraints)
+    - [Global constraint](#global-constraint)
+    - [State constraint](#state-constraint)
+  - [Checking Constraint](#checking-constraint)
+  - [Summary: Adding Constraints](#summary-adding-constraints)
 
 ## Introduction
 
@@ -68,7 +71,7 @@ m.transaction(caller=user_account,
 
 ### State constraint
 
-Use [state.constrain(constraint)](https://manticore.readthedocs.io/en/latest/api.html?highlight=operator#manticore.core.state.StateBase.constrain) to add a constraint to a specific state
+Use [state.constrain(constraint)](https://manticore.readthedocs.io/en/latest/states.html?highlight=statebase#manticore.core.state.StateBase.constrain) to add a constraint to a specific state
 It can be used to constrain the state after its exploration to check some property on it.
 
 ## Checking Constraint
diff --git a/program-analysis/manticore/exercises/example.md b/program-analysis/manticore/exercises/example.md
@@ -1,7 +1,7 @@
 # Example: Arithmetic overflow
 This scenario is given as an example. You can follow its structure to solve the exercises.
 
-[`my_token.py`](example/my_token.py) uses manticore to find for an attacker to generate tokens during a transfer on Token ([my_token.sol](exercises/example/my_token.sol)).
+[`my_token.py`](example/my_token.py) uses manticore to find for an attacker to generate tokens during a transfer on Token ([my_token.sol](example/my_token.sol)).
 
 ## Proposed scenario
 
diff --git a/program-analysis/manticore/exercises/exercise1.md b/program-analysis/manticore/exercises/exercise1.md
@@ -25,7 +25,7 @@ Follow the pattern initilization, exploration and property for the script.
 
 - `m.ready_states` returns the list of state alive
 - `Operators.AND(a, b)` allows to create and AND condition
-- You can use the template proposed in [exercise1/template.sol](./exercise1/template.sol)
+- You can use the template proposed in [exercise1/template.py](./exercise1/template.py)
 
 ### Solution
 
diff --git a/program-analysis/manticore/exercises/exercise2.md b/program-analysis/manticore/exercises/exercise2.md
@@ -34,7 +34,7 @@ state.platform.transactions[-1].return_data
 data = ABI.deserialize("uint", data)
 ```
 
-- You can use the template proposed in [exercise2/template.sol](./exercise2/template.sol)
+- You can use the template proposed in [exercise2/template.py](./exercise2/template.py)
 
 ### Solution
 
diff --git a/program-analysis/manticore/getting-throwing-paths.md b/program-analysis/manticore/getting-throwing-paths.md
@@ -2,10 +2,12 @@
 
 **Table of contents:**
 
-- [Introduction](#introduction)
-- [Using state information](#using-state-information)
-- [How to generate testcase](#how-to-generate-testcase)
-- [Summary: Getting Throwing Path](#summary-getting-throwing-path)
+- [Getting Throwing Path](#getting-throwing-path)
+  - [Introduction](#introduction)
+  - [Using state information](#using-state-information)
+  - [How to generate testcase](#how-to-generate-testcase)
+  - [Summary](#summary)
+  - [Summary: Getting Throwing Path](#summary-getting-throwing-path)
 
 
 ## Introduction
@@ -51,7 +53,7 @@ data = ABI.deserialize("uint", data)
 
 ## How to generate testcase
 
-Use [m.generate_testcase(state, name)](https://manticore.readthedocs.io/en/latest/api.html#manticore.ethereum.ManticoreEVM.generate_testcase) to generate testcase:
+Use [m.generate_testcase(state, name)](https://github.com/trailofbits/manticore/blob/dc8c3c822bbd50adabe50cafef38457505c0bc7b/manticore/ethereum/manticore.py#L1572) to generate testcase:
 
 ```python3
 m.generate_testcase(state, 'BugFound')
diff --git a/program-analysis/manticore/symbolic-execution-introduction.md b/program-analysis/manticore/symbolic-execution-introduction.md
@@ -28,7 +28,7 @@ As `f()` contains two paths, a DSE will construct two differents path predicates
 - Path 1: `a == 65`
 - Path 2: `Not (a == 65)`
 
-Each path predicate is a mathematical formula that can be given to a so-called [SMT solver](https://github.com/trailofbits/building-secure-contracts/blob/master/program-analysis/determine-properties.md), which will try to solve the equation. For `Path 1`, the solver will say that the path can be explored with `a = 65`. For `Path 2`, the solver can give `a` any value other than 65, for example `a = 0`.
+Each path predicate is a mathematical formula that can be given to a so-called [SMT solver](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/symbolic-execution-introduction.md), which will try to solve the equation. For `Path 1`, the solver will say that the path can be explored with `a = 65`. For `Path 2`, the solver can give `a` any value other than 65, for example `a = 0`.
 
 ### Verifying properties
 Manticore allows a full control over all the execution of each path. As a result, it allows to add arbirtray contraints to almost anything. This control allows for the creation of properties on the contract.
