Fairyproof’s Analysis of Abnormal Event of NASA
NASA, a token deployed on BSC showed an abnormally huge transfer amount on 22nd December 2021 +UTC.
NASA, a token deployed on BSC showed an abnormally huge transfer amount on 22nd December 2021 +UTC.
The token contract’s address deployed on BSC was:
0xF8d64dc86b0d2Df8A93c87c94c85B127B68bC676
The hash value of the transaction that showed an abnormal amount was:
0xf7159ea9b8c18f0494ca06bb0a72dca5766a5147f9f96d3415eba30cecd5cde4
Based on the information obtained from one BSC explorer, a huge number of NASA tokens were transferred in this transaction. Here is a screenshot of more details related to this issue:
The whole process was a swap operation that took place on Pancake. The first transfer showed a number of 3.245 e63 NASA tokens were transferred, which was an extremely huge amount.
After checking the recipient’s address 0xf6c3fde59d70e89b56b8f13cb01ffae16366bfad, we found out that the balance of its NASA token was 1504136468711454337(the conversion could be viewed on https://bscscan.com/unitconverter?wei=1504136468711454337.). Apparently, it looked normal, but it was dramatically different from the transferred amount.
Following this clue, it might seem that something wrong happened with the “Transfer” operation or the “balanceOf” operation.
After we reviewed the NASA token contract’s source code, we found out that it was a token very similar to SafeMoon. In its “transfer” and “transferFrom” functions, a fee was charged. In this operation, two fees were charged.
The first charged fee was sent to an address variable “_rugPullFundAddress” whose value was:0xF6c3fde59d70E89b56b8F13cb01FFAe16366bFad. This transaction was the one with that huge amount.
The second charged fee was sent to an address variable “_marketingAddress” whose value was 0x249A7778707183A63b72237d4976D62c7196A13e. This transaction was the second transfer shown in the screenshot. The amount transferred looked normal.
After we dug into these transactions, we found out that the following two functions triggered these transactions.
After comparing these two functions we could see that the _txToRugPullFund function didn’t apply “ tokenFromReflection()” to the input amount in its event.
We went further into the “tokenFromReflection()” function and here was the code:
This function divided “rAmount” by “_getRate()”.
After reviewing the NASA token contract’s code, we found out that the return value of “_getRate()” was 1e57. So, if “_txToRugPullFund” were to apply “tokenFromReflection” to its input amount in its event, the event would show a correct number.
We reviewed both the “transfer” and the “balanceOf” functions and both applied “tokenFromReflection”.
Hence the issue was only with the event. The root cause was that the “_txToRugPullFund” function didn’t apply “tokenFromReflection” to its input amount in its event.
The actual transfer amount was correctly handled as of the time of writing.