Entonces el problema que tenes es que estan almacenadas como string, pero son hex Y luego te gustaria compararlos como hacias antes.
EDIT:
Edito un poco por que estoy en dudas.
- Como podes tener 00 si la entrada va a ser de un teclado ? Es imposible que asi sea.
- Deberias decir que caracteres son validos para el password, es decir Numeros y letras, letras mayusculas y minusculas, ¿signos?. Mientras mas agregues mas dificil puede llegar a ser la reconstruccion o no. Depende del metodo empleado
- 2X no es un numero hexa en tu ejemplo, que letra/numero/simbolo es B8 ?, O son coordenadas de donde se toca el touch ? (imagino que es un touchpad por el nombre).
- Si son coordenadas puede ser un problema, deberias limitar el rango de valores, ya que no podrias distinguir sino el separador de cada pass.
Soluciones que se me ocurren:
1 - Una solucion es que termines comparandolo con algo de 14 y no 7 valores. Esto implica que la contraseña ingresada deba ser desmembrada para que entre en los 14 lugares. Es decir se hace en ese momento nomas ( por el caso de tiempo de CPU ocupado), y ocuparia 14 lugares como maximo en RAM siempre.
2 - Otra solucion es que de esos 7 valores se genere por cada uno el valor correspondiente y luego se compare. Esta solucion puede tener 2 formas.
La primera es crear un array de 14 lugares que sera destruido al salir de esa funcion, transformar la llave a esos 14 lugares, simplificando la entrada del pass y guardado. Tiene un costo computacional inicial igual que el anterior, pero esta ves el maximo RAM consumido aumenta a 21 lugares de RAM, por un momento, ya que luego se destruye y volvemos a tener 7 lugares, es decir deberias tener 14 lugares disponibles en el stack.
La otra es calcularlo a medida que se necesita, esto posee un costo computacional altisimo, pero solo ocuparias como maximo 9 espacios de RAM ( key + 2 lugares en el stack ). y esos 2 desaparecerian al finalizar la funcion.
3 - Otra solucion es que sean los datos del archivo quien se tomen de a par y se comparen con la llave. Esta solucion tiene tambien un gran costo computacional, ya que deberias hacerlo por cada uno de esos 512 valores. Ademas aumenta la complejidad por que antes de obtener esos valores se deberia verificar que se encuentran dentro el set de letras/numeros/etc que pueden ir en el password.
La 1ra y 2da solucion tiene una rapida implementacion, la otra va a ser necesario crear un memcpy propio que efectue el mismo trabajo pero que tenga en cuenta lo demas.
Y si tuviera que elegir por el costo computacional me quedo entre la 1ra y la 2da, todo va a depender si es que necesitas ademas la llave en otro lado, es decir si necesitas muchas veces tener la llave en texto comun "4567g6h", entonces mejor mantenerla asi. Ahora si no te importa como esta almacenada la llave iria por la 1ra y la mantendria como "34353637673668".
-----------------------------
600 llaves * ( 14 caracteres pass + 2 salto de linea/retorno de carro (peor caso) ) = 9600 bytes
Y estas leyendo cada 512, eso significa que debe repetirse esto 17 a 19 veces. Por cada password.
Vas a tener que pensar como vas a hacer lo siguiente tambien:
Si tenemos 2 caracteres extras por pass, es decir \r\n, da justo que 512/16 = 32 es un entero. Lo cual vas a poder leer uno tras otro en 512 bytes y no modificar los indices de lectura.
Si por casualidad tenemos 1 solo caracter extra es decir \n solo, 512 / 15 = 34.133, o mejor dicho 34 password, y 2 bytes del proximo password que va a venir en los otros 512 bytes del buffer. Los cuales vas a tener que arreglartelas para que funcione correctamente, ya sea guardando ese valor creando una funcion especial de lectura y comenzando desde otro indice luego o modificando el indice de lectura del archivo (o byte offset como lo llama FatFS, que imagino que la libreira que hizo Suky lo posee).