borken links fixed (#66)

Co-authored-by: kaden <kaden.zipfel@hotmail.com>

vulnerabilities/dos-revert.md

@@ -83,7 +83,7 @@ Regardless of usage of checked math, it's necessary to ensure that any valid inp
 
 ### Unexpected Balance
 
-It's important to take caution in enforcing expected contract balances of tokens or Ether as those balances may be increased by an attacker to cause an unexpected revert. This is easily possible with ERC20 tokens by simply `transfer`ring to the contract, but is also possible with Ether by [Forcibly sending Ether to a contract](./forcibly-sending-ether.md).
+It's important to take caution in enforcing expected contract balances of tokens or Ether as those balances may be increased by an attacker to cause an unexpected revert. This is easily possible with ERC20 tokens by simply `transfer`ring to the contract, but is also possible with Ether by forcibly sending Ether to a contract.
 
 Consider, for example, a contract which expects the Ether balance to be 0 for the first deposit to allow for custom accounting logic. An attacker may forcibly send Ether to the contract before the first deposit, causing all deposits to revert. 
 

vulnerabilities/overflow-underflow.md

@@ -19,7 +19,6 @@ The most common way in which integer over/underflow is possible when you convert
 uint256 public a = 258;
 uint8 public b = uint8(a); // typecasting uint256 to uint8
 ```
-
 The above code snippet will overflow and the ``2`` will be stored in the variable ``b`` due to the fact that maximum value in uint8 data type is ``255``. So, it will overflow and reset to ``0`` without reverting.
 
 ### Using Shift Operators

vulnerabilities/reentrancy.md

@@ -104,7 +104,7 @@ As we can see in the above example, although both functions have a nonReentrant
 
 ### Reentrancy prevention
 
-The simplest reentrancy prevention mechanism is to use a [`ReentrancyGuard`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/security/ReentrancyGuard.sol), which allows you to add a modifier, e.g. `nonReentrant`, to functions which may otherwise be vulnerable. Although effective against most forms of reentrancy, it's important to understand how read-only reentrancy may be used to get around this and to always use the **checks-effects-interactions pattern**.
+The simplest reentrancy prevention mechanism is to use a [`ReentrancyGuard`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol), which allows you to add a modifier, e.g. `nonReentrant`, to functions which may otherwise be vulnerable. Although effective against most forms of reentrancy, it's important to understand how read-only reentrancy may be used to get around this and to always use the **checks-effects-interactions pattern**.
 
 For optimum security, use the **checks-effects-interactions pattern**. This is a simple rule of thumb for ordering smart contract functions.
 
@@ -135,4 +135,4 @@ Examples from: https://medium.com/coinmonks/protect-your-solidity-smart-contract
 
 - [Reentrancy Attacks on Smart Contracts: Best Practices for Pentesters](https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/)
 - [Reentrancy attack on Smart Contracts: How to identify the exploitable and an example of an attack](https://medium.com/@gus_tavo_guim/reentrancy-attack-on-smart-contracts-how-to-identify-the-exploitable-and-an-example-of-an-attack-4470a2d8dfe4)
-- [Protect Your Solidity Smart Contracts From Reentrancy Attacks](https://medium.com/coinmonks/protect-your-solidity-smart-contracts-from-reentrancy-attacks-9972c3af7c21)
+- [Protect Your Solidity Smart Contracts From Reentrancy Attacks](https://medium.com/coinmonks/protect-your-solidity-smart-contracts-from-reentrancy-attacks-9972c3af7c21)

vulnerabilities/transaction-ordering-dependence.md

@@ -10,4 +10,4 @@ One solution to transaction-ordering dependence is to use a commit-reveal scheme
 
 - [Solidity Transaction Ordering Attacks](https://medium.com/coinmonks/solidity-transaction-ordering-attacks-1193a014884e)
 - [Analysis of Transaction Ordering in Ethereum](https://users.encs.concordia.ca/~clark/papers/2019_wtsc_front.pdf)
-- [SWC-114: Transaction Order Dependence](https://swcregistry.io/docs/SWC-114)
+- [SWC-114: Transaction Order Dependence](https://swcregistry.io/docs/SWC-114)

vulnerabilities/uninitialized-storage-pointer.md

@@ -11,4 +11,4 @@ Data is stored in the EVM as either `storage`, `memory`, or `calldata`. It is im
 - [Solidity Security Blog - Storage](https://github.com/sigp/solidity-security-blog#storage)
 - [Solidity Documentation: Data Location](https://solidity.readthedocs.io/en/latest/types.html#data-location)
 - [Solidity Documentation: Layout in Storage](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html)
-- [Solidity Documentation: Layout in Memory](https://docs.soliditylang.org/en/latest/internals/layout_in_memory.html)
+- [Solidity Documentation: Layout in Memory](https://docs.soliditylang.org/en/latest/internals/layout_in_memory.html)