Reproduce the attack in paper

[wtdcode]

I'm reproducing the result of ityfuzz. I got the sheet from here: #153. However, for the first one AES, ityfuzz fails to give a result in 30 minutes (and seems to be stuck forever). My CLI is:

/bins/cli_onchain evm -o -t 0x7109709ECfa91a80626fF3989D68f67F5b1DD12D,0xdDc0CFF76bcC0ee14c3e73aF630C029fe020F907,0x55d398326f99059fF775485246999027B3197955,0x9ad32e3054268B849b84a8dBcC7c8f7c52E4e69A,0xca4d0d24aa448329b7d4eb81be653224a59e7b08,0x10ED43C718714eb63d5aA57B78B54704E256024E,0x40eD17221b3B2D8455F4F1a05CAc6b77c5f707e3 --onchain-block-number 23695904 --onchain-etherscan-api-key <Redacted> -i -p --onchain-url "http://192.168.4.209:8546" --onchain-explorer-url "https://api.bscscan.com/api" --onchain-chain-id 56 --onchain-chain-name bsc

Enabling flashloan oracle (-f) gives a sequence quickly but looks far from an exploit.

================ Oracle ================
0x40ed17221b3b2d8455f4f1a05cac6b77c5f707e3, Reserves changed from (0x000000000000000000000000000000000000000000000d8ee82c2dca561d78c5_U256, 0x000000000000000000000000000000000000000000033bb7a10b927c281d0eb4_U256) to (0x000000000000000000000000000000000000000000000d8ee82c2dca561d78c5_U256, 0x0000000000000000000000000000000000000000000349f7515860b3a2ec6202_U256)

================ Trace ================
Begin
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0xddc0cff76bcc0ee14c3e73af630c029fe020f907 distributeFee with 0 ETH (26c4e60d), liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0x9ad32e3054268b849b84a8dbcc7c8f7c52e4e69a sellQuote(0x0000000000000000000000000000000000000000) with 0 ETH (dd93f59a0000000000000000000000000000000000000000000000000000000000000000), liq percent: 0
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x40ed17221b3b2d8455f4f1a05cac6b77c5f707e3 approve(0x9ad32e3054268b849b84a8dbcc7c8f7c52e4e69a,0x455552655258204e4fac5f87798787878787870000fffffb0000020000130000) with 0 ETH (095ea7b30000000000000000000000009ad32e3054268b849b84a8dbcc7c8f7c52e4e69a455552655258204e4fac5f87798787878787870000fffffb0000020000130000), liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0x40ed17221b3b2d8455f4f1a05cac6b77c5f707e3 sync with 0 ETH (fff6cae9), liq percent: 0

Even though reserve changes and thus the price got manipulated somehow, it's not complete because anyone theoretically can borrow a bunch of tokens and change the price dramatically. That said, I see two problem here:

• It doesn't include how to do the flashloan and possible side effects of a flashloan as far as I understand.
• The sequence doesn't seem to guarantee attacker could profit from it.

Or does ityfuzz deems this as an exploit?

[wtdcode]

The following can't be reproduced (no vuln is found) either with or without flashloan oracle for a 2 hour fuzzing compaign:

APC, BGLD, DFS, Discover, DPC, Gym2, HPAY, Nmbplatform, OmniEstate, PancakeHunny, RL, SDAO, TIFI

[shouc]

Thanks for reporting. I'll keep track of each here.

• APC: Can find it, takes 3.5 hrs
• BGLD
• DFS: Can find it
• Discover
• DPC
• Gym2: Delegatecall target changed, ABI on Etherscan no longer matches the contract on original block (Can't be fixed)
• HPAY: Can find it
• Nmbplatform: Uniswap issue, seems to be failed on transfer (Uniswap Liquidation is Not Reflected on State #205)
• OmniEstate: Can find it, takes 5hrs (Storage slot warmness for mutators #206)
• PancakeHunny: This exploit requires offchain oracle collaborations. Previously, we manually added the attacker address to caller set.
• RL
• SDAO: Can find it
• TIFI: Borrow of TIFI failed, need investigation

[shouc]

Known working list for BSC exploits: https://github.com/fuzzland/ityfuzz/blob/master/backtesting.md

[wtdcode]

Annex seems a false positive:

================ Oracle ================
Earned 2126421117736501159162324 more than owed 1080863983938136854000000, net earned = 1045557133798364305162324wei (1ETH)

================ Trace ================
Begin
0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 borrow token 0x98936bde1cf1bff1e7a8012cee5e2583851f2067 with Some(0x0000000000000000000000000000000000000000000000000f00001115256b16_U256) ETH, liq percent: 0
0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x98936bde1cf1bff1e7a8012cee5e2583851f2067 claimReward with 0 ETH (b88a802f), liq percent: 10

How does this trace complete the attack? It even doesn't contain the specific liquidator address, who actually lose the fund.

[wtdcode]

Same with BEGO, note this attack even doesn't require any flashloan:

================ Oracle ================
Earned 335747008480961262603344048416879319034000000 more than owed 335747008465998149484265961015645369450000000, net earned = 14963113119078087401233949584000000wei (14963113119ETH)

================ Trace ================
Begin
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x88503f48e437a377f1ac2892cbb3a5b09949fadd approve(0x0000000000000000000000000000000000000000,0x4f616e63616b653a20494e56414c49445f544f00000000000000000000000100) with 0 ETH (095ea7b300000000000000000000000000000000000000000000000000000000000000004f616e63616b653a20494e56414c49445f544f00000000000000000000000100), liq percent: 0
0xe1a425f1ac34a8a441566f93c82dd730639c8510 borrow token 0xc342774492b54ce5f8ac662113ed702fc1b34972 with Some(0x0000000000000000000000000000000000008c8b8b8b8b00108b8a008000f200_U256) ETH, liq percent: 0
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0xc342774492b54ce5f8ac662113ed702fc1b34972 burn(0x0000000000000000000000000000000000000000000000000000ff1c025591a8) with 0 ETH (42966c680000000000000000000000000000000000000000000000000000ff1c025591a8), liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0x88503f48e437a377f1ac2892cbb3a5b09949fadd skim(0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c) with 0 ETH (bc25cf77000000000000000000000000bb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c), liq percent: 0
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0x88503f48e437a377f1ac2892cbb3a5b09949fadd sync with 0 ETH (fff6cae9), liq percent: 0
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c deposit with 140166711482846090003028268416553084274 ETH (d0e30db0), liq percent: 0
0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x88503f48e437a377f1ac2892cbb3a5b09949fadd sync with 0 ETH (fff6cae9), liq percent: 10
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with Some(0x0000000000000000000000000000000000000000000000000000000000000001_U256) ETH, liq percent: 0
0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x88503f48e437a377f1ac2892cbb3a5b09949fadd sync with 0 ETH (fff6cae9), liq percent: 10
0xe1a425f1ac34a8a441566f93c82dd730639c8510 borrow token 0xc342774492b54ce5f8ac662113ed702fc1b34972 with Some(0x0000000000000000000000000000000000000000000000008ac7230489e80000_U256) ETH, liq percent: 0
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c deposit with 195574595811630763702525574756212804363 ETH (d0e30db0), liq percent: 0
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c deposit with 0 ETH (d0e30db0), liq percent: 10

The only vulnerable function is mint which uses isSigned modifier, however, it even doesn't appear in this trace.

Trying to turn of flashloan oracle doesn't help too (not producing any traces).

[shouc]

Annex one is FP and cannot be prevented as ItyFuzz can warp to the future during mutations

For BEGO one, I can't really reproduce. Can you share the command?

The command we used:

ETH_RPC_URL=<BSC RPC URL> ityfuzz evm\
 -t 0xc342774492b54ce5F8ac662113ED702Fc1b34972\
 -o -i -f -c BSC\
 --onchain-block-number 22315678\
 --onchain-etherscan-api-key PXUUKVEQ7Y4VCQYPQC2CEK4CAKF8SG7MVF

Can you please try again after rm -rf cache

[wtdcode]

ATK seems another fp:

Reverted? false
 Txn: Begin
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0xd228faee4f73a73fcc73b6d9a1bd25ee1d6ee611 skim(0x55d398326f99059ff775485246999027b3197955) with 0 ETH (bc25cf7700000000000000000000000055d398326f99059ff775485246999027b3197955), liq percent: 0
0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with Some(0x000000000000000000000000000000007f8d8ff77e1000010000b84a841354d5_U256) ETH, liq percent: 0
0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with Some(0x000000000000000000000000000000007f8d8ff77e1000010000ff7fffff54d5_U256) ETH, liq percent: 10
0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c withdraw(0x0000000000000000000000000000000000000000e6000024365cbcc8c8f00000) with 0 ETH (2e1a7d4d0000000000000000000000000000000000000000e6000024365cbcc8c8f00000), liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x55d398326f99059ff775485246999027b3197955 decreaseAllowance(0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd,0x0000000000000000000000000000000000000000000000000000000000000000) with 0 ETH (a457c2d70000000000000000000000008ef508aca04b32ff3ba5003177cb18bfa6cd79dd0000000000000000000000000000000000000000000000000000000000000000), liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with Some(0x00000000000000000000000000000000ebff00000100000f00596f6d20746868_U256) ETH, liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with Some(0x000000000000000000000000000000006f6e206f766555666c6f770000000000_U256) ETH, liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0x96bf2e6cc029363b57ffa5984b943f825d333614 147004bb with 0 ETH (147004bb), liq percent: 10
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 borrow token 0x9cb928bf50ed220ac8f703bce35be5ce7f56c99c with Some(0x000000000000000000000000000000000000000800ff000000f072727272720b_U256) ETH, liq percent: 0
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x96bf2e6cc029363b57ffa5984b943f825d333614 6778048e with 0 ETH (6778048e), liq percent: 0
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x96bf2e6cc029363b57ffa5984b943f825d333614 6778048e with 0 ETH (6778048e), liq percent: 0
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x96bf2e6cc029363b57ffa5984b943f825d333614 6778048e with 0 ETH (6778048e), liq percent: 0
== 0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0x96bf2e6cc029363b57ffa5984b943f825d333614 98d5fdca with 0 ETH (98d5fdca), liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0x96bf2e6cc029363b57ffa5984b943f825d333614 b6dd5913 with 0 ETH (b6dd5913), liq percent: 0
== 0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0x96bf2e6cc029363b57ffa5984b943f825d333614 2d3f7b14(0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c) with 0 ETH (2d3f7b14000000000000000000000000bb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c), liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x96bf2e6cc029363b57ffa5984b943f825d333614 c2412676 with 0 ETH (c2412676), liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0x96bf2e6cc029363b57ffa5984b943f825d333614 e7ee6ad6(0x0000000000000000000000000000000000000000000000000000000000000000) with 0 ETH (e7ee6ad60000000000000000000000000000000000000000000000000000000000000000), liq percent: 0
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x96bf2e6cc029363b57ffa5984b943f825d333614 23e15d27(0x55983d8701e40353fee90803688170a16424ee70,0x0000000000000000000000000000000000000000000000000000000000000000) with 0 ETH (23e15d2700000000000000000000000055983d8701e40353fee90803688170a16424ee700000000000000000000000000000000000000000000000000000000000000000), liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0x96bf2e6cc029363b57ffa5984b943f825d333614 1c80cc16 with 0 ETH (1c80cc16), liq percent: 0
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x96bf2e6cc029363b57ffa5984b943f825d333614 1c80cc16 with 0 ETH (1c80cc16), liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x7109709ecfa91a80626ff3989d68f67f5b1dd12d with Some(0x0000000000000000000000000000000000000000000000000000000000000001_U256) ETH, liq percent: 10
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with Some(0x0000000000000000000000000000000000000000000400008ac7230489d22000_U256) ETH, liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0x71d5c49eeba1a7c3a2653c9fc38dcffe85611eb5 bcb3e7c4(0x0000000000000000000000000000000000000000) with 0 ETH (bcb3e7c40000000000000000000000000000000000000000000000000000000000000000), liq percent: 10
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x96bf2e6cc029363b57ffa5984b943f825d333614 3d38397a(0x0000000000000000000000000000000000000000000000000000000000000000,0x601b8ab0c1d51e71796a0df5453ca671ae23de3d) with 0 ETH (3d38397a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000601b8ab0c1d51e71796a0df5453ca671ae23de3d), liq percent: 0
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 borrow token 0x9cb928bf50ed220ac8f703bce35be5ce7f56c99c with Some(0x000000000000000000000000000000000000000100000000000000002c646472_U256) ETH, liq percent: 0
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c transferFrom(0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd,0x0000000000000000000000000000000000000000,0x0000000000000000000000000000000000000000000000000000000000000000) with 0 ETH (23b872dd0000000000000000000000008ef508aca04b32ff3ba5003177cb18bfa6cd79dd00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000), liq percent: 0
== 0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0x96bf2e6cc029363b57ffa5984b943f825d333614 128456ee(0x601b8ab0c1d51e71796a0df5453ca671ae23de3d) with 0 ETH (128456ee000000000000000000000000601b8ab0c1d51e71796a0df5453ca671ae23de3d), liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with Some(0x0000000000000000000000000000000000000001000000000000000040000000_U256) ETH, liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with Some(0x00000000000000000000000000000000000000000000001000007e0000000000_U256) ETH, liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x96bf2e6cc029363b57ffa5984b943f825d333614 8da5cb5b with 0 ETH (8da5cb5b), liq percent: 10
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0xd228faee4f73a73fcc73b6d9a1bd25ee1d6ee611 Stepping with return:  with 0 ETH (00000000), liq percent: 0

claimToken1 is not called. No idea how it could work.

[wtdcode]

Known working list for BSC exploits: https://github.com/fuzzland/ityfuzz/blob/master/backtesting.md

Also I noticed that BGLD is marked reproducible in this link however I still can't reproduce it. Could you at least how a vuln trace of BGLD?

Reproduced, looks like just reserves changed.

btw, BEGO could be reproduced correctly now.

[wtdcode]

I can no longer reproduce Gym_1 after syncing with master branch. Even my previous branch looks like false positive:

================ Oracle ================
Earned 246690699606038682668727164423946532476 more than owed 125398918092922961751762609755343000000, net earned = 121291781513115720916964554668603532476wei (121291781513115ETH)

================ Trace ================
Begin
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0x3a0d9d7764fae860a659eb96a500f1323b411e68 with Some(0x0000000000000000000000000000000000000617070726f76652066726f6007f_U256) ETH, liq percent: 0
0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x8dc058ba568f7d992c60de3427e7d6fc014491db sync with 0 ETH (fff6cae9), liq percent: 10
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb borrow token 0xe98d920370d87617eb11476b41bf4be4c556f3f8 with Some(0x00000000000000000000000000000000000000000000000000dbdb00616e6365_U256) ETH, liq percent: 0
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x627f27705c8c283194ee9a85709f7bd9e38a1663 skim(0x8dc058ba568f7d992c60de3427e7d6fc014491db) with 0 ETH (bc25cf770000000000000000000000008dc058ba568f7d992c60de3427e7d6fc014491db), liq percent: 0
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb borrow token 0x58f876857a02d6762e0101bb5c46a8c1ed44dc16 with Some(0x0000000000000000000000000000000000000007e8e8e8e80000e403fff07af9_U256) ETH, liq percent: 0
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x627f27705c8c283194ee9a85709f7bd9e38a1663 sync with 0 ETH (fff6cae9), liq percent: 0
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb borrow token 0x58f876857a02d6762e0101bb5c46a8c1ed44dc16 with Some(0x0000000000000000000000000000000000000007e8e8e8e80000e403fff07af9_U256) ETH, liq percent: 0
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb borrow token 0x58f876857a02d6762e0101bb5c46a8c1ed44dc16 with Some(0x0000000000000000000000000000000000000007e8e8e8e80000e403fff07af9_U256) ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0x3a0d9d7764fae860a659eb96a500f1323b411e68 with Some(0x0000000000000000000000000000000000000000000000008ac7230489e80000_U256) ETH, liq percent: 0
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x8dc058ba568f7d992c60de3427e7d6fc014491db skim(0xe1a425f1ac34a8a441566f93c82dd730639c8510) with 0 ETH (bc25cf77000000000000000000000000e1a425f1ac34a8a441566f93c82dd730639c8510), liq percent: 10

Because the root vulnerability migrate is not touched in this trace.

[wtdcode]

SImilarly, GDS no longer reproduces after 12 hours fuzzing.

[wtdcode]

PancakeHunny seems false positive:

================ Oracle ================
Earned 115792089237316195423570985008687907853269984665640564039457584007913129639935000000 more than owed 0, net earned = 115792089237316195423570985008687907853269984665640564039457584007913129639935000000wei (115792089237316195423570985008687907853269984665640564039457ETH)

================ Trace ================
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0x541e619858737031a1244a5d0cd47e5ef480342c claimTokens(0x0000000000000000000000000000000000000000,0x68Dd4F5AC792eAaa5e36f4f4e0474E0625dc9024,0) with 0 ETH (9fc314c8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000068dd4f5ac792eaaa5e36f4f4e0474e0625dc90240000000000000000000000000000000000000000000000000000000000000000), liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x541e619858737031a1244a5d0cd47e5ef480342c Stepping with return:  with 0 ETH (00000000), liq percent: 0

0x541e619858737031a1244a5d0cd47e5ef480342c has nothing to do with the attack itself. It's also not provided via command line:

ityfuzz evm -o -t 0x12180BB36DdBce325b3be0c087d61Fce39b8f5A4,0x0E09FaBB73Bd3Ade0a17ECC321fD13a19e81cE82,0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c,0xb9b0090aaa81f374d66d94a8138d80caa2002950,0x109Ea28dbDea5E6ec126FbC8c33845DFe812a300,0x515Fb5a7032CdD688B292086cf23280bEb9E31B6,0x565b72163f17849832A692A3c5928cc502f46D69 -c bsc --onchain-block-number 7962338 -f -i -p --onchain-etherscan-api-key $BSC_ETHERSCAN_API_KEY

No idea why the address is there.

[wtdcode]

RFB seems false positive

================ Oracle ================
Earned 211869202094938181522065441157241704682000000 more than owed 211869202094938181519517649876260857068000000, net earned = 2547791280980847614000000wei (2ETH)

================ Trace ================
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with 567907478573653328787556433658506 ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with 60673113500109321449791296360543701188 ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with 45094766140408081142363659741738075944 ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with 10000000000000000000 ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with 166153499473114494112975882535043072 ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with 10000000000000000000 ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd borrow token 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c with 105934601047469090759596719540351324790 ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c withdraw(0) with 0 ETH (2e1a7d4d0000000000000000000000000000000000000000000000000000000000000000), liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c deposit with 0 ETH (d0e30db0), liq percent: 0
== 0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c deposit with 0 ETH (d0e30db0), liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x03184aaa6ad4f7be876423d9967d1467220a544e approve(0x03184AAA6Ad4F7BE876423D9967d1467220a544e,69346688063472754589537985497064327899231717846681310383536315519680696551545) with 0 ETH (095ea7b3000000
00000000000000000003184aaa6ad4f7be876423d9967d1467220a544e9950d5a2f2c7264863d40100bf993f0cdbc4711806caba6284d07e8080500879), liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x03184aaa6ad4f7be876423d9967d1467220a544e sync with 0 ETH (fff6cae9), liq percent: 10
== 0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0x03184aaa6ad4f7be876423d9967d1467220a544e transferFrom(0x0000000000000000000000000000000000000000,0x0000000000000000000000000000000000000000,0) with 0 ETH (23b872dd0000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000), liq percent: 0
== 0x35c9dfd76bf02107ff4f7128bd69716612d31ddb borrow token 0x26f1457f067bf26881f311833391b52ca871a4b5 with 324210794659053568 ETH, liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x26f1457f067bf26881f311833391b52ca871a4b5 Stepping with return:  with 0 ETH (00000000), liq percent: 0

According to the analysis here: https://twitter.com/BlockSecTeam/status/1599991294947778560 , the root cause is randMod of the RFB contract 0x26f1457f067bf26881f311833391b52ca871a4b5. But the only transaction that touches the address is:

== 0x35c9dfd76bf02107ff4f7128bd69716612d31ddb borrow token 0x26f1457f067bf26881f311833391b52ca871a4b5 with 324210794659053568 ETH, liq percent: 0
== 0x68dd4f5ac792eaaa5e36f4f4e0474e0625dc9024 => 0x26f1457f067bf26881f311833391b52ca871a4b5 Stepping with return:  with 0 ETH (00000000), liq percent: 0

I can't see how this triggers randMod and earns ETH.

[wtdcode]

EGD finance seems the input is improper because the attacker's contract 0xc30808d9373093fbfcec9e026457c6a9dab706a7 is added. Quote from https://github.com/fuzzland/ityfuzz/blob/master/backtesting.md

ityfuzz evm -o -t 0x55d398326f99059fF775485246999027B3197955,0x202b233735bF743FA31abb8f71e641970161bF98,0xa361433E409Adac1f87CDF133127585F8a93c67d,0x16b9a82891338f9bA80E2D6970FddA79D1eb0daE,0x34Bd6Dba456Bc31c2b3393e499fa10bED32a9370,0xc30808d9373093fbfcec9e026457c6a9dab706a7,0x34bd6dba456bc31c2b3393e499fa10bed32a9370,0x93c175439726797dcee24d08e4ac9164e88e7aee -c bsc --onchain-block-number 20245522 -f -i -p --onchain-etherscan-api-key $BSC_ETHERSCAN_API_KEY

This gives:

================ Trace ================
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0xc30808d9373093fbfcec9e026457c6a9dab706a7 4641257d with 0 ETH (4641257d), liq percent: 0
== 0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0xc30808d9373093fbfcec9e026457c6a9dab706a7 Stepping with return:  with 0 ETH (00000000), liq percent: 0

This obviously works because this is the original attacking transaction: https://bscscan.com/tx/0x50da0b1b6e34bce59769157df769eb45fa11efc7d0e292900d6b0a86ae66a2b3 . Note 0x4641257d is exactly the signature of harvest, the entry point of the original attack contract.

Removing the address from the set and re-running gives another trace:

================ Oracle ================
0xa361433e409adac1f87cdf133127585f8a93c67d, Reserves changed from (0x000000000000000000000000000000000000000000005a8a9e5416812dc8ab7b_U256, 0x0000000000000000000000000000000000000000002b6144f676be81716e0d30_U256) to (0x000000000000000000000000000000000000000000005a8a9e5416812dc8abcb_U256, 0x0000000000000000000000000000000000000000002b6144f676be81716e0d30_U256)

================ Trace ================
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb borrow token 0x202b233735bf743fa31abb8f71e641970161bf98 with 5231653821711686392733 ETH, liq percent: 0
0xe1a425f1ac34a8a441566f93c82dd730639c8510 borrow token 0x55d398326f99059ff775485246999027b3197955 with 10000000000000000000 ETH, liq percent: 0
0x8ef508aca04b32ff3ba5003177cb18bfa6cd79dd => 0xa361433e409adac1f87cdf133127585f8a93c67d skim(0xF45cd219aEF8618A92BAa7aD848364a158a24F33) with 0 ETH (bc25cf77000000000000000000000000f45cd219aef8618a92baa7ad848364a158a24f33), liq percent: 10
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0xa361433e409adac1f87cdf133127585f8a93c67d skim(0x0E09FaBB73Bd3Ade0a17ECC321fD13a19e81cE82) with 0 ETH (bc25cf770000000000000000000000000e09fabb73bd3ade0a17ecc321fd13a19e81ce82), liq percent: 10
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0x16b9a82891338f9ba80e2d6970fdda79d1eb0dae skim(0xa361433E409Adac1f87CDF133127585F8a93c67d) with 0 ETH (bc25cf77000000000000000000000000a361433e409adac1f87cdf133127585f8a93c67d), liq percent: 0
0x35c9dfd76bf02107ff4f7128bd69716612d31ddb => 0xa361433e409adac1f87cdf133127585f8a93c67d mint(0xa361433E409Adac1f87CDF133127585F8a93c67d) with 0 ETH (6a627842000000000000000000000000a361433e409adac1f87cdf133127585f8a93c67d), liq percent: 10
0xe1a425f1ac34a8a441566f93c82dd730639c8510 => 0xa361433e409adac1f87cdf133127585f8a93c67d burn(0x0Ddcd354BAC10f239558D4d63f192BcAeA2C8f85) with 0 ETH (89afcb440000000000000000000000000ddcd354bac10f239558d4d63f192bcaea2c8f85), liq percent: 0

This looks a bit more promising (reserves changes) so not a big issue.

[shouc]

Sorry, we merged a PR that breaks the power scheduler, increasing the false negatives. It should be fixed now. I am working on the FP; thanks for reporting!

[wtdcode]

Sorry, we merged a PR that breaks the power scheduler, increasing the false negatives. It should be fixed now. I am working on the FP; thanks for reporting!

I don't see too many improvements regarding reproducing while it crashes more frequently.

thread 'main' panicked at src/evm/middlewares/cheatcode.rs:257:58:
decode cheatcode failed: UnknownSelector { name: "VmCalls", selector: 0xa6afed95 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[shouc]

Can you please share the commands? Thanks

[spaceh3ad]

for SEAMAN

❯ ityfuzz evm -o -t 0x55d398326f99059fF775485246999027B3197955,0x6bc9b4976ba6f8C9574326375204eE469993D038,0x6637914482670f91F43025802b6755F27050b0a6,0xDB95FBc5532eEb43DeEd56c8dc050c930e31017e -c bsc --onchain-block-number 23467515 -f -i -p --onchain-etherscan-api-key XXXX
thread 'main' panicked at src/evm/mod.rs:600:13:
Please specify --deployment-script (The contract that deploys the project) or --offchain-config-file (JSON for deploying the project)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace