Как парсить действия программы?

Может пойти от обратного? Почитать документацию к PIC и попробовать самому реализовать нужный функционал? Или хотябы поискать исходники программ, которые с PIC работают.

Документации точно нет. Так как это узконаправленая тема, и разработчики продают такие платы от 100к рублей…. Но прошивки на эти платы от других людей есть, правда очень кривые, но кто то смог разобраться. Вопрос как это делают. Если бы ыбли исходники то проблем бы небыло.

как это делают

Как-то так:

https://stackoverflow.com/questions/5125896/how-to-disassemble-a-binary-executable-in-linux-to-get-the-assembly-code

strace -s 9999 -e write точно не перехватывает общение программы с устройством?

А вот тут я не много не пойму что происходит. Я скачал с устройства 2 исполняемых файла, один тот который нужен work_s, второй обычный curl

root@debian:/home/cj# file curl curl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=226548ab6aed1adde526230acbd63654cfbfcc1a, stripped root@debian:/home/cj# file work_s work_s: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), too many section (65535) root@debian:/home/cj#

Как видно все ок. Теперь делаю objdump:

root@debian:/home/cj# /usr/arm-linux-gnueabihf/bin/objdump -d work_s /usr/arm-linux-gnueabihf/bin/objdump: work_s: File truncated

А вот curl: root@debian:/home/cj# /usr/arm-linux-gnueabihf/bin/objdump -d curl curl: file format elf32-littlearm

Disassembly of section .init:

0000973c <_init@@Base>: 973c: e92d4008 push {r3, lr} 9740: eb000168 bl 9ce8 <fputs@plt+0x10c> 9744: e8bd8008 pop {r3, pc}

Disassembly of section .plt:

00009748 strerror@plt-0x14: 9748: e52de004 push {lr} ; (str lr, [sp, #-4]!) 974c: e59fe004 ldr lr, [pc, #4] ; 9758 <_init@@Base+0x1c> 9750: e08fe00e add lr, pc, lr 9754: e5bef008 ldr pc, [lr, #8]! 9758: 00025d70 andeq r5, r2, r0, ror sp ………………………………

Все работает. Что не так с этим файлом?

Выдает вот так: — SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3611, si_uid=0, si_status=0, si_utime=0, si_stime=0} — — SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3615, si_uid=0, si_status=0, si_utime=0, si_stime=0} — — SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3616, si_uid=0, si_status=0, si_utime=0, si_stime=0} — — SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3647, si_uid=0, si_status=0, si_utime=0, si_stime=0} — — SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4510, si_uid=0, si_status=0, si_utime=0, si_stime=0} — — SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6140, si_uid=0, si_status=0, si_utime=0, si_stime=0} — — SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7767, si_uid=0, si_status=0, si_utime=0, si_stime=0} — — SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} — +++ killed by SIGSEGV +++

File truncated

Такие вопросы гуглятся довольно быстро.

Вы уверены, что именно вы должны этой задачей заниматься? Если это порыв вида «а что там может быть сложного», то могу только удачи пожелать.

Больше этим заниматься некому. Так что прошу подсказку, гугл мне не помогает. Онлайн отладчик так же пробовал, эффект один.

Попробуй добавить ключ -f, чтобы strace отслеживал и порождённые процессы. Если будешь логи записывать в файлы, а лучше логи записывать в файлы, то -ff включает запись трассировки отдельных процессов в разные файлы.

Да, я делал и -f и -ff и -y. Я четко получаю все вызовы write относительно GPIO например, вижу все файлы. Но программа потом начинает общатся именно с PIC, и пишет об этом log файл, и я вижу все вызовы write о том что программа пишет лог. Но ни между ними ничего нет! Как будто идет чистая запись в log.

Вот короткий пример. В этот момент идет общения с PIC:

22089 stat64(«/var/log/work_s/driver», {st_mode=S_IFREG|0644, st_size=268655, …}) = 0

22089 open(«/var/log/work_s/driver», O_WRONLY|O_CREAT|O_APPEND, 0666) = 10</mnt/data/var/log/work_s/driver>

22089 fstat64(10</mnt/data/var/log/work_s/driver>, {st_mode=S_IFREG|0644, st_size=268655, …}) = 0

22089 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb456e000

22089 fstat64(10</mnt/data/var/log/work_s/driver>, {st_mode=S_IFREG|0644, st_size=268655, …}) = 0

22089 _llseek(10</mnt/data/var/log/work_s/driver>, 268655, [268655], SEEK_SET) = 0

22089 write(10</mnt/data/var/log/work_s/driver>, «[2022/07/12 11:19:56] INFO: Swit»…, 67) = 67

22089 close(10</mnt/data/var/log/work_s/driver>) = 0

22089 munmap(0xb456e000, 4096) = 0

22089 gettimeofday({1657624796, 961006}, NULL) = 0

22089 stat64(«/var/log/work_s/temp», {st_mode=S_IFREG|0644, st_size=397242, …}) = 0

22089 open(«/var/log/work_s/temp», O_WRONLY|O_CREAT|O_APPEND, 0666) = 10</mnt/data/var/log/work_s/temp>

22089 fstat64(10</mnt/data/var/log/work_s/temp>, {st_mode=S_IFREG|0644, st_size=397242, …}) = 0

22089 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb456e000

22089 fstat64(10</mnt/data/var/log/work_s/temp>, {st_mode=S_IFREG|0644, st_size=397242, …}) = 0

22089 _llseek(10</mnt/data/var/log/work_s/temp>, 397242, [397242], SEEK_SET) = 0

22089 write(10</mnt/data/var/log/work_s/temp>, «[2022/07/12 11:19:56] INFO: Sett»…, 53) = 53

22089 close(10</mnt/data/var/log/work_s/temp>) = 0

22089 munmap(0xb456e000, 4096) = 0

22089 gettimeofday({1657624796, 962794}, NULL) = 0

22089 gettimeofday({1657624796, 962926}, NULL) = 0

22089 stat64(«/var/log/work_s/driver», {st_mode=S_IFREG|0644, st_size=268722, …}) = 0

22089 open(«/var/log/work_s/driver», O_WRONLY|O_CREAT|O_APPEND, 0666) = 10</mnt/data/var/log/work_s/driver>

22089 fstat64(10</mnt/data/var/log/work_s/driver>, {st_mode=S_IFREG|0644, st_size=268722, …}) = 0

22089 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb456e000

22089 fstat64(10</mnt/data/var/log/work_s/driver>, {st_mode=S_IFREG|0644, st_size=268722, …}) = 0

22089 _llseek(10</mnt/data/var/log/work_s/driver>, 268722, [268722], SEEK_SET) = 0

22089 write(10</mnt/data/var/log/work_s/driver>, «[2022/07/12 11:19:56] INFO: Chec»…, 42) = 42

22089 close(10</mnt/data/var/log/work_s/driver>) = 0

22089 munmap(0xb456e000, 4096) = 0

22089 nanosleep({1, 0}, 0xbed54788) = 0

22089 gettimeofday({1657624797, 964964}, NULL) = 0

22089 stat64(«/var/log/work_s/driver», {st_mode=S_IFREG|0644, st_size=268764, …}) = 0

22089 open(«/var/log/work_s/driver», O_WRONLY|O_CREAT|O_APPEND, 0666) = 10</mnt/data/var/log/work_s/driver>

22089 fstat64(10</mnt/data/var/log/work_s/driver>, {st_mode=S_IFREG|0644, st_size=268764, …}) = 0

22089 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb456e000

22089 fstat64(10</mnt/data/var/log/work_s/driver>, {st_mode=S_IFREG|0644, st_size=268764, …}) = 0

22089 _llseek(10</mnt/data/var/log/work_s/driver>, 268764, [268764], SEEK_SET) = 0

22089 write(10</mnt/data/var/log/work_s/driver>, «[2022/07/12 11:19:57] INFO: open»…, 40) = 40

22089 close(10</mnt/data/var/log/work_s/driver>) = 0

22089 munmap(0xb456e000, 4096) = 0

22089 gettimeofday({1657624797, 966795}, NULL) = 0

22089 stat64(«/var/log/work_s/driver», {st_mode=S_IFREG|0644, st_size=268804, …}) = 0

22089 open(«/var/log/work_s/driver», O_WRONLY|O_CREAT|O_APPEND, 0666) = 10</mnt/data/var/log/work_s/driver>

22089 fstat64(10</mnt/data/var/log/work_s/driver>, {st_mode=S_IFREG|0644, st_size=268804, …}) = 0

22089 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb456e000

22089 fstat64(10</mnt/data/var/log/work_s/driver>, {st_mode=S_IFREG|0644, st_size=268804, …}) = 0

22089 _llseek(10</mnt/data/var/log/work_s/driver>, 268804, [268804], SEEK_SET) = 0

22089 write(10</mnt/data/var/log/work_s/driver>, «[2022/07/12 11:19:57] INFO: open»…, 40) = 40

И еще, с -ff больше 10000 файлов получается.

плата подключена к контроллеру PIC

Как хоть подключена?

Через 18 пиновый шлейф. Какие порты ПЛИС подключены я не знаю

По какому протоколу связь с микроконтроллером? Если по uart, то просто ткни rx двух USB uart конвертеров параллельно каждой линии uart. Совершай манипуляции с программой и смотри что при этом летит в uart.

Для других протоколов можно обзавестись логическим анализатором. На мой взгляд, мониторить физический уровень самое простое.

Возможно, там общение через запись-чтение памяти. Тогда strace ничего не увидит.

Не через uart. На сколько понял по логу I2C. Но это не точно. Вот на счет логического анализатора хорошая идея. Сейчас буду рассматривать где взять

90% что через память, так как никаких системных вызовов не видно которые могли что либо читать или писать в порты

теперь прошу помочь со следующим. Смотрите я хочу скомпилировать простую программу:

#include <stdio.h>
#include <string.h> 
#include <stdbool.h>


int main(int argc, char *argv[])
{
    printf("test");
    return 0;
}
 

И так, Пытаюсь через

arm-linux-gnueabihf -Wall -c main.c -o myc

В результате после запуска:

Syntax error: word unexpected (expecting ")")

arm-linux-gnueabihf Дает тот же эффект.

Далее скачал xilinx SDK с огромным трудом через VPN. Так как без VPN не дает.

.\armr5-none-eabi-gcc.exe -Wall -c E:\share\myc\main.c -o myc

Эффект тот же:

Syntax error: word unexpected (expecting ")")

Помогите разобраться с этим

Вобщем к чему я пришел в конце концов, скомпилировать мне удалось, тут вопрос закрыт.

Теперь про дизасемблирования файла, у него в ELF заголовке спецально затерты поля e_shnum и e_shstrndx.

https://i.vgy.me/r5Wgxo.png

Адрес точки входа превышает размер файла 0xd984c. Как ОС находит ее?

Файл размером 860 708 байт. А точка входа аж 890 956

Как решить это?