Fuzzing en teléfonos móviles

Ya habíamos hablado antes de fuzzing, por ejemplo en Fuzzing, ciclos vacíos y fallos.

En [PDF] Fuzzing the Phone in your Phone podemos leer un artículo sobre el tema aplicado a teléfonos móviles (iPhone, Android y Windows Mobile): se generan SMS ‘confusos’ (fuzzed SMS messages) y se consigue lo esperable, que fallen cosas como por ejemplo, desconectar el teléfono de la red.

También hablamos en su día de ataques con SMSs a teléfonos concretos (y no en experimentos controlados, sino en el ‘mundo real’) en Nuevos ataques con SMSs.

Anuncios

Las pruebas y los programas

En Testing is not a substitute for thinking (binary search part 3) una entrada interesante: con las metodologías ligeras tan de moda en estos tiempos, a veces pensamos que basta con las pruebas (‘tests’) para estar seguros de que todo va bien. No diremos que las pruebas no son útiles ni necesarias, pero en algunos casos (casi siempre) hace falta algo más y el autor da estas razones:

  1. Las pruebas sólo pueden mostrar la presencia de fallos, no su ausencia
  2. Las pruebas pueden tener errores, igual que el código que se quiere probar
  3. Las pruebas aumentan la confianza, no la comprensión

Yo añadiría una cuarta (¿relacionada con la segunda y la primera?) y es que es bastante posible que a la hora de preparar las pruebas nos dejemos algo porque es difícil que seamos capaces de prever todos los casos de uso.

Ya lo comentábamos en Una base axiomática para el desarrollo de programas la teoría y la práctica han de ir de la mano (y muy cerquita de la experiencia).

Y, en la medida de lo posible, utilizar más herramientas: Fuzzing y cubrimiento de código.