-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
firmware T16 #2
Comments
No, lo siento. Quizás si entras por puerto serie desde el bootloader puedes hacer downgrade a una versión anterior (que te puedo proporcionar) pero es posible que incluso el bootloader esté bloqueado. |
También lo intenté, en las 2 primeras opciones pide un "boot password" y en la tercera supongo que el root. La F601 tiene todos los puertos cerrados, supongo que en cuanto el técnico le configura el idont. Es curioso que dediquen tanto esfuerzo para que no puedas utilizar tus propios datos voip. |
Pues, no se me ocurre nada más. Quizás sea posible simular el router para que el tr069 provisione y así interceptar los datos sip, pero cuando hice mitm no conseguí que la central completase el aprovisionamiento, así que no tengo muchas pistas sobre como se pueda hacer. |
los datos que conseguiste de la central fueron por casualidad Me da la sensación que primero configuran el router para poder conectarse con él y tras ello es cuando provisionan completamente con los datos sip, por eso no pudiste ver los datos interesantes con el mint. |
Exacto, a partir de ahí no provisionaba si no quitaba el mitmproxy. |
El router en el primer POST les envia su ConnectionRequestURL, su central guarda ese dato y le manda el ConnectionRequestUsername y el ConnectionRequestPassword, justo despues intentan desde la central conectar a esa ConnectionRequestURL con un GET, y si el router les devuelve un HTTP/1.1 200 OK, en ese momento un nuevo POST del router recibe como respuesta los datos SIP. Creo que la clave para ver los datos SIP en el mint es añadir una regla para acceder a la ConnectionRequestURL del router desde fuera. |
Pues, he enviado un bootstrap con una ConnectionRequestURL que controlo y no he visto ningún intento por su parte de conexión. Es posible que filtren e intenten conectar solo en un puerto que ellos esperan. |
Incluso si pongo la url del router no veo ningún intento (en el router tengo redirigidas las peticiones tr069 a mi servidor y si recibe un connection request lo veo). |
Yo lo vi creando un bridge y haciendo un reset de fabrica al router, en las trazas se veian las tramas HTTPS del primer POST del router, luego la conexión HTTP de la central contra el router para validar el cliente, y justo despues las tramas HTTPS del segundo POST del router |
Entonces de alguna manera la central detecta que no es el router y/o tiene alguna medida adicional de seguridad. |
por ejemplo es posible que la central solo haga eso si la sesión PPPoE se ha establecido con las credenciales genéricas digiuser@digi/123456 |
Exacto, no envia los datos sip hasta que "valida" el router del cliente, y para validarlo intenta conectar contra él, configurandole el usuario y pass que es justo lo que veias con el mint. |
Esas credenciales genéricas se usan para acceder al servidor TR, si te fijas al acceder con ellas solo hay acceso a su red local de servidores, no dan acceso externo a internet. |
Ya, por eso digo, probablemente si tienes una sessión PPPoE real la central ni siquiera intenta aprovisionar, solo lo hace si usas las credenciales genéricas (probablemente tenga un rango de ip especifico).
Si pudiese quedarme sin internet lo intentaría (con un cliente PPPoE en mi ordenador, no pienso hacer un reset al router 😉) |
Exacto, funciona tal y como indicas :) Habia pensado tambien en la descarga de firmwares |
De ahí he sacado todos los firmwares desde la T2 hasta la T16 😉 |
Antes de todo, muchas gracias por todo el trabajo . No sé si se ha conseguido alguna cosa con el firmware T16. Yo he probado cosas como Javitol pero sin éxito. ¿Sabéis si hay algún dump del firmware de digi? Con binwalk no he visto la manera de poderlo conseguir. Un saludo y muchas gracias, |
Por mi parte no hay ninguna novedad |
Buenas, estoy probando con la T17 y no consigo nada... He probado a cargar el T11 y T14 ruso que he encontrado para hacer downgrade y me da error como era de esperar. Algún alma caritativa tiene un T12 o anterior de digi a ver si me pasa el checksum? Por otro lado la contraseña por defecto cuántos caracteres tiene? Tiene símbolos? Es solo hexadecimal o alfanumérica? Que lo mismo me da por probar con fuerza bruta a ver qué pasa, y si mi quito caracteres mejor. |
Si no has podido hacer el downgrade con la T11 dudo que puedas con la T12, pero por tener la tengo. |
Al final lo conseguí con la T2 de digi, el problema es que la versión rusa que encontré daba error de checksum, aparentemente a partir de alguna versión solo se puede downgradear a versiones de digi. |
@olivluca |
no, sorry. |
Buenos días @olivluca ,
tu idea de simular el servidor tr es genial, muchas gracias por compartirla.
A mi me han puesto un ZTE H298A que se ha actualizado a la version T16 del firmware en cuanto el técnico lo enchufó.
En router conecta al puerto del servidor simulado, pero no envia el POST, igual ahora validan el certificado.
¿Alguna idea para conseguir el acceso admin con la version T16 del firmware?
Muchas gracias por todo.
The text was updated successfully, but these errors were encountered: