I am able to write NVS values by creating a pre-generate NVS data partition (as binary file) and write it in the esp32 partition. But I am unable to read these values despite there are indeed present in the NVS partition.
The commands I executed are:
1- nvs_partition_gen.py generate mfgdata.csv mfgdata.bin 0x5000
to get the pre-generate NVS data partition from
key,type,encoding,value
customNvs,namespace,,
batterySn,data,u32,65535
smartboxSn,data,u32,65534
test,data,u32,65533
2- parttool.py -p COM24 -b 115200 write_partition --partition-name=nvs --input=mfgdata.bin
to write the new NVS partition
I extracted the NVS partition and indeed, the value was there:
00000020: aaff ffff ffff ffff ffff ffff ffff ffff ................
00000030: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000040: 0001 01ff ba23 32a8 6375 7374 6f6d 4e76 .....#2.customNv
00000050: 7300 0000 0000 0000 01ff ffff ffff ffff s...............
00000060: 0104 01ff 24f9 ba27 6261 7474 6572 7953 ....$..'batteryS
00000070: 6e00 0000 0000 0000 ffff 0000 ffff ffff n...............
00000080: 0104 01ff 6a8e f27b 736d 6172 7462 6f78 ....j..{smartbox
00000090: 536e 0000 0000 0000 feff 0000 ffff ffff Sn..............
000000a0: 0104 01ff a69b 9df6 7465 7374 0000 0000 ........test....
000000b0: 0000 0000 0000 0000 fdff 0000 ffff ffff ................
000000c0: ffff ffff ffff ffff ffff ffff ffff ffff ...............
The problem is that I am not able to read these value. Before I wrote batterySn value thru Preferences API thru a bluetooth app.
I extracted NVS partition after setting batterySn thr the app and I get this:
00000040: 0001 01ff ba23 32a8 6375 7374 6f6d 4e76 .....#2.customNv
00000050: 7300 0000 0000 0000 01ff ffff ffff ffff s...............
00000060: 0104 01ff 24f9 ba27 6261 7474 6572 7953 ....$..'batteryS
00000070: 6e00 0000 0000 0000 ffff 0000 ffff ffff n...............
00000080: 0104 01ff 6a8e f27b 736d 6172 7462 6f78 ....j..{smartbox
00000090: 536e 0000 0000 0000 feff 0000 ffff ffff Sn..............
000000a0: 0104 01ff a69b 9df6 7465 7374 0000 0000 ........test....
.
.
.
00002380: 0204 01ff fd7a be81 7570 7469 6d65 0000 .....z..uptime..
00002390: 0000 0000 0000 0000 3c00 0000 ffff ffff ........<.......
000023a0: 0204 01ff 4bb2 b35d 6261 7474 6572 7953 ....K..]batteryS
000023b0: 6e00 0000 0000 0000 0100 0000 ffff ffff n...............
000023c0: 0204 01ff eab6 692c 7570 7469 6d65 0000 ......i,uptime..
000023d0: 0000 0000 0000 0000 7800 0000 ffff ffff ........x.......
My customNvs value are still there and there is batterySn value but in a different place. Only the second batterySn value can be read.
I tried to add a new argument to the write command like so:
parttool.py -p COM24 -b 115200 --partition-table-offset 0x9000 write_partition --partition-name=nvs --input=mfgdata.bin
Because my customNVS partition have an offset of 0x9000 but by doing that I get an error:
File "C:\ESP-IDF\components\partition_table\parttool.py", line 368, in <module>
main()
File "C:\ESP-IDF\components\partition_table\parttool.py", line 337, in main
target = ParttoolTarget(**target_args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\ESP-IDF\components\partition_table\parttool.py", line 119, in __init__
partition_table = gen.PartitionTable.from_binary(b)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\ESP-IDF\components\partition_table\gen_esp32part.py", line 231, in from_binary
result.append(PartitionDefinition.from_binary(data))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\ESP-IDF\components\partition_table\gen_esp32part.py", line 381, in from_binary
res.name = res.name.decode()
^^^^^^^^^^^^^^^^^
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte
Please tell me if my explanation is not clear enough or my process to write values in NVS partition is wrong.
My custom partition:
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000
otadata, data, ota, 0xE000, 0x2000
app0, app, ota_0, 0x10000, 0x2A0000
app1, app, ota_1, 0x2B0000, 0x2A0000
ffat, data, fat, 0x550000, 0x2B0000
Related
I'm reading the wikipedia article on Master Boot Record and specifically curious about what (if anything) needs to be in the "bootstrap code area" for the MBR to be readable in modern systems. I used parted to create an MBR on an SD card then used xxd /dev/mmcblk0 to peek at the raw data that was written. I can see:
partition entries at 0x01BE and 0x01CE
boot signature 0x55AA at 0x01FE-0x01FF
But what is the meaning of the data from 0x0000 through 0x01BD?
Example:
00000000: fab8 0010 8ed0 bc00 b0b8 0000 8ed8 8ec0 ................
00000010: fbbe 007c bf00 06b9 0002 f3a4 ea21 0600 ...|.........!..
00000020: 00be be07 3804 750b 83c6 1081 fefe 0775 ....8.u........u
00000030: f3eb 16b4 02b0 01bb 007c b280 8a74 018b .........|...t..
00000040: 4c02 cd13 ea00 7c00 00eb fe00 0000 0000 L.....|.........
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001b0: 0000 0000 0000 0000 fed0 4bb2 0000 8020 ..........K....
000001c0: 2100 8328 0d0c 0008 0000 f1f2 0200 0003 !..(............
000001d0: c2eb 8303 c1eb f1fa 0200 0000 6000 0000 ............`...
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.
Some context: This is a disk image for a bootable SD card in a Beablebone-like ARM/Linux SBC. But since the MBR is architecture/ OS independent, I assume - at least on ARM - there is no actual machine code in the "bootstrap code area." Is it x86/ BIOS machine code that exists by convention and is ignored on ARM?
If I wrote arbitrary data in 0x100-0x150 would the MBR still be readable?
I created an AVI file by rendering the frames using Cairo. The AVI generation code is part of an OCaml library. However, ffmpeg and vlc both yield only the very first frame. If I cut the avi header and use ffplay with the proper codec options, I can view the movie just fine.
What causes ffmpeg to think this file has only one frame?
The header of the file looks like this:
0000000 4952 4646 d0e0 0278 5641 2049 494c 5453
0000010 00c0 0000 6468 6c72 7661 6869 0038 0000
0000020 a2c2 0000 0000 0000 0000 0000 0100 0000
0000030 003c 0000 0000 0000 0001 0000 0000 0000
0000040 01e0 0000 01e0 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 494c 5453 0074 0000
0000060 7473 6c72 7473 6872 0038 0000 6976 7364
0000070 4752 2042 0000 0000 0000 0000 0000 0000
0000080 000a 0000 00f0 0000 0000 0000 003c 0000
0000090 2000 00fd 0000 0000 0001 0000 0000 0000
00000a0 01e0 01e0 7473 6672 0028 0000 0028 0000
00000b0 01e0 0000 01e0 0000 0001 0018 0000 0000
00000c0 8c00 000a 0000 0000 0000 0000 0000 0000
00000d0 0000 0000 494c 5453 d00c 0278 6f6d 6976
00000e0 3030 6364 d000 0278 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
I found the answer. Something not mentioned in the docs I read was that the stream itself needs to be encoded as a list of CHUNKS. So every frame shall be one CHUNK. This is, of course, not necessary in principle, but seems to be a very common convention.
I have an image file, which is 1048592 bytes length.
16 bytes header and 1048576 bytes data.
The begining bytes of its hex looks like below,
does anyone know how to decode it?
504b 4d20 3130 0000 0400 0800 0400 0800
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0203 0310 37ff ff00 485f 76d2 0d99 0331
7878 8f3e 110e 1186 2a2a 3bc9 7391 f733
1d1d 1de2 fff7 0008 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 1213 14d0 337f 7f80
4444 4685 1d91 333f 2636 37cd 3b9d 7fbb
0303 0315 f777 cccc 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
....
The header states it is a PKM image format.
The format is:
4 byte magic number(504b 4d20): "PKM "
2 byte version "10"
2 byte data type: 0 (ETC1_RGB_NO_MIPMAPS)
16 bit big endian extended width
16 bit big endian extended height
16 bit big endian original width
16 bit big endian original height data, 64bit big endian words.
From Game Developers SE Question
PKM format for ETC1 texture (All OGLES 2.0 devices compatibles)
PKM is useful for packaging ETC1-compressed images, but like with PNG, it doesn't support actual texture features.
It seems like you met this image format:
https://community.arm.com/thread/3968
It has PKM 10 in the beginning
You can convert the "PKM 10" format .pkm files to .png format using the following program:
https://forum.ragezone.com/f857/pkm-encrypt-decrypt-convert-to-1179253/
I have a binary file of a Fortran program. For this binary file want to know the source coding of the Fortran program. By using hexdum -c I have converted the binary file to ascii file. Still it is not understandable. How to convert a binary file or ascii file to human readable format.
Below I have past the some portion of ascii file after doing hexdum -c
0003D80 0000 0000 0100 1300 8901 0000 D8B4 0408
0003D90 0000 0000 0100 1000 9701 0000 CCB5 0408
0003DA0 0000 0000 0100 1400 A301 0000 B09D 0408
0003DB0 0000 0000 0200 0C00 B901 0000 0000 0000
0003DC0 0000 0000 0400 F1FF BE00 0000 0000 0000
0003DD0 0000 0000 0400 F1FF EE00 0000 0000 0000
0003DE0 0000 0000 0400 F1FF B901 0000 0000 0000
0003DF0 0000 0000 0400 F1FF 0100 0000 0000 0000
0003E00 0000 0000 0400 F1FF 1000 0000 0000 0000
0003E10 0000 0000 0400 F1FF 0100 0000 0000 0000
0003E20 0000 0000 0400 F1FF 3E00 0000 0000 0000
0003E30 0000 0000 0400 F1FF B901 0000 0000 0000
0003E40 0000 0000 0400 F1FF E901 0000 0000 0000
0003E50 0000 0000 0400 F1FF F201 0000 00B1 0408
0003E60 1400 0000 0100 0F00 0302 0000 14B1 0408
0003EE0 1400 0000 0100 0F00 8B02 0000 B4B1 0408
0003EF0 1400 0000 0100 0F00 9C02 0000 C8B1 0408
0003F00 1400 0000 0100 0F00 AF02 0000 DCB1 0408
0003F10 1400 0000 0100 0F00 C202 0000 F0B1 0408
0003F20 1400 0000 0100 0F00 D502 0000 04B2 0408
0003F30 1400 0000 0100 0F00 E802 0000 18B2 0408
0003F40 1400 0000 0100 0F00 FB02 0000 2CB2 0408
There are decompilers which will attempt to generate source code from the binary, but it would not be the original source code. Meaning it would not have comments or local variable names. In order to get a decompiler for your binary though, you have to find out which compiler was used to generate it, then which architecture it was compiled for. The next step would be to search for a decompiler for that compiler, or a decompiler for that architecture which is similar enough to the compilation techniques used on the original compiler to generate reasonable source code.
The binary file you gave (since it's a compiled program) isn't just a binary representation of ASCII or any other text code. The reason is that It's machine code, meaning that it doesn't translate into anything human readable.
Some other people have mentioned, there are some decompilers which attempt to reverse the compile process (but those wouldn't give variable names and comments).
If it's an open source program you're trying to find the source code for, you should be able to find it somewhere online (like on sourceforge.net)
Camtasia Studio is a software package for recording screen captures. One thing it does, it records the mouse movement coordinates separately from the video of your screen. It does this so you can modify the appearance of the cursor after you are done recording.
Once you have recorded your screen, it has an option for exporting the raw components of your capture. One of the files contains the cursor coordinates which look like this...
4556 5453 0300 0000 0c00 0000 0c00 0000
ca00 0000 0c00 0000 0100 0000 0000 0000
8002 0000 e001 0000 1900 0000 cb00 0000
1900 0000 0100 0000 0000 0000 000c 0259
0000 0059 0014 0000 00e0 e8ab 096a 032d
08b8 0100 00c8 0000 0008 0000 0037 0000
00b0 feff ffef 0328 02d2 0100 00f0 0328
02d2 0100 00f1 0329 02e0 0100 00f2 032a
02e0 0100 00f5 032b 02ed 0100 00f8 032d
02ed 0100 00fb 032f 02fa 0100 0001 0432
02fa 0100 0007 0435 0208 0200 000e 043a
0208 0200 0018 043f 0215 0200 0023 0445
0215 0200 002e 044a 0215 0200 0039 0450
0215 0200 0046 0455 0215 0200 004f 0458
0215 0200 0056 045a 022c 0200 005d 045e
022c 0200 0063 0462 0242 0200 0068 0465
0242 0200 006f 046b 0258 0200 0072 046f
0258 0200 0079 0476 0280 0200 0082 047d
0280 0200 0089 0484 028c 0200 0091 048a
028c 0200 0098 0494 029a 0200 009e 049c
029a 0200 00a3 04a0 029a 0200 00a7 04a3
029a 0200 00aa 04a6 02aa 0200 00af 04ab
02bc 0200 00b2 04ae 02bc 0200 00b4 04b3
02bc 0200 00b8 04b7 02cc 0200 00be 04bd
02cc 0200 00c1 04bf 02dd 0200 00c3 04c1
02dd 0200 00c6 04c4 02f8 0200 00c9 04c6
02f8 0200 00cb 04c8 0205 0300 00cc 04c9
0213 0300 00cd 04c9 0213 0300 00cd 04ca
0220 0300 00ce 04cb 0221 0300 00ce 04cc
0221 0300 00ce 04cd 0236 0300 00ce 04ce
0236 0300 00cd 04cf 024d 0300 00cc 04d0
024d 0300 00cc 04d1 0262 0300 00cb 04d2
0262 0300 00cb 04d3 0279 0300 00ca 04d3
02a5 0300 00c9 04d3 0218 0000 0002 0000
000c 0000 0002 0000 0000 0000 0081 0404
0487 06a5 04a5 0300 00f8 0304 0487 06ba
040a 0000 0003 0000 000a 0000 0001 0000
0000 0000 0000 0008 0009 000c 0000 0001
0000 000c 0000 0001 0000 0000 0000 00ff
033b 027f 061b 040c 0000 0005 0000 000c
0000 0001 0000 0000 0000 0000 0000 00ff
ffff ff0c 0000 0004 0000 000c 0000 0001
0000 0000 0000 0001 0000 0000 0000 001c
0000 002d 0100 001c 0000 0001 0000 0090
0300 0000 0100 0079 0000 0044 0000 0000
0000 0000 0000 0000 0000 00
This is from a 1 second recording. The screen capture size was 640x480. I was moving the mouse from the top left corner to the bottom right corner.
So here is my question. Is there a way to translate this information to time and X, Y coordinates of the video? I guess I just don't understand the notation but I want to use this information for my own project. Can anyone make sense of this data?