JS reverse core process:
- From analyzing network requests -->
- Locate where the encrypted parameters are generated -->
- Deduct the "JS encryption algorithm code" of the encryption parameter -->
- Supplement the browser environment -->
- to the final node call;
This process is the main meridian of JS reverse and the core of JS reverse, and each step has its own systematic analysis plan, such as "locating the encryption parameter generation point" , and its plans include:
- Search encryption parameters
- Go to the call stack through the requested Initiator
- xhr breakpoint request sending location
- DOM breakpoint response data rendering position
- Event Listener breakpoint trigger event location
- Hook object assignment - object property access
etc. . . Combining this series of analysis schemes to form a system, the ultimate goal is: "locate the place where the encryption parameters are generated" , and then enter the follow-up process - deduct the "js encryption algorithm code" of the encryption parameters ;
For the reverse engineering of different anti-crawling websites, we have to go through the first three steps in person, and it is difficult to have a general solution; the
first three steps require us to spend time polishing and practicing, so that we can use them freely to deal with higher difficulties the reverse of
However, the step of "replenishing the browser environment" is quite special, and there is a feasible pass-through solution. The ultimate goal
of this step is to make the deducted "JS encryption algorithm code" run correctly in the node environment . There are two options for achieving this:
- Replace the browser environment logic used in "JS encryption algorithm code" ; for example:
var flag;
if(navigator.userAgent){
flag=true
}
替换为 var flag=true;
- Use js to forge various environments of the browser, such as
BOM： navigator.userAgent DOM：document.cookie;
Of course, these two solutions can be used in combination, but their defects still exist:
-
The difficulty of the first solution is that it is necessary to locate which browser environments the code uses before performing logic replacement; and when the website js logic is updated, it needs to be replaced again. . Unable to kill different websites
-
The difficulty of the second solution is that there are too many browser environments, and there are too many objects that need to be forged, but it can be "killed" when there are enough supplements .
In order to reduce the energy spent in this step and greatly improve work efficiency, we choose to optimize the second solution to achieve the purpose of pass-kill:
pass-kill plan – use js to simulate a browser environment that tends to be perfect, and let the deducted "JS encryption Algorithm code" is like running in a real browser;
this solution has a large amount of engineering code, and needs to use the "environment supplementary framework" to organize various browser environment codes to achieve the final effect.
"Completion environment framework through train": Detailed explanation of browser supplementation environment in JS reverse engineering