Loading the SWF into FFDEC looks like this
The flash file holds a binaryData which when decrypted becomes another flash file that exploit CVE-2016-4117. The logic to decode the flash file looks like below,
The flash file holds a binaryData which when decrypted becomes another flash file that exploit CVE-2016-4117. The logic to decode the flash file looks like below,
while(_loc6_ < _loc4_)
{
_loc3_[_loc6_] = _loc3_[_loc6_] ^ _loc5_;
_loc6_++;
_loc5_ = _loc5_ + 17 & 255;
}
Simple porting of the above script script to Python for decoding the binaryData blob.
def main():
data = bytearray(open("binaryblob.bin", "rb").read())
length = len(data)
key = data[length-1]
for i in range(0,length):
data[i] = data[i] ^ key
key = key + 17 & 255
f = open("C:\\decrypted.swf", "wb")
f.write(data)
f.close()
if __name__ == '__main__':
main()
And the decoded file looks like,
The base flash file has additional code to confirm if it has decoded the flash file properly. It checks few decoded bytes to confirm if everything worked fine.
The base flash file also has another trick up its sleeves. It has function that does the shellcode substitution. This function searches the decoded flash file for "NOSP SLED" (9090909090....) and replaces it with the shellcode from the base flash file.
This probably is done by the attackers for speedy replacement of shellcodes without touching the concealed flash file. So the decoded flash file before and after replacement of the shell looks like below.
No comments:
Post a Comment