När han såg onekey-bossen försvara sina rättigheter och Resupply, förlora några M-tillgångar, beklagade han sig över att Defi verkligen är för ömtåligt. Efter att ha tittat runt verkade jag inte vara särskilt tydlig med hur hackare attackerade, så jag gjorde lite efterforskningar själv och delade det med dig: Huvudpersonen i berättelsen är ResupplyPair, användaren kan låna och låna genom att satsa tillgångar, och isSolvent-modifieraren i kontraktet ansvarar för att kontrollera om användaren är berättigad att låna ut de begärda tillgångarna, den specifika kodlogiken är som följer: Du kan se beräkningen av LTV på rad 282, om vi har ett sätt att sätta _exchangeRate till 0, skulle då inte kontrollen alltid vara sann? Fortsätt läsa koden: Du kan se att variabeln för detta värde kommer från anropet till oraklet getPrices och är nämnaren, med andra ord måste vi göra priset på säkerheten extremt stort. När du läser oraklets kod kan du se att getPrices bara är ett lager av vidarebefordran, som faktiskt anropar convetToAssets-gränssnittet för den insatta tillgången (dvs. valvet). Fortsätt läsa koden: Du kan se att detta resultat består av mycket komplexa matematiska operationer, här hackaren är genom att förstärka molekylen, ytterligare total_assets, för att slutföra attacken, titta på den _total_assets funktionsimplementeringen kan hittas: Det här värdet är relaterat till den borrowed_token som innehas av kontrollantkontraktet för det här valvet, vilket är crvUSD. Analysen är faktiskt tydlig här, ResupplyPair skapades med ett tomt valv, och hackaren överförde en viss mängd borrowed_token till kontrollkontraktet för valvet, och slutligen fick _exchangeRate återgå till noll, så att värdet på hans pantsatta tillgångar förstärktes oändligt, och han lånade ut upp till 10 miljoner reUSD till en mycket liten kostnad. Attack Handel: Adress till ResupplyPair-kontraktet: Adress till kontrakt för Treasury controller: Adress till Treasury Contract: Adress till Oracle-kontrakt: