having -1 as offset in proxy storage slots

[18121A05L2]

As i have seen we have -1 offset for the proxy storage slots

Implementation storage slot - bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1))
Admin storage slot. - bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1))

https://eips.ethereum.org/EIPS/eip-1967

i have googled for it and i have seen that those -1 have added because of a preimage attack , after going through some articles also still i didn't get it

preimage attack in the sense finding the input of the hash as we all know the input for the above storage slots and how can an attacker can able to change the Implementation slot address of a contract even if he know the preimage

[EngrPips]

I haven't personally made any findings on this. @PatrickAlphaC, we could use some help here, sir.

[PatrickAlphaC]

The key concern revolves around how storage slots are allocated in proxy contracts. Here's the step by step explanation:

In the ERC-1967 specification, important proxy data (like the implementation address) is stored at specific slots calculated as:

bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)

Without the -1 offset, an attacker could potentially:

1. Calculate keccak256('eip1967.proxy.implementation')
2. Create a contract with a state variable that would map to that exact storage slot
3. The compiler would naturally place their malicious variable at that slot

This becomes dangerous because:
If this malicious contract becomes the implementation contract
Writing to their carefully placed state variable would overwrite the proxy's crucial storage (like the implementation address)
This could potentially hijack the proxy by overwriting the implementation address with an attacker-controlled address

By subtracting 1 from the hash:
The final storage slot becomes effectively impossible to "accidentally" target
An attacker would need to find an input that, when hashed, equals the target slot + 1
Due to the preimage resistance of keccak256, finding such an input is computationally infeasible

When Solidity allocates storage slots for state variables, it can only allocate slots based on the direct hash of values/strings, not a hash minus 1
Even if you know the target slot (0x360894a...bbc), you cannot work backwards to find a variable declaration that would make Solidity allocate that slot
This is because Solidity's storage allocation mechanism doesn't have any way to subtract 1 during its slot allocation process.

Does that make sense?

[18121A05L2]

Yes @PatrickAlphaC , just a few more doubts

regarding this

attacker Create a contract with a state variable that would map to that exact storage slot

if we Assume the both contracts like , OurProxyContract and AttackerStorageSlotMappedContract

for Each contract deployed on the Ethereum blockchain has its own independent storage space, identified by its contract address right ?

and even if attacker update that state variable it wouldn't affect our state variable

i have asked chatgpt an example like above - https://chatgpt.com/share/6788d2b1-4124-8010-b72e-08d673dc199f

correct me if am wrong at any

regarding this

Even if you know the target slot (0x360894a...bbc), you cannot work backwards to find a variable declaration that would make Solidity allocate that slot

we can't work back words , but if we know the keccack hash of the storage slot like (0x360894a...bbc) then we can directly update the storage slot of that isolated contract address using sstore which would not affect other contracts storage slots