Relocations for this machine are not implemented, and the IDA version is too low, causing assembly code generation to fail.

Table of contents

1. Problem description

2. When an Android app crashes, you need to view the assembly code context to assist in analysis.

3. Use IDA to open the .so dynamic library file, and it will prompt that Relocations for this machine are not implemented.

4. The IDA version is older and does not support the ARM64 instruction set. Just use version 7.0.

5. Find the location of the crashed assembly instruction in the target function

6. Find the C++ source code location corresponding to the assembly instruction that crashed by reading the assembly code context.


C++ software anomaly troubleshooting series of tutorials from entry to mastery (column article list, welcome to subscribe, continuous updates...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/125529931 C/C++ basics and advanced (column) Article, continuing to be updated...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/category_11931267.html Summary of VC++ common function development (list of column articles, welcome to subscribe, continuously updated...) icon-default.png?t=N7T8https://blog.csdn .net/chenlycly/article/details/124272585 A collection of cases from entry to mastery of C++ software analysis tools (column article, continuously updated...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/131405795 Open source components and database technology (column article, continuously updated...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/category_12458859.html Network programming and network problem sharing (column article, continuously updated...) icon-default.png?t=N7T8https:// blog.csdn.net/chenlycly/category_2276111.html        Recently, when I used IDA to open a .so dynamic library compiled on the 64-bit ARM platform, IDA first prompted: Relocations for this machine are not implemented, and then no assembly code was generated after opening. After many attempts and research, we found that the IDA version is too low. The old version of IDA has problems with the ARM64 instruction set or does not support the ARM64 instruction set. Just use version 7.0 and above . This article describes in detail the phenomenon of the problem and the process of trying to solve it.

1. Problem description

       Recently, when troubleshooting the crash problem of an Android app, I needed to view the assembly code context of the .so dynamic library implemented in C++ at the bottom of the app to assist in the analysis. But when using the 64-bit version of IDA to open the .so dynamic library, the first prompt is: Relocations for this machine are not implemented :

Then after opening, no assembly code is generated.

2. When an Android app crashes, you need to view the assembly code context to assist in analysis.

       The Android app crashed during the test, and a Tombstone file containing exception information was automatically generated. Open the Tombstone file and view the function call stack at the time of the crash, as shown below:

As can be seen from the above stack, the crash occurred in the libxxservice_hddll.so dynamic library (this module is the underlying business library and is a dynamic library implemented in C++ language). Specifically, the crash occurred in the function CXXXServiceHMpHandler::OnTextImageCreateBannerInfoRsp, and you can see that relative to The offset value of this function is 1048 (this is a decimal integer value). It is only seen that the crash occurred in this function, but there is a lot of code in the function, and it is impossible to determine which line of code the crash occurred from the existing information.

       Now that we have the function name and the offset value relative to the function, we can use the IDA tool to open the libxxservice_hddll.so dynamic library file and locate the code segment CXXXServiceHMpHandler::OnTextImageCreateBannerInfoRsp(mtmsg::CMtMsg*, unsigned int, unsigned int)+1048 The address corresponds to that sentence of assembly code , and then match the context of the assembly code with the C++ source code to see which line of C++ source code the crashed assembly code corresponds to. You may be able to quickly determine the cause of the problem.


       Here, I would like to highlight some of my best-selling columns:

Column 1: (This column has nearly 350 subscriptions. It has strong practical reference value and is widely praised! The column articles are being continuously updated and are expected to be updated to more than 200 articles!)

Summary of C++ software debugging and exception troubleshooting series of articles from entry to mastery icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/125529931

Based on the project practice of troubleshooting C++ software exceptions in recent years, this column systematically summarizes the common causes of C++ software exceptions and common ideas and methods for troubleshooting C++ software exceptions. It also details the debugging methods and methods of C++ software, with pictures and texts. The method gives specific practical problem analysis examples and leads everyone to gradually master the related technologies of C++ software debugging and exception troubleshooting. It is suitable for basic advanced and related C++ developers who want to improve their skills!

The articles in the column are all summarized through actual project operations (a large amount of anomaly troubleshooting materials and cases have been accumulated through actual project operations), and have strong practical reference value! The column articles are still being updated, and the number of articles is expected to be updated to more than 200!

Column 2: 

C/C++ basics and advanced (column article, continuously updated...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/category_11931267.html

Based on many years of practical development, this book summarizes and explains some basic and advanced content of C/C++, and expands and elaborates on relevant knowledge points in detail with pictures and texts! The column covers many aspects of the C/C++ field, and also gives common written interview questions in C/C++ and networking, and details commonly used debugging methods and techniques in Visual Studio!

Column 3: 

Open source components and database technology icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/category_12458859.html

Based on years of practical development, we share some open source components and database technologies! 


3. Use IDA to open the .so dynamic library file, and it will prompt that Relocations for this machine are not implemented.

       The current crash occurs in the libxxservice_hddll.so dynamic library, so we need to open the binary file with IDA and view the relevant assembly code context. The libxxservice_hddll.so library is 64-bit , so you need to use the 64-bit version of IDA to open it. The IDA version I am currently using is Version 6.1.110315 (64-bit) . Drag the libxxservice_hddll.so file into IDA, and a prompt box to select the file format will pop up (generally just choose the default, and IDA will automatically recognize it) :

In fact, there is a question at this time. The automatically generated file type string is: ELF64 for Unknown CPU [183] ​​(Shared object) [elfldw] , that is, IDA cannot identify the CPU platform type of the compiled file . This is a bit strange. Before Never encountered it either.

       Then the following prompt box pops up during the opening process:

Roughly speaking, the relocation of the machine was not performed. Then ignore this prompt and continue to open the libxxservice_hddll.so file. After the opening is successful, click Jump -> Jump to function... in the IDA menu bar. In the function list window that pops up, click the Search button at the bottom of the window and enter tombstone. The function CXXXServiceHMpHandler::OnTextImageCreateBannerInfoRsp in the function call stack shown in (As mentioned above, the crash occurred in this function, you need to view the assembly code of this function), the function was found:

Double-click this entry, and IDA will jump to the assembly code of the function, and you will see the following information:

I didn’t see any valid assembly code, just a string of numbers. Is it binary machine code?

       Looking back now, first the Relocations for this machine are not implemented prompt popped up, and then no assembly code was generated. Maybe something went wrong.

4. The IDA version is older and does not support the ARM64 instruction set. Just use version 7.0.

       First of all, there is no problem with the libxxservice_hddll.so file, and it can be used normally when the app program is running. Is my IDA version too old? My version of IDA looks like this:

It is the 2011 version, which has been more than ten years ago. Our libxxservice_hddll.so library was compiled under the ARM64 platform. Does it mean that the old version of IDA does not support the ARM64 platform?

        So I searched online and downloaded the 2017 version of IDA. I wanted to see if this version could open the library file normally. First, drag the libxxservice_hddll.so library file into IDA, and a window for selecting the file format will pop up, as shown below:

From the picture above, we know that IDA has identified the platform type of this binary file as ARM64 . It is estimated that since it can be identified, assembly code should be generated. Then after the file is opened, search for the CXXXServiceHMpHandler::OnTextImageCreateBannerInfoRsp function, view the assembly code of the function, and see the following assembly code:

Therefore, IDA7.0 supports binary files of the ARM64 platform, and the generated assembly code is normal.

5. Find the location of the crashed assembly instruction in the target function

        The assembly code corresponding to the CXXXServiceHMpHandler::OnTextImageCreateBannerInfoRsp function is as follows:

       You can see that the function address (function first address) of this function is 0x0000000000074DE8, according to the relative function offset displayed in the Tombstone file:

#00 pc 0000000000075200  /xxxkyui/lib64/libxxservice_hddll.so (CXXXServiceHMpHandler::OnTextImageCreateBannerInfoRsp(mtmsg::CMtMsg*, unsigned int, unsigned int)+1048) (BuildId: d6e3064a3e1a03d9bea3c4496e78cb4942d187d1)

Calculate new address:

0x0000000000074DE8 + 0x418 (corresponding to 1048 in decimal) = 0x0000000000075200

Then search the address 0x0000000000075200 in IDA and find the corresponding assembly code line. The specific method is to click the mouse into the assembly code window (make the window focus), then press the shortcut key g, the Jump to address window will pop up, and enter the address calculated above 0x0000000000075200:

Click OK and it will jump to the corresponding line, as shown below:

6. Find the C++ source code location corresponding to the assembly instruction that crashed by reading the assembly code context.

        We are usually used to seeing the assembly code of the X86 platform, but we are not used to seeing the assembly code of this ARM architecture. Whether it is the name of the assembly instruction or the name of the register, there is a big difference. I feel that the assembly code of the X86 platform is more comfortable to read.

       Above we have located the position in the assembly code, but which line of C++ source code corresponds to the assembly code? In addition, the compiler will optimize the C++ code when compiling under Release (some variables or function calls may be optimized out), resulting in assembly code and C++ code that may not be completely consistent, or even difficult to correspond.

       How to match assembly code with C++ source code? Do we have to chew through the assembly code sentence by sentence? Forcibly reading the assembly code context requires a certain amount of assembly skills, which is difficult for ordinary people to do. Generally, we use the annotation information in the assembly context to assist reading. In this example, we use the annotation information to quickly read and locate.

Generally, when reading the assembly code context, on the one hand, you use the comments in the assembly code, and on the other hand, you compare the assembly code with the C++ source code!

       The line of assembly code corresponding to the address 0x0000000000075200. There is a comment immediately below this line of code, which is a comment for the constant value string:

But I can't see the complete string. There is a trick here. You can move the mouse over the variable and the complete content of the variable will be displayed in TooTip mode , as shown below:

This is a coincidence. Such a string is in the print log, so I went to the C++ source code to find the CXXXServiceHMpHandler::OnTextImageCreateBannerInfoRsp function. In the function, I looked for a print like "[CXXXServiceHMpHandler::OnTextImageCreateBannerInfoRsp] dispatch". There is indeed this line of print. As follows:

So I found the approximate C++ source code corresponding to the address 0x0000000000075200. Therefore, the null pointer problem in this example should be the ptTip pointer in the above picture, that is, the pointer value is null. As a result, calling the value interface using this pointer caused a crash.

       For an introduction to the IDA tool and detailed usage instructions , please refer to the article I wrote before:

Detailed explanation of the use of IDA disassembly tool icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/120635120 Use IDA to view the assembly code context to assist in troubleshooting C++ software exceptions icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/ details/128942626 Use the disassembly tool IDA to view the context of the abnormal assembly code to assist in analyzing C++ software exceptions icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/132158574

Guess you like

Origin blog.csdn.net/chenlycly/article/details/135076536