Arduino: u_int8_t tableau de chaîne de caractères

J'ai NFC intégré à l'application sur android qui envoie un hachage comme une apdu de réponse. C'est le code que j'utilise dans mon application Android pour envoyer la table de hachage:

@Override
    public byte[] processCommandApdu(byte[] arg0, Bundle arg1) {

        String hash = "e68d3f574009cbbe011150263634c5c0";

        return hash.getBytes(Charset.forName("UTF-8"));

    }

Maintenant quand je le reçois sur l'Arduino côté des choses-je obtenir ces données BRUTES:

10154561005110253555248485799989810148494949534850255255255255255255255255255

Comment puis-je obtenir le hash dos de qui?

C'est ce que j'ai en ce moment mais ce n'est évidemment pas de travail:

        uint8_t response[32];

        uint8_t responseLength = sizeof(response);

        if (nfc.inDataExchange(message, sizeof(message), response, &responseLength)) {

            Serial.print("RAW: ");
            for (int i = 0; i < sizeof(response); i++) {
                Serial.print(response[i]);
            }

            Serial.println(" ");

            char buffer[32];
            itoa((int)response,buffer,8);

            Serial.print("ITOA: ");
            for (int i = 0; i < sizeof(buffer); i++) {
                Serial.print(buffer[i]);
            }

            Serial.println(" ");
       }

Et c'est la sortie série du code ci-dessus:

RAW: 10154561005110253555248485799989810148494949534850255255255255255255255255255 
ITOA: 4253   µ      + 
  3ü       R

Halp!!!

InformationsquelleAutor ReX357 | 2013-11-26

1

Trois suggestions, mais aucun d'entre eux explique pourquoi les derniers octets obtenir tronquée:
1. Ne pas convertir le code hexadécimal de la représentation d'une chaîne de caractères à envoyer plus tard ces caractères en encodage UTF-8. Il serait beaucoup plus efficace (et moins de décodage d'effort) pour envoyer directement le hachage des octets:
```
@Override
public byte[] processCommandApdu(byte[] arg0, Bundle arg1) {
    byte[] hash = {
            (byte)0xe6, (byte)0x8d, (byte)0x3f, (byte)0x57,
            (byte)0x40, (byte)0x09, (byte)0xcb, (byte)0xbe,
            (byte)0x01, (byte)0x11, (byte)0x50, (byte)0x26,
            (byte)0x36, (byte)0x34, (byte)0xc5, (byte)0xc0
    };

    return hash;
}
```
  Si vous avez déjà le hachage comme une chaîne hexadécimale, je vous suggère de le convertir à sa représentation en octets sur l'Android à côté de la première.
2. Lors de l'utilisation de HCE, vous devez vous en tenir à la norme ISO/CEI 7816-4 unités apdu au lieu de simplement envoyer des données aléatoires. Une commande APDU (format court) se compose des éléments suivants:
```
+----------+----------+----------+----------+----------+------------+----------+
| CLA      | INS      | P1       | P2       | Lc       | DATA       | Le       |
| (1 Byte) | (1 Byte) | (1 Byte) | (1 Byte) | (1 Byte) | (Lc Bytes) | (1 Byte) |
+----------+----------+----------+----------+----------+------------+----------+
```
  Où Lc indique le nombre d'octets de DONNÉES. Si des DONNÉES est vide, la Lc est vide aussi. Le code pour le nombre d'octets attendu comme réponse (avec le cas particulier de Chier = 0x00, ce qui signifie 256 réponse octets attendus.
  
  Une réponse APDU (c'est ce que vous envoyez comme une valeur de retour dans processCommandApdu) ressemble à ceci:
```
+----------+----------+----------+
| DATA     | SW1      | SW2      |
| (n Byte) | (1 Byte) | (1 Byte) |
+----------+----------+----------+
```
  DONNÉES les données de réponse. SW1 & SW2 forme la réponse mot d'état (généralement SW1 = 0x90, SW2 = 0x00 pour les succès). Notez que SW1 et SW2 sont obligatoires.
3. Lors d'une itération à travers la réponse de inDataExchange utiliser la longueur de la réponse fournie par la fonction (responseLength) à la place de votre maximum de longueur de la mémoire tampon:
```
for (int i = 0; i < responseLength; ++i) {
    ...
}
```
  Par ailleurs, je vous suggère de vous fournir un tampon de plus que le maximum prévu longueur de la réponse. (En particulier dans votre cas où vous utilisez le codage UTF-8 pour un 32 chaîne de caractères qui pourraient être (pour certains personnages) résultat de plus de 32 octets.)
InformationsquelleAutor Michael Roland
-1

OK, donc j'ai trouvé ma réponse. Je n'ai pas besoin ltid. Je peux juste transtypage les entrées BRUTES de char et d'obtenir ce dont j'ai besoin:
```
            Serial.print("TYPECASTED RAW: ");
            for (int i = 0; i < sizeof(response); i++) {
                Serial.print((char)response[i]);
            }

            Serial.println(" ");
```
Et que outputed:
```
e68d3f574009cbbe0111502ÿÿÿÿÿÿÿÿÿ
```
Maintenant, je me demande juste pourquoi les 9 derniers caractères sont remplacés par des 255?
- Certaines valeurs entières ont des significations spéciales en tant que caractères. Il ne devrait pas travailler juste traduire directement, à moins que les entiers étaient censés être des caractères. Hexadécimal permet de résoudre ce dans un sens, base64 de la résoudre d'une autre.
InformationsquelleAutor ReX357

Vous devez vous connecter pour publier un commentaire.