Recibí el SMS de la muerte que anula la señal móvil (y así lo solucioné)

Un simple mensaje de texto enviado a alguien puede cortarle la señal móvil a su teléfono. La víctima no ve nada, no tiene que tocar nada y no podrá saber jamás quién fue. Y aunque podría considerarse como un SMS con virus o malware, en realidad es un exploit — una falla real en cómo Android procesa cierto tipo de mensaje, algo que decidí probarlo yo mismo.

Durante la prueba mi teléfono de prueba quedó con un bucle de fallos durante días, algo que no era realmente grave. Sin embargo, si me pareció interesante que este SMS corte llamadas activas, sin importar en qué momento de la conversación llegue.

¿Virus, malware o troyano por SMS?

Como dije, este no es un virus por sms, troyano o malware que se instala en el teléfono y se queda ahí espiando o robando datos. No instala nada, no roba información, no se queda residente. Es un solo mensaje malformado que aprovecha un error en el sistema Android — específicamente al procesar mensajes WAP Push, el mismo mecanismo que usan algunas operadoras para enviar configuraciones al teléfono.

Sin embargo, el efecto práctico para quien lo recibe se siente igual de invasivo que un ataque: tu teléfono reacciona a algo que llegó de la nada, sin que hicieras clic en nada.

Cómo funciona

Android se confunde al calcular el tamaño de ese mensaje técnico, y el proceso que controla las llamadas y la señal se cae de golpe, se reinicia solo, y en ese reinicio el teléfono se queda sin servicio por un instante. Esto se encuentra documentado en smsofdeath.com, la fuente original que también desarrolló el APK para enviar este tipo de mensajes “defectuosos”.

Cómo hice la prueba

Cloné el repositorio de GitHub, lo abrí en Android Studio y compilé el APK yo mismo. Usé dos teléfonos:

• Emisor: un Poco X6 Pro con Android 16 (HyperOS 3).
• Receptor: un Samsung Galaxy A16 con Android 16 (One UI 8).

Antes de poder instalar la app en el emisor, es necesario desactivar Play Protect para saltar el aviso “esta app puede ser dañina” — algo esperable al tratarse de una herramienta que explota una falla, aunque no sea malware en sí. Esta app también requiere acceso a los SMS, algo que no pude activar hasta que fui manualmente a los ajustes de la app y desactivé los permisos restringidos. Solo después de eso se me permitió habilitar el permiso de mensajes de texto.

Luego de eso, el proceso de envío en sí es ridículamente simple: pones el número de la víctima, le das a enviar, y listo.

Qué pasó en la primera prueba

Apenas envié el mensaje, al Galaxy A16 le apareció el ícono de “sin señal” casi de inmediato. Volvió sola un par de segundos después. En la app de mensajes del receptor no apareció absolutamente nada — ni rastro del SMS, ni notificación. Repetí la prueba dos veces, mismo resultado ambas.

Hasta ahí, todo coincidía con lo que se podía esperar de este “sms de la muerte”: un corte de señal breve, nada catastrófico.

El teléfono queda “atascado” internamente

Corriendo este comando en el teléfono receptor:

adb logcat | Select-String -Pattern "com.android.phone","FATAL EXCEPTION"

Aparecieron crashes repetidos del proceso com.android.phone — el mismo que controla llamadas y señal — con mensajes como:

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.android.phone, PID: ####
I ActivityManager: Process com.android.phone (pid ####) has died
I ActivityManager: Start proc ####:com.android.phone (restart)

El patrón se repetía: el proceso crasheaba, Android lo reiniciaba automáticamente, y volvía a crashear poco después. En un momento, el sistema hasta llegó a activar su propio mecanismo de defensa interno (RescueParty, el vigilante que Android usa para paquetes del sistema que fallan seguido y que, en casos extremos, puede forzar un reseteo de fábrica).

Es por esa razón que el investigador de este fallo indica que muchos mensajes pueden causar serios problemas. Si se satura un celular con este ataque intensivamente, pueden aparecer avisos como éste en el log:

ActivityManager: Process com.android.phone has crashed too many times, killing!
Reason: crashed quickly

En ese caso, Android deja de reintentar reiniciar con gentileza y directamente fuerza un kill del proceso por considerarlo inestable.

Aunque mi teléfono no se reinició de fábrica, es interesante que haya tenido ese comportamiento cuando solamente había enviado dos SMS “maliciosos”. De todas maneras, reiniciarse el teléfono de esa forma o manualmente no soluciona el problema.

El mensaje queda en cola

Este fallo persiste porque los mensajes enviados nunca se “consumen” — quedan guardados en la tabla cruda de SMS del teléfono, esperando ser procesados, y como su contenido está malformado a propósito, cada vez que Android reiniciaba el proceso de telefonía, intentaba procesarlos de nuevo, volvía a fallar, y así en bucle. Esto se puede saber mediante este comando:

adb shell content query --uri content://sms/raw --projection _id:destination_port:date:deleted

Esto devolvió los mensajes pendientes, identificables por llegar al puerto 134020 (el canal típico de este tipo de mensaje binario) y con deleted=0, es decir, nunca procesados.

Cómo lo arreglé

La solución fue sacar esos mensajes de la cola directamente, sin depender de un reinicio:

adb shell cmd appops set com.android.shell WRITE_SMS allow
adb shell content delete --uri content://sms/raw --where _id=1
adb shell content delete --uri content://sms/raw --where _id=2
adb shell cmd appops set com.android.shell WRITE_SMS default

⚠️ Importante: si tu teléfono queda en esta misma situación y necesitás ir más a fondo (por ejemplo, borrar la base completa del proveedor de telefonía con pm clear com.android.providers.telephony), eso también borra el historial de SMS y la configuración de APN de tu operadora, así que tendrías que reconfigurar los datos móviles después.

Tras limpiar la cola y reiniciar una vez más, corrí el logcat filtrado otra vez: cero crashes, el proceso se mantuvo estable.

Este SMS corta llamadas en curso

La parte más interesante es que al enviar el SMS mientras el teléfono víctima tiene una llamada activa, la llamada se corta casi casi de inmediato. Repetí la prueba varias veces, enviando el SMS en distintos segundos de la llamada — a veces justo al conectar, otras más avanzada la conversación — y el resultado fue el mismo todas las veces: la llamada se corta, sin excepción.

Esto no solo es evidente sino que también deja rastro en el registro de llamadas en el log:

disconnectCause=DisconnectCause [ Code: (ERROR) Reason: (CS_DEATH) ]

CS_DEATH significa literalmente que el servicio de llamadas (“Connection Service”) murió a mitad de la conversación. Obviamente no es un corte de red ni que se colgó manualmente — es el proceso de telefonía cayéndose por el mensaje malformado, con la llamada todavía en curso.

¿Esto sirve para dañar un teléfono?

Depende. En reposo, el efecto es un corte de señal de un par de segundos — nada grave por sí solo, y muy lejos de lo que sugiere llamarlo un SMS de la muerte o SMS bomba. Si el SMS llega durante una llamada en curso, la corta siempre, sin importar el momento.

Pero si el mensaje se envía de forma repetida y frecuente (algo que no probé), el teléfono víctima puede quedar en un bucle de fallos que podría forzar un autoformateo del equipo. Y aún tras ello el problema seguiría, por lo que la única forma es limpiar los mensajes en cola mediante ADB, como ya se explicó.

Este tipo de fallas no son nuevas en Android. Algo similar se encontró con un mensaje que hace fallar WhatsApp en el teléfono de otra persona o el link que apaga un Samsung Galaxy. Cerca de otras personas, la tecnología Bluetooth puede ser usada para generar spam en celulares y PCs.

¿Tu teléfono es vulnerable?

Afortunadamente Google ya parchó esta falla en la actualización de seguridad de Octubre y Noviembre de 2026. Si tu teléfono está actualizado a esa fecha o después, no debería ser vulnerable a este SMS peligroso en particular. Revisá en Ajustes > Acerca del teléfono > Información de software la fecha de tu parche de seguridad, y si no está al día, actualízalo.

Si tu teléfono es atacado

Estos son los pasos que debes seguir para diagnosticar y resolver el bucle:

1. Conectá el teléfono por USB con depuración ADB activada.
2. Corré adb logcat | Select-String -Pattern "com.android.phone","FATAL EXCEPTION" (en PowerShell) para confirmar si hay crashes repetidos.
3. Revisá la cola con adb shell content query --uri content://sms/raw --projection _id:destination_port:date:deleted.
4. Si aparecen mensajes pendientes, activá el permiso con adb shell cmd appops set com.android.shell WRITE_SMS allow y borralos uno por uno con content delete --uri content://sms/raw --where _id=N.
5. Cierra el permiso de nuevo, reinicia el teléfono y confirma con el logcat que ya no aparecen más crashes.

Nota final

El APK que usé para esta prueba se puede compilar desde el repositorio original en GitHub, solo con fines de testeo y pruebas. Si lo vas a probar, hazlo en tus propios dispositivos o con consentimiento explícito de la otra persona, nunca a espaldas de nadie, y estate preparado para tener que limpiar la cola de SMS tu mismo si el teléfono queda atascado.