Integration broken. Login API was changed.

[guerrerotook]

Securitas Direct changed the login API in the web application and now the integration is broken.

Working on this.

[rlcobos2]

Thanks for your effort.

This is a nice project!!!

Ánimo!!!

[alnavasa]

Thanks a lot @guerrerotook , there's a lot of people that would benefit from your hard work! thanks!

[Lugib]

Buenas noticias!! Ya he conseguido capturar el tráfico TLS de la app de android y ya tengo todo lo necesario. Además esta semana empiezo dos semanas de vacaciones y me voy a poner a tope con eso.

Voy a cambiar bastantes cosas y simular que es un dispositivo Android en vez de la web que es ahora.

Good news everyone, I successfully capture the TLS traffic in the Android app and now I have everything I need to continue. These next two weeks I will on vacations and I will have a lot of free time.

There are going to be a lot of changes in the code because I'm going to simulate that I'm a Android device instead of the web app.

Great news! Buenas noticias compi! Hopefully new version will fix integration problems. If you need any tester let me know I can help :-)

Cheers! Saludos y Gracias!

[andr1u]

Thank you again!

I uninstalled the addon because was not working, reinstalling will not create the alarm entity again. Hope this fix like May's water! 😁

[vipial1]

Buenas noticias!! Ya he conseguido capturar el tráfico TLS de la app de android y ya tengo todo lo necesario. Además esta semana empiezo dos semanas de vacaciones y me voy a poner a tope con eso.

Voy a cambiar bastantes cosas y simular que es un dispositivo Android en vez de la web que es ahora.

Eso es genial! Asi quizás tambien se puede solicitar imágenes de los fotodetectores! Te puedo echar una mano si lo necesitas.

[Lugib]

Any news so far @guerrerotook ?

[guerrerotook]

Hey, progress report. I made all the code changes to incorporate all the necessary headers and secrets that the API required.

I'm making process with the API but because I have to test with my personal account I don't want to upset the API.

[soth78]

If u need a tester @guerrerotook, let me know!

[andr1u]

Hey, progress report. I made all the code changes to incorporate all the necessary headers and secrets that the API required.

I'm making process with the API but because I have to test with my personal account I don't want to upset the API.

Hi @guerrerotook, can we test the OTP branch?

[guerrerotook]

Hi @guerrerotook, can we test the OTP branch?

Not yet, I'm able to get the authentication token but struggled to setup the config flow in HA.

In the future I will ask you guys to test this branch before merging back to master.

[andr1u]

Hi @guerrerotook, can we test the OTP branch?

Not yet, I'm able to get the authentication token but struggled to setup the config flow in HA.

In the future I will ask you guys to test this branch before merging back to master.

OK. Thank you again for your work!

[vipial1]

Hi @guerrerotook, can we test the OTP branch?

Not yet, I'm able to get the authentication token but struggled to setup the config flow in HA.

In the future I will ask you guys to test this branch before merging back to master.

hey @guerrerotook Take a look to this: https://github.com/vipial1/securitas-direct-new-api/commit/531f476452a36b9efb742e78f341f7c524c55656

It is not nice, but working.

[guerrerotook]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token.

But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

[otistarda]

Hola a todos, permítanme resumir mis esfuerzos hasta ahora con la nueva autenticación de dispositivos que Securitas comenzó a implementar recientemente. Como sabrá, ahora es obligatorio verificar el dispositivo al que está llamando la API para tener una sesión abierta. Eso es lo que hace que la integración HA no funcione, o que no funcione si tenemos que iniciar sesión cada 20 minutos con un código SMS.

¿Dónde estamos ahora?

Hay una nueva rama otp_challange que contiene todos mis esfuerzos para hacer que esto funcione. Hay una llamada a la API validate_device que, como dice el nombre, valida que el dispositivo está autorizado. Tengo el flujo de SMS trabajando en HA. Puede seleccionar uno de sus números de teléfono, recibir un SMS y luego volver a llamar a esta API. Pero por alguna razón esto no funciona como se esperaba. Deberíamos obtener esta respuesta en json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

Y luego haga otra solicitud para iniciar sesión y deberíamos obtener algo como eso:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

En el hash y el refreshToken deberíamos obtener un token web seguro.

Pero no, lo que obtenemos es un token hash en device_call que realiza la segunda llamada para iniciar sesión con la propiedad needDeviceAuthorization establecida en verdadero.

¿Cuál es el corazón de la cuestión?

En este momento hay una propiedad idDevice que identifica el dispositivo que se ve así:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

Pero no tengo idea de cómo crear una identificación como esta. No parece una cadena de base 64 codificada y parece un token cifrado. Eso es lo que nos impide validar con éxito el dispositivo.

¿Qué he probado?

Tengo este antiguo dispositivo Android en el que instalé un certificado CA de confianza para poder monitorear todo el tráfico en el dispositivo desde todas las aplicaciones. Con eso pude capturar completamente todo el tráfico de la aplicación securitas. Desinstalo la aplicación y la vuelvo a instalar un par de veces para ver cómo funciona el flujo. Una vez que se valida el dispositivo, incluso si desinstala la aplicación y la vuelve a instalar, no necesita validar nuevamente. Entonces, la operación del dispositivo de validación persiste de alguna manera en el tiempo.

¿Qué estoy preguntando?

Ayuda. No sé si alguien tiene más experiencia con este tipo de API o pone otra perspectiva que me puede funcionar. Ofrezco la posibilidad de compartir los logs sin mi información personal o ayudar a alguien a capturar el tráfico en sus dispositivos.

Gracias por tu esfuerzo, estoy seguro que al final lo conseguiras.

[DNKROZ]

Hello @guerrerotook , first and foremost thanks for all your work, appreciated.

As far as I understand (not my area of expertise) we don't have a way to generate a secure web token from scratch since this is something done by the app and we can only see the results of that but not the method used to generate it, but we can have (or maybe access) the stored device token since this should be stored locally or exchanged with the remote server during the validation process.

Maybe, as a workaround for the time being, we could include this device token during HA integration config flow as a user input value and use the token generated by our phone (or a cheap Android device) to be able to spoof that id info and disguise the custom integration as our own phone or device.

It's not ideal, this would be to be able to run all config flow from the custom integration (including SMS and device token generation) but should enable us to have "something" to work with.

Most probably you've already thought about this... but just my two cents :) If you need something from me (I have several Android phones with several Android versions) or some testing just ask.

Regards.

[vipial1]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token.

But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

hmmmm, interesting. Have you checked the HTTP response headers? Sometimes you find there some interesting values. If you can share with me some logs (maybe wireshark trace?), I would take a look.

[jmatiasGH]

https://empleo.securitasdirect.es/vacancy-detail/r2021100571

Aquí a lo mejor encuentras alguna explicación.

El mar, 2 ago 2022 18:30, Luis Guerrero @.***> escribió:

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code. Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device https://github.com/guerrerotook/securitas-direct-new-api/blob/otp_challange/custom_components/securitas/securitas_direct_new_api/apimanager.py#L173that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{

"data": {

    "xSValidateDevice": {

        "res": "OK",

        "msg": "Petición procesada correctamente",

        "hash": null,

        "refreshToken": null,

        "legals": null

    }

}

}

And then make another request to login and we should get something like that:

{

"data": {

    "xSLoginToken": {

        "__typename": "XSLoginToken",

        "res": "OK",

        "msg": "Usuario validado correctamente",

        "hash": "",

        "refreshToken": "",

        "legals": true,

        "changePassword": false,

        "needDeviceAuthorization": false,

        "mainUser": true

    }

}

}

In the hash and the refreshToken we should get a secure web token. https://hackernoon.com/json-web-token-how-to-secure-your-data-with-jwt-8j5o3wzb#:~:text=A%20JSON%20Web%20Token%20%28JWT%29%20is%20an%20open,digitally%20signed%2C%20it%20can%20be%20verified%20and%20trusted.

But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true. What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device. What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time. What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

— Reply to this email directly, view it on GitHub https://github.com/guerrerotook/securitas-direct-new-api/issues/57#issuecomment-1202961007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AV2JLYDDY5FWU7R74Q5RQUDVXFEKXANCNFSM5Y3Q75DQ . You are receiving this because you commented.Message ID: @.***>

[soysnorre]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token. But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

hmmmm, interesting. Have you checked the HTTP response headers? Sometimes you find there some interesting values. If you can share with me some logs (maybe wireshark trace?), I would take a look.

Muchas gracias por el esfuerzo en esta integración @guerrerotook-. Acabo de intentar llevar a cabo la integración con Securitas y no soy capaz de llevar a cabo la misma.

Ahora tras leer todos estos ISSUES encuentro la razón de ella.

Sólo hacerte saber del gran trabajo que haces y si necesitas de ayuda para algo lo intentamos, pero mi nivel de programación es bajo es este momento en estas areas.

Saludos y gracias,

[bcampru]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token.

But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

Hello, I've tried to reverse engineer the verisure app, what i've discovered is that they are saving the deviceId param inside a sharedPreferences (com.indigitall.prefs), the key name is com.indigitall.prefs.deviceId.

For getting and setting this variable they are using the class yb/c (you can find this reverse engineering the apk), in my opinion the important method of this class is the one named u:

public static void u(Context paramContext, String paramString) {
    if (a.t(paramString)) {
      SharedPreferences.Editor editor = h(paramContext);
      if (editor != null)
        editor.putString("com.indigitall.prefs.deviceId", paramString).apply(); 
    } 
}

I've tried to track where the paramString variable is created and it comes from the class r8/b. From this point it starts to get difficult to track the origin and I've stopped here, the next step might be trying to debug the app and see what's going on.

Hopefully this will be helpful.

[guerrerotook]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token. But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

Hello, I've tried to reverse engineer the verisure app, what i've discovered is that they are saving the deviceId param inside a sharedPreferences (com.indigitall.prefs), the key name is com.indigitall.prefs.deviceId.

For getting and setting this variable they are using the class yb/c (you can find this reverse engineering the apk), in my opinion the important method of this class is the one named u:

public static void u(Context paramContext, String paramString) {
    if (a.t(paramString)) {
      SharedPreferences.Editor editor = h(paramContext);
      if (editor != null)
        editor.putString("com.indigitall.prefs.deviceId", paramString).apply(); 
    } 
}

I've tried to track where the paramString variable is created and it comes from the class r8/b. From this point it starts to get difficult to track the origin and I've stopped here, the next step might be trying to debug the app and see what's going on.

Hopefully this will be helpful.

That is very interesting, do you know how to read those values in Android? I have a rooted device.

[AdriVillaB]

The shared preferences is stored on the data directory, /data/data/<package_name>/shared_prefs. It's a XML file with all the values there, you could grep for com.indigitall.prefs.deviceId and you'll get your value.

[otistarda]

nada nuevo sobre securitas, ¿no?

[shantur]

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

@guerrerotook : I am trying to figure out how Device ID is generated. It would be helpful if you could share the captured traffic?

[shantur]

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

Sometimes apps create some file in external storage and read them later. Maybe this creates a file in the external storage. Try to use any file explorer app to check external storage

[shantur]

@guerrerotook : I have figured out the login flow which leads to proper refresh token and hash. Below are the requests needed. Variables are in <> brackets

Request 1 - mkLoginToken

Headers : None required

Body

{
    "operationName": "mkLoginToken",
    "query": "mutation mkLoginToken($user: String!, $password: String!, $id: String!, $country: String!, $lang: String!, $callby: String!, $idDevice: String!, $idDeviceIndigitall: String!, $deviceType: String!, $deviceVersion: String!, $deviceResolution: String!, $deviceName: String!, $deviceBrand: String!, $deviceOsVersion: String!, $uuid: String!) { xSLoginToken(user: $user, password: $password, country: $country, lang: $lang, callby: $callby, id: $id, idDevice: $idDevice, idDeviceIndigitall: $idDeviceIndigitall, deviceType: $deviceType, deviceVersion: $deviceVersion, deviceResolution: $deviceResolution, deviceName: $deviceName, deviceBrand: $deviceBrand, deviceOsVersion: $deviceOsVersion, uuid: $uuid) { __typename res msg hash refreshToken legals changePassword needDeviceAuthorization mainUser } }",
    "variables": {
        "callby": "OWA_10",
        "country": "GB",
        "deviceBrand": "google",
        "deviceName": "Android SDK built for x86",
        "deviceOsVersion": "10",
        "deviceResolution": "",
        "deviceType": "",
        "deviceVersion": "10.64.0",
        "id": "OWA_______________<username>_______________<timestamp>",
        "idDevice": "<device_id_used_by_firebase_push_notification_not_check_can_be_anything>",
        "idDeviceIndigitall": "<device_id_used_by_InDigital_apis_not_checked_can_be_anything>",
        "lang": "en",
        "password": "<password>",
        "user": "<username>",
        "uuid": "<unique_installation_id_which_identifies_current_device>" 
    }
}

Response

{
  "data": {
    "xSLoginToken": {
      "__typename": "XSLoginToken",
      "res": "OK",
      "msg": "User validated successfully",
      "hash": null,
      "refreshToken": null,
      "legals": true,
      "changePassword": false,
      "needDeviceAuthorization": true,
      "mainUser": false
    }
  }
}

Request 2 - mkValidateDevice

Headers -

auth : {"user":"<username>","id":"OWA_______________<username>_______________<timestamp>","country":"GB","lang":"en","callby":"OWA_10","hash":"","refreshToken":""}

Body

{
    "operationName": "mkValidateDevice",
    "query": "mutation mkValidateDevice($idDevice: String, $idDeviceIndigitall: String, $uuid: String, $deviceName: String, $deviceBrand: String, $deviceOsVersion: String, $deviceVersion: String) {\n  xSValidateDevice(idDevice: $idDevice, idDeviceIndigitall: $idDeviceIndigitall, uuid: $uuid, deviceName: $deviceName, deviceBrand: $deviceBrand, deviceOsVersion: $deviceOsVersion, deviceVersion: $deviceVersion) {\n    res\n    msg\n    hash\n    refreshToken\n    legals\n  }\n}\n",
    "variables": {
        "deviceBrand": "google",
        "deviceName": "Android SDK built for x86",
        "deviceOsVersion": "10",
        "deviceVersion": "10.64.0",
        "idDevice": "<device_id_used_by_firebase_push_notification_not_check_can_be_anything>",
         "uuid": "<unique_installation_id_which_identifies_current_device" 
    }
}

Response

{
  "errors": [
    {
      "message": "Unauthorized",
      "name": "SecurityError",
      "time_thrown": "2022-08-31T20:04:57.326Z",
      "data": {
        "auth-type": "OTP",
        "auth-code": "10001",
        "auth-phones": [
          {
            "id": 0,
            "phone": "********155"
          },
          {
            "id": 1,
            "phone": "********627"
          }
        ],
        "auth-otp-hash": "<otp_hash>"
      },
      "path": [
        "xSValidateDevice"
      ]
    }
  ],
  "data": {
    "xSValidateDevice": null
  }
}

Request 3 - mkLoginToken

Headers -

auth : {"user":"<username>","id":"OWA_______________<username>_______________<timestamp>","country":"GB","lang":"en","callby":"OWA_10","hash":"","refreshToken":""}

Body

{
    "operationName": "mkSendOTP",
    "query": "mutation mkSendOTP($recordId: Int!, $otpHash: String!) {\n  xSSendOtp(recordId: $recordId, otpHash: $otpHash) {\n    res\n    msg\n  }\n}\n",
    "variables": {
        "otpHash": "<otp_hash>",
        "recordId": <selected_phone_id>
    }
}

Response

{
  "data": {
    "xSSendOtp": {
      "res": "OK",
      "msg": "Request processed correctly"
    }
  }
}

Request 4 - mkValidateDevice

Headers -

auth : {"user":"<username>","id":"OWA_______________<username>_______________<timestamp>","country":"GB","lang":"en","callby":"OWA_10","hash":"","refreshToken":""}
security : {"token":"<sms_verification_code>","type":"OTP","otpHash":"<otp_hash>"}

Body

<Same as Request 2>

Response

{
  "data": {
    "xSValidateDevice": {
      "res": "OK",
      "msg": "Request processed correctly",
      "hash": null,
      "refreshToken": null,
      "legals": null
    }
  }
}

Request 5 - mkLoginToken

Headers : None required

Body

<Same as Request 1>

Response

{
  "data": {
    "xSLoginToken": {
      "__typename": "XSLoginToken",
      "res": "OK",
      "msg": "User validated successfully",
      "hash":  <login_token_hash>,
      "refreshToken": <refresh_token>,
      "legals": true,
      "changePassword": false,
      "needDeviceAuthorization": false,
      "mainUser": false
    }
  }
}

After this the current device is won't need verification again. Notes : Device Brand and Device Name can be anything, but not tested.

Hope this helps and the integration can be improved. Let me know if you need more help.

[guerrerotook]

Hey, @shantur thank very much for the comment. You are right this is the right flow and this flow is already implemented in the otp_challenge branch where I have been working.

The problem came when you calling a second time the mkValidateDevice and I don't get a valid token and refresh token. So the device is not validated but the login succeed. Meaning that for about 30 minutes you can call the api but then you need to do the SMS code again. Something that is not acceptable.

I explain that a little bit up in the post, here is the link. https://github.com/guerrerotook/securitas-direct-new-api/issues/57#issuecomment-1202961007

The problem is that this idDevice I don't know how to generate in a way that let me validate the device.

Happy to show you my setup, I clone this repository, https://github.com/guerrerotook/home-assistant open the VSCode Container in there and in the component/securitas-direct is a submodule to this repo, so you can work and experiment there.

[shantur]

@guerrerotook : I think the flow is a bit different. As I explained the idDevice is not being used for our purposes, I examined the Android app and the requests it makes. I tested with idDevice just being set to "bla" and it works. idDevice is just used for Firebase push notifications and it comes from Firebase Cloud Messaging, idDevice and idDeviceIndigitall can be totally ignored and just set to anything. uuid is the one that identifies our device and should be kept same in all the requests.

I couldn't get the custom component working with latest home-assistant dev environment and need to look into it but one difference that I spotted in your version is that you have "OWP_10" in callby and id fields where as I have "OWA_10". This could be the factor as OWP could mean OW Portal and OWA could be OW App.

I won't get time to try your version of home-assistant till later this evening, if you have this working would you mind testing the OWA change?

Thanks

[guerrerotook]

Interesting. I will test this flow as you described. The idDeviceIndigtall is for the marketing team https://indigitall.com/ but I thought the idDevice it was important.

This is how I create the UUID, https://github.com/guerrerotook/securitas-direct-new-api/blob/ef4b0fb42bc45f6918b42f6fef3ce5c389c0571b/custom_components/securitas/__init__.py#L91 just for your information.

Thanks for the help!

[shantur]

@guerrerotook : OWP to OWA Fixed the issue. I have submitted a PR (https://github.com/guerrerotook/securitas-direct-new-api/pull/65) which fixes config_flow as well. I didn't want to change much to make sure it goes well with your plans.

Let me know if this helps.

[andr1u]

Come on guys! It seems you’re close to fix it…

[guerrerotook]

Testing it right now!

[guerrerotook]

@guerrerotook : OWP to OWA Fixed the issue. I have submitted a PR (#65) which fixes config_flow as well. I didn't want to change much to make sure it goes well with your plans.

Let me know if this helps.

It works! That was beautiful. I just tested on my local development environment that was executed two weeks ago and it automatically gets a new token and everything works out of the box.

Thanks very much for the contribution @shantur. It fixed everything.

I'm going to clean the code, merge back to master, prepare the release and update the documentation.

[otistarda]

@guerrerotook: OWP a OWA Solucionado el problema. He enviado un PR ( #65 ) que también corrige config_flow. No quería cambiar mucho para asegurarme de que va bien con tus planes. Déjeme saber si esto ayuda.

¡Funciona! Eso fue hermoso. Acabo de probar en mi entorno de desarrollo local que se ejecutó hace dos semanas y automáticamente obtiene un nuevo token y todo funciona de forma inmediata.

Muchas gracias por el aporte. Arregló todo.

Voy a limpiar el código, fusionarlo de nuevo con el maestro, preparar el lanzamiento y actualizar la documentación.

Felicidades a todos.

spectacular you are some cracks

[josecarre]

Yessss!!! amazing work @shantur and @guerrerotook ! looking forward for testing the new release 😃

[otistarda]

no words, amazing

[siom7]

Many many many thanks for your patience and your hard work !!!

[soth78]

Incredible work... Congratulation to the team

El sáb, 3 sept 2022 12:56, siom7 @.***> escribió:

Many many many thanks for your patience and your hard work !!!

— Reply to this email directly, view it on GitHub https://github.com/guerrerotook/securitas-direct-new-api/issues/57#issuecomment-1236095566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGFF2DASBQL5BVEK4SAPDRDV4MVHXANCNFSM5Y3Q75DQ . You are receiving this because you commented.Message ID: @.***>

[DNKROZ]

Great job, congratulations to everyone involved, can't wait to use the integration again. Regards.

[otistarda]

Hey guys, does anyone else have this? From HA the alarm is armed perfectly but I cannot disarm it I have to do it from the app

[chabou-san]

Great job, congratulations to everyone involved, can't wait to use the integration again. Regards.

This. Big kudos to everyone involved. 👍🎉

[TheGui01]

Hi !

Same issue here. I tested the code before the final merge and I had to put my disarm code under quote : code: '1234' Since the code has been adapted and and I had to revert to code: 1234, it doesn't work anymore. I think there is an issue with the variable type somewhere...

Le sam. 3 sept. 2022 à 13:54, otistarda @.***> a écrit :

Hey guys, does anyone else have this? From HA the alarm is armed perfectly but I cannot disarm it I have to do it from the app

— Reply to this email directly, view it on GitHub https://github.com/guerrerotook/securitas-direct-new-api/issues/57#issuecomment-1236104777, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXUJD2B6Y735ARXGPCQWDGTV4M4BHANCNFSM5Y3Q75DQ . You are receiving this because you are subscribed to this thread.Message ID: @.*** com>

[pganansia]

Great great job!

[Javvaz]

First of all, thanks for you work and dedication, I appreciate it. At the same time, I would like to comment I got to implement the new integration with 2FA, but I don't get to disarm the alarm either scripts or control panel, I only can arm, but not disarm, I have no idea.

I have checked everything without success. Do you have any tip or idea?

[rlcobos2]

Congratulations @guerrerotook , this is a very good work!!!!

I have the same issue, but want to explain.

When you disarm the alarm, really this is disarmed ( you can check in the mobile app ), but not refresh the status on HA until some minutes.

Thanks for all your effort!!!

[otistarda]

Felicidades@guerrerotook, este es un muy buen trabajo !!!!

Tengo el mismo problema, pero quiero explicar.

Cuando desarma la alarma, realmente se desarma (puede verificar en la aplicación móvil), pero no actualiza el estado en HA hasta algunos minutos.

¡¡¡Gracias por todo tu esfuerzo!!!

In my case no, if I disarm from HA when entering the application it is still connected :-(

[soysnorre]

Muchas gracias @guerrerotook.. Increible trabajo

En mi caso, siendo primera vez que integro, el panel es ok y arma , pero como puedo ver en otros no desarma la misma. Reviso en la aplicación y frente al cuadro de alarma y no desactiva.

Saludos y gracias.

[soth78]

Same here, can arm bur disarm doesn't even try

So excited to see the advances!!!

El dom, 4 sept 2022 9:11, Snorre @.***> escribió:

Muchas gracias @guerrerotook https://github.com/guerrerotook.. Increible trabajo

En mi caso, siendo primera vez que integro, el panel es ok y arma , pero como puedo ver en otros no desarma la misma. Reviso en la aplicación y frente al cuadro de alarma y no desactiva.

Saludos y gracias.

— Reply to this email directly, view it on GitHub https://github.com/guerrerotook/securitas-direct-new-api/issues/57#issuecomment-1236275741, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGFF2DFMX45AJ5NCCYQARPDV4RDRBANCNFSM5Y3Q75DQ . You are receiving this because you commented.Message ID: @.***>

[IgorPereira-PT]

I have the same issue.

I can arm but i can't disarm.

I tried to call the service to disarm, with and without a code but always without success.

[otistarda]

A ver si a nuestro crack se le ocurre algo :-(

[vipial1]

Is it working with the latest HomeAssistant version? I got exception after sending the received sms code.