Skip to content

esp32c3 esp_partition_write() call on encrypted partition results in partially wrong data written to flash (QEMU-246) #123

@gw8484

Description

@gw8484

Checklist

  • Checked the issue tracker for similar issues to ensure this is not a duplicate
  • Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
  • Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

Plaintext data written to encrypted partition using:

esp_partition_erase_range()
esp_partition_write()

should result in properly encrypted data in flash that can be decrypted and read back using:

esp_partition_read()

Actual behavior (suspected bug)

Partially correct data is encrypted and written to flash.

Example plaintext data:

[20150.00h.04m.37s.558] 30 31 32 33 34 35 36 37  38 39 21 40 23 24 25 5E  |  0123456789!@#$%^
[20150.00h.04m.37s.559] 26 2A 61 62 63 64 65 66  67 68 69 6A 6B 6C 6D 6E  |  &*abcdefghijklmn
[20150.00h.04m.37s.560] 6F 70 71 72 73 74 75 76  77 78 79 7A 41 42 43 44  |  opqrstuvwxyzABCD
[20150.00h.04m.37s.561] 45 46 47 48 49 4A 4B 4C  4D 4E 4F 50 51 52 53 54  |  EFGHIJKLMNOPQRST
[20150.00h.04m.37s.562] 55 56 57 58 59 5A 30 31  32 33 34 35 36 37 38 39  |  UVWXYZ0123456789
[20150.00h.04m.37s.563] 21 40 23 24 25 5E 26 2A  61 62 63 64 65 66 67 68  |  !@#$%^&*abcdefgh
[20150.00h.04m.37s.564] 69 6A 6B 6C 6D 6E 6F 70  71 72 73 74 75 76 77 78  |  ijklmnopqrstuvwx
[20150.00h.04m.37s.565] 79 7A 41 42 43 44 45 46  47 48 49 4A 4B 4C 4D 4E  |  yzABCDEFGHIJKLMN
[20150.00h.04m.37s.566] 4F 50 51 52 53 54 55 56  57 58 59 5A 30 31 32 33  |  OPQRSTUVWXYZ0123
[20150.00h.04m.37s.566] 34 35 36 37 38 39 21 40  23 24 25 5E 26 2A 61 62  |  456789!@#$%^&*ab
[20150.00h.04m.37s.569] 63 64 65 66 67 68 69 6A  6B 6C 6D 6E 6F 70 71 72  |  cdefghijklmnopqr
[20150.00h.04m.37s.570] 73 74 75 76 77 78 79 7A  41 42 43 44 45 46 47 48  |  stuvwxyzABCDEFGH
[20150.00h.04m.37s.570] 49 4A 4B 4C 4D 4E 4F 50  51 52 53 54 55 56 57 58  |  IJKLMNOPQRSTUVWX
[20150.00h.04m.37s.571] 59 5A 30 31 32 33 34 35  36 37 38 39 21 40 23 24  |  YZ0123456789!@#$
[20150.00h.04m.37s.572] 25 5E 26 2A 61 62 63 64  65 66 67 68 69 6A 6B 6C  |  %^&*abcdefghijkl
[20150.00h.04m.37s.573] 6D 6E 6F 70 71 72 73 74  75 76 77 78 79 7A 41 42  |  mnopqrstuvwxyzAB

is not correctly encrypted and written to flash. When the above data is decrypted and read back from flash the result is:

[20150.01h.20m.00s.926] 30 31 32 33 34 35 36 37  38 39 21 40 23 24 25 5E  |  0123456789!@#$%^
[20150.01h.20m.00s.926] 26 2A 61 62 63 64 65 66  67 68 69 6A 6B 6C 6D 6E  |  &*abcdefghijklmn
[20150.01h.20m.00s.927] 30 31 32 33 34 35 36 37  38 39 21 40 23 24 25 5E  |  0123456789!@#$%^
[20150.01h.20m.00s.928] 26 2A 61 62 63 64 65 66  67 68 69 6A 6B 6C 6D 6E  |  &*abcdefghijklmn
[20150.01h.20m.00s.928] 55 56 57 58 59 5A 30 31  32 33 34 35 36 37 38 39  |  UVWXYZ0123456789
[20150.01h.20m.00s.929] 21 40 23 24 25 5E 26 2A  61 62 63 64 65 66 67 68  |  !@#$%^&*abcdefgh
[20150.01h.20m.00s.930] 55 56 57 58 59 5A 30 31  32 33 34 35 36 37 38 39  |  UVWXYZ0123456789
[20150.01h.20m.00s.930] 21 40 23 24 25 5E 26 2A  61 62 63 64 65 66 67 68  |  !@#$%^&*abcdefgh
[20150.01h.20m.00s.931] 4F 50 51 52 53 54 55 56  57 58 59 5A 30 31 32 33  |  OPQRSTUVWXYZ0123
[20150.01h.20m.00s.931] 34 35 36 37 38 39 21 40  23 24 25 5E 26 2A 61 62  |  456789!@#$%^&*ab
[20150.01h.20m.00s.932] 4F 50 51 52 53 54 55 56  57 58 59 5A 30 31 32 33  |  OPQRSTUVWXYZ0123
[20150.01h.20m.00s.933] 34 35 36 37 38 39 21 40  23 24 25 5E 26 2A 61 62  |  456789!@#$%^&*ab
[20150.01h.20m.00s.933] 49 4A 4B 4C 4D 4E 4F 50  51 52 53 54 55 56 57 58  |  IJKLMNOPQRSTUVWX
[20150.01h.20m.00s.934] 59 5A 30 31 32 33 34 35  36 37 38 39 21 40 23 24  |  YZ0123456789!@#$
[20150.01h.20m.00s.935] 49 4A 4B 4C 4D 4E 4F 50  51 52 53 54 55 56 57 58  |  IJKLMNOPQRSTUVWX
[20150.01h.20m.00s.935] 59 5A 30 31 32 33 34 35  36 37 38 39 21 40 23 24  |  YZ0123456789!@#$

Error logs or terminal output

Steps to reproduce the behavior

write a block of a known data using the following function sequence to an encrypted partition:

esp_partition_erase_range()
esp_partition_write()
esp_partition_read()

Project release version

9.2.2

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Linux

Operating system version

Ubuntu 22.04

Shell

Bash

Additional context

It looks like the second 32-byte sub-block of every 64-byte block is encrypted and written incorrectly using the plaintext data of the first 32-byte sub-block of every 64-byte block.

The same tests were done on the esp32 qemu of the same version (9.2.2) and works correctly.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions