MTDBLOCK1 appears to be overwritten with SD Card contents on embedded Linux system - filesystems

Background
I am maintaining a product that has an Analog Devices ADSP-BF547 Blackfin Microprocessor that is running the ADI's 2011R1-RC3 distribution of uCLinux, which uses Busybox. The processor mounts an SD card which it writes some encrypted TAR file reports to periodically. Note, uCLinux is for processors with no MMU.
Here are some details about the uImage partitions and what is mounted:
root:root:~> cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "uboot"
mtd1: 00800000 00020000 "uImage0"
mtd2: 00800000 00020000 "uImage1"~> cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "uboot"
mtd1: 00800000 00020000 "uImage0"
mtd2: 00800000 00020000 "uImage1"
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAH4)
Creating 7 MTD partitions on "MT29F2G08ABAEAH4":
0x000000000000-0x000000100000 : "uboot"
0x000000100000-0x000000900000 : "uImage0"
0x000000900000-0x000001100000 : "uImage1"
0x000001100000-0x000003000000 : "firmware"
0x000003000000-0x000003400000 : "factory_conf"
0x000003400000-0x000003800000 : "var_conf"
0x000003800000-0x000010000000 : "nand_temp"
yaffs: dev is 32505859 name is "mtdblock3" ro
yaffs: passed flags ""
yaffs: dev is 32505860 name is "mtdblock4" ro
yaffs: passed flags ""
yaffs: dev is 32505861 name is "mtdblock5" rw
yaffs: passed flags ""
yaffs: dev is 32505862 name is "mtdblock6" rw
yaffs: passed flags ""
root:~> mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
mdev on /dev type tmpfs (rw,nosuid,relatime,mode=0755,size=10M)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600)
var on /var type ramfs (rw,relatime)
tmp on /tmp type tmpfs (rw,nosuid,nodev,relatime)
/dev/mtdblock3 on /mnt/firmware type yaffs2 (ro,noatime)
/dev/mtdblock4 on /mnt/factory_conf type yaffs2 (ro,noatime)
/dev/mtdblock5 on /mnt/var_conf type yaffs2 (rw,noatime)
/dev/mtdblock6 on /mnt/nand_temp type yaffs2 (rw,noatime)
/dev/mmcblk0p1 on /mnt/sd type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
The Problem
I've gotten a few units back from the field that are failing to boot. U-Boot reports that there is no valid uImage. I read out the memory from U-Boot at the beginning of where the uImage should be and discovered that it has been mostly erased. What has been written appears to be the same contents that get written to the SD card. However, this area does not resemble a FAT filesystem.
I am basing this assumption on:
The the file name present in an ASCII of the dump matches the same conventions we use on the SD card
The string "reports" is in the dump, which is the directory we write to on the SD card
The only ASCII information a report contains is the string REPORTDATA
Here is the beginning of the dump that shows these features:
00000000: 03 00 00 00 01 00 00 00 ff ff 72 65 70 6f 72 74 ..........report
00000010: 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 s...............
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100: 00 00 00 00 00 00 00 00 00 00 ff ff ed 41 00 00 .............A..
00000110: 00 00 00 00 00 00 00 00 06 cb b9 5e 06 cb b9 5e ...........^...^
00000120: 06 cb b9 5e ff ff ff ff ff ff ff ff ff ff ff ff ...^............
00000130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00000140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
*
000001a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000001b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000001c0: ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 ................
000001d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000001e0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ................
000001f0: ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 ................
00000200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00000210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
*
000007e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000007f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00000800: 03 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
00000810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
000008e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000008f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000900: 00 00 00 00 00 00 00 00 00 00 ff ff ed 41 00 00 .............A..
00000910: 00 00 00 00 00 00 00 00 02 cb b9 5e 06 cb b9 5e ...........^...^
00000920: 06 cb b9 5e ff ff ff ff ff ff ff ff ff ff ff ff ...^............
00000930: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00000940: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
*
000009a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000009b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000009c0: ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 ................
000009d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000009e0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ................
000009f0: ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 ................
00000a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00000a10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
*
00000fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00000ff0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00001000: 01 00 00 00 01 01 00 00 ff ff 30 39 39 39 39 5f ..........09999_
00001010: 41 42 43 44 30 30 31 36 30 5f 30 34 33 39 36 32 ABCD00160_043962
00001020: 5f 31 33 32 31 2e 74 61 72 00 00 00 00 00 00 00 _1321.tar.......
00001030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
000010e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000010f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001100: 00 00 00 00 00 00 00 00 00 00 ff ff 80 81 00 00 ................
00001110: 00 00 00 00 00 00 00 00 08 cb b9 5e 08 cb b9 5e ...........^...^
00001120: 08 cb b9 5e 00 00 00 00 ff ff ff ff ff ff ff ff ...^............
00001130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00001140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
*
000011a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000011b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000011c0: ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 ................
000011d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000011e0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ................
000011f0: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 ................
00001200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00001210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
*
000017e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000017f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00001800: 52 45 50 4f 52 54 44 41 54 41 01 f8 7b 00 00 34 REPORTDATA..{..4
00001810: 00 46 b0 9e 27 97 7d 88 33 da 21 93 2b c8 51 c2 .F..'.}.3.!.+.Q.
00001820: 7e 00 02 80 fb 30 bc 14 9a 86 73 c5 c8 f7 37 5f ~....0....s...7_
00001830: 79 28 45 c5 53 03 c8 73 91 b9 fe 21 1d f7 41 ac y(E.S..s...!..A.
00001840: 8c 85 7d f0 d6 c8 c2 9f 07 2d 65 81 d4 2e a5 a0 ..}......-e.....
When we build these reports, we do so using temporary files in RAM (/tmp/). Prior to copying the report to the SD card and giving it an appropriate name we check that the SD card is mounted. Finally we use a system call to the mv command to move the file.
I attempted to unmount the SD card right after we check whether it is present and I've attempted to eject it. I've also attempted to do the same immediately prior to running the mv command. In either case an error message is printed that makes sense, e.g.:
mv: can't rename '/tmp/reportZe1MAL': No such file or directory
ERROR: Failed to move /tmp/reportZe1MAL to /mnt/sd/reports/09999_ABCD00160_044082_1007.tar: exit status was 256
Questions
Does the filesystem in the corrupted area resemble anything, e.g. tempfs?
How could a write to /mnt/sd, which is mmcblk0p1, end up in NAND mtdblock1 which isn't even mounted?
I have not attempted to create an out of ram scenario yet. But it is on my list of things to try.
Edit, here is a clue
I was able to look at some log data within the encrypted tar file that was written to NAND. From this log data I can tell that the device thinks that the SD card is mounted but the directory /mnt/sd/reports does not exist just prior to generating the tar file. I am seeing this consistently across multiple units.

Related

Zlib uncompress method not parsing an array of bytes from an image

Currently I'm trying to read the bytes from the IDAT chunk of a PNG image, in C. I am able to get all the other info, including the said array of bytes.
The problem arises whenever I try to decompress said array with zlib's uncompress() method.
[ ... ]
int decompress(Chunk * _chunk, Image * _image)
{
uLongf compressedSize = _chunk->length;
byte * uncompressedData = NULL;
uLongf uncompressedSize = 0;
int ret = uncompress(uncompressedData, &uncompressedSize, _chunk->data, compressedSize);
if(ret != Z_OK)
{
fprintf(stderr, "Error: failed to uncompress IDAT chunk data. ERR CODE: %d\n", ret);
return -1;
}
[ ... ]
}
The chunk struct is defined as such:
typedef struct chunk
{
uint32_t length;
byte chunkType[4];
byte *data;
} Chunk;
The byte type is just an unsigned char, and the image struct is defined as follows:
typedef struct image
{
uint32_t width;
uint32_t height;
byte bitDepth;
byte colorType;
byte compression;
byte filter;
byte interlace;
} Image;
The test image's HEX representation is:
89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52
00 00 00 11 00 00 00 12 04 03 00 00 00 4F D7 28
67 00 00 00 30 50 4C 54 45 00 00 00 80 00 00 00
80 00 80 80 00 00 00 80 80 00 80 00 80 80 80 80
80 C0 C0 C0 FF 00 00 00 FF 00 FF FF 00 00 00 FF
FF 00 FF 00 FF FF FF FF FF 7B 1F B1 C4 00 00 00
09 70 48 59 73 00 00 0E C4 00 00 0E C4 01 95 2B
0E 1B 00 00 00 28 49 44 41 54 08 D7 63 D8 0D 05
1B 18 36 30 00 01 FF FF FF 24 B1 FE FF FF C0 C0
40 0E 6B FF FF FF 20 73 48 60 C1 5D 0A 00 BB 1A
49 27 39 98 BC 6E 00 00 00 00 49 45 4E 44 AE 42
60 82
And the bytes of the IDAT chunk are:
08 D7 63 D8 0D 05 1B 18 36 30 00 01 FF FF FF 24 B1 FE FF FF C0 C0 40 0E 6B FF FF FF 20 73 48 60 C1 5D 0A 00 BB 1A 49 27
It must be noted that I'm not taking the CRC of the chunk as well; from my understanding it shouldn't be a problem.
Any idea as to why the uncompress() method is returning Z_DATA_ERROR?
You're not giving uncompress() anywhere to put the uncompressed data! uncompressedData cannot be NULL.

How to read binary executable by instructions?

is there a way to read given amount of instructions from a binary executable file on x86 architecture programmatically?
If I had a binary of a simple C program hello.c:
#include <stdio.h>
int main(){
printf("Hello world\n");
return 0;
}
Where after compilation using gcc, the disassembled function main looks like this:
000000000000063a <main>:
63a: 55 push %rbp
63b: 48 89 e5 mov %rsp,%rbp
63e: 48 8d 3d 9f 00 00 00 lea 0x9f(%rip),%rdi # 6e4 <_IO_stdin_used+0x4>
645: e8 c6 fe ff ff callq 510 <puts#plt>
64a: b8 00 00 00 00 mov $0x0,%eax
64f: 5d pop %rbp
650: c3 retq
651: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
658: 00 00 00
65b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
Is there an easy way in C to read for example first three instructions (meaning the bytes 55, 48, 89, e5, 48, 8d, 3d, 9f, 00, 00, 00) from main? It is not guaranteed that the function looks like this - the first instructions may have all different opcodes and sizes.
this prints the 10 first bytes of the main function by taking the address of the function and converting to a pointer of unsigned char, print in hex.
This small snippet doesn't count the instructions. For this you would need an instruction size table (not very difficult, just tedious unless you find the table already done, What is the size of each asm instruction?) to be able to predict the size of each instruction given the first byte.
(unless of course, the processor you're targetting has a fixed instruction size, which makes the problem trivial to solve)
Debuggers have to decode operands as well, but in some cases like step or trace, I suspect they have a table handy to compute the next breakpoint address.
#include <stdio.h>
int main(){
printf("Hello world\n");
const unsigned char *start = (const char *)&main;
int i;
for (i=0;i<10;i++)
{
printf("%x\n",start[i]);
}
return 0;
}
output:
Hello world
55
89
e5
83
e4
f0
83
ec
20
e8
seems to match the disassembly :)
00401630 <_main>:
401630: 55 push %ebp
401631: 89 e5 mov %esp,%ebp
401633: 83 e4 f0 and $0xfffffff0,%esp
401636: 83 ec 20 sub $0x20,%esp
401639: e8 a2 01 00 00 call 4017e0 <___main>
.globl _start
_start:
bl main
b .
.globl main
main:
add r1,#1
add r2,#1
add r3,#1
add r4,#1
b main
intentionally wrong architecture, architecture doesnt matter file format matters. built this into an elf file format, which is very popular, and is simply a file format which is what I understood your question to be, to read a file, not modify the binary to read the program runtime from memory.
it is very much popular and there are tools that do it which you appear to know how to run.
Disassembly of section .text:
00001000 <_start>:
1000: eb000000 bl 1008 <main>
1004: eafffffe b 1004 <_start+0x4>
00001008 <main>:
1008: e2811001 add r1, r1, #1
100c: e2822001 add r2, r2, #1
1010: e2833001 add r3, r3, #1
1014: e2844001 add r4, r4, #1
1018: eafffffa b 1008 <main>
if I hexdump the file though
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 28 00 01 00 00 00 00 10 00 00 34 00 00 00 |..(.........4...|
00000020 c0 11 00 00 00 02 00 05 34 00 20 00 01 00 28 00 |........4. ...(.|
00000030 06 00 05 00 01 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 1c 10 00 00 1c 10 00 00 05 00 00 00 |................|
00000050 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000 00 00 00 eb fe ff ff ea 01 10 81 e2 01 20 82 e2 |............. ..|
00001010 01 30 83 e2 01 40 84 e2 fa ff ff ea 41 11 00 00 |.0...#......A...|
00001020 00 61 65 61 62 69 00 01 07 00 00 00 08 01 00 00 |.aeabi..........|
00001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001040 00 00 00 00 00 10 00 00 00 00 00 00 03 00 01 00 |................|
00001050 00 00 00 00 00 00 00 00 00 00 00 00 03 00 02 00 |................|
00001060 01 00 00 00 00 00 00 00 00 00 00 00 04 00 f1 ff |................|
00001070 06 00 00 00 00 10 00 00 00 00 00 00 00 00 01 00 |................|
00001080 18 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |................|
00001090 09 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |................|
000010a0 17 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |................|
000010b0 55 00 00 00 00 10 00 00 00 00 00 00 10 00 01 00 |U...............|
000010c0 23 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |#...............|
000010d0 2f 00 00 00 08 10 00 00 00 00 00 00 10 00 01 00 |/...............|
000010e0 34 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |4...............|
000010f0 3c 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |<...............|
00001100 43 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |C...............|
00001110 48 00 00 00 00 00 08 00 00 00 00 00 10 00 01 00 |H...............|
00001120 4f 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |O...............|
00001130 00 73 6f 2e 6f 00 24 61 00 5f 5f 62 73 73 5f 73 |.so.o.$a.__bss_s|
00001140 74 61 72 74 5f 5f 00 5f 5f 62 73 73 5f 65 6e 64 |tart__.__bss_end|
00001150 5f 5f 00 5f 5f 62 73 73 5f 73 74 61 72 74 00 6d |__.__bss_start.m|
00001160 61 69 6e 00 5f 5f 65 6e 64 5f 5f 00 5f 65 64 61 |ain.__end__._eda|
00001170 74 61 00 5f 65 6e 64 00 5f 73 74 61 63 6b 00 5f |ta._end._stack._|
00001180 5f 64 61 74 61 5f 73 74 61 72 74 00 00 2e 73 79 |_data_start...sy|
00001190 6d 74 61 62 00 2e 73 74 72 74 61 62 00 2e 73 68 |mtab..strtab..sh|
000011a0 73 74 72 74 61 62 00 2e 74 65 78 74 00 2e 41 52 |strtab..text..AR|
000011b0 4d 2e 61 74 74 72 69 62 75 74 65 73 00 00 00 00 |M.attributes....|
000011c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000011e0 00 00 00 00 00 00 00 00 1b 00 00 00 01 00 00 00 |................|
000011f0 06 00 00 00 00 10 00 00 00 10 00 00 1c 00 00 00 |................|
00001200 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 |................|
00001210 21 00 00 00 03 00 00 70 00 00 00 00 00 00 00 00 |!......p........|
00001220 1c 10 00 00 12 00 00 00 00 00 00 00 00 00 00 00 |................|
00001230 01 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 |................|
00001240 00 00 00 00 00 00 00 00 30 10 00 00 00 01 00 00 |........0.......|
00001250 04 00 00 00 05 00 00 00 04 00 00 00 10 00 00 00 |................|
00001260 09 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 |................|
00001270 30 11 00 00 5c 00 00 00 00 00 00 00 00 00 00 00 |0...\...........|
00001280 01 00 00 00 00 00 00 00 11 00 00 00 03 00 00 00 |................|
00001290 00 00 00 00 00 00 00 00 8c 11 00 00 31 00 00 00 |............1...|
000012a0 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................|
000012b0
can google the file format and find a lot of info at wikipedia, with a smidge more at one of the links
useful header information
00 10 00 00 entrh
34 00 00 00 phoff
c0 11 00 00 shoff
00 02 00 05 flags
34 00 ehsize
20 00 phentsize
01 00 phnum
28 00 shentsize
06 00 shnum
05 00shstrndx
so if I look at the beginning of the sections there are shnum number of them
0x11C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x11E8 1b 00 00 00 01 00 00 00 06 00 00 00 00 10 00 00 00 10 00 00
0x1210 21 00 00 00 03 00 00 70 00 00 00 00 00 00 00 00 1c 10 00 00
0x1238 01 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 30 10 00 00
0x1260 09 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 30 11 00 00
0x1288 11 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 8c 11 00 00
0x1260 strtab type offset 0x1130 which is broken into null terminated strings until you hit a double null
[0] 00
[1] 73 6f 2e 6f 00 so.o
[2] 24 61 00 $a
[3] 5f 5f 62 73 73 5f 73 74 61 72 74 5f 5f 00 __bss_start__
[4] 5f 5f 62 73 73 5f 65 6e 64 5f 5f 00 __bss_end__
[5] 5f 5f 62 73 73 5f 73 74 61 72 74 00 __bss_start
[6] 6d 61 69 6e 00 main
...
main is at address 0x115F in the file which is offset 0x2F in the
strtab.
0x1238 symtab starts at 0x1030, 0x10 or 16 bytes per entry
00001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001040 00 00 00 00 00 10 00 00 00 00 00 00 03 00 01 00 |................|
00001050 00 00 00 00 00 00 00 00 00 00 00 00 03 00 02 00 |................|
00001060 01 00 00 00 00 00 00 00 00 00 00 00 04 00 f1 ff |................|
00001070 06 00 00 00 00 10 00 00 00 00 00 00 00 00 01 00 |................|
00001080 18 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |................|
00001090 09 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |................|
000010a0 17 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |................|
000010b0 55 00 00 00 00 10 00 00 00 00 00 00 10 00 01 00 |U...............|
000010c0 23 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |#...............|
000010d0 2f 00 00 00 08 10 00 00 00 00 00 00 10 00 01 00 |/...............|
000010e0 34 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |4...............|
000010f0 3c 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |<...............|
00001100 43 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |C...............|
00001110 48 00 00 00 00 00 08 00 00 00 00 00 10 00 01 00 |H...............|
00001120 4f 00 00 00 1c 10 01 00 00 00 00 00 10 00 01 00 |O...............|
000010d0 2f 00 00 00 has the 0x2f offset in the symbol table
so this is main, from this entry the address 08 10 00 00 or 0x1008 in
the processors memory, unfortunately due to the values I chose it happens to also be the file offset, dont get that confused.
this section is type 00000001 PROGBITS
0x11E8 1b 00 00 00 01 00 00 00 06 00 00 00 00 10 00 00 00 10 00 00
offset 0x1000 in the file 0x1C bytes
here is the program, the machine code.
00001000 00 00 00 eb fe ff ff ea 01 10 81 e2 01 20 82 e2
00001010 01 30 83 e2 01 40 84 e2 fa ff ff ea 41 11
so starting at memory offset 0x1008 which is 8 bytes after the
entry point (unfortunately I picked a bad address to use) we need to
go 0x8 bytes offset into this data
01 10 81 e2 01 20 82 e2
00001008 <main>:
1008: e2811001 add r1, r1, #1
100c: e2822001 add r2, r2, #1
1010: e2833001 add r3, r3, #1
this is all very file dependent, the cpu could care less about labels, main only means something to the humans, not the cpu.
If I convert the elf into other formats which are perfectly executable:
motorola s record:
S00A0000736F2E7372656338
S1131000000000EBFEFFFFEA011081E2012082E212
S10F1010013083E2014084E2FAFFFFEAB1
S9031000EC
raw binary image
hexdump -C so.bin
00000000 00 00 00 eb fe ff ff ea 01 10 81 e2 01 20 82 e2 |............. ..|
00000010 01 30 83 e2 01 40 84 e2 fa ff ff ea |.0...#......|
0000001c
The instruction bytes of interest are of course there, but the symbol information isnt. It depends on the file format you are interested in as to 1) if you can find "main" and then 2) print out the first few bytes at that address.
Hmm, a bit disturbing, but if you link for 0x2000 gnu ld burns some disk space and puts the offset at 0x2000, but choose 0x20000000 and it burns more disk space but not as much
000100d0 2f 00 00 00 08 00 00 20 00 00 00 00 10 00 01 00
shows the file offset is 0x010010 but the address in target space is 0x20000008
00010010 01 30 83 e2 01 40 84 e2 fa ff ff ea 41 11 00 00
00010020 00 61 65 61 62 69 00 01 07 00 00 00 08 01
just to demonstrate/enforce the file offset and the target memory space address are two different things.
this is a very nice format for what you are wanting to do
arm-none-eabi-objcopy -O symbolsrec so.elf so.srec
cat so.srec
$$ so.srec
$a $20000000
_bss_end__ $2001001c
__bss_start__ $2001001c
__bss_end__ $2001001c
_start $20000000
__bss_start $2001001c
main $20000008
__end__ $2001001c
_edata $2001001c
_end $2001001c
_stack $80000
__data_start $2001001c
$$
S0090000736F2E686578A1
S31520000000000000EBFEFFFFEA011081E2012082E200
S31120000010013083E2014084E2FAFFFFEA9F
S70520000000DA

Pulling individual integer value from hexadecimal value

Here is my hex code:
42 4D C6 00 00 00 00 00 00 00 76 00 00 00 28 00
00 00 0A 00 00 00 0A 00 00 00 01 00 04 00 00 00
00 00 50 00 00 00 12 0B 00 00 12 0B 00 00 10 00
00 00 10 00 00 00 FF 00 00 00 00 FF 00 00 00 00
42 00 5A 5A 84 00 00 00 FF 00 FF 00 FF 00 00 FF
FF 00 08 FF FF 00 5A FF FF 00 FF FF FF 00 FF FF
FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF
FF 00 FF FF FF 00 92 59 00 16 47 00 00 00 25 90
01 64 61 00 00 00 59 90 11 64 61 00 00 00 99 00
16 48 11 00 00 00 90 01 64 61 11 00 00 00 00 16
64 61 00 00 00 00 01 16 46 10 09 00 00 00 11 64
41 00 99 00 00 00 16 64 11 09 95 00 00 00 66 48
10 09 53 00 00 00
I know that the pixel "assignment" starts with the first line being (10 pixels wide):
92 59 00 16 47 00 00 00
I need to count how many times each colour is in the image, but I am unable to pull the individual integer value (ie: just the 9, then just the 2, then just the 5, and so on). The only value I am able to pull is "92" then "59" then "00"...
This is my code for that segment (the offset is 118 and the total hex values remaining are 80):
int nbr_each[NBRCOLOURS];
int ch, pixel;
fseek(fptr, 118, SEEK_SET);
for (count = 0; count < 81; count++)
{
pixel = fgetc(fptr);
nbr_each[pixel] = nbr_each[pixel] + 1;
}
fgetc will get you the individual characters.
first = fgetc(fptr); // '9'
second = fgetc(fptr); // '2'
space = fgetc(fptr); // ' '
Then convert each digit to a number 0..9 by subtracting off '0':
first -= '0';
second -= '0';
Then to count each digit, something like this:
nbr_each[first]++;
nbr_each[second]++;

XBee Transmit Request broadcast

I'm trying to send a broadcast using a router on a XBee S2 network.
All the devices are properly configured and have joined the network, but the packet is not being received.
I'm sending
7E 00 11 10 01 00 00 00 00 00 00 FF FF 00 00 00 00 41 42 43 2A
to the module.
What am I doing wrong?
You are not setting the 16-bit network address to 0xFFFE.
You have to send
7E 00 11 10 01 00 00 00 00 00 00 FF FF FF FE 00 00 41 42 43 2D

How to hide text inside compiled C code?

I am not so familiar with the C language and compiling it in Linux but I have something to ask and hope you can assist.
I have this line of code that uses an installed command and its parameters to join domain. (see pic).
After I run gcc join.c to compile it its created a file a.out.
So far so good but when I run vim a.out to view to content of that file I see mypassword can be easily viewed by a simple text editor. (see second pic)
Is there anything I can do to avoid this when compiling my C code?
#include <stdio.h>
#include <unistd.h>
int main ()
{
printf("Running 'net join' with the following parameters: \n");
char *domain="mydomain";
char *user="domainjoinuser";
char *pass="mypassword";
char *vastool="/opt/quest/bin/vastool";
char *ou="OU=test,DC=mtdomain,DC=local";
char unjoin[512];
sprintf(unjoin,"/opt/quest/in/vastool -u %s -w '%s' unjoin -f",user,pass);
printf("Domain: %s\n",domain);
printf("User: %s\n",user);
printf("-----------------\n");
printf("Unjoin.............\n");
system(unjoin);
printf("Join................\n");
execl("/opt/quest/bin/vastool", "vastool", "-u", user, "-w", pass, "join", "-c", "ou", "-f", domain, (char*)0);
}
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 3e 00 01 00 00 00 40 83 04 08 00 00 00 00 |..>.....#.......|
00000020 40 00 00 00 00 00 00 00 40 0a 00 00 00 00 00 00 |#.......#.......|
00000030 00 00 00 00 40 00 38 00 04 00 40 00 1c 00 1b 00 |....#.8...#.....|
00000040 03 00 00 00 04 00 00 00 20 01 00 00 00 00 00 00 |........ .......|
00000050 20 81 04 08 00 00 00 00 20 81 04 08 00 00 00 00 | ....... .......|
00000060 1c 00 00 00 00 00 00 00 1c 00 00 00 00 00 00 00 |................|
00000070 01 00 00 00 00 00 00 00 01 00 00 00 05 00 00 00 |................|
00000080 20 01 00 00 00 00 00 00 20 81 04 08 00 00 00 00 | ....... .......|
00000090 20 81 04 08 00 00 00 00 b0 05 00 00 00 00 00 00 | ...............|
000000a0 b0 05 00 00 00 00 00 00 00 10 00 00 00 00 00 00 |................|
000000b0 01 00 00 00 06 00 00 00 e0 06 00 00 00 00 00 00 |................|
000000c0 e0 96 04 08 00 00 00 00 e0 96 04 08 00 00 00 00 |................|
000000d0 60 02 00 00 00 00 00 00 60 02 00 00 00 00 00 00 |`.......`.......|
000000e0 00 10 00 00 00 00 00 00 02 00 00 00 06 00 00 00 |................|
000000f0 24 08 00 00 00 00 00 00 24 98 04 08 00 00 00 00 |$.......$.......|
00000100 24 98 04 08 00 00 00 00 a0 00 00 00 00 00 00 00 |$...............|
00000110 a0 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 |................|
00000120 2f 6c 69 62 36 34 2f 6c 64 2d 6c 69 6e 75 78 2d |/lib64/ld-linux-|
00000130 78 38 36 2d 36 34 2e 73 6f 2e 32 00 00 00 00 00 |x86-64.so.2.....|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 00 00 00 00 01 00 00 00 12 00 00 00 70 86 04 08 |............p...|
00000160 00 00 00 00 c0 01 00 00 00 00 00 00 13 00 00 00 |................|
00000170 12 00 00 00 80 86 04 08 00 00 00 00 a1 00 00 00 |................|
00000180 00 00 00 00 1a 00 00 00 12 00 00 00 90 86 04 08 |................|
00000190 00 00 00 00 8f 00 00 00 00 00 00 00 22 00 00 00 |............"...|
000001a0 12 00 00 00 a0 86 04 08 00 00 00 00 61 00 00 00 |............a...|
000001b0 00 00 00 00 29 00 00 00 12 00 00 00 b0 86 04 08 |....)...........|
000001c0 00 00 00 00 b0 01 00 00 00 00 00 00 2f 00 00 00 |............/...|
000001d0 12 00 0c 00 80 86 04 08 00 00 00 00 00 00 00 00 |................|
000001e0 00 00 00 00 35 00 00 00 20 00 00 00 00 00 00 00 |....5... .......|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 5f 5f 6c |.............__l|
00000200 69 62 63 5f 73 74 61 72 74 5f 6d 61 69 6e 00 70 |ibc_start_main.p|
00000210 72 69 6e 74 66 00 73 70 72 69 6e 74 66 00 73 79 |rintf.sprintf.sy|
00000220 73 74 65 6d 00 65 78 65 63 6c 00 5f 69 6e 69 74 |stem.execl._init|
00000230 00 5f 5f 67 6d 6f 6e 5f 73 74 61 72 74 5f 5f 00 |.__gmon_start__.|
00000240 6c 69 62 63 2e 73 6f 2e 36 00 00 00 04 00 00 00 |libc.so.6.......|
00000250 08 00 00 00 06 00 00 00 04 00 00 00 03 00 00 00 |................|
00000260 07 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 |................|
00000270 02 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00 |................|
00000280 00 00 00 00 f8 98 04 08 00 00 00 00 07 00 00 00 |................|
00000290 01 00 00 00 00 00 00 00 00 00 00 00 00 99 04 08 |................|
000002a0 00 00 00 00 07 00 00 00 02 00 00 00 00 00 00 00 |................|
000002b0 00 00 00 00 08 99 04 08 00 00 00 00 07 00 00 00 |................|
000002c0 03 00 00 00 00 00 00 00 00 00 00 00 10 99 04 08 |................|
000002d0 00 00 00 00 07 00 00 00 04 00 00 00 00 00 00 00 |................|
000002e0 00 00 00 00 18 99 04 08 00 00 00 00 07 00 00 00 |................|
000002f0 05 00 00 00 00 00 00 00 00 00 00 00 20 99 04 08 |............ ...|
00000300 00 00 00 00 07 00 00 00 06 00 00 00 00 00 00 00 |................|
00000310 00 00 00 00 28 99 04 08 00 00 00 00 06 00 00 00 |....(...........|
00000320 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000330 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000340 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 |1.I..^H..H...PTI|
00000350 c7 c0 90 85 04 08 48 c7 c1 00 85 04 08 48 c7 c7 |......H......H..|
00000360 6c 83 04 08 e8 07 03 00 00 f4 66 90 55 48 89 e5 |l.........f.UH..|
00000370 48 81 ec 30 02 00 00 48 8d 05 66 13 00 00 48 89 |H..0...H..f...H.|
00000380 c7 b8 00 00 00 00 e8 f5 02 00 00 48 8d 05 86 13 |...........H....|
00000390 00 00 48 89 45 f8 48 8d 05 84 13 00 00 48 89 45 |..H.E.H......H.E|
000003a0 f0 48 8d 05 88 13 00 00 48 89 45 e8 48 8d 05 88 |.H......H.E.H...|
000003b0 13 00 00 48 89 45 e0 48 8d 05 94 13 00 00 48 89 |...H.E.H......H.|
000003c0 45 d8 48 8b 45 e8 49 89 c3 48 8b 45 f0 49 89 c2 |E.H.E.I..H.E.I..|
000003d0 48 8d 05 98 13 00 00 48 89 c6 48 8d 85 d8 fd ff |H......H..H.....|
000003e0 ff 48 89 c7 4c 89 d2 4c 89 d9 b8 00 00 00 00 e8 |.H..L..L........|
000003f0 9c 02 00 00 48 8b 45 f8 48 89 c6 48 8d 05 9b 13 |....H.E.H..H....|
00000400 00 00 48 89 c7 b8 00 00 00 00 e8 71 02 00 00 48 |..H........q...H|
00000410 8b 45 f0 48 89 c6 48 8d 05 8c 13 00 00 48 89 c7 |.E.H..H......H..|
00000420 b8 00 00 00 00 e8 56 02 00 00 48 8d 05 82 13 00 |......V...H.....|
00000430 00 48 89 c7 b8 00 00 00 00 e8 42 02 00 00 48 8d |.H........B...H.|
00000440 05 81 13 00 00 48 89 c7 b8 00 00 00 00 e8 2e 02 |.....H..........|
00000450 00 00 48 8d 85 d8 fd ff ff 48 89 c7 b8 00 00 00 |..H......H......|
00000460 00 e8 3a 02 00 00 48 8d 05 6e 13 00 00 48 89 c7 |..:...H..n...H..|
00000470 b8 00 00 00 00 e8 06 02 00 00 48 b8 00 00 00 00 |..........H.....|
00000480 00 00 00 00 50 48 8b 45 f8 50 48 8d 05 90 13 00 |....PH.E.PH.....|
00000490 00 50 48 8d 05 85 13 00 00 50 48 8d 05 7a 13 00 |.PH......PH..z..|
000004a0 00 50 48 8d 05 6d 13 00 00 50 48 8b 45 e8 49 89 |.PH..m...PH.E.I.|
000004b0 c1 48 8d 05 5b 13 00 00 49 89 c0 48 8b 45 f0 49 |.H..[...I..H.E.I|
000004c0 89 c3 48 8d 05 47 13 00 00 49 89 c2 48 8d 05 35 |..H..G...I..H..5|
000004d0 13 00 00 48 89 c6 48 8d 05 14 13 00 00 48 89 c7 |...H..H......H..|
000004e0 4c 89 d2 4c 89 d9 b8 00 00 00 00 e8 c0 01 00 00 |L..L............|
000004f0 48 83 c4 30 c9 c3 00 00 00 00 00 00 00 00 00 00 |H..0............|
00000500 48 89 6c 24 d8 4c 89 64 24 e0 48 8d 2d 4f 01 00 |H.l$.L.d$.H.-O..|
00000510 00 4c 8d 25 48 01 00 00 48 89 5c 24 d0 4c 89 6c |.L.%H...H.\$.L.l|
00000520 24 e8 4c 89 74 24 f0 4c 89 7c 24 f8 48 83 ec 38 |$.L.t$.L.|$.H..8|
00000530 4c 29 e5 41 89 ff 49 89 f6 48 c1 fd 03 49 89 d5 |L).A..I..H...I..|
00000540 31 db e8 d9 00 00 00 48 85 ed 74 1a 0f 1f 40 00 |1......H..t...#.|
00000550 4c 89 ea 4c 89 f6 44 89 ff 41 ff 14 dc 48 83 c3 |L..L..D..A...H..|
00000560 01 48 39 eb 75 ea 48 8b 5c 24 08 48 8b 6c 24 10 |.H9.u.H.\$.H.l$.|
00000570 4c 8b 64 24 18 4c 8b 6c 24 20 4c 8b 74 24 28 4c |L.d$.L.l$ L.t$(L|
00000580 8b 7c 24 30 48 83 c4 38 c3 0f 1f 80 00 00 00 00 |.|$0H..8........|
00000590 f3 c3 00 00 01 00 02 00 14 00 00 00 00 00 00 00 |................|
000005a0 01 7a 52 00 01 78 10 01 1b 0c 07 08 90 01 07 10 |.zR..x..........|
000005b0 14 00 00 00 1c 00 00 00 88 fd ff ff 2a 00 00 00 |............*...|
000005c0 00 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 |................|
000005d0 01 7a 52 00 01 78 10 01 1b 0c 07 08 90 01 00 00 |.zR..x..........|
000005e0 24 00 00 00 1c 00 00 00 18 ff ff ff 89 00 00 00 |$...............|
000005f0 00 4a 86 06 8c 05 66 0e 40 83 07 8d 04 8e 03 8f |.J....f.#.......|
00000600 02 02 58 0e 08 00 00 00 14 00 00 00 44 00 00 00 |..X.........D...|
00000610 80 ff ff ff 02 00 00 00 00 00 00 00 00 00 00 00 |................|
00000620 48 83 ec 08 48 8b 05 fd 12 00 00 48 85 c0 74 05 |H...H......H..t.|
00000630 e8 cb 79 fb f7 48 83 c4 08 c3 00 00 48 83 ec 08 |..y..H......H...|
00000640 48 83 c4 08 c3 00 00 00 00 00 00 00 00 00 00 00 |H...............|
00000650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000660 ff 35 82 12 00 00 ff 25 84 12 00 00 00 00 00 00 |.5.....%........|
00000670 ff 25 82 12 00 00 68 00 00 00 00 e9 e0 ff ff ff |.%....h.........|
00000680 ff 25 7a 12 00 00 68 08 00 00 00 e9 d0 ff ff ff |.%z...h.........|
00000690 ff 25 72 12 00 00 68 10 00 00 00 e9 c0 ff ff ff |.%r...h.........|
000006a0 ff 25 6a 12 00 00 68 18 00 00 00 e9 b0 ff ff ff |.%j...h.........|
000006b0 ff 25 62 12 00 00 68 20 00 00 00 e9 a0 ff ff ff |.%b...h ........|
000006c0 ff 25 5a 12 00 00 68 28 00 00 00 e9 90 ff ff ff |.%Z...h(........|
000006d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000006e0 00 00 00 00 52 75 6e 6e 69 6e 67 20 27 6e 65 74 |....Running 'net|
000006f0 20 6a 6f 69 6e 27 20 77 69 74 68 20 74 68 65 20 | join' with the |
00000700 66 6f 6c 6c 6f 77 69 6e 67 20 70 61 72 61 6d 65 |following parame|
00000710 74 65 72 73 3a 20 0a 00 6d 79 64 6f 6d 61 69 6e |ters: ..mydomain|
00000720 00 64 6f 6d 61 69 6e 6a 6f 69 6e 75 73 65 72 00 |.domainjoinuser.|
00000730 6d 79 70 61 73 73 77 6f 72 64 00 2f 6f 70 74 2f |mypassword./opt/|
00000740 71 75 65 73 74 2f 62 69 6e 2f 76 61 73 74 6f 6f |quest/bin/vastoo|
00000750 6c 00 4f 55 3d 74 65 73 74 2c 44 43 3d 6d 74 64 |l.OU=test,DC=mtd|
00000760 6f 6d 61 69 6e 2c 44 43 3d 6c 6f 63 61 6c 00 2f |omain,DC=local./|
00000770 6f 70 74 2f 71 75 65 73 74 2f 69 6e 2f 76 61 73 |opt/quest/in/vas|
00000780 74 6f 6f 6c 20 2d 75 20 25 73 20 2d 77 20 27 25 |tool -u %s -w '%|
00000790 73 27 20 75 6e 6a 6f 69 6e 20 2d 66 00 44 6f 6d |s' unjoin -f.Dom|
000007a0 61 69 6e 3a 20 25 73 0a 00 55 73 65 72 3a 20 25 |ain: %s..User: %|
000007b0 73 0a 00 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d |s..-------------|
000007c0 2d 2d 2d 2d 0a 00 55 6e 6a 6f 69 6e 2e 2e 2e 2e |----..Unjoin....|
000007d0 2e 2e 2e 2e 2e 2e 2e 2e 2e 0a 00 4a 6f 69 6e 2e |...........Join.|
000007e0 2e 2e 2e 2e 2e 2e 2e 2e 2e 2e 2e 2e 2e 2e 2e 0a |................|
000007f0 00 2f 6f 70 74 2f 71 75 65 73 74 2f 62 69 6e 2f |./opt/quest/bin/|
00000800 76 61 73 74 6f 6f 6c 00 76 61 73 74 6f 6f 6c 00 |vastool.vastool.|
00000810 2d 75 00 2d 77 00 6a 6f 69 6e 00 2d 63 00 6f 75 |-u.-w.join.-c.ou|
00000820 00 2d 66 00 01 00 00 00 00 00 00 00 44 00 00 00 |.-f.........D...|
00000830 00 00 00 00 04 00 00 00 00 00 00 00 4c 82 04 08 |............L...|
...
Is there anything i can do to avoid this when compiling my C code?
The only thing you can do is to not hard-code the password or any sensitive information into your C program: even if you encrypt this sensitive information in one way or the other, either the decryption key would need to be provided at runtime by a user running your program, or the info could be decrypted by a sufficiently motivated person. You might as well prompt the user for the password.
Note that any other form of hiding would be a mere obfuscation - a small obstacle on the way of a user who is trying to access your secret information. It may deter a few "script kiddies", but it would fall to the first knowledgeable user.
As dasblinkenlight pointed out, whatever you do will not deter somebody from getting your password. For instance, he could run strace on your program to figure out which arguments are being passed to vastool, or he could use a debugger. If you write programs with the intent of being secure, always keep Kerkhoff's principle in mind:
A (crypto-) system should be secure even if everything about the system [...] is public knowledge.
However, if you like some extra smokescreen security obfuscation, you might want to have a look at the memfrob(3) function:
void *memfrob(void *s, size_t n);
The memfrob() function
encrypts the first n bytes of the memory area s by exclusive-ORing
each character with the number 42. The effect can be reversed by using
memfrob() on the encrypted memory area.
Note that this function is not a proper encryption routine as the XOR
constant is fixed, and is only suitable for hiding strings.
one way is to use a function (rot13(), reverse(), chartobinary() f.e.) and call your function with the encoded string.

Resources