pt., 28 maj 2021 o 19:23 BERTRAND Joël <joel.bertr...@systella.fr>
napisał(a):
> Hello,
>
> I beg your pardon as my question is not related to gcc itself.
>
> I have added to my firmware a subset of avr-crypto-lib (AES and
> RSA).
> If AES128/192/256 run as expected, RSA causes a memory corruption.
>
If you know where you bug is, try to reduce your code to the bare minimum,
example:
#include "rsa_basic.h"
extern rsa_publickey_t *public;
#define BIGGER_THEN_RSA_KEY_MODULUS 300
int main() {
char str[BIGGER_THEN_RSA_KEY_MODULUS] = "This is a test";
stty_print("Hi!\n");
rsa_clef_publique(); //even this is too much, you should set "public"
directly
bigint_t data = { .length_W = strlen(str),
.info = 0, //?? make sure you know how to set this!!! (for all bigint_t)
.wordv = str};
/* add your fix here */
stty_print("data:\n");
stty_print_bigint(&data);
stty_print_public(public);
rsa_enc(&data, public);
stty_print("encrypted:\n");
stty_print_bigint(&data);
stty_print("Done\n");
}
> buffer overflow somewhere without success. Is there a tool like electric
> fence to find memory corruption on avr ?
That's a good question, unfortunately I don't know the answer,
but in your case you could use "simavr" (avr simulator) for
testing/debugging,
simavr output should look like this (for the code above, after fixing your
bug):
firmware-antivol$ simavr -t -vv --mcu atmega1284 --freq 8000000
firmware.elf
Loaded 113450 .text at address 0x0
Loaded 2316 .data
Loaded 3200 .eeprom
Hi!.
data:.
BIGINT: 0x40f5..
L=14..
I=6..
54 68 69 73 20 69 73 20 61 20 74 65 73 74 ..
..
RSA public key: 0xe89..
BIGINT: 0xe89..
L=3..
I=0..
01 00 01 ..
..
BIGINT: 0xe8e..
L=256..
I=7..
89 39 71 6D 12 88 0F DF 7F 7E 30 B2 97 B4 64 36..
F6 6A 97 58 F7 97 9C 6B BC CD 76 01 4F 7D 4B AF..
74 3C 76 4A B8 88 A3 BE 64 56 11 51 36 A4 EE 0C..
ED B3 34 FA EE 5E D8 28 0B 60 F3 E1 F8 29 C1 C5..
52 6E 97 73 B8 71 BF 0C F4 D8 E9 73 DC E1 3A 10..
1B 27 24 8A 19 53 FB 41 31 FA 08 3E DE 3E 52 B6..
7A ED CF DE A2 38 BF 04 C8 F1 71 C0 B4 9E CC 19..
2D E4 39 36 E3 FB 81 CC 6B 19 7D F2 2E 23 87 10..
6D 91 74 9B AD D6 FF 23 AF DB B7 8F 18 E3 AC 9F..
38 4B 34 26 7D 1A B5 74 BC 6E 15 2A 98 E5 F1 D3..
20 A0 3B C0 90 A4 56 AC 10 26 2F EC B8 6A B6 DB..
F9 56 56 49 21 13 1D 22 3A 1D 09 7C 54 7E 86 F3..
0A EC 5A B4 ED A3 01 8A FD 8D AB 5B E6 9F D1 24..
38 FD 3B 92 DB 3C 93 60 70 D9 9B 7D 37 70 40 60..
22 75 3C 53 F3 55 F5 C1 D5 8A DC DB 00 DD 70 5A..
3B 2A 3E AA 52 0E C2 B8 69 AF EE 22 B1 23 E9 D3..
encrypted:.
BIGINT: 0x40f5..
L=256..
I=7..
37 B2 E9 51 35 58 4E DA A4 D6 B2 B8 B3 6A F6 38..
CE C6 23 54 5B 6C 95 D9 59 78 1E A4 0B 1A C8 2F..
96 93 18 95 11 88 9D 98 03 E6 32 6D 79 7B AE 0C..
E8 0F 3A 9E 3F DF B7 72 C8 AC E2 38 D7 42 63 E1..
32 57 2A 1A 06 C7 39 36 AF FE 47 C7 D5 A6 B5 E8..
E1 CB 04 B8 9C C3 1F B4 13 65 26 6C 8F 4A A5 F6..
70 45 B9 96 A7 7E C5 17 A7 70 BE 58 B0 D3 55 A8..
AD 56 5B 8B DE A0 8A 24 EB 3D F2 EF B8 B5 59 05..
F8 1D 3F FE C1 E5 96 EE 69 54 D4 7B 6C 38 EE 60..
81 74 34 A4 12 93 94 66 47 48 DE D0 5B 74 B4 5E..
1D B5 88 F6 7A FE CE 78 CB C7 42 97 D2 06 43 FF..
67 97 BB 92 3B 4B 77 12 D8 1E DA DD F2 8C D4 1C..
DE 25 38 CD 35 60 A9 25 12 1C B0 67 95 DF 38 B6..
4D 00 14 FD EB 1C 06 14 20 70 70 8E 08 42 13 94..
72 FA AE 3B 3A 82 B8 7D FA 21 F2 69 82 C9 AB D2..
46 34 F8 21 50 0B 29 EB E6 6E B6 53 38 09 9D 87..
Done.
Note 1. I didn't initialize the serial, simavr doesn't care
Note 2. I had to fix firmware.h:322:
- unsigned char reserve[0x0200 - 34];
+ unsigned char reserve[0x0200 - 36];
Note 3. ".eeprom" section is in firmware.elf (where it probably should be)
Note 4. you can also debug the simavr simulation with avr-gdb:
firmware-antivol$ simavr -t -vv --mcu atmega1284 --freq
8000000 firmware.elf -g
(in second terminal)
firmware-antivol$ avr-gdb firmware.elf -ex 'target remote
:1234'
good luck with debugging!
--------------------------------------------------
some afterthoughts after seeing your code:
* for debugging it's a good practice to compile your code with '-g -O0'
flags, your makefiles should have one place where I could set/change this
(consider using CFLAGS)
* consider replacing: (*it).luminosite with: it->luminosite (it's much
easier to read, at least for me)
* should you use malloc? the best answer to this is: google "avr malloc"
* should you use VLA's (variable length arrays, this: "bigint_word_t
d_b[a->length_W + b->length_W]") normally I would say definitely yes,
but you probably will use your multitasking library at some point (I'm
not sure if multitasking on avr is a good idea, but I'm old ;) ) so bear in
mind that you will have to fine tune stack sizes for each thread.
* should you use static allocated memory: definitely yes, whenever it's
possible (on small CPUs)
* consider adding to your makefile (it's sometimes helpful): avr-size
--format=avr --mcu=atmega1284 firmware.elf
* don't do this: eeprom_read_byte((const uint8_t *) (0x0200 + i));
do this instead: eeprom_read_byte((uint8_t *) offsetof(eeprom,
appKey[i]));
(see Note 2. above, it took me 2h to find this error)
And finally:
>sob., 29 maj 2021 o 20:37 David Brown <david.br...@hesbynett.no>
napisał(a):
>Such encryption can work on an AVR that is big enough, but it is not a
>good fit for a microcontroller of that kind.
Think about this!
(avr was developed in 1996, we have 2021 ;) )
Best regards,
Pawel
