Arc of the Hill Country

Below is the full playlist and the outline for Section 1 the Web3 Hacking in Python course.. This is the most in-depth python based web3 material I have seen anywhere online.

Section 1 is the foundational section of the course using python for web3 that covers the following topics and also assumes that you have already taken my smart contract hacking course from 2020.

Smart Contract and Blockchain Web3 Hacking in Python:

Section 1:

Smart Contract Interactions:

1. Simple Smart Contract Interactions

2. ERC20 Token Interactions

3. Wallet Interactions

4. Manual ByteCode Reversing

5. ByteCode Function BruteForce Automation

6. Automated Reversing and Disassembly

7. Transaction Signing

8. In Depth Manual Smart Contract Interactions

9. Asynchronous programming to monitor Contract Events

Homework Assignments

1. Uniswap Pair nested Contract Interactions

2. Attacking Smart Contract Pathways Manually with python

3. Analyze Bytecode and Determine what it Interactions

Network Interactions:

1. Blocks and transaction Filtering and Monitoring

2. Pending Transaction Subscriptions And Network Monitoring

3. Monitoring Smart Contract Mempool Transactions (Uniswap Routers)

Playlist:

https://www.youtube.com/watch?v=UBK2BoFv6Lo&list=PLCwnLq3tOElrubfUWHa1qKrJv1apO8Aag&index=1

Related links

"Odysseus is a tool designed for testing the security of web applications. Odysseus is a proxy server, which acts as a man-in-the-middle during an HTTP session. A typical HTTP proxy will relay packets to and from a client browser and a web server. Odysseus will intercept an HTTP session's data in either direction and give the user the ability to alter the data before transmission. For example, during a normal HTTP SSL connection a typical proxy will relay the session between the server and the client and allow the two end nodes to negotiate SSL. In contrast, when in intercept mode, Odysseus will pretend to be the server and negotiate two SSL sessions, one with the client browser and another with the web server." read more...

Download: http://www.bindshell.net/tools/odysseus

Introduction to (cryptographic) hash functions

A long time ago (according to some sources since 1970) people started designing hash functions, for an awful lot of different reasons. It can be used for file integrity verification, password verification, pseudo-random generation, etc. But one of the most important properties of a cryptographic hash function is that it can "uniquely" identify a block of data with a small, fixed bit string. E.g., malware can be identified by using only the hash itself, so everybody who has the same malware sample will have the same hash; thus they can refer to the malware by the hash itself.

It is easy to conclude that there will always be collisions, where a different block of data has the same result hashes. The domain (block of data) is infinite, while the codomain (possible hash values) is finite. The question is how easy it is to find two different blocks of data, having the same hash. Mathematicians call this property "collision resistance." Proper cryptographic hash functions are collision-resistant, meaning it is impractical or impossible to find two different blocks of data, which have the same hash.

In 1989 Ronald Rivest (the first letter in the abbreviation of the RSA algorithm) designed the MD-2 hashing algorithm. Since 1997 there are publications about that this hashing algorithm is far from perfect.

In 1990 Ronald Rivest designed the MD-4 algorithm, which is considered as broken at least from 1991. But MD-4 is still in use from Windows XP until Windows 8 in the password protocol (NTLM). Unfortunately, there are more significant problems with NTLM besides using MD-4, but this can be the topic of a different blog post.

In 1991 (you might guess who) designed yet another hashing algorithm called MD-5, to replace MD-4 (because of the known weaknesses). But again, in from 1993 it has been shown many times that MD-5 is broken as well. According to Wikipedia, "On 18 March 2006, Klima published an algorithm [17] that can find a collision within one minute on a single notebook computer, using a method he calls tunneling". This means, that with the 8 years old computing power of a single notebook one can create two different files having the same MD-5 hash. But the algorithms to generate collisions have been improved since, and "a 2013 attack by Xie Tao, Fanbao Liu, and Dengguo Feng breaks MD-5 collision resistance in 2^18 time. This attack runs in less than a second on a regular computer." The key takeaway here is that it is pretty damn hard to design a secure cryptographic hash function, which is fast, but still safe. I bet that if I would develop a hash function, Ron would be able to hack it in minutes.

Now, dear malware researcher, consider the following scenario. You as, a malware analyst, find a new binary sample. You calculate the MD-5 hash of the malware, and Google for that hash. You see this hash value on other malware researchers or on a sandbox/vendor's site. This site concludes that this sample does this or that, and is either malicious or not. Either because the site is also relying solely on MD-5 or because you have only checked the MD-5 and the researcher or sandbox has a good reputation, you move on and forget this binary. But in reality, it is possible that your binary is totally different than the one analyzed by others. The results of this mistake can scale from nothing to catastrophic.

If you don't believe me, just check the hello.exe and erase.exe on this site from Peter Sellinger. Same MD-5, different binaries; a harmless and a (fake) malicious one... And you can do the same easily at home. No supercomputers, no NSA magic needed.

On a side-note, it is important to mention that even today it can be hard to find a block of data (in generic), if only the MD-5 hash is known ("pre image resistance"). I have heard people arguing this when I told them using MD-5 as a password hash function is a bad idea. The main problem with MD-5 as a password hash is not the weaknesses in MD-5 itself, but the lack of salt, lack of iterations, and lack of memory hardness. But still, I don't see any reason why you should use MD-5 as a building block for anything, which has anything to do with security. Would you use a car to drive your children to the school, which car has not been maintained in the last 23 year? If your answer is yes, you should neither have children nor a job in IT SEC.

Conclusion

If you are a malware researcher, and used MD-5 only to identify malware samples in the past, I suggest to write it down 1000 times: "I promise I won't use MD-5 to identify malware in the future."

I even made a website dedicated to this problem, www.stopusingmd5now.com . The next time you see a post/article/whatever where malware is identified by the MD-5 hash only, please link to this blog post or website, and the world will be a better and more professional place.

PS: If you are a forensics investigator, or software developer developing software used in forensics, the same applies to you.
PS 2: If you find this post too provocative and harsh, there is a reason for this ...

Update: I have modified two malware (Citadel, Atrax) with the help of HashClash, and now those have the same MD-5. Many thanks for Marc Stevens for his research, publishing his code, and help given during the collision finding.

Arc of the Hill Country

Wednesday, May 31, 2023

Web3 Smart Contract And Blockchain Hacking With Python Free Course Section 1

Smart Contract and Blockchain Web3 Hacking in Python:

Section 1:

Smart Contract Interactions:

Homework Assignments

Network Interactions:

Playlist:

Odysseus

Related posts

Stop Using MD-5, Now!

Introduction to (cryptographic) hash functions

Conclusion

Read more

Tuesday, May 30, 2023

TYPES OF HACKING

Related articles