Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

The Magic of a number-- A Journey to crack Mac Software

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

Shulou(Shulou.com)06/01 Report--

Background and purpose

The next article will show you how to accomplish an "impossible" task-to crack the fee-paying software Paw by changing a number.

At first, I saw a very useful App on Mac, called Paw, in the blog of some great god. Paw can simulate various HTTP requests on Mac, visually manage HTTP Header, Parameters, Cookies, etc., and a very unexpected feature is that it can automatically generate code in Swfit, OC, JS and other languages by downloading plug-ins.

However, Paw is extremely expensive, and the cracked version is not easy to search. So he thought about solving the needs by himself, so the hapless Paw became the experimental subject. Download the original app from here first

Since I had no experience in reverse engineering before, I didn't understand and suffered when reading other people's introductions, so I tried to describe this journey of cracking app from scratch in simple and detailed language. As a reference, it took me about seven hours to complete the crack (a lot of time was wasted on finding and learning to use tools, which is not difficult to crack later). The download address of the cracked version will be given at the end of the article.

Due to the limited level, I only introduce the basic knowledge of reverse engineering, which can be regarded as my own study notes. I also hope to popularize some basic knowledge of reverse engineering to more programmers who are just rookies like me. At the same time, I urge myself to pay attention to code specification and safety in the process of Coding.

Knowledge reserve

If you want to crack app, you must first develop app and understand at least some basic command line operations, source code, assembly code, and basic definitions of binary code. If any of these basic requirements are not met, the whole process will be very painful.

Tool preparation

The main tools used to crack Paw are as follows.

Homebrew-even people who don't know this would be embarrassed to say that they are programmers who use Mac.

Hopper Disassembler-decompiler tool that decompiles the assembly code from the executable file.

Class-dump-an entry-level tool for reverse engineering that exports some information about an App.

Otx-a tool introduced by a foreign god, I can't say its definite use. Install through the brew install-- HEAD homebrew/head-only/otx command.

Hex friend-binary editor, use this to modify binaries.

Gdb, a famous debugger, can also be used with lldb. Install through the brew install gdb command.

Begin cracking found the crack point.

To crack App, of course, you have to understand why you want to crack it, which point restricts us, first of all, run the original Paw. You can see the following interface:

This Welcome interface is very annoying, and because of its existence, we can't click on the main interface of the program. There are only two ways to shut down the Welcome interface: select the Try Paw button to get a 30-day trial period or click the Register License button to enter your own License.

So our purpose is very clear-- to close the Welcome page.

Preliminary study on Paw

Since you want to crack the App, it is inevitable to understand the structure of the App. Now all we have is the Paw.app file in the Applications folder. The breakthrough lies in Paw.app/Contents/MacOs/Paw, an executable binary. Our future operations, most of the time is to deal with it. Under the "applications" folder, right-click Paw and select "Show package contents" to see the binary file.

At this time, the first tool, class-dump, came out. Due to space constraints, I will not introduce the specific configuration of this tool. You can refer to this article

Export other application header files using class-dump

Let's first export the header file of Paw with class-dump and execute the command in the terminal:

Class-dump-H / Applications/PawReal.app/Contents/MacOS/Paw-o / Users/ your user name / Desktop/classdump

Change your user name, and when the run is over, you can see a folder called classdump on your desktop. Don't be frightened by the dense files inside, this is all the header files of the app.

Be considerate of others and be flexible.

How to find the information we need next? it is not realistic to look at it one by one, even if there are only the definitions of methods and variables in the header file. Fortunately, class-dump has other functions. Execute the command:

Class-dump-f license / Applications/PawReal.app/Contents/MacOS/Paw

You can find all the license-related parts of the header file.

Why are you looking for license? you need to guess this. Since the software requires a registration code and the Welcome interface has a Register License button, there must be a part of the code used to manage certificates (License). Let's think from the developer's point of view that if you want to follow the naming convention, there may be the License keyword in the header file.

Of course, this is just a guess, if the search results for the License keyword are not satisfactory, we can also change some keywords, such as Register, Validate, and so on.

Fortunately, we found some clues through class-dump, as shown in the figure:

In the figure, we found a more valuable class: LMWelcomeViewController

Make a reasonable guess and chase while winning

After discovering LMWelcomeViewController, the class used to manage Welcome pages, let's start with the file and look at the functions inside. Coincidentally, there is a set of functions that all start with showWelcomeWindow. Intuition tells us that this method of displaying Welcome pages is likely to be the key to solving the problem.

So do it again, take a look at the information of the function showWelcomeWindow. Run:

Class-dump-f showWelcome / Applications/PawCrack.app/Contents/MacOS/Paw

You can see the results as follows:

This basically confirms the previous conjecture: the code in LMApplicationDelegate.m executes when the program starts, determines whether the user has registered in some way, if not, calls the showWelcomeWindow function, and takes the instance object of the LMWelcomeViewController class as a parameter, which executes its own showWelcomeWindow method to display the Welcome page.

Of course, such an analysis is likely to be wrong. Because the logic of determining whether to register or not is not necessarily done in LMApplicationDelegate, it can also be placed in LMWelcomeViewController. But in any case, notice that the boldface part is also a paragraph, the whole process is actually a "if". Oh, just. " The logic of.

Remember this logic, we will make some changes according to this logic in a moment!

Take a closer look at the function implementation

Now that we know that LMWelcomeViewController's showWelcomeWindow method may be the key to solving the problem, let's take a look at how this method is implemented.

Open Hopper Disassembler, drag the Paw binaries in the MacOS folder, and start the analysis. Hopper Disassembler can be disassembled into assembly code based on binaries. When you first opened it, the software looked like this:

What you see in this software is often very strange, different from any high-level programming language. This assembly language has caused great obstacles to novice reading, fortunately, there are some comments, but also can generate pseudo-code to assist us in reading. I can hardly read assembly language, so I try to avoid studying them too much.

Search for what we are interested in under the Labels tag on the left, such as the showWelcomeWindow method just mentioned.

You can see the implementation of the showWelcomeWindow method in LMWelcomeViewController and LMApplicationDelegate, respectively:

The showWelcomeWindow method in LMApplicationDelegate is very simple, and the showWelcomeWindow method with parameters called can be guessed from the comments in the green section. Or we can select the assembly code and click the icon in the upper right corner to generate pseudo code.

The showWelcomeWindow method in LMWelcomeViewController is complex.

As you can see in the previous picture, the two assembly instructions are je and ret

Je is an acronym for "jump euqal", meaning that if equal, jump to an address. So we can see the cmp instruction on the top line of je. The counterpart to je is jne, which means "jump not euqal"

Ret, as its name implies, is an abbreviation for return, which means that the function is returned here.

In fact, we can already get a general idea of the implementation of the showWelcomeWindow method in this. Made a decision, if the city is back, otherwise do the following operation, and according to the green prompt on the right, we see the "scary" showWindow method, which is not seen in the header file, it is probably a private method.

If you are not at ease, you can also generate pseudo-code and take a look:

Skillfully changing logic

The logic that appeared in the previous analysis of the entire Welcome page is actually a "if., just." The judgment, then want to crack, it is also very easy. There are two methods that either determine that the condition is not valid or change the execution statement. Obviously, for newcomers who are not familiar with assembly and reverse engineering, it is easier to judge the conditions. Notice that the je instruction is preceded by a number: 00000001000cdfaf, which represents the address of the instruction in the virtual memory space. So what's the use of this address?

Comb the train of thought

Indeed, at first glance, it is useless to get the address of the instruction. And from the beginning to the present, I have been in contact with things that I have never touched at all, and I am a little dizzy.

Combing through the ideas so far, we found the showWelcomeWindow method from the license keyword tree. It is analyzed that the key step is the je instruction, and finally the address of the instruction in virtual memory is known.

In fact, our goal is very simple, which is to replace the je instruction with the jne instruction. So far, there are only three steps left.

Calculate the binary code of the je instruction.

Calculate the binary code of the jne instruction.

In the binary file, replace the binary code that calculates the je instruction with the binary code that calculates the jne instruction.

Fortunately, the gdb debugger can do the first two steps for us. It eliminates the process of converting from assembly to binary code that we are not familiar with at all. The gdb debugger has an xstroke x command that reads data from a given memory address.

We know that the process of running a program is simply the process in which the binary code is loaded into memory from the hard disk and then runs from the entrance of the program. We are not assemblers and are not good at static conversion from assembly code to binary code. But the gdb debugger allows us to dynamically and inversely find binaries from memory.

Therefore, it is still the last step away from success!

Binary file

So, execute:

X/x 0x00000001000cdfaf

The following results can be obtained:

0x1000cdfaf: 0x83480774

The 0x83480774 here is the program binary code in hexadecimal format. Then you can open the Hex friend software to modify the binary code. Hex friend presents the application in hexadecimal form, supporting find and replace functions.

Press Command + F to find it.

Special attention should be paid to the problem of byte order (Byte Order). Intel processors are generally stored at small end (Little endian), while binary codes on hard disk are stored at Big endian. The so-called big end is to put the highest bit of the number at the front, and the small end to put the highest bit at the back.

In other words, 0x83480774 as a small number, its large-end form should be 74074883, after clicking the Replace & Find button, the unfortunate thing happened: this number appeared more than once.

The solution is simple, just look at the binary code of the next instruction in the same way. Execute:

0x1000cdfb1: 0x83480774

Get:

0x1000cdfaf: 0x08c48348

4883c408 is represented by the big end, and the first four digits of this number are exactly the same as the last four digits of the previous number. This is not a coincidence, because the length of the binary code varies with different instructions. Gdb's xram x instruction always reads data in memory of the same length.

This doesn't affect cracking Paw, but if you want to know more about it, you can check it out with the otx command:

You can see that the actual binary code of the eq instruction is 7407.

Now we have finally identified the digital 74074883c408 to be replaced, which contains the binary code of the eq instruction and the binary code of the following instructions. This extra information is used to uniquely determine the location of this set of numbers.

"7407" consists of "74" and "07". By consulting relevant materials or looking for several other eq instructions and enq instructions, we can know that the binary code of eq instruction is "74" and that of eq instruction is "75".

So the number to replace should be "75074883c408". After filling in the relevant data in Hex friend, select Replace and save it. As shown in the figure:

At this point, the whole cracking process is completed. In fact, when you think about it, we just changed a 4 into a 5!

File signature

After replacing the original file with the modified binary, the opening program will always report an error immediately. If you run it on the command line, you can also see the prompt for killed 9.

This is because Apple has added a code signing (CodeSignature) mechanism to ensure the security of the software. You can find the _ CodeSignature folder and the CodeResources file in it under the Contents folder. Any modification to the binary file cannot pass the code signature check.

For a specific explanation of the code signature and the operation process, you can read this article:

"How to re-sign Apple's applications once they've been modified"

The article describes each step very thoroughly, so I won't repeat it. As described in the article, after you have established your own signing certificate, simply execute this command:

Codesign-f-s certificate title / Applications/PawCrack.app/Contents/MacOS/Paw

The name of the certificate is written in the name of the certificate you created. If all goes well, you will get the following prompt:

/ Applications/PawCrack.app/Contents/MacOS/Paw: replacing existing signature

After the code is resigned, you can successfully open the cracked App.

After opening App, we can see that the annoying Welcome page is missing. Because the judgment logic is reversed, the showWelcomeWindow method is not executed.

The cracked version of app can be found here: Paw cracked version

Summary

First of all, let's review the whole cracking process. After we have prepared the tool, we first search for the available method name in the header file, and then use the decompiler to see the assembly code implementation of the specific method. Combine the basic assembly syntax and pseudo code to understand the working principle of the whole method. Finally, the logic of the if statement is modified to complete the cracking.

In fact, because most of the functional limitations are based on if else statements, that is to say, for a considerable number of software, as long as we analyze its logic, we only need to change a 4 to 5 to crack.

The whole cracking process, in addition to consolidating the basic knowledge of the operating system, I think there are some other gains for iOS engineer:

Strictly abide by the "Dimitt Law", define and implement what is not necessary in the .m file. This will not only prevent it from being scanned by class-dump, but also lighten the development burden of your colleagues.

The-g parameter is removed when compiling the release version of gcc. I guess it was because Paw did this that I couldn't add breakpoints with the gdb debugger. Because the symbolic name of the function cannot be found.

For the most core parts, you can do appropriate code confusion.

Doing the above is very easy, but enough to prevent a large number of general technical tinkerer (such as the author himself) from causing trouble.

references

"Giving gdb permission to control other processes"

"I Can Crack Your App With Just A Shell"

"How to re-sign Apple's applications once they've been modified"

Beginning Mac Hacking

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report