CelerSMS

Solución de Respuesta Automática por SMS Utilizando Software Gratuito

admin@celersms.com (Victor Celer) — Mon, 26 Dec 2022 09:32:00 GMT

Las soluciones de respuesta automática por SMS se usan para asignación de turnos y emisión de comprobantes, votación electrónica, encuestas, suscripción y cancelación de servicios, entre muchos otros casos de uso. El usuario envía un SMS con una palabra clave y recibe una respuesta automática. En este artículo se explica cómo implementar este tipo de solución utilizando solamente software gratuito: el Gateway de código abierto Kannel y la app gratuita SMS Proxy para Android.

Centro de Mensajes (SMSC)

El Centro de Mensajes, más oficialmente conocido como Central de Servicio de Mensajes Cortos (en inglés, Short Message Service Center) o SMSC, es el elemento de la red móvil que se encarga de enrutar, almacenar y despachar los mensajes SMS.¹ Generalmente, también puede gestionar la tasación, el filtrado (por ejemplo, la protección contra spam) y otras tareas relacionadas con la gestión de SMS. De todos modos, el objetivo principal del SMSC es almacenar y entregar los mensajes SMS. Los mensajes son almacenados hasta que el destinatario esté disponible para recibirlos o dichos mensajes expiren, lo que suceda primero. La función del SMSC es muy similar a la de un servidor de correo electrónico. Los e-mail no se intercambian punto a punto, sino que se entregan a través de un servidor de correo, el cual aplica un modelo de almacenamiento y reenvío (en inglés, store-and-forward). El SMSC es como un servidor de correo electrónico para SMS. El operador móvil puede tener múltiples SMSC. Cuando se envía un SMS a otro usuario, el SMS llegará primero al SMSC. Después de eso, el SMSC intentará entregarlo al usuario final.

Hay casos especiales en los que el SMSC no funciona en modo store-and-forward o los SMS se entregan directamente al usuario final sin pasar por el SMSC. Estos casos especiales están por fuera del alcance de este artículo.

Dado que el SMSC forma parte de la red móvil, la comunicación entre el teléfono y el SMSC es inalámbrica. Sin embargo, los proveedores de servicios prefieren tener una conexión de SMSC dedicada, lo cual puede ser más eficiente y especialmente útil para manejar grandes volúmenes de tráfico. El operador móvil puede permitirles acceder al SMSC a través de una interfaz dedicada utilizando el protocolo SMPP. Existen varios protocolos alternativos: CIMD2, UCP, SEMA e incluso algunas API basadas en HTTP, pero SMPP es el estándar de facto desde los años 90. Actualmente hay más de 30 proveedores de SMSC y prácticamente todos ellos soportan SMPP. También existen proveedores de SMS masivos y concentradores de SMS, los cuales suelen exponer una API o interfaz dedicada para enviar y recibir SMS de la misma forma que un SMSC.

Gateway de SMS

Estrictamente hablando, no es obligatorio utilizar un Gateway SMS para enviar y recibir SMS. Generalmente es posible interactuar con el SMSC directamente. El protocolo SMPP es un estándar abierto.² Cualquiera puede desarrollar un cliente SMPP o reutilizar una librería de código abierto, como OpenSmpp, para interactuar con el SMSC sin intermediarios ni proxies. Sin embargo, el uso de un Gateway de SMS puede ser conveniente para evitar el desarrollo de una implementación propia. Típicamente el Gateway de SMS puede soportar diferentes protocolos de SMSC, no solo SMPP. También puede soportar el filtrado de SMS, la compartición de conexiones SMSC, enrutamiento, encolamiento, registro de logs, autenticación de usuarios, etc. El Gateway de código abierto Kannel tiene todas estas características y muchas más.

Por supuesto, puede utilizar cualquier otro Gateway de SMS de su preferencia. Existen diferentes alternativas gratuitas. Por ejemplo, Apache Camel incluye un Gateway SMS integrado. Jasmin es otro Gateway de SMS de código abierto. También existen muchos Gateway de SMS comerciales. No obstante, en términos de estabilidad y rendimiento, Kannel funciona perfectamente para casi cualquier tipo de proyecto de SMS. Algunos operadores móviles utilizan Kannel incluso para servicios críticos para el negocio.

Proxy de SMSC

Un proxy de SMSC es cualquier tipo de servicio intermediario entre el cliente SMS y el SMSC. Por ejemplo, el Gateway de SMS también puede actuar como un proxy de SMSC. Puede haber múltiples proxies, uno detrás de otro. Esto se conoce como una cadena de proxies. Por lo general, un proxy de SMSC se comporta como un proxy transparente. Esto significa que el proxy actúa como un SMSC real y el cliente de SMS puede no estar al tanto de la presencia del proxy.

Es común que los operadores móviles prefieran suministrar el acceso a un proxy de SMSC en lugar del SMSC real. Los proxies pueden proporcionar una capa de protección adicional, balanceo de carga, filtrado, control de acceso, etc.

En este artículo, el proxy de SMSC es una app para Android. Al igual que cualquier tipo de equipo móvil, el smartphone suele tener capacidad de envío y recepción de SMS. Por lo tanto, es posible usar una app para convertir el teléfono en un proxy de SMSC. Generalmente la capacidad de un teléfono para enviar y recibir mensajes es bastante limitada. Usualmente, el dispositivo y el operador móvil limitan el ancho de banda a unos pocos SMS por minuto. Si se supera el límite, el operador puede bloquear la suscripción para que no envíe más SMS de forma temporal o permanente. Por eso, si necesita enviar miles de SMS diariamente, definitivamente necesitará usar una conexión de SMSC dedicada en lugar de un solo teléfono móvil. El proxy de SMSC descrito en este artículo sirve para ahorrar tiempo y costos en la fase de prototipo de servicios nuevos de SMS, realizar pruebas unitarias o crear soluciones de bajo tráfico. Aunque la app es gratuita, tenga en cuenta que el operador móvil puede cobrar por cada SMS. En algunos países, las tarifas de SMS pueden ser bastante altas. Se recomienda consultar las tarifas locales de SMS para evitar costos inesperados.

Configuración de la app «SMS Proxy»

La app se puede descargar desde Amazon. La versión SMS Proxy Lite es gratuita para cualquier propósito, incluido el uso comercial. No tiene limitaciones, anuncios o avisos de prueba.

Si el teléfono tiene Android 6.0 (Marshmallow) o más reciente, al iniciar la app por primera vez, se solicitará otorgar los permisos para enviar y ver SMS. Es necesario otorgar estos permisos para que la app pueda enviar y recibir SMS. Las versiones anteriores de Android no solicitan estos permisos de manera explícita.

La pantalla principal presenta 2 parámetros de configuración:

• Puerto es el número de puerto TCP, en el cual el proxy aguardará la conexión SMPP entrante. Puede ser cualquier valor en el rango de 1024 a 65535. Según IANA,³ el número de puerto registrado para SMPP es 2775. En esta app, el valor por defecto es 5011.

• Limitar el tráfico a una determinada cantidad de SMS por minuto. Este límite puede ser cualquier valor en el rango de 1 a 100. El valor por defecto es 10. De manera predeterminada, Android limita el tráfico saliente a un máximo de 30 SMS cada 30 minutos. Si necesita aumentar este límite, intente buscar en Google por sms_outgoing_check_max_count. Este límite es una característica de seguridad. Si lo aumenta, existe el riesgo de que el tráfico saliente exceda lo permitido por el operador móvil. En ese caso, la línea puede ser bloqueada. Recuerde que el operador puede cobrar por cada SMS. Por lo tanto, no intente aumentar los límites a menos que sea realmente necesario. Ni Android ni la app limitan el tráfico entrante de SMS.

Si se modifica el puerto o el límite de SMS por minuto, los nuevos valores serán tenidos en cuenta la próxima vez que se inicie el SMSC. Pulse el botón Iniciar para desplegar el SMSC.

En Android 6.0 (Marshmallow) o posterior, existe una función de ahorro de batería que restringe las conexiones de red después de unos minutos de inactividad, si el cargador está desconectado. La app desplegará un mensaje de advertencia acerca de esta función cuando el SMSC se inicie por primera vez. Para evitar que el SMSC se desconecte después de unos minutos, puede mantener el cargador conectado o deshabilitar la optimización de batería para la app SMS Proxy. Esto último se puede realizar presionando el botón Ajustes para desplegar el listado de apps y el estado de optimización de batería correspondiente. Inicialmente la lista desplegará solo las apps sin optimización de batería. Puede ajustar el filtro para listar todas las apps. Después de eso, podrá encontrar en el listado la app SMS Proxy y deshabilitar la optimización de batería para dicha app. De esta manera podrá evitar desconexiones inesperadas. La app SMS Proxy está diseñada para ahorrar batería, incluso cuando la optimización de batería de Android está desactivada.

Si WiFi está activa, el proxy utilizará la dirección IP del adaptador WiFi. En la parte inferior de la pantalla podrá ver un mensaje indicando que el SMSC espera conexión en X.X.X.X:YYYY, donde X.X.X.X es la IP (normalmente 192.168.X.X) y YYYY es el número de puerto configurado más arriba.

Si WiFi no está activa, la dirección IP no se mostrará. En este caso, es posible conectar el cliente SMS a través de USB, configurando ADB con redirección de puertos, por ejemplo:

adb forward tcp:5011 tcp:5011

Mientras el túnel ADB esté activo, se podrá conectar con el proxy en 127.0.0.1:5011, a menos que haya cambiado el número de puerto.

Tome nota de la IP y el número de puerto. Estos valores se configurarán en el Gateway Kannel para establecer la conexión SMPP. Mantenga la app SMS Proxy ejecutándose en primer plano para evitar desconexiones.

Configuración del Gateway «Kannel»

Kannel se utiliza principalmente en Linux. Los instaladores están disponibles para muchas distribuciones populares de Linux. Por lo general, instalar Kannel en Linux requiere un solo clic o unos pocos comandos de consola. También es posible hacerlo funcionar en Windows y otros sistemas operativos. Si tiene una buena razón para no usar Linux, aunque no se me ocurre alguna, existen varios tutoriales que explican cómo ejecutar Kannel con Cygwin para Windows. En este artículo no usaremos ninguna herramienta externa, pero en cualquier proyecto de SMS de la vida real es necesario implementar scripts y servicios web para personalizar y automatizar la operación de Kannel. Linux y otros sistemas operativos Unix tienen todas las herramientas necesarias para esto. Esta es una de las razones por las que la mayoría de los proyectos de gran escala que utilizan Kannel se implementan en Linux.

Para los novatos y los usuarios que no disponen de mucho tiempo libre para instalar Linux, existen sitios que permiten descargar imágenes preconfiguradas de Linux para máquinas virtuales como VMware o VirtualBox. Varios sitios web ofrecen imágenes para máquinas virtuales listas para usar de forma gratuita, por ejemplo: OSboxes. Cuando utilice una máquina virtual para ejecutar Linux, asegúrese de configurar los adaptadores de red en modo puente para permitir la conectividad entre Linux y el teléfono Android.

Mi servidor de pruebas es CentOS 7 para x64. Por lo tanto, descargué este instalador de Kannel preparado por Roman Dmitriev: kannel-1.4.4-1cnt7.x86_64.rpm. El RPM descargado se puede instalar directamente, por ejemplo:

wget 'ftp://***/kannel-NNN.rpm'
sudo rpm -ivh kannel-NNN.rpm

Nota: En el ejemplo anterior, simplemente reemplace *** y NNN por la URL y el nombre del instalador apropiados, según la distribución de Linux y la CPU.

Antes de iniciar Kannel, editemos su archivo de configuración principal. La ubicación predeterminada es /etc/kannel.conf:

group = core
admin-interface = 127.0.0.1
admin-port = 13000
admin-password = modificar
smsbox-interface = 127.0.0.1
smsbox-port = 13001
sms-resend-retry = 1
access-log = /var/log/kannel/access.log
log-file = /var/log/kannel/kannel.log
log-level = 1

group = smsbox
bearerbox-host = 127.0.0.1
sendsms-interface = 127.0.0.1
sendsms-port = 13013
global-sender = 123

group = sendsms-user
username = ""
password = ""
default-smsc = celersms

# Esta es la conexion con la app SMS Proxy
# 192.168.X.X es la IP del adaptador WiFi del smartphone
group = smsc
smsc-id = celersms
smsc = smpp
host = 192.168.20.22
port = 5011
transceiver-mode = 1
smsc-username = ""
smsc-password = ""
system-type = ""
log-file = /var/log/kannel/smpp.log

# Captura palabras clave SI y NO (mayusculas o minusculas)
group = sms-service
keyword-regex = ^(?i)(si|no)$
catch-all = 1
text = Mensaje recibido (%t)
max-messages = 1

# Descarta todos los demas SMS
group = sms-service
keyword = default
text = N/A
max-messages = 0

En la sección core configuramos la interfaz de administración. Esto es obligatorio, incluso si no vamos a enviar ningún comando administrativo. Por razones de seguridad, se recomienda evitar desplegar los puertos de Kannel en las interfaces de red públicas, a menos que sea necesario. En este ejemplo, desplegamos todos los puertos en la interfaz local 127.0.0.1 para restringir el acceso remoto. Si necesita permitir el acceso remoto, asegúrese de habilitar SSL y configurar contraseñas seguras para minimizar los riesgos de seguridad.

Nuestro Gateway Kannel abrirá los siguientes tres puertos:

• 127.0.0.1:13000 es la interfaz de administración obligatoria

• 127.0.0.1:13001 es el servicio de SMS box

• 127.0.0.1:13013 es el puerto de sendsms (sirve para enviar SMS)

Si alguno de estos puertos ya está en uso, puede cambiarlo. Tome nota del puerto sendsms, ya que este puerto se utilizará para enviar los mensajes SMS de prueba.

Nótese que tenemos configurados dos servicios de SMS. El primero usa una expresión regular para capturar todos los mensajes con las palabras clave “SI” y “NO” (sin distinción entre mayúsculas y minúsculas) y responde con la fecha y hora cuando se recibió el mensaje. Como tal, este es nuestro servicio de respuesta automática. El segundo servicio captura todos los demás SMS y los descarta. Es necesario configurar un servicio predeterminado para ignorar los SMS no deseados, ya que de lo contrario Kannel responderá con un mensaje de error.

Todos los logs se escriben en /var/log/kannel:

• kannel.log es el log principal que escribe el Gateway Kannel. Este es el primer log a revisar si el Gateway no inicia correctamente.

• access.log registra la actividad de SMS. Si necesita obtener el listado de usuarios que enviaron cierta palabra clave durante un período de tiempo específico, el log de acceso contiene esta información.

• smpp.log contiene las trazas del protocolo SMPP. Si se produce un error de conexión hacia la app de SMS Proxy, este log puede revelar mayor detalle acerca del problema.

Enviar y recibir SMS

Intentemos iniciar el Gateway. Esto se puede hacer por medio del comando service:

sudo service kannel start

Revise el contenido de kannel.log para ver si existe algún error. Si el Gateway se inició correctamente, revise smpp.log para ver si la conexión con la app SMS Proxy se estableció correctamente. Esto también se puede ver en la interfaz de usuario de la app. Si la conexión no es exitosa, verifique que la app se esté ejecutando en primer plano, no esté bloqueada por políticas de ahorro de batería, la IP y el puerto estén configurados correctamente y la conectividad no esté bloqueada por un firewall.

Si todo está bien, intentemos enviar un SMS de prueba (reemplace 1234567 con el número destino apropiado):

wget 'http://127.0.0.1:13013/cgi-bin/sendsms?username=&password=&to=1234567&text=Hola'

Generalmente es posible enviar el SMS a uno mismo, especificando el número de teléfono propio como número de destino. Esto puede ser útil si no se dispone de otra línea para hacer pruebas. En este ejemplo, no estamos especificando un nombre de usuario y contraseña para enviar el SMS porque configuramos un nombre de usuario vacío en kannel.conf. Omitir la autenticación de usuario, como hacemos en este ejemplo, no es recomendable para los servicios productivos.

Intentemos enviar un SMS con formato Unicode con algún emoji. Nótese que agregamos el parámetro coding=2 para activar la codificación Unicode:

wget 'http://127.0.0.1:13013/cgi-bin/sendsms?username=&password=&to=1234567&coding=2&text=%D8%3D%DE%00'

El valor correspondiente en hexadecimal para diferentes emoticonos y emoji se puede encontrar en esta tabla (consulte la columna UTF16). Para mayor información acerca de la codificación de SMS con emoticonos y emoji puede consultar este artículo.

Si el envío de SMS funciona correctamente, lo siguiente que podemos probar es el servicio de respuesta automática. Este servicio producirá una respuesta cuando el SMS entrante tenga la palabra clave “SI” o “NO”. Un caso de uso más realista invocaría una URL de un servicio web para procesar los SMS que coincidan con el filtro que se tiene configurado. Por ejemplo:

group = sms-service
keyword-regex = ^(?i)(si|no)$
catch-all = 1
get-url = "http://127.0.0.1:13013/cgi-bin/sendsms?username=&password=&to=%p&text=Mensaje+recibido+(%t)"
max-messages = 0

La configuración anterior utiliza la API de sendsms para enviar la respuesta. El resultado será el mismo que antes. Sin embargo, en este caso puede configurar su propio servicio web para procesar estos mensajes e implementar escenarios más complejos y personalizados. Tenga en cuenta que en este caso max-messages se deja en cero para evitar que se produzcan dos respuestas.

Kannel soporta muchas funcionalidades avanzadas y diferentes tipos de mensajes. Todos estos casos de uso están cubiertos en la documentación oficial. Además, la app SMS Proxy Pro se puede utilizar para enviar SMS binarios, si el dispositivo Android es compatible con esta función. Los SMS binarios se pueden usar para realizar configuración remota de dispositivos, enviar contenido interactivo, rastrear la ubicación del móvil y mucho más.

Referencias

1. «Technical realization of the Short Message Service (Release 16)» (en inglés), ETSI (2020)

2. «Short Message Peer-to-Peer Protocol Specification Version 5.0» (en inglés), SMS Forum (2003)

3. «Service Name and Transport Protocol Port Number Registry» (en inglés), Internet Assigned Numbers Authority

Sistemas Abiertos, pero Seguros

admin@celersms.com (Vladimir Kameñar) — Fri, 31 Dec 2021 17:21:00 GMT

Android se posicionó como el sistema operativo móvil más utilizado en el mundo, en gran parte debido a su calidad de sistema abierto. Los sistemas operativos más antiguos, como Symbian, Blackberry OS, Windows Mobile, con los cuales entró a competir Android a mediados de los años 2000, eran sistemas de código cerrado. Google logró cautivar a los desarrolladores ofreciendo una plataforma abierta, personalizable, con herramientas de desarrollo gratuitas.

Existe la opinión de que los sistemas abiertos son menos seguros. Si los hacker tienen acceso a los códigos fuente de los componentes del sistema operativo, entonces no tienen la necesidad de hacer ingeniería inversa en busca de vulnerabilidades. Si las aplicaciones tienen control sobre la mayoría de los recursos del dispositivo, entonces es posible que estos recursos se utilicen en perjuicio de los intereses del usuario. Uno de los grandes retos para Google ha sido mantener Android como una plataforma abierta, pero al mismo tiempo contrarrestar sus posibles desventajas en materia de seguridad.

Tim Cook dijo en VivaTech 2021 que ha habido 47 veces más incidencias de malware en Android que en iOS. Panda Security había publicado una métrica similar en 2019, indicando que los casos de malware en Android son cerca de 50 veces más frecuentes que en iOS.

En realidad, estas cifras no son tan desfavorables para Android, como podría parecer a primera vista. Estas métricas abarcan teléfonos rooteados y versiones de Android muy antiguas, en las cuales los niveles de seguridad eran mínimos. Además, si Android es tan popular entre los desarrolladores, también lo es entre los hacker y los autores de malware.

Algunos de los sistemas operativos más seguros corresponden a la familia BSD: OpenBSD, NetBSD, FreeBSD.¹ Estos sistemas operativos son abiertos, pero aun así son más seguros que muchos de los sistemas operativos cerrados.

Una de las ventajas del código fuente abierto, desde el punto de vista de seguridad, es que los expertos en seguridad pueden estudiar este código. Esto no solo ayuda a identificar y corregir posibles vulnerabilidades. También permite detectar patrones de diseño que conducen a la ocurrencia de vulnerabilidades futuras.²

Permisividad vs. inseguridad

Las primeras versiones de Android tenían controles de seguridad mínimos. Las aplicaciones podían acceder a todos los datos del usuario y el teléfono. Desde el punto de vista del desarrollador esto era una gran ventaja en comparación con otros sistemas operativos, pero al mismo tiempo provocó que los fabricantes de teléfonos (Samsung, HTC, Sony, etc.) comenzaran a personalizar sus versiones de Android, eliminando las funcionalidades más peligrosas o restringiendo el acceso a las mismas.

Google también comenzó a eliminar las funcionalidades que representaban mayor riesgo. Por ejemplo, uno de los cambios polémicos fue la eliminación de la API sendRawPdu en Android 2.x, sin explicación oficial de parte de Google y sin alternativa que no implique rooteo del dispositivo. Esta API era usada por las aplicaciones para enviar SMS binarios.

La primera generación de Android permitió evidenciar un conflicto de intereses. Por una parte, Google deseaba que Android se convirtiera en la plataforma móvil más utilizado, desplazando a la competencia. Por otra parte, Google no podía permitir que los desarrolladores tuvieran control total sobre el dispositivo, ya que esto último hacía inviable el uso comercial masivo de Android.

En este punto se vuelve evidente que la vulnerabilidad original de Android se debió a su permisividad (falta de restricciones para acceder a los recursos, datos o funcionalidades sensibles), no al hecho de que el sistema fuese abierto. Esta permisividad comenzó a desaparecer en las versiones subsiguientes. Las versiones más actuales tienen niveles de permisividad comparables con los de otros sistemas operativos, no solamente móviles. Por ejemplo, Android 8 introdujo restricciones para las aplicaciones que se ejecutan en segundo plano. Estas restricciones ayudan a ahorrar el uso de batería, datos y otros recursos, por parte de los procesos que no son visibles para el usuario. Otro ejemplo de reducción de permisividad son las restricciones para el acceso a la SIM a partir de Android 2.x. Actualmente solamente las aplicaciones del sistema y las aplicaciones con privilegios de operador pueden interactuar directamente con la SIM.

Cada nueva versión de Android introduce restricciones adicionales. Esto obliga a los desarrolladores a modificar su código para adaptarse a las restricciones nuevas. En algunos casos no es posible encontrar una alternativa equivalente, como en el ejemplo de sendRawPdu mencionado más arriba. Por lo tanto, cualquier aplicación que hace uso de recursos sensibles puede volverse obsoleta en una futura versión de Android.

Diferentes sabores de Android

Por ejemplo, un teléfono de marca Samsung y otro teléfono de marca Huawei pueden tener la misma versión de Android, pero las plataformas no son idénticas. Como se mencionó más arriba, los fabricantes de teléfonos comenzaron a personalizar sus propias distribuciones, conocidas como Custom ROM, prácticamente a partir de las primeras versiones de Android.

Las versiones genéricas, publicadas y mantenidas por Google, son conocidas como AOSP (en inglés, Android Open Source Project). Estas versiones son usadas en los dispositivos producidos por Google y otros dispositivos genéricos, generalmente de bajo costo.

Las versiones personalizadas pueden incluir cambios cosméticos, ya que las primeras versiones genéricas no contaban con interfaces gráficas particularmente atractivas. Por ejemplo, los dispositivos de gama alta fabricados por HTC incluían unas mejoras de interfaz de usuario conocidas como Sense. Las versiones personalizadas también pueden incluir cambios en el kernel (núcleo) para soportar mejor el hardware del dispositivo. Esto permite mejorar el rendimiento y aprovechar mejor los recursos del dispositivo. El hardware es bastante heterogéneo, por lo que la versión AOSP no siempre logra tener compatibilidad y aprovechar el hardware de la mejor forma posible. Por ejemplo, algunos fabricantes incluyen termovisor, lector RFID, impresora, entre otros ejemplos de dispositivos que no son de uso común en los teléfonos móviles. Para soportar estas funcionalidades añadidas también puede ser necesario personalizar Android.

Las versiones personalizadas pueden ser más seguras o menos seguras. Por ejemplo, algunos operadores preinstalan aplicaciones, las cuales permiten agregar aplicaciones adicionales sin el consentimiento del usuario. Esto compromete la privacidad y seguridad del usuario. Además, estos mecanismos de instalación automática de apps pueden ser explotados para difundir malware, burlando todas las restricciones de seguridad del dispositivo.

En resumen, no todos los Android son iguales. Por lo tanto, resulta sorprendente que diferentes fuentes generalicen el concepto de seguridad en Android sin hacen un estudio comparativo de diferentes versiones y personalizaciones existentes.

Un reto para el desarrollador

El desarrollador Android puede elegir que su aplicación solamente funcione en dispositivos no rooteados con las últimas versiones de Android disponibles. Algunos desarrolladores de servicios bancarios y afines toman esta decisión para reducir los riesgos de vulnerabilidades. Ingresar al banco desde un teléfono muy viejo puede ser como acceder desde un computador público. El riesgo de comprometer la seguridad por cuenta de un programa espía puede ser muy alto.

Por otra parte, soportar una mayor variedad de dispositivos, incluyendo los más antiguos, permite alcanzar una mayor base de usuarios.

En caso de que el usuario llegue a ser víctima de fraude, la responsabilidad no va a ser del fabricante del teléfono, el sistema operativo o el operador móvil. El desarrollador de la app será señalado como responsable. Por lo tanto, es muy importante evaluar los riesgos antes de publicar la aplicación.

Referencias

1. Michael W. Lucas (2013), «Absolute OpenBSD: Unix for the practical paranoid» (en inglés), 2ª ed, No Starch Press. ISBN 978-1-59327-476-4

2. Amiangshu Bosu, Jeffrey C. Carver et al (2014). «When are OSS Developers More Likely to Introduce Vulnerable Code Changes? A Case Study.» (en inglés), IFIP International Conference on Open Source Systems, DOI:10.1007/978-3-642-55128-4_37

Tarjeta SIM como Módulo de Seguridad (HSM)

admin@celersms.com (Victor Celer) — Sat, 25 Dec 2021 20:37:00 GMT

El artículo anterior expuso que las SIMcard (o tarjetas SIM) pueden utilizarse para otorgar privilegios de operador. Estos privilegios permiten obtener los permisos más elevados y sensibles en Android, sin recurrir al rooteo del dispositivo. Por lo tanto, resulta evidente que tanto los operadores móviles como los proveedores de los dispositivos Android confían plenamente en la seguridad de la SIM.

Las SIM son dispositivos creados especialmente para resistir cualquier intento de hackeo. Estos dispositivos incluyen mecanismos de bloqueo automático para proteger la información sensible. Por ejemplo, los equipos de trazado y depuración para SIM pueden costar miles de euros, aunque estos equipos solamente interceptan los datos que viajan entre la SIM y el teléfono, como un «sniffer» de red. Estos equipos no permiten clonar las tarjetas o extraer las claves allí almacenadas.

Módulos HSM

Dado que la SIM ofrece un alto nivel de seguridad, mayor que la protección alcanzable por medio de software, existen diferentes casos de uso de SIM en calidad de HSM (en inglés, Hardware Security Module). Los módulos HSM son procesadores criptográficos, implementados en hardware, cuyo propósito es la protección de claves criptográficas. Aunque existen emuladores de HSM en software, los módulos HSM físicos pueden ofrecer mayor seguridad. Esto se debe a la imposibilidad de leer la memoria de estos procesadores de manera externa, lo cual hace prácticamente imposible la ingeniería inversa. En cambio, los módulos HSM emulados en software no pueden impedir la lectura de la memoria de manera física. El mismo razonamiento es usado por los fabricantes de SIM para argumentar que los chips físicos son más seguros que las SIM virtuales.

No se debe confundir las SIM virtuales con la evolución de eSIM. Estas últimas virtualizan los datos contenidos en la SIM, pero el dispositivo de almacenamiento sigue siendo un chip físico, el cual protege el acceso a la memoria de la misma manera como la SIM tradicional. Este chip no es removible. Por eso, se dice que eSIM es la versión embebida de SIM.

Las llaves de autenticación de la suscripción móvil se almacenan dentro de la SIM. Sin embargo, la SIM puede almacenar llaves adicionales. Por ejemplo, algunos bancos utilizan esta funcionalidad para cifrar las transacciones electrónicas hechas desde el celular. Las llaves bancarias son diferentes de las llaves de autenticación en la red móvil, pero se almacenan y protegen de la misma manera.

Comandos APDU

La comunicación entre el teléfono y la SIM funciona por medio de comandos APDU, cuyo formato está definido en el estándar ISO/IEC 7816-4.¹

Tradicionalmente la comunicación es iniciada por el teléfono y se realiza de manera síncrona. Es decir, se espera que la SIM responda antes de enviar el próximo APDU:

El comando APDU enviado hacia la SIM incluye un encabezado obligatorio con 4 octetos: CLA, INS, P1 y P2.

CLA	Clase: ETSI, 3GPP, Global Platform²
INS	Código de instrucción
P1	Parámetro #1
P2	Parámetro #2

El resto del APDU es opcional y puede incluir datos adicionales. Por ejemplo, estos datos adicionales sirven para seleccionar un archivo o un applet dentro de la SIM, enviar datos específicos para dicho applet, etc. El formato de los datos puede ser definido por el desarrollador, pero la longitud del APDU debe ser acorde al estándar ISO/IEC 7816-4.

Al procesar el APDU se produce una respuesta, cuyo formato establece que los 2 últimos octetos, conocidos como SW (en inglés, Status Word), indican el estado del resultado. Generalmente el valor 9000 en hexadecimal corresponde a un resultado exitoso. Veamos un ejemplo de APDU y su respectiva respuesta:

>> 00 A4 00 00 02 3F 00
<< 90 00

El contenido del APDU puede ser interpretado según el estándar ETSI TS 102.221,³ como sigue:

El octeto CLA indica que la instrucción es de clase 3G. El octeto INS indica que se debe ejecutar la instrucción SELECT (seleccionar). Los parámetros 1 y 2 pueden indicar el modo de selección. En este caso se debe seleccionar el directorio de raíz conocido como MF (en inglés, Master File), cuyo identificador es 3F00. El octeto L_C, el cual precede el identificador MF, indica la longitud de los datos adicionales. En este caso son 2 octetos adicionales, ya que el identificador MF ocupa 2 octetos. El directorio de raíz está presente en todos los sistemas de archivos en la SIM. Por lo tanto, este APDU debería funcionar correctamente en cualquier SIM compatible con 3G.

Applets JavaCard

Supongamos que tenemos un applet criptográfico instalado en la SIM, el cual se usa para encriptar datos sensibles. Los applets se identifican por medio de un ID único conocido como AID. Supongamos que el AID de nuestro applet criptográfico de pruebas es 01020304050607. Normalmente el AID tiene una longitud mayor, pero por simplicidad supondremos que son solamente estos 7 octetos. Entonces, el APDU para seleccionar dicho applet sería:

>> 00 A4 04 00 07 01 02 03 04 05 06 07 00
<< 90 00

Luego de seleccionar el applet podemos enviar otro APDU con los datos que deseamos encriptar.

Para mayor información acerca de los applets JavaCard y ejemplos de código se recomienda consultar el sitio oficial de Oracle JavaCard. Los applets más simples pueden ser compilados con las herramientas gratuitas, disponibles en el mismo sitio, e instalados en una SIM de pruebas. La gran mayoría de las SIMs actuales soportan esta tecnología. Nótese que JavaCard es una tecnología basada en Java. El desarrollo de applets JavaCard tiene cierta similitud con el desarrollo de aplicaciones Java, excepto que el manejo de memoria es diferente debido a la escasez de este recurso en las SIM. El formato del bytecode JavaCard también se diferencia del formato de bytecode de JVM, pero estas diferencias son transparentes para el desarrollador.

Los applets JavaCard pueden hacer uso de la tecnología SIM Application Toolkit, la cual permite ejecutar comandos proactivos en el teléfono, como enviar SMS, desplegar notificaciones y menú interactivos, entre otras funcionalidades.

Envío de APDU por medio de AT+CSIM

La manera más simple de poner en práctica el material expuesto hasta ahora consiste en utilizar un modem GSM para enviar los APDU por medio de un emulador de terminal, como Hyper Terminal o PuTTY. Con el mismo propósito se puede utilizar la librería gratuita CelerCOM para Java.

De esta manera no es necesario utilizar un dispositivo lector de tarjetas y un software especializado para el envío de APDU. La mayoría de los modem GSM soportan el comando AT llamado AT+CSIM, el cual permite encapsular comandos APDU para la SIM. Internamente Android utiliza este mismo comando para ejecutar los APDU que las aplicaciones envían por medio del servicio TelephonyManager.

Por ejemplo, el APDU para seleccionar el directorio raíz MF puede ser enviado de la siguiente manera:

AT+CSIM=14,"00a40000023f00"

El valor 14 es la longitud del APDU en caracteres.

Si el modem responde con un error genérico como +CME ERROR es posible que el modem no soporte el comando AT+CSIM. La mayoría de los modem GSM soportan este comando. Inclusive es posible utilizar un teléfono Android como modem, pero es más práctico usar un modem GSM para puerto USB.

Estos comandos AT+CSIM, enviados por medio de una terminal hacia el modem GSM, sirven para verificar la validez de los comandos. Se recomienda hacer estas pruebas antes de utilizar los mismos APDU en una aplicación Android.

Open Mobile API

Si ya instalamos el applet JavaCard en la SIM de pruebas y ya validamos los comandos APDU, el siguiente paso es hacer una aplicación Android para interactuar con la SIM.

Android soporta el envío de APDU por medio del servicio TelephonyManager a partir de la versión 5.1. A partir de Android 9 esta funcionalidad está disponible por medio de SEService. Esta nueva opción se basa en las especificaciones de Open Mobile API v3⁴ de Trusted Connectivity Alliance, una organización integrada por los fabricantes de SIM, anteriormente conocida como SIMAlliance. Todas estas API requieren permisos elevados. Sin embargo, si estamos usando una SIM de pruebas, podemos instalar el hash de nuestra llave de desarrollo dentro de ARA o ARF para obtener privilegios de operador, como se explicó en el artículo anterior.

Existen implementaciones alternas, basadas en Open Mobile API. Una de las más conocidas se llama SEEK (en inglés, Secure Element Evaluation Kit).⁵ Esta API fue creada por Giesecke & Devrient, uno de los fabricantes de SIMcard.

A continuación veamos un ejemplo que produce el mismo APDU que habíamos probado anteriormente con AT+CSIM, utilizando TelephonyManager:

import android.telephony.TelephonyManager;
import android.telephony.IccOpenLogicalChannelResponse;

   TelephonyManager tm = (TelephonyManager)getSystemService("phone");
   IccOpenLogicalChannelResponse resp =
      tm.iccOpenLogicalChannel(
         "01020304050607", // AID
         0                 // p2
   );
   int ch = resp.getChannel();
   if(ch > 0){
      String sResp =
         tm.iccTransmitApduLogicalChannel(
            ch,
            CLA, INS, P1, P2, P3, DATA
      );
      tm.iccCloseLogicalChannel(ch);
   }

Este código intenta seleccionar el applet JavaCard con AID 01020304050607. Luego le envía el APDU correspondiente a los parámetros CLA, INS, P1, P2, P3 y DATA. El parámetro P3 es opcional. Si no aplica, se puede especificar un valor negativo para que el APDU se envíe solamente con los 4 octetos de CLA, INS, P1 y P2.

A veces, la SIMcard responde con SW 61XX. Es decir, el penúltimo octeto de la respuesta tiene el valor hexadecimal 61. Esto significa que el APDU no puede ser procesado por el momento, pero se puede reintentar. Una implementación robusta debería procesar estas respuestas 61XX y generar al menos un reintento de envío del mismo APDU. Es importante limitar los reintentos para no saturar la SIM y evitar un bloqueo indefinido. Un único reintento puede ser suficiente.

No olvide implementar manejo de errores. El anterior código debería quedar encerrado en un bloque try/catch. Además, es importante recordar que estas API de TelephonyManager requieren el permiso MODIFY_PHONE_STATE. Este permiso puede ser obtenidos en tiempo de instalación solamente hasta Android 2.2. A partir de Android 2.3 este permiso se puede obtener únicamente por las aplicaciones del sistema (preinstaladas) o por medio de privilegios de operador. Esta última opción es la más recomendada, como se había explicado más arriba.

A continuación se presenta otro ejemplo, utilizando Open Mobile API:

import android.se.omapi.SEService;
import android.se.omapi.Session;
import android.se.omapi.Channel;
import android.se.omapi.Reader;
import java.util.concurrent.Executors;

   ExecutorService exe = Executors.newSingleThreadExecutor();
   SEService se = new SEService(
      this, // context
      exe,  // para procesar los callback
      this  // listener
   );
   Reader[] readers = se.getReaders();
   if(readers.length > 0){
      Session sess = readers[0].openSession();
      Channel ch = sess.openLogicalChannel(
         // AID
         new byte[]{ 1, 2, 3, 4, 5, 6, 7 },
         0 // p2
      );
      byte[] respApdu = ch.transmit(
         new byte[]{ /* APDU */ }
      );
      ch.close();
   }

Nótese que en este caso los APDU son codificados como arreglos de bytes, no cadenas de texto hexadecimales. Otra diferencia importante es que la API puede manejar los reintentos de envío de APDU automáticamente, por lo que no es necesario procesar las respuestas con SW 61XX.

En este caso también se recomienda agregar un bloque try/catch para manejo de errores. Uno de los errores posibles es la ausencia de permisos.

Adicionalmente, se puede combinar los ejemplos de TelefonyManager y SEService para implementar una solución compatible con diferentes versiones de Android.

Conclusiones

La SIM, como módulo de seguridad, puede ser útil para almacenar datos sensibles, implementar servicios de encripción y desencripción, entre otros usos. La ventaja principal tiene que ver con la seguridad física de la SIM.

Las aplicaciones Android requieren permisos elevados para poder interactuar con la SIM. Para obtener estos permisos se recomienda hacer uso de los privilegios de operador, los cuales pueden ser otorgados por medio de la misma SIM.

Existen diferentes API para interactuar con la SIM en Android. La disponibilidad de estas API depende del fabricante y la versión del sistema operativo. Es posible combinar las API para soportar múltiples versiones de Android.

Referencias

1. «ISO/IEC 7816-4» (en inglés), ISO/IEC JTC 1/SC 17 (2005)

2. «Global Platform Technology Card Specification v2.3.1» (en inglés), Global Platform (2018)

3. «Smart Cards; UICC-Terminal interface; Physical and logical characteristics (Release 15)» (en inglés), ETSI (2018)

4. «Open Mobile API v3.0» (en inglés), Trusted Connectivity Alliance (2016)

5. Michael Roland, Michael Hölzl (2016). «Open Mobile API: Accessing the UICC on Android Devices» (en inglés), University of Applied Sciences Upper Austria.

Control de Permisos Android

admin@celersms.com (Victor Celer) — Fri, 03 Dec 2021 18:23:00 GMT

El control de permisos en las primeras versiones de Android consistía únicamente en declarar dichos permisos dentro de AndroidManifest.xml. Hoy en día se mantiene la misma modalidad para los permisos menos ofensivos. En cambio, los permisos más sensibles, como el acceso a la ubicación, requieren aprobación expresa de parte del usuario. Algunos permisos, como el envío de SMS, requieren aprobación selectiva por parte del equipo de Google Play para la publicación en línea. Además, los aplicativos firmados por el operador móvil tienen mayores privilegios. Esto se conoce como privilegios de operador y se usa para configurar el dispositivo (por ejemplo, los servicios de VoLTE). Los permisos pueden funcionar de manera temporal o permanente. Además, algunos permisos pueden funcionar de manera diferente si el servicio se encuentra en segundo plano.

Permisos de tiempo de instalación

Los permisos de tiempo de instalación, como su nombre lo indica, se otorgan en el momento de la instalación de la aplicación. Un ejemplo de permiso de tiempo de instalación es el permiso para acceder a internet.

Para hacer uso de un permiso de tiempo de instalación simplemente se debe declarar dicho permiso en AndroidManifest.xml, por ejemplo:

android.permission.INTERNET"/>
android.permission.READ_EXTERNAL_STORAGE"/>

Estos permisos son visibles para el usuario en la tienda en línea. Sin embargo, muchas veces el usuario no presta atención a estos permisos durante la instalación de la app. Por eso, los permisos que se obtienen de esta manera tienen un nivel de impacto bajo desde el punto de vista de seguridad.

Los permisos de tiempo de instalación se adjudican de manera permanente.

Permisos de tiempo de ejecución

En cambio, los permisos más sensibles requieren acciones adicionales a la declaración dentro del XML. Un ejemplo son los permisos de localización:

android.permission.ACCESS_COARSE_LOCATION"/>
android.permission.ACCESS_FINE_LOCATION"/>

El permiso ACCESS_COARSE_LOCATION aplica para las apps que requieren acceso a la localización aproximada del dispositivo. La localización aproximada generalmente se obtiene por medio de los servicios de red. En cambio, el permiso ACCESS_FINE_LOCATION se usa para obtener la localización precisa, la cual generalmente hace referencia a GPS. Google recomienda incluir ambos permisos para que el usuario pueda decidir si se aplica la localización aproximada o precisa, lo cual es posible a partir de Android 12.

Sin embargo, solamente declarar estos permisos no es suficiente. A partir de Android 6 se debe solicitar estos permisos en tiempo de ejecución. De esta manera el usuario tiene mayor conciencia de los permisos sensibles y puede no autorizarlos.

Google recomienda utilizar las clases auxiliares ContextCompat y ActivityCompat para validar y solicitar los permisos en tiempo de ejecución. Por ejemplo:

import androidx.core.content.ContextCompat;
import androidx.core.app.ActivityCompat;

String COARSE = "android.permission.ACCESS_COARSE_LOCATION";
String FINE = "android.permission.ACCESS_FINE_LOCATION";
int LOCRESULT = 123;

Context ctx = getApplicationContext();
if(ContextCompat.checkSelfPermission(ctx, FINE) != 0 &&
   ContextCompat.checkSelfPermission(ctx, COARSE) != 0){
   ActivityCompat.requestPermissions(this,
      new String[]{ FINE }, LOCRESULT);
}

Este código verifica si alguno de estos 2 permisos ya se encuentra aprobado. En caso contrario se despliega un cuadro solicitando que el usuario conceda los permisos. Nótese que la verificación de permisos se realiza sobre el contexto asociado con el proceso, en el cual se está ejecutando la aplicación. Esto es porque internamente Android asocia los permisos con el ID de proceso (PID) y el ID de usuario (UID). En cambio, la solicitud de permisos recibe un parámetro que representa la actividad (Activity) actual, ya que puede desplegar un elemento interactivo para que el usuario apruebe la solicitud. Cuando el usuario apruebe o desapruebe la solicitud de permisos, se invocará el método onRequestPermissionsResult sobre esta misma actividad:

@Override
public void onRequestPermissionsResult(
   int req, String perms[], int[] res){
   if(req == LOCRESULT
      && res.length > 0 && res[0] == 0){
      // permisos concedidos
   }
}

Es opcional procesar la notificación del resultado. La aprobación se realiza de manera asíncrona. Por lo tanto, procesar la notificación permite implementar una lógica condicional según la decisión del usuario. Por ejemplo, si el usuario decide no aprobar los permisos, la aplicación podría desplegar un mensaje de error o implementar una funcionalidad alterna.

Si no desea utilizar librerías auxiliares AndroidX (Android Extension Library), es posible implementar la misma lógica por medio de las API estándar de Android. Esta opción no es recomendada por Google y podría dejar de funcionar en alguna versión futura de Android.

import android.os.Process;
import android.app.Activity;

String COARSE = "android.permission.ACCESS_COARSE_LOCATION";
String FINE = "android.permission.ACCESS_FINE_LOCATION";
int LOCRESULT = 123;

int pid = Process.myPid(), uid = Process.myUid();
if(checkPermission(FINE, pid, uid) != 0 &&
   checkPermission(COARSE, pid, uid) != 0){
      requestPermissions(new String[]{ FINE }, LOCRESULT);
}

En ambos casos es importante agregar la verificación de versión de SDK y un manejo mínimo de errores con un bloque try/catch, como sigue:

if(Build.VERSION.SDK_INT > 22){
   try{
     // verificar permisos de localización
   }catch(Exception exc){
      Log.e("App", "exception", exc);
   }
}

De esta manera, el código de validación de permisos se ejecuta solamente en Android 6 o posterior (SDK mayor que 22), ya que en versiones anteriores estos permisos eran otorgados en tiempo de instalación.

Recuerde que a partir de Android 12 se recomienda separar los permisos de localización aproximada y localización precisa para que el usuario pueda elegir uno de los 2 métodos, ambos o ninguno.

Para habilitar otros permisos de tiempo de ejecución se utiliza la misma metodología. Previo a la solicitud de los permisos, se recomienda desplegar un cuadro informativo explicando por qué se requieren dichos permisos. Esto ayuda a convencer al usuario para que no bloquee los permisos.

Los permisos de tiempo de ejecución pueden ser revocados automáticamente, luego de un período de inactividad. Esto sucede a partir de Android 11. Si la app deja de utilizarse durante un tiempo largo (varios meses), los permisos pueden ser revocados automáticamente. Por lo tanto, la aplicación debe verificar los permisos cada vez que los va a utilizar.

Privilegios de operador

A partir de Android 5.1 se introdujo una funcionalidad conocida como privilegios de operador (en inglés, Carrier Privileges). Esta funcionalidad permite otorgar permisos especiales para las aplicaciones cuya firma digital concuerda con la lista de firmas instaladas en la SIMcard. Se asume que solamente el operador móvil o el fabricante de la SIMcard pueden modificar la lista de firmas en la SIMcard. Un proveedor de aplicaciones independiente no tiene acceso a las llaves administrativas de la SIMcard. Por lo tanto, no puede manipular la lista de firmas.

Lo que se almacena en la SIMcard es un valor hash (SHA1) de la clave, no la clave misma. Opcionalmente, junto con este hash, se puede incluir el nombre del paquete de la aplicación, correspondiente al parámetro package dentro de AndroidManifest.xml. Esto puede ser útil si la misma firma se usa en múltiples aplicaciones, pero los privilegios de operador son requeridos solamente en algunas.

Existen 2 métodos para almacenar la lista de firmas en la SIMcard:

• Por medio de un aplicativo llamado ARA, el cual se ejecuta dentro de la SIMcard. Este aplicativo se encuentra definido en el estándar GPD_SPE_013.¹

• Dentro de un archivo llamado ARF definido en el estándar PKCS #15.²

ARF es soportado a partir de Android 7 y se usa si no se encuentra ARA. Dado que ARA tiene prioridad y es soportado a partir de Android 5.1, este método es más usado que ARF.

Actualmente la gran mayoría de las SIMcard soportan los estándares Global Platform. Esto no garantiza que el aplicativo ARA se encuentre disponible en todas las SIMcard, ya que no todos los operadores hacen uso de esta funcionalidad. Una versión de ARA de código abierto se puede encontrar aquí:

El aplicativo ARA-M de Bertrand Martel es gratuito y compatible con la mayoría de las SIMcard.

Los operadores móviles acostumbran utilizar versiones de ARA suministradas por los fabricantes de SIMcard. Una de las razones es que los aplicativos genéricos pueden ocasionar uso intensivo de la memoria no volátil de la SIMcard, lo cual acorta su vida útil.

El proyecto CoIMS contiene una guía para instalar ARA-M. Además, incluye consejos para depurar errores comunes.

Para instalar un aplicativo en la SIMcard se debe contar con las llaves administrativas. El dilema está en que las SIMcard de pruebas, las cuales se comercializan para propósitos de ingeniería e incluyen llaves administrativas, generalmente no incluyen suscripción móvil. En cambio, las SIMcard que ofrecen los operadores móviles no incluyen llaves administrativas. Por lo tanto, las posibilidades de utilizar esta tecnología con una suscripción móvil real son limitadas. Generalmente se requiere una cooperación estrecha con el operador móvil para lograr aprovisionar las firmas del desarrollador en las SIMcard de los usuarios móviles.

A continuación se presenta la lista con algunas funcionalidades disponibles bajo privilegios de operador:

• Obtener el ID de la suscripción móvil (IMSI).

• Cambiar el nombre del operador.

• Activar/desactivar las redes LTE, CDMA, GSM/WCDMA, etc.

• Modificar la configuración de IMS (ej: VoLTE, VoWiFi).

Una lista más completa puede ser consultada en el sitio oficial de Android para desarrolladores, aunque la lista exhaustiva no es pública. Los privilegios de operador también abarcan los permisos sensibles de tiempo de ejecución, como los permisos para activar o desactivar servicios de datos, bloquear redes, seleccionar la red móvil actual de manera manual o automática, intercambiar comandos APDU con la SIMcard, etc. En el siguiente artículo profundizaremos en este último caso de uso.

Dentro de la app Android no se requiere ningún código adicional para hacer uso de los privilegios de operador. Estos privilegios son otorgados automáticamente si la SIMcard contiene el hash de la llave, con la cual se encuentra firmada la app, y opcionalmente el nombre del paquete de la app. Los privilegios también se revocan automáticamente si la SIMcard es removida.

Los privilegios de operador funcionan aun sin registro en la red móvil. También funcionan en modo avión. Si el teléfono soporta dual-SIM o multi-SIM, Android intenta escanear las firmas de ARA o ARF en todas las SIMcard disponibles.

Conclusiones

El manejo de permisos Android ha evolucionado y se ha vuelto cada vez más restrictivo. Aunque Android es un sistema operativo abierto, no todos los aspectos en el manejo de los permisos son públicos y están documentados.

Si tiene la necesidad de utilizar permisos sensibles y no puede obtener dichos permisos para la versión de Android más actual, es posible que en una versión más antigua la obtención de los mismos permisos sea menos restrictiva. Por ejemplo, la lectura del ID de la suscripción (IMSI) en Android 1.6 se podía hacer simplemente declarando el permiso READ_PHONE_STATE dentro del archivo AndroidManifest.xml.

Si está desarrollando una aplicación de uso masivo, es importante reducir el uso de permisos, especialmente los permisos sensibles. No hacerlo incrementa los riesgos de seguridad, por lo que también afecta la permanencia de la aplicación en las tiendas en línea como Google Play.

Referencias

1. «Secure Element Access Control v1.1» (en inglés), Global Platform (2014)

2. «Cryptographic Token Information Format Standard v1.1» (en inglés), RSA Laboratories (1999)

Seguridad vs. Usabilidad en las Apps Android

admin@celersms.com (Miguel Angel Cano) — Thu, 25 Nov 2021 21:20:05 GMT

Uno de los dilemas en el desarrollo de apps es el balance entre la facilidad de uso y la carga funcional. Esta última representa el conjunto de los casos de uso que ofrece la aplicación. Entre más grande el conjunto, más compleja la interacción con el usuario.

Muchas de las funciones de seguridad, como la autenticación del usuario o la confirmación de una operación sensible, implican acciones adicionales que el usuario debe realizar. Estas acciones pueden ser la lectura de la huella dactilar, el ingreso de una clave, etc. Estas acciones también son parte de la carga funcional y afectan la usabilidad de la aplicación.

¿Qué es una interfaz de usuario intuitiva?

Los ejemplos de aplicaciones más simples incluyen la linterna y la brújula. La interacción con el usuario es simple porque la funcionalidad de la aplicación es mínima. Probablemente nadie ha tenido que leer un manual para aprender a manipular la linterna o jugar Tetris. En cambio, la aplicación de configuración de Android tiene centenares de opciones, muchas de las cuales requieren conocimientos técnicos. Lograr que la experiencia de usuario (UX) sea intuitiva en una aplicación compleja es un reto importante, inclusive para los desarrolladores de Google.

Se dice que la interfaz de usuario es intuitiva si el usuario promedio puede comprenderla fácilmente, sin capacitación previa. No se debe confundir los conceptos de interfaz intuitiva e interfaz fácil de usar, aunque muchas veces sean lo mismo. Por ejemplo, ingresar una clave por medio de unas perillas giratorias que simulan la cerradura de una caja fuerte puede ser intuitivo, pero más complejo que usar el teclado numérico para ingresar un PIN.

Una interfaz de discado con dial rotatorio o disco de marcar, la cual se usó en todos los teléfonos analógicos, es muy simple, pero hoy en día podría no ser intuitiva, ya que muchas personas no han visto o no recuerdan los teléfonos antiguos.

Interfaces web-app

Actualmente es común el uso de interfaces de tipo web-app dentro de las aplicaciones móviles. También se utilizan interfaces híbridas, en las cuales una parte de la interfaz es de tipo web-app y otra parte es nativa. Las interfaces de tipo web-app son generadas por un servidor web remoto y se despliegan dentro de la aplicación de una manera similar a los navegadores web, como Chrome. La popularidad de este tipo de interfaces se debe principalmente a 2 factores, a saber:

• Es posible realizar cambios en la interfaz de manera centralizada, sin publicar una nueva versión de la app y esperar que los usuarios descarguen la actualización.

• Se puede usar la misma base de código para la interfaz web y la app. Esto reduce los costos de desarrollo y mantenimiento.

Desde el punto de vista de seguridad, las interfaces web-app también pueden tener ventajas:

• Si una posible vulnerabilidad puede ser corregida a nivel de web-app, sin modificar el código nativo, el tiempo de mitigación se reduce considerablemente. Por lo tanto, el impacto también se reduce.

• Es más difícil hackear una solución que se ejecuta en un servidor remoto, ya que sólo se tiene acceso a la interfaz de usuario de la misma.

Los servidores web no son invulnerables. Una web-app también puede ser insegura. Sin embargo, en general el código que se ejecuta remotamente en la nube puede estar más protegido que el código nativo que se ejecuta localmente.

La experiencia de usuario con las interfaces web-app suele ser menos óptima, ya que la descarga de la interfaz puede tomar un tiempo, especialmente si la conexión de Internet es lenta. El uso de Internet, además de generar un consumo de datos, produce un incremento en el uso de batería en el teléfono. Se recomienda considerar el uso de interfaces web-app solamente si la aplicación implica conectividad, como las aplicaciones bancarias, redes sociales, etc.

Seguridad vs. comodidad

El mayor reto está en mejorar la seguridad de un servicio sin que estas mejoras generen una mala experiencia de usuario. Por ejemplo, el uso de la biometría, como la huella dactilar o reconocimiento facial, en lugar de memorizar claves, es uno de los avances tecnológicos que han mejorado la experiencia de usuario. El uso de biometría no implica desarrollo de complejos algoritmos de inteligencia artificial. Estos algoritmos ya están disponibles a nivel de hardware o sistema operativo del teléfono.

Otro ejemplo son los sistemas de autenticación basados en patrones de comportamiento del usuario.¹ Estos sistemas estudian la manera como el usuario interactúa con el teléfono, lo cual incluye la manipulación de la pantalla táctil (posición, velocidad, ángulo de deslizamiento), frecuencia y duración de uso, entre otras variables. Ya existen implementaciones comerciales con este tipo de sistemas. De hecho, la idea de perfilar el comportamiento del usuario con fines de autenticación no es nueva. Las implementaciones experimentales han existido al menos desde 2016.²

Estas implementaciones han demostrado tener una efectividad superior al 75%. Al combinar estos perfiles de comportamiento con otros factores, como biometría y claves tradicionales, se logra un mayor nivel de confiabilidad.

Sin embargo, es importante recordar que los usuarios pueden cambiar sus hábitos. Además, la autenticación es solamente uno de los aspectos que abarca la seguridad de un servicio. La suplantación de la identidad del usuario es solamente uno de los métodos que utilizan los estafadores para cometer fraude. Otros métodos consisten en interceptar los canales de comunicación explotando posibles vulnerabilidades, la ingeniería inversa, etc.

El eslabón más débil

Thomas Reid, filósofo escocés, escribió que «una cadena es tan fuerte como su eslabón más débil». Esta frase se aplica perfectamente en materia de seguridad informática, incluyendo los servicios móviles. Por lo tanto, es importante auditar constantemente cada uno de los módulos o procesos que intervienen en el servicio. Reducir al mínimo posible los eslabones de la cadena también ayuda a minimizar los riesgos.

El eslabón más débil puede ser el usuario, quien anota su contraseña y la guarda en un lugar visible para no olvidarla. El uso de protocolos poco seguros por compatibilidad con dispositivos antiguos o versiones previas del aplicativo también se puede convertir en una vulnerabilidad.

Un colega que desarrolla drivers para Windows dice que a veces el cambio más inofensivo puede ocasionar efectos desastrosos. El desarrollo de apps también es susceptible a este tipo de situaciones, aunque en menor medida. Un control estricto de cambios y versiones, combinado con pruebas de control de calidad exhaustivas, reducen la probabilidad de errores, incluyendo los errores de seguridad.

En las grandes empresas de software existe el cargo de especialista en seguridad u oficial de seguridad de la información. Contar con recursos dedicados a los tema de seguridad ayuda a reducir los riesgos. La seguridad es un aspecto menos visible que la usabilidad o la carga funcional, por lo que no siempre recibe la misma atención durante el ciclo de desarrollo. Además, los desarrolladores no siempre son expertos en seguridad. Por lo tanto, si el equipo de desarrollo no cuenta con especialistas en seguridad, se debe buscar capacitar a los desarrolladores. Muchas de las vulnerabilidades que se detectan en las apps se deben a desconocimiento o descuido.

Referencias

1. Adnan Ali, Vasaki Ponnusamy, Anbuselvan Sangodiah (2019), «User Behaviour-Based Mobile Authentication System» (en inglés), DOI:10.1007/978-981-13-6861-5_40

2. Hassan Sbeyti (2016), «Mobile user authentication based on user context and behavioral pattern (MOUBE)» (en inglés), Arab Open University

Mitigación de Ingeniería Inversa en Apps Android

admin@celersms.com (Victor Celer) — Wed, 07 Jul 2021 16:35:00 GMT

No es posible evitar que una aplicación móvil sea descompilada y su funcionamiento interno sea expuesto. El propósito de la ingeniería inversa puede ser el uso ilegal del aplicativo (piratería informática), explotación de sus posibles vulnerabilidades, entre otros efectos perjudiciales para el desarrollador y los usuarios legales. Existen métodos de protección, los cuales encriptan el código del aplicativo, pero dicho código eventualmente es desencriptado por el mismo aplicativo para poder ser ejecutado en la máquina virtual Dalvik de Android. Por eso, el título de este artículo hace referencia a la mitigación, no a la prevención. Los desarrolladores de apps Android, especialmente las apps comerciales, pueden tomar medidas para que la ingeniería inversa resulte ser más compleja y dispendiosa. De esta manera se logra diferir y minimizar el impacto. Por ejemplo, si fuera necesario invertir varias semanas de esfuerzo para romper la protección anti-copia de un videojuego, es probable que una nueva versión del juego sea liberada antes de que se logre piratear la anterior.

No confíe en las soluciones genéricas

Un error común consiste en asumir que una protección comercial de tipo DRM o afín puede ser más afectiva que desarrollar un sistema anti-copia propio. El uso de librerías comerciales para protección de apps puede simplificar la labor de los piratas. Tan pronto se identifique la referencia de la librería comercial, una simple búsqueda en los foros especializados en ingeniería inversa podrá arrojar los pasos exactos para desactivar dicha protección. En cambio, crear un sistema anti-copia propio puede complicar mucho más este proceso. Algunas compañías de software han contratado a hacker éticos para crear sus propios sistemas de protección avanzados. Por ejemplo, en los años 2000 la compañía canadiense SSG había contratado los servicios del hacker ético Kris Kaspersky para implementar un sistema anti-copia de CD.

Inclusive sin recurrir al conocimiento de los hacker más expertos, es posible implementar mecanismos anti-piratería efectivos. A continuación se comparten recomendaciones que han demostrado su efectividad en diversos proyectos de apps.

La estrategia del señuelo

Una buena táctica es hacerle creer al reverser (en inglés, reverser hace referencia a quien practica la ingeniería inversa) que el algoritmo es simple. Por ejemplo:

if(!isRegistered()){
   Toast.makeText(ctx,
      "Error de registro", 0).show();
   // ...
}

Una manipulación mínima de este código sería suficiente para que la copia pirata del aplicativo funcione como si estuviera debidamente registrada. Eso es lo que debería de creer quién haya descompilado este código. Lo ideal es que el aplicativo realmente funcione de manera correcta durante algún tiempo. Por ejemplo, la compañía de videojuegos Aterdux había sacado al mercado un juego con esta misma táctica del señuelo. Los piratas lograron hackearlo rápidamente, pero luego se supo que la versión pirata funcionaba sólo hasta cierto punto de la campaña del juego. Más adelante se realizaba una nueva comprobación de autenticidad. Entonces, lo que realmente lograron los piratas fue convertir el juego en una especie de "demo".

La estrategia del señuelo, si se usa de manera inteligente, puede generar una gran frustración en quienes pretenden usar la app de manera ilegal.

Trasladar la funcionalidad de la app

Esto significa alojar de manera externa parte o toda la funcionalidad del aplicativo. El concepto no es nuevo. Por ejemplo, en los años 90 la compañía Rainbow Tech comenzó a alojar bloques funcionales de aplicativos ejecutables en dispositivos llamados dongle, los cuales se conectaban al puerto de impresora del PC. La misma idea se aplica hoy en día en los dispositivos de seguridad llamados token. En el caso de un teléfono móvil la SIMcard puede hacer las veces de token. Es muy difícil replicar la información que se encuentra almacenada en el interior de un dispositivo de seguridad. Algunos proveedores como Ubirch implementan algoritmos de blockchain utilizando la SIMcard. Esta tecnología se desarrolló para garantizar la autenticidad (ej: el registro de un usuario en la red celular, la propiedad de una cuenta bancaria, la telemetría, etc.) El mismo principio se puede usar para proteger la licencia de una aplicación.

Sin embargo, puede ser más simple y efectivo trasladar una parte o toda la funcionalidad de la app hacia la nube. La app podría ser una simple interfaz de usuario para acceder a un servicio que se ejecuta en un servidor en Internet.

Esta estrategia es utilizada por las compañías de desarrollo de software más grandes. Además, se puede decir que las apps de los bancos funcionan de ese modo, ya que las transacciones son procesadas por los sistemas bancarios en línea.

No en todos los casos puede ser posible que la app tenga acceso a Internet para verificación de autenticidad. Por ejemplo, el acceso a Internet puede ser limitado o demasiado costoso a bordo de un avión, entre otros medios de transporte. Otro detalle importante a tener en cuenta es que una falla en la nube puede dejar sin servicio a todos los usuarios legales del aplicativo.

Minimizar el impacto

Si la app se actualiza frecuentemente y su costo es bajo, esta app no sería particularmente atractiva para los piratas. Sin embargo, inclusive las apps gratuitas pueden ser distribuidas ilegalmente. Los piratas pueden contaminar las apps con diferentes tipos de malware para luego sustraer la información personal de los usuarios, claves, etc.

Se recomienda generar conciencia en los usuarios, explicando los riesgos que conlleva la instalación de apps provenientes de fuentes no oficiales.

Generación de Identificadores Únicos de Dispositivo Android

admin@celersms.com (Victor Celer) — Mon, 31 May 2021 22:41:00 GMT

Generar u obtener un único identificador para cada dispositivo donde se instala una app puede ser útil para diferentes propósitos. Por ejemplo, en un sistema de votación en línea puede ser interesante evitar múltiples votos en un mismo dispositivo. En los sistemas transaccionales los identificadores únicos sirven para propósitos de trazabilidad. Esto también puede servir para efectos de control de licencias (ej: limitar el número de dispositivos donde se puede instalar la app).

La información personal del usuario, como su número de documento de identidad o número de teléfono, no debería de ser usada para estos propósitos debido a restricciones de confidencialidad. Tampoco se recomienda el uso de identificadores de hardware, como la dirección MAC o el número IMEI. Una de las razones para evitar el uso de identificadores de hardware en Android es que su obtención requiere permisos elevados. Además, el número IMEI no siempre es único. Algunos de estos números se repiten a pesar de que las normas de GSMA lo prohíben.

No existe un método que arroje un identificador realmente único en todas las versiones de Android. En este artículo combinamos varios de los métodos existentes para cubrir la mayoría de los casos de uso. Podemos comenzar con el método más usado que es el "android_id":

long uid = 0;
String ss;
try{
   ss = Secure.getString(ctx, "android_id");
   if(ss != null){
      uid = new BigInteger(ss, 16).longValue();
      if(uid == 0x9774D56D682E549CL)
         uid = 0; // filtrar valor no único
   }
}catch(Exception ex){
   Log.e("UID", "error", ex);
}

Nótese que este código continúa la ejecución en caso de cualquier error inesperado, incluyendo errores numéricos. Si se obtiene el valor hexadecimal 9774D56D682E549C, este valor es descartado, ya que se conoce que el mismo valor puede ser reportado en múltiples dispositivos.

Si el anterior código no nos arroja un valor distinto de cero, entonces podemos intentar obtener la dirección MAC de Bluetooth, suponiendo que la app tiene permisos para usar Bluetooth:

// Desde Android 10 la MAC no puede ser consultada de esta manera
if(uid == 0 && Build.VERSION.SDK_INT <= 28){
   ss = null;
   try{
      BluetoothAdapter btAdapter = BluetoothAdapter.getDefaultAdapter();
      try{
         Field ff = btAdapter.getClass().getDeclaredField("mService");
         ff.setAccessible(true);
         Object oo = ff.get(btAdapter);
         ss = (String)oo.getClass().getDeclaredMethod("getAddress").invoke(oo);
      }catch(Throwable th){
         ss = btAdapter.getAddress();
      }
   }catch(Exception ex){
      Log.e("UID", "error", ex);
   }
   if(ss != null){

      // Convertir MAC a long
      int bb, vv = 0, xx = 0, yy = ss.length();
      boolean pp = false;
      while(xx < yy){
         if((bb = (ss.charAt(xx++) | 0x20) - 0x30) > 9)
            bb -= 0x27;
         if(bb >= 0 && bb <= 0xF){
            if(pp = !pp)
               vv = bb << 4;
            else
               uid = uid << 8 | vv | bb;
         }
      }

      // MAC no válida
      if((int)uid == 0 || uid <= 0 || uid > 0xFFFFFFFFFFFFL)
         uid = 0;
   }
}

Si el código anterior tampoco logra obtener un buen valor, entonces una alternativa puede ser tomar la hora exacta con milisegundos, en la cual se instaló un paquete conocido, como "SystemUI". Este valor no es único, pero puede tener una dispersión y persistencia razonablemente buenas:

if(uid == 0){
   try{
      uid = new File(ctx.getPackageManager().getApplicationInfo(
         "com.android.systemui", 0).sourceDir).lastModified();
   }catch(Exception ex){
      Log.e("UID", "error", ex);
   }
}

Una combinación de estos 3 métodos permite cubrir casi la totalidad de los casos de uso. Para evitar colisiones entre los 3 o más métodos se recomienda acompañar el identificador único con algún indicador que sirva para diferenciar el método utilizado.

Recuerde que no todos los teléfonos tienen Bluetooth. No todos los dispositivos Android son teléfonos y tienen suscripción móvil e IMEI. No todos los dispositivos Android tienen las mismas apps por defecto disponibles. La diversidad de dispositivos Android genera retos de desarrollo interesantes. Si omitimos compatibilidad con algún dispositivo o grupo de dispositivos podemos perder un segmento del mercado.

¿Cómo crear un paquete AAB para Android desde línea de comandos?

admin@celersms.com (Vladimir Kameñar) — Thu, 04 Mar 2021 19:35:00 GMT

En un artículo anterior, aprendimos cómo crear un ejecutable APK para Android desde línea de comandos, sin usar ningún IDE. Avancemos más y creemos un paquete AAB (Android App Bundle). Sólo utilizaremos JDK, Android SDK y Bundletool. Los pasos que se describen a continuación se probaron en Windows, pero los mismos comandos se pueden adaptar a cualquier otro entorno.

¿Qué es AAB? (Android App Bundle)

Actualmente, AAB es el formato preferido para publicar aplicaciones en Google Play. Este formato de publicación incluye todos los recursos y el código compilado de la aplicación. La generación y la firma del ejecutable APK se delegan a Google Play. De esta manera, el APK se puede optimizar al incluir sólo el código y los recursos necesarios para un dispositivo específico. Por lo tanto, el tamaño de la descarga se puede reducir significativamente.

Por ejemplo, supongamos que nuestra aplicación es compatible tanto con teléfonos como con Android TV. Para compatibilidad con Android TV, hemos creado una imagen de fondo grande de alta resolución. Si publicamos la aplicación en formato APK, nuestra imagen de fondo se descargará en los teléfonos inteligentes, aunque nunca se usará allí. El formato AAB permite evitar la inclusión de datos innecesarios para acelerar la descarga, ahorrar ancho de banda y espacio de almacenamiento.

En el momento de redactar este artículo, sólo Google Play utiliza el formato AAB. Las demás tiendas de aplicaciones no lo utilizan.

¿Por qué no usar IDE?

Android Studio puede crear un AAB automáticamente con un solo clic. Hacerlo manualmente puede ser útil para entender mejor cómo funciona este proceso. Por ejemplo, si está creando su propia herramienta para generar aplicaciones de Android, esta guía se puede utilizar como referencia. Hay casos especiales en los que puede ser necesario evitar el uso de código generado automáticamente. Entonces, es posible que deba compilar el paquete manualmente.

Las herramientas de trabajo

Sólo necesitaremos el JDK, Android SDK y Bundletool. JDK es necesario para compilar el código Java y generar los binarios. También se puede utilizar para generar el certificado para la firma. El SDK de Android contiene las herramientas necesarias para convertir el bytecode al formato Dex usado por la máquina virtual Dalvik de Android, alinear y firmar el paquete. Bundletool se utiliza para generar el AAB. También se usa para probar el AAB localmente, generando los APK específicos para cada dispositivo de prueba.

Si aun no tiene JDK 1.6 o posterior instalado, lo puede descargar desde el sitio oficial de Oracle. Asegúrese de instalar el Kit de Desarrollo Java (JDK), no solamente el entorno de ejecución JRE. Se recomienda configurar la variable de entorno JAVA_HOME para que apunte a la ubicación de instalación de Java (sin incluir el subdirectorio bin). Esto no es obligatorio, pero ayuda a evitar conflictos en la localización del JDK, especialmente si existen mas de una versión de JDK instaladas.

La instalación del SDK de Android no es una tarea tan sencilla. Google ya no provee el paquete de instalación completo para el SDK. Existen 2 opciones alternas:

• Instalar Android Studio desde el sitio oficial. Desde la página inicial del IDE se puede realizar la instalación del SDK fácilmente.

• Otra opción consiste en descargar e instalar las herramientas de línea de comandos (Command Line Tools), las cuales están disponibles en la sección más inferior de la misma página oficial. Las herramientas de línea de comandos no son el SDK. Luego de instalar estas herramientas de línea de comandos puede ejecutar el sdkmanager para descargar y configurar el SDK de Android.

Las herramientas Build Tools del SDK de Android deben tener al menos la versión 29.0.2. Es posible que las versiones anteriores no incluyan la herramienta AAPT2 o que existan problemas de compatibilidad. También puede descargar la última versión de AAPT2 de Maven como se explica aquí.

La versión mas actual de Bundletool se puede descargar aquí. La herramienta es un único archivo JAR.

Ejemplo de proyecto

Un ejemplo de proyecto completo, incluyendo el código fuente Java y los archivos de procesamiento por lotes de Windows para crear y ejecutar el aplicativo Android, está disponible en nuestro repositorio de GitHub.

Se recomienda crear su propio certificado para firmar el APK. La herramienta keytool de JDK se puede usar para reemplazar nuestro certificado de ejemplo con uno propio:

del src\demo.keystore /q

REM El siguiente comando es una sola linea
"%JAVA_HOME%"\bin\keytool -genkey -keystore src\demo.keystore -keyalg RSA -keysize 2048 -validity 10000 -alias demo

La ruta src\demo.keystore se puede cambiar si desea almacenar el certificado en una ubicación distinta. Si no ha configurado la variable de entorno JAVA_HOME, se debe especificar la ruta completa al ejecutar keytool. El tiempo de validez del certificado y el nombre del alias se pueden modificar. Keytool requiere ingresar unos datos acerca de la organización, ubicación y solicitará asignar una contraseña. La contraseña de nuestro demo.keystore es password (no es una clave realmente fuerte).

build.bat

Antes de ejecutar build.bat se debe configurar los parámetros que se describen a continuación. Un editor de texto plano como el Bloc de Notas (Notepad) se puede usar para editar build.bat:

• BUILD_TOOLS es la ubicación de las herramientas Build Tools dentro del SDK de Android. Utilice el valor de ejemplo como referencia.

• ANDROID_JAR es la ruta de android.jar para la versión de API requerida. Se recomienda utilizar la última versión de API disponible. Esto no afecta la ejecución del APK en versiones de Android anteriores, a menos que la aplicación utilice características específicas de las nuevas versiones.

• BUNDLETOOL es la ubicación del archivo jar de Bundletool. Intente utilizar la última versión, si es posible.

Revisemos las acciones que realiza el archivo de procesamiento por lotes paso a paso:

1. Compilar los recursos. Este comando analiza los recursos (imágenes, xml, etc.) y los empaqueta en un archivo ZIP. Observe que para construir un AAB estamos usando la herramienta AAPT2 en lugar de AAPT.

"%BUILD_TOOLS%\aapt2" compile --dir res\ -o obj\res.zip

2. Enlazar los recursos. Esta es una sola línea:

"%BUILD_TOOLS%\aapt2" link --proto-format -o obj\linked.zip -I "%ANDROID_JAR%" --manifest src\AndroidManifest.xml --java src obj\res.zip --auto-add-overlay

3. Compilar el código fuente Java y generar el código binario (bytecode) correspondiente.

"%JAVA_HOME%\bin\javac" -d obj -classpath src -bootclasspath "%ANDROID_JAR%" src\com\celer\hello\*.java

4. Convertir el bytecode al formato Dex utilizado por la máquina virtual Dalvik de Android.

"%BUILD_TOOLS%\dx" --dex --output=bin\classes.dex obj

5. Combinar los recursos y el bytecode en un solo paquete:

cd obj
"%JAVA_HOME%\bin\jar" xf linked.zip resources.pb AndroidManifest.xml res
mkdir manifest dex 2>nul
move AndroidManifest.xml manifest
copy /Y /B ..\bin\classes*.dex dex\ 2>nul
"%JAVA_HOME%\bin\jar" cMf base.zip manifest dex res resources.pb

6. Generar el AAB.

"%JAVA_HOME%\bin\java" -jar "%BUNDLETOOL%" build-bundle --modules=base.zip --output=..\bin\hello.aab

7. Firmar el AAB.

"%JAVA_HOME%\bin\jarsigner" -keystore ..\src\demo.keystore -storepass password ..\bin\hello.aab demo

Si no hay errores el resultado es un AAB listo para ser publicado en Google Play.

¿Cómo cambiar un módem USB al modo de solo módem?

admin@celersms.com (Vladimir Kameñar) — Sat, 26 Dec 2020 22:55:00 GMT

Actualmente muchos módem USB emulan dispositivos de almacenamiento: unidad de CD flash o tarjeta micro SD. El bus USB permite este tipo de emulación. Esto se convirtió en una práctica normal para muchos modelos de módem USB. El dispositivo puede comportarse como una unidad flash (memoria extraíble) para permitir que el usuario instale los controladores y el software complementario.

No es necesario proporcionar un CD / DVD o descargar los controladores de Internet. Una vez instalados los controladores, el dispositivo se reconoce como módem o puerto COM virtual (VCP). Esto es conveniente para el usuario común de Windows, pero complica las cosas en Linux. El módem aparecerá como unidad flash, no como un módem normal. Por lo tanto, no será posible enviar SMS. El comando media eject (expulsión) puede hacer que el dispositivo USB active el modo de módem.

Cuando el dispositivo recibe el comando de expulsión, puede desactivar la unidad de almacenamiento y habilitar la interfaz de módem. Es posible que este truco no funcione en algunos casos. Las siguientes instrucciones proporcionan una forma genérica de reconfigurar el módem USB para que se comporte en modo "solo módem".

Modo de solo módem

¡Advertencia! Estas instrucciones son para usuarios avanzados, desarrolladores, que necesitan interactuar con el módem directamente para enviar / recibir SMS o establecer una conexión a Internet. No intente reconfigurar su módem si el propósito no es claro y necesario. En algunos casos, los cambios podrían ser irrevertibles.

La opción más genérica y recomendada para Linux es utilizar el script USB_ModeSwitch. Este script puede reconfigurar el dispositivo automáticamente.

Para los módem Huawei y ZTE, existe un procedimiento alternativo que se puede ejecutar en Windows. Para realizar los pasos que se describen a continuación, deberá utilizar un software emulador de terminal como Hyper Terminal, PuTTY o nuestro CelerCOM TTY gratuito.

1. El primer paso es instalar el módem. El procedimiento exacto puede variar dependiendo del proveedor, pero suele ser sencillo. Simplemente conecte el dispositivo al puerto USB, espere el mensaje de ejecución automática y siga las instrucciones en pantalla. Después de instalar el dispositivo, se recomienda realizar pruebas básicas, como conectarse a Internet, solo para asegurarse de que el dispositivo funcione correctamente y la suscripción móvil esté activa.

2. Identifique el puerto COM que está vinculado con el módem. Vaya a Panel de control → Administrador de dispositivos:

Siempre busque primero en la categoría Módems. Si no está allí, intente buscar en Puertos (COM y LPT). A veces, el dispositivo puede aparecer repetido. Ignore las ocurrencias con nombres como debug (depuración) o diagnostics (diagnóstico).

3. En el ejemplo anterior, el puerto es COM26. Conéctese al puerto COM usando Hyper Terminal, PuTTY o CelerCOM TTY e ingrese el comando para habilitar el modo "solo módem". Este comando es específico del proveedor. Por ejemplo, la mayoría de los módems ZTE admiten este comando: AT+ZCDRUN=8.

Comandos específicos del proveedor

La siguiente tabla presenta los comandos específicos para habilitar el modo "solo módem" para algunos proveedores conocidos:

Proveedor	Comando
Huawei	AT^U2DIAG=0
ZTE	AT+ZCDRUN=8
ZTE (chipset Icera)	AT%USBMODEM=0