Explicación detallada del paso elevado de entorno complementario inverso JS

Explicación detallada del paso elevado de entorno complementario inverso JS

"Ruishu" es una gran montaña en el camino inverso, un muro que muchos inversores JS no pueden evitar, y también es un punto brillante en el currículum de salto de trabajo. ¡Debemos superarlo antes del próximo salto de trabajo! ! Afortunadamente, hay muchos artículos en Internet que explican Ruishu, y nos enseñan paso a paso a analizar el proceso de Ruishu y cómo deducir la lógica de Ruishu, en un intento de enseñarnos (manual cabeza de perro ) . Sin embargo, hay algunos artículos que explican en detalle cómo pasar Ruishu simplemente complementando el entorno. ¡Hoy está aquí!

Para permitir que todos manejen a fondo al hermano mayor Ruishu, este artículo describirá las siguientes cuatro partes:

1. La lógica del proceso de rs
2. Hablando de código de deducción pase rs
3. Explicar en detalle el proceso de suplementación del medio ambiente.
4. Comparación de deducción de código y entorno complementario
5. adelantamiento en curva

Es largo, ¡así que siéntate y comienza!
Nota: El contenido de este artículo toma un sitio web rs4 para recién llegados: Bienes raíces en línea como ejemplo;

Uno: La lógica del proceso de rs

Cuando hacemos ingeniería inversa, primero debemos analizar qué 加密参数se debe revertir y luego revertir estos parámetros. Por supuesto, lo mismo es cierto para Ruishu.
Así que nuestro primer paso es 明确逆向的目标:

• Fenómeno: el sitio web en rs solicitará page_url dos veces, y el contenido de página correcto solo se puede obtener cuando se solicita page_url por segunda vez;
• Análisis: analice el cuerpo de la solicitud y descubra que cookie_s y cookie_t están incluidos en la segunda solicitud a page_url, y cookies_s proviene del encabezado de respuesta establecido cuando se solicita page_url por primera vez;
• Conclusión: Entonces nuestro objetivo está determinado: agrietamiento cookie_t的生成逻辑;

Ahora, sabemos que el parámetro de cifrado que debe revertirse es cookie_t, entonces, ¿de dónde proviene cookie_t? Analicemos primero la solicitud del sitio web.

Análisis del proceso de solicitud del sitio web de Ruishu:

第一次请求：Solicite page_url, el código de estado de la respuesta es 202, cookie_s se establece en el encabezado de la respuesta;

el cuerpo de la respuesta es el código fuente HTML, que se puede dividir en cuatro partes de arriba a abajo: Déjame estropearlo primero它们的作用

1. 动态Se utilizará una metaetiqueta cuyo contenido sea largo y constante (cambia con cada solicitud) cuando eval ejecute la segunda capa de código JS;
2. Un archivo js externo , generalmente cuyo contenido está en la misma página 固定, la siguiente función autoejecutable descifrará el contenido del archivo para generar el código fuente JS requerido para la ejecución de eval, que es la segunda capa del código vm;
3. Una gran función de ejecución automática动态 (la página de inicio cambiará cada vez que se solicite ), principalmente para descifrar el contenido JS del enlace externo y agregar algunos atributos a la ventana como $_ts, que se usará en vm;
4. La función llama a las dos etiquetas de secuencia de comandos al final, 更新cookielo hará más largo. Podemos ignorar esto aquí.

第二次请求：Solicitar enlace externo js, ​​el contenido general es fijo;

第三次请求：Solicite page_url, devuelva 200 y lleve cookies_s, cookie_T para solicitar normalmente;

Entonces, ¿qué sucede exactamente cuando visitamos este sitio web en un navegador? ¿Qué es digno de nuestra atención?
Simulemos 浏览器加载page_url源码lo que sucede primero:

1. El navegador carga meta;
2. El navegador solicita 外链jsy ejecuta el contenido js;
3. Ejecute el código fuente de page_url 自执行函数, 外链js解密convertirá las decenas de miles de líneas de cadenas js requeridas por eval, y agregará muchos atributos a window.$_ts, luego llame a la función eval 进入VMpara ejecutar el js descifrado, generar cookies , después de eval es ejecutado, continúa ejecutando la función de autoejecución;
4. Ejecute el código en la etiqueta del script al final, que actualizará cookie_t ( puede ignorarlo )
5. Ejecute setTimeout, función de devolución de llamada eventlistener ( puede ignorarlo )

瑞数执行流程图解como sigue:

Aquí debemos centrarnos en eval调用la ubicación (es decir VM的入口), la ubicación donde se genera la cookie .

Nota: Cuando el navegador v8 llama a eval para ejecutar código, abrirá una máquina virtual (VM+número) para ejecutar código JS.

Podemos ubicar directa hook evalo 搜索.calldirectamente la posición donde se llama eval

_$Ln es 解密后la cadena de código js; ingresar vm es una función autoejecutable, que tiene 生成cookiecierta lógica, y la cookie de ubicación se puede enganchar o buscar directamente en el código vm ( 5)

código de cookie de enlace:

// hook  指定cookie赋值
(function () {
    
    
    'use strict';
    Object.defineProperty(document, 'cookie', {
    
    
        set: function (cookie) {
    
    
            if(cookie.indexOf("FSSBBIl1UgzbN7N80T")!= -1){
    
    
                debugger;
            }
            return cookie;
        }
    });
})();

Bueno, lo anterior es la lógica general del proceso de Ruishu, entonces, ¿cómo pasamos 扣代码Ruishu generando cookie_t?

2. Hablando de deducir el código para pasar el número suizo

Dado que el código fuente de Ruishu page_url se 动态cambia cada vez que se solicita, VM代码también se cambia dinámicamente, por lo que debemos guardar un código estático para facilitar la depuración;
como se muestra en la figura, simplemente corrija la respuesta de page_url,

Al solicitar de esta manera, page_url 外链JSes fijo, 自执行函数fijo VM中的代码y fijo, entonces, ¿el cookie_t generado cada vez por este código fijo también es fijo?
Respuesta: No , porque la generación de cookie_t usa números aleatorios , marcas de tiempo y valores en localStorage (el valor será +1 cada vez que se llame), también enganchamos las dos variables de números aleatorios y marcas de tiempo , y luego cada time Abra un nuevo navegador sin seguimiento para ejecutar, y la cookie_t final generada se corrige.

En este punto, podemos comenzar la deducción de este código estático.Si la deducción es consistente con la generada por el nodo cookie_ty el código estático generado por el navegador, cookie_tsignifica que la deducción es exitosa.

El código de deducción necesita deducir dos partes, la parte del código fuente page_url y la parte cookie_t generada en la VM.
De acuerdo con nuestro análisis anterior, se usará el código en la VM window.$_ts, por lo que primero debemos asegurarnos de que el código deducido del código fuente de page_url se pueda generar normalmente cuando se ejecuta para eval window.$_ts.

Primero deducimos la suma de page_url 自执行函数y 外链JS内容metacontenido, y luego simplemente complementamos el entorno de acuerdo con el informe de error de ejecución, de modo que cuando el código deducido se ejecuta para evaluar, la window.$_tssuma descifrada VM JS代码es consistente con la generada por el código estático local.

Esto significa que hemos deducido la parte del código fuente de page_url y luego podemos deducir la parte que genera cookie_t en la máquina virtual.

Del análisis anterior cookie的定位, podemos saber que la cookie_t secundaria se genera en la función _$bO, entonces somos nosotros 扣代码的起点, ajustamos la función al final del archivo, la ejecutamos directamente y luego compensamos lo que falta BOM、DOM api. al encontrar el código utilizado, podemos Usar 等价逻辑替换, por ejemplo, la lógica original aquí es obtener el contenido del contenido en la etiqueta meta y luego eliminar la etiqueta meta, podemos reemplazarlo directamente con devolver meta_contenido de manera equivalente. Como se muestra en la imagen:

Si al final, el cookie_t generado por el nodo es inconsistente con el generado por el código estático local , significa que el código que deducimos no ha pasado algunas pruebas ambientales.Podemos ubicarlo de acuerdo con la diferencia entre la ejecución del nodo y el navegador , tal como ejecución del nodo a un lugar determinado El valor es diferente del obtenido por el navegador que ejecuta el código estático, lo que indica que hay una diferencia en la lógica anterior. Continúe avanzando y repita este proceso para encontrar todas las detecciones de entorno faltantes y completar la deducción de la parte VM.

En este punto, hemos completado la deducción del código rs estático y lo hemos logrado, pero el código del sitio web rs es 动态sí, window.$_tsy VM jscambiará cada vez que se solicite. ¿Tenemos que deducir cada copia? No, de hecho, ahora estamos a solo un mapeo del éxito real. Aunque
las decenas de miles de líneas de código js de la VM cambiarán cada vez, solo cambia el nombre de la variable y todo lo demás permanece sin cambios.
El mapeo es hacer corresponder los nombres de atributos en el JS con los nombres de atributos fijos 动态window.$_tsusados ​​en el JS en la máquina virtual que deducimos .window.$_ts

Entonces, en el proceso de deducción, debemos prestar atención a qué lugares de la máquina virtual se utilizan 外部变量(es decir, qué variables en una función provienen de otros ámbitos, incluso variables externas), debemos prestar atención a dónde se encuentran estas variables externas. viene de , si la propia VM está definida en la función de ejecución, entonces no se preocupe, si viene de window.$_ts, necesita registrarlo, esto es lo que necesita ser mapeado.

Aquí se usa la lógica de cálculo window.$_ts._$IK, por lo que debemos pasar este valor cuando hacemos el mapeo;window.$_ts={_$IK:对应的动态属性名}

Después de resolver el mapeo, el código se deducirá con éxito a través de rs.
Bueno, eso es todo por el código de deducción, y el próximo paso es el enfoque de nuestro artículo.

3. Explicar el proceso de complementar el medio ambiente en detalle.

Los camaradas que no conocen el principio del entorno complementario pueden consultar mi artículo anterior: JS逆向之浏览器补环境详解De
hecho 纯补环境, el principio de Ruishu es muy simple. Observemos el diagrama del flujo de ejecución de Ruishu . Ejecución de estos JS dinámicos basados ​​en el entorno del navegador. puede generar cookie_t utilizable. Entonces, siempre que el entorno del navegador que complementamos sea lo suficientemente perfecto para hacer que estos JS dinámicos se parezcan a nosotros 补的环境===浏览器环境, entonces el entorno que complementamos ejecuta estos JS dinámicos y también puede generar cookies_t utilizables, y luego extraemos cookies_t a través de document.cookie

Expresado en pseudocódigo es:

// 补的环境头
window = this;
... 省略大量环境头
// 模拟meta标签及其content
document.createElement('meta');
Meta$content = "{qYnKTJPAw84QfF5jm0I2_1IqhgTvRw8Y0yCBPxIVn6od8AeJE6CBz8ZSU6U...省略";
// 固定的外链js
$_ts=window['$_ts'];if(!$_ts)$_ts={
    
    };$_ts.scj=[];$_ts['dfe1675']='þþ+...省略';
// page_url动态自执行函数
(function(){
    
    var _$CK=0,_$WI=[[9,3,6,0,4,1; ...ret = _$su.call(_$fr, _$WR); 很长...省略}}}}}}}})();;


// 获取cookie
function get_cookie(){
    
    
    return document.cookie;
}
// 获取MmEwMD参数
function get_mme(){
    
    {
    
    
    XMLHttpRequest.prototype.open("GET","http://脱敏/",true);
    return XMLHttpRequest.prototype.uri;
}}

Este es el archivo final que completaremos. Dado que las funciones autoejecutables dinámicas Meta$content y page_url cambian dinámicamente, necesitamos usar expresiones regulares para extraer estas dos cadenas cada vez que solicitamos page_url, y luego unirlas en el archivo. y luego python pyexecjs llama a get_cookie para obtener la cookie_t disponible;

También se menciona en la deducción del código anterior que la cookie_t generada se cambia debido a los números aleatorios y las marcas de tiempo involucradas en la operación de generación de cookie_t. Podemos arreglar la marca de tiempo y los números aleatorios para que la misma cookie_t estática generada por JS sea fija.静态JS代码hook

// 固定定随机数和时间戳
Date.prototype.getTime = function(){
    
    return 1672931693};
Math.random = function(){
    
    return 0.5};

补的环境También podemos juzgar si estamos === a través de la cookie_t final generada 浏览器环境.
El principio es muy simple, y el siguiente paso es cómo ponerlo en práctica. Necesitamos hacer un encabezado de entorno perfecto para que la cookie_t obtenida por esta 静态JSejecución sea consistente con la obtenida por el navegador.
Debido a que la complementación del entorno es un trabajo sistemático y existen rutinas generales , podemos utilizar el método mencionado en el artículo anterior 补环境框架para complementar sistemáticamente el entorno, lo que tenemos que hacer es log输出mejorar continuamente este marco de acuerdo con los problemas que se presenten.

Como se muestra en la figura, inicie el marco, el anterior es el encabezado del entorno que agregamos y el siguiente es el código que deducimos.

Continuar con la depuración. Cuando Proxy拦截器interceptamos BOM、DOM apiel uso, el depurador vivirá. Podemos verificar qué línea de código usa el entorno del navegador de acuerdo con la pila de llamadas

Tal entorno complementario alternativo hasta que pueda generarse al final cookie_t, juzgue si es consistente con la generación local del navegador, si no, use la dicotomía para ubicar, vea qué entorno del navegador no se ha complementado, hasta que finalmente obtenga el correcto, publique aquí para el cookie_trenderizado de ejecución final:
Esto es parte de la impresión final 环境检测点:

Esto es lo que termina con la búsqueda cookie_t:

De la misma manera, MmEwMDla misma lógica se aplica al entorno de complemento de parámetros. Cuando el encabezado del entorno sea perfecto, ejecute el archivo de resultado final en python para obtener los siguientes resultados:

4. Ambiente complementario y código de deducción resumen:

Para js逆向mí, estos son dos medios convencionales y prácticos, y cada uno tiene sus propias ventajas y desventajas;

No importa qué método se use, primero deducimos el código JS cifrado del sitio web y luego elegimos si continuamos deduciendo el código y reemplazamos la 浏览器环境apilógica utilizada, o usamos el entorno complementario para hacer que el código JS cifrado parezca estar en el navegador. funcionamiento del entorno.

• Tanto el código de deducción como el entorno complementario dependen de la competencia de JS, el código de deducción se centra más en la sintaxis js y la lógica del código, y el entorno complementario se centra más en la simulación de la cadena de prototipos y los objetos BOM y DOM.
• El dominio de la deducción de código depende de la experiencia inversa, y el entorno complementario casi solo depende del dominio de JS.
• La deducción del código necesita depurar y rastrear mucha lógica. Para rs, si no entiende la confusión, tendrá hemorroides en las nalgas;
• El código de deducción debe reemplazar la lógica de detección del entorno, por lo que también necesita saber dónde se usa el entorno del navegador; el marco del entorno complementario solo se puede usar para monitorear el uso del entorno del navegador y se puede usar como una herramienta auxiliar para código de deducción.
• Dado que Ruishu es dinámico, el código de deducción solo puede deducir uno estático, por lo que es necesario encontrar todos los atributos dinámicos utilizados en la máquina virtual para el mapeo. El entorno complementario es universal, cuanto más complementario, más sitios web se pueden eliminar.
• Deducir códigos es más eficiente que complementar el entorno.Después de todo, la cantidad de códigos para complementar el entorno es mucho mayor que los códigos de deducción.La brecha se puede reducir eliminando entornos innecesarios;
• El tiempo manual del código de deducción es mucho mayor que el del entorno complementario.

En general, 扣代码se enfoca en la sintaxis js y la lógica del código, y su competencia depende de la experiencia inversa. Es diferente para diferentes sitios web, es difícil de usar universalmente y la eficiencia laboral es baja, pero la eficiencia de ejecución del programa es alta. .
补环境Se centra en la cadena de prototipos y la simulación del entorno del navegador. La competencia casi solo depende del dominio de los principios de JS. Cuantos más sitios web diferentes se complementen, más sitios web se pueden eliminar. La eficiencia manual es extremadamente alta, pero la eficiencia de ejecución del programa es no es alta.

5. Enlace de adelantamiento en curva

Pasar a Ruishu es el pequeño objetivo de casi todos los inversionistas novatos, y también es un punto de interrogación común para los entrevistadores. A través de este artículo, hemos aprendido 瑞数的流程及破解思路que podemos intentar implementar un marco de entorno complementario completo desde cero, 纯环境黑盒过瑞数pero llevará mucho tiempo desarrollarlo y hay muchas tareas repetitivas que son aburridas (copiar, pegar, comparar, etc.).

Tome el carril rápido: el marco de entorno complementario
de esta versión de este artículo se mejora sistemáticamente en función del marco del artículo anterior. En la actualidad, se puede decir que es bastante completo y ha complementado muchos entornos. Si lo desea para ahorrar Si pasa mucho tiempo, directamente , puede contactarme en WeChat: dengshengfeng666 Referencia de código fuente pagado; precio fijo 199, después del pago, envíe directamente el código fuente del proyecto marco (puede comenzar directamente con el último Léame gráfico), y si tiene alguna pregunta en el futuro, puede preguntarme directamente. O envíeme un mensaje privado directamente en CSDN.极大提高效率弯道超车

Mejoras entre esta versión y la versión anterior:

1. Optimice los tipos de interceptores Proxy13, alcance el límite de Proxy y conviértalo en proxy recursivo, admita abcde ... detección de profundidad de nivel;
2. Mejore el mecanismo de llamada del archivo de resultado final.js, para que pueda usarse directamente para V8 y llamadas de nodo sin modificaciones;
3. Agregue algunos objetos BOM y DOM, como: XMLHttpRequest, XMLHttpRequestEventTarget, etc.;
4. Complete todos los métodos del entorno del navegador utilizados por rs, para que puedan pasar rs en un cuadro negro;
5. Optimice el método de depuración, puede romper el punto cuando quiera romper y omitir la detección cuando no quiera romper;
6. Agregue el caso de py llamando directamente al archivo de resultados, que puede ser llamado por v8 y nodo usando python;
7. Optimice el archivo Léame e introduzca la configuración y el uso del entorno con imágenes y textos.

Adelantamiento en curva, empieza por mí
El directorio marco de esta versión: