Jump to content
xisto Community
Sign in to follow this  
tansqrx

Yahoo! Protocol: Part 17 - Crash

Recommended Posts

The results from a crash can be simply summarized in the following statement: âAccess violation when reading (00730079). In windows terms, an access violation occurs when a program tries to read information from a protected area in memory or a section of memory that does not belong to that particular program. In this case, Yahoo! Messenger tried to read the memory address 00730079. Table 2 shows the currently allocated memory areas for Messenger sorted by ascending address.

 

Posted Image

 

Table 2 - Currently Allocated Memory Addresses


It is seen that 00730079 is not included as a valid address and thus the memory access violation occurs.

 

Posted Image

 

Table 3 - Registers

By examining the processor registers, as shown in Table 3, the EIP or instruction pointer is set to the value of MSVCR71.7C3417E1. MSVCR71 is one of the external dynamic link libraries (DLL) loaded by messenger at run time, and is a common DLL supplied by Microsoft. Through examination of the source assembly, it is found that this instructions lies within the strlen function and the instruction that caused the fault is MOV AL, BYTE PTR DS:[ECX]. This instruction moves the contents of the address located at ECX into the lower part of the EAX. ECX is unreadable and thus the access violation.

After much experimentation it was found that a single shared files packet would not cause a crash. Even if multiple packets were sent, if enough time has elapsed between the packets Messenger will not crash. Only if a second packet is received by Messenger before processing is complete on the first packet will the access violation occur. This leads me to conclude that the packet being received by Messenger is not so much of the problem as timing issues within Messenger. By adding break points to the program, it is found that considerable processing is performed between certain types of packets. One such packet is the P2P file transfer packet used in the shared files boot. Several registry accesses are performed and in total over 10,000 operations are performed before this type of packet is fully processed. Even with lighting fast speeds of current processors, this lag gives plenty of time for a second packet to be received by a relatively slow network connection.

This theory is further supported by studying other boot code. Although different packets are used, every boot needs to send multiple packets in rapid succession and all boots result in an access violation at address 00730079.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.