As, CP and _signature parameter codes are located in the encrypted JS code. This article will look at how to use these JS code to generate the encryption parameter values we need.

Generally, we have located JS and the next step is to peel out the relevant code for use. There are probably several mainstream ways of use:

  • According to the relevant JS encryption logic, using their familiar language (Python) “translate” into Python code. This disadvantage is also obvious, we need to read all the details of the encryption logic, and if the target JS code is very large or the logic is very complex, you know…

  • Execute the stripped JS code using libraries such as ExecJS.

  • You are smart enough to immediately think of using an automated tool like Selenium to drive the browser to execute JS, but the detection of headless browsers is so sophisticated that, for example, you’ll find that headless browsers don’t get critical data either.

  • Use Node.js. Since Node.js is a JavaScript environment based on the Chrome V8 engine, you can bypass browser detection by executing JS in this environment.

So, today we’ll show you how to use Node.js to execute JS code to get encrypted values.

We saw in the previous article that the as and cp parameters are the AS and cp properties under the e object

And the e object is actually a function

A function is the generating logic of as and cp parameters

The key point is that you need to know that variable I corresponds to O.fault, and breakpoint debugging will know that O.Fault is actually a C function

Now let’s strip out the C function

From the 1285 lines

To 1439 line

And then it strips out the code that calls the C function, the A function

From line 1218 to line 1234

Here, since o.fault corresponds to function C, change (0, O.fault) to C

We can put this code into a function that, when generated, returns the values of as and cp, as follows

Because the code is too long, I will take a screenshot of some of the code

Let’s run the stripped code into WebStorm

Let’s start digging into the _signature section

Window.byted_acrawler.sign (a) is where the _signature parameter is generated

And window.byted_acrawler.sign is function e

Function e is a piece of obfuscated code

We don’t need to do any more analysis here, just cut this whole thing out and call it

Byted_acrawler has two methods init and sign

A global search for window.byted_acrawler finds the code for init in the index page

So let’s cut both of these pieces of code off and put them into a function to call

Then define the calling function

At this point, you think you can run the code and be happy to get the encrypted value

But here’s the reality…

Window is not defined? What’s going on here?

Because there is a special Object in JavaScript called a Global Object, it and all of its properties can be accessed from anywhere in the program: the Global variable.

In browser JavaScript, normally window is the global object, while the global object in Node.js is global, and all global variables (except global itself) are properties of the Global object.

The window is undefined, so we just assign global to the window, and the window becomes a global object

After we define it, we will run it, and then we will get this error again…

Node.js is powered by the V8 engine, but it’s not like the actual browser environment, so you need to be patient and debug it step by step.

Through n* N debugging, finally complete all the required things

This is my run result

Let’s see if we can get the data

Finally, we can get the correct encryption parameters, there should be red packets, oh no, applause…

Write an interface in Node.js, the crawler requests the interface, the interface generates parameter values, returns the corresponding parameter values, and then you can happily do what you want to do

Like this

The client requests the encrypted value

Reverse is not easy, in order to avoid abuse, small partners if you need a complete code, you can add my wechat background message to get the code

One js analysis process is relatively simple. The difficulty is that the browser environment has been detected by the other side. We cannot simply use ExecJS or Selenium to drive the browser to execute JS and obtain data.

Of course, if you have enough patience and time to debug and analyze exactly what parameters they’re testing and then bypass them, that’s fine

In this paper, the actual combat goal, compared to using node.js environment to run code, or can be relatively simple and fast to achieve the goal to complete the task, the premise is to have some Node.js foundation, otherwise the environment construction and debugging process is quite tired…

I’m sure there are many people (like me) who have broken their balls when trying to debug Node.js because the Node environment is different from the real browser.

So in my next post, I’ll show you another way to easily execute node.js and get results without having to debug painful Node.js, theoretically bypassing all browser detection altogether.