LINUX.ORG.RU
Форум — General  

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

 , ,


0

2

Всем привет. У меня появилась задача но пока что не знаю как с ней справится. Имеются некие готовые платы на ПЛИС от xilinx zynq. На них стоит Linux (ARM). Каждая такая плата подключена к контроллеру PIC. На каждой плате своя программа для работы с этим PIC (И прошивки PIC разные). Эти программы имеют нужные функции для работы с этими PIC контроллерами, вот только эти программы до боли не удобные. Задача у меня такая. Каким то образом посмотреть алгоритм работы этой программы, то есть что программа открывает и записывает, что читает, парсинг действий. Программы пишут Log и я впринципе смогу соотнести что к чему. Вот только я не понимаю как увидить это. Я использовал strace. Но не смог увидеть что куда пишется…. Можете помочь и направить меня в нужное русло. Ситуация как с WEB, берешь браузер, смотришь нужные запросы которые посылаются на сайт и повторяешь. А как делают в таких ситуациях?


Ответ на: комментарий от Flotsky

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

CJ1
() автор топика
Ответ на: комментарий от Flotsky

А вот тут я не много не пойму что происходит. Я скачал с устройства 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 ………………………………

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

CJ1
() автор топика
Ответ на: комментарий от filosofia

Выдает вот так: — 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 +++

CJ1
() автор топика
Ответ на: комментарий от CJ1

File truncated

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

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

Flotsky ★★
()
Ответ на: комментарий от CJ1

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Да, я делал и -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

CJ1
() автор топика

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

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

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от KivApple

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

CJ1
() автор топика

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

#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 ")")

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

CJ1
() автор топика

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

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

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

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

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

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

CJ1
() автор топика
General