Всем привет. На просторах интернета очень много материала по поводу x86 архитектуры, к сожалению информации по разбору ELF файлов с защитой я найти не смог. Не считая https://habr.com/ru/articles/513944/ но там достаточно примитивно. Пытаюсь расковырять файл https://github.com/ludwig-v/wireles...U2W/_/2020.07.08.1306/Extracted/usr/sbin/hcid от прошивки usb донгла. DIE показывает, что это потенциальный upx, однако сам upx расшифровать его не может. Судя по strace используется /dev/hwaes. Похоже на то, что товарищи форкнули upx и добавили aes (если это конечно aes). Код (Text): execve("/usr/sbin/hostapd", ["/usr/sbin/hostapd"], 0x7eed4dd8 /* 13 vars */) ("/proc/self/exe", O_RDONLY) 3 (PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) (0x76ef7000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) (0x76f3bd8c, 0x76f3cf58, 0) (0x76f3b000PROT_READ|PROT_EXEC) ("/proc/self/exe", "/usr/sbin/hostapd", 4095) (0x7ed853ac, 0x7ed854e0, 0) (0x10000PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) (0x10000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) (0x10000, 0x10134, 0) (PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) ("/dev/hwaes", O_RDWR) 4 (4, _IOC(_IOC_READ|_IOC_WRITE, 0x62, 0x6, 0xc), 0x7ed852a0) (4) (0x76eb2000, 277916) (0x10134, 0x99514, 0) (0x99514, 0x9951c, 0) (0x10000PROT_READ|PROT_EXEC) (0xaa000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) (0xaa000, 0xaac6c, 0) (0xaa000PROT_READ|PROT_WRITE) (0xab000) ("/lib/ld-linux.so.3", O_RDONLY) 4 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\340\n\0\0004\0\0\0"..., 512) (PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) (0x76ec5000PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) (0x76ef4000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1f000) (4) (PROT_READ, MAP_PRIVATE, 3, 0) (3) (0x76ef7000, 286552) () uname({sysname="Linux", nodename="sk_mainboard", ...) (PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) ("/etc/ld.so.preload", R_OK) ("/tmp/lib/tls/v7l/neon/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/tls/v7l/neon/vfp", 0x7ed85488) ("/tmp/lib/tls/v7l/neon/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/tls/v7l/neon", 0x7ed85488) ("/tmp/lib/tls/v7l/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/tls/v7l/vfp", 0x7ed85488) ("/tmp/lib/tls/v7l/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/tls/v7l", 0x7ed85488) ("/tmp/lib/tls/neon/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/tls/neon/vfp", 0x7ed85488) ("/tmp/lib/tls/neon/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/tls/neon", 0x7ed85488) ("/tmp/lib/tls/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/tls/vfp", 0x7ed85488) ("/tmp/lib/tls/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/tls", 0x7ed85488) ("/tmp/lib/v7l/neon/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/v7l/neon/vfp", 0x7ed85488) ("/tmp/lib/v7l/neon/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/v7l/neon", 0x7ed85488) ("/tmp/lib/v7l/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/v7l/vfp", 0x7ed85488) ("/tmp/lib/v7l/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/v7l", 0x7ed85488) ("/tmp/lib/neon/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/neon/vfp", 0x7ed85488) ("/tmp/lib/neon/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/neon", 0x7ed85488) ("/tmp/lib/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib/vfp", 0x7ed85488) ("/tmp/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/tmp/lib", {st_mode=S_IFDIR|0755, st_size=80, ...) ("/lib/tls/v7l/neon/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/tls/v7l/neon/vfp", 0x7ed85488) ("/lib/tls/v7l/neon/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/tls/v7l/neon", 0x7ed85488) ("/lib/tls/v7l/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/tls/v7l/vfp", 0x7ed85488) ("/lib/tls/v7l/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/tls/v7l", 0x7ed85488) ("/lib/tls/neon/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/tls/neon/vfp", 0x7ed85488) ("/lib/tls/neon/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/tls/neon", 0x7ed85488) ("/lib/tls/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/tls/vfp", 0x7ed85488) ("/lib/tls/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/tls", 0x7ed85488) ("/lib/v7l/neon/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/v7l/neon/vfp", 0x7ed85488) ("/lib/v7l/neon/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/v7l/neon", 0x7ed85488) ("/lib/v7l/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/v7l/vfp", 0x7ed85488) ("/lib/v7l/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/v7l", 0x7ed85488) ("/lib/neon/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/neon/vfp", 0x7ed85488) ("/lib/neon/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/neon", 0x7ed85488) ("/lib/vfp/libdl.so.2", O_RDONLY|O_CLOEXEC) ("/lib/vfp", 0x7ed85488) ("/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0h\t\0\0004\0\0\0"..., 512) (3, {st_mode=S_IFREG|0755, st_size=9752, ...) (PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) (0x76f2b000PROT_NONE) (0x76f3a000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) (3) ("/tmp/lib/libm.so.6", O_RDONLY|O_CLOEXEC) ("/lib/libm.so.6", O_RDONLY|O_CLOEXEC) 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\320<\0\0004\0\0\0"..., 512) (3, {st_mode=S_IFREG|0755, st_size=665120, ...) (PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) (0x76eb2000PROT_NONE) (0x76ec2000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa1000) (3) ("/tmp/lib/librt.so.1", O_RDONLY|O_CLOEXEC) ("/lib/librt.so.1", O_RDONLY|O_CLOEXEC) 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\340\27\0\0004\0\0\0"..., 512) (3, {st_mode=S_IFREG|0755, st_size=26600, ...) (PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) (0x76f18000PROT_NONE) (0x76f27000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) (3) ("/tmp/lib/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/lib/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls/v7l/neon/vfp/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls/v7l/neon/vfp", 0x7ed85440) ("/usr/lib/tls/v7l/neon/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls/v7l/neon", 0x7ed85440) ("/usr/lib/tls/v7l/vfp/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls/v7l/vfp", 0x7ed85440) ("/usr/lib/tls/v7l/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls/v7l", 0x7ed85440) ("/usr/lib/tls/neon/vfp/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls/neon/vfp", 0x7ed85440) ("/usr/lib/tls/neon/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls/neon", 0x7ed85440) ("/usr/lib/tls/vfp/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls/vfp", 0x7ed85440) ("/usr/lib/tls/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/tls", 0x7ed85440) ("/usr/lib/v7l/neon/vfp/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/v7l/neon/vfp", 0x7ed85440) ("/usr/lib/v7l/neon/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/v7l/neon", 0x7ed85440) ("/usr/lib/v7l/vfp/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/v7l/vfp", 0x7ed85440) ("/usr/lib/v7l/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/v7l", 0x7ed85440) ("/usr/lib/neon/vfp/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/neon/vfp", 0x7ed85440) ("/usr/lib/neon/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/neon", 0x7ed85440) ("/usr/lib/vfp/libnl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/vfp", 0x7ed85440) ("/usr/lib/libnl-3.so.200", O_RDONLY|O_CLOEXEC) 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\230W\0\0004\0\0\0"..., 512) (3, {st_mode=S_IFREG|0755, st_size=72948, ...) (PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) (PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) (0x76dfd000PROT_NONE) (0x76e10000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) (3) ("/tmp/lib/libnl-genl-3.so.200", O_RDONLY|O_CLOEXEC) ("/lib/libnl-genl-3.so.200", O_RDONLY|O_CLOEXEC) ("/usr/lib/libnl-genl-3.so.200", O_RDONLY|O_CLOEXEC) 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\08\32\0\0004\0\0\0"..., 512) (3, {st_mode=S_IFREG|0755, st_size=23568, ...) (PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) (0x76f00000PROT_NONE) (0x76f10000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) (3) ("/tmp/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) ("/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\320H\0\0004\0\0\0"..., 512) (3, {st_mode=S_IFREG|0755, st_size=92608, ...) (PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) (0x76ddc000PROT_NONE) (0x76deb000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) (0x76ded000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) (3) ("/tmp/lib/libc.so.6", O_RDONLY|O_CLOEXEC) ("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\\f\1\0004\0\0\0"..., 512) (3, {st_mode=S_IFREG|0755, st_size=1251160, ...) (PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) (0x76db0000PROT_NONE) (0x76dc0000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12d000) (0x76dc3000PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) (3) (PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) (0x76efc850) (0x76dc0000PROT_READ) (0x76deb000PROT_READ) (0x76f3a000PROT_READ) (0x76ec2000PROT_READ) (0x76f27000PROT_READ) (0x76ef4000PROT_READ) (0x76efc3f8) (0x76efc400, 12) (32, {sa_handler=0x76dca1d0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x76cb0670, , 8) (SIGRT_1, {sa_handler=0x76dca2b8, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x76cb0670, , 8) У меня сейчас какой-то кривой strace. Видимо его нужно правильно пересобрать. syscall он кроме read не понимает( Собственно хочу понять, а в ту ли сторону я ковыряю, или же это фейк и там фулл кастом пакер, который надо пытаться ковырять с абсолютно другой стороны, а не пытаться править upx.
Поковырялся еще пару часиков. Судя по сигнатурам это 99% измененный upx. В итоге дошел до этого: Код (Text): upx: E:\Stuff\ARMimg_maker: Exception: compressed data violation Код сильно размазан + похоже, что там добавлена антиотладка тк если прицепиться к процессу, то он просто закроется. Однако если запустить его через gdb, то все ок, но любая бряка вне syscall приводит к SIGSEGV Код (Text): 13CB8: got SIGSEGV signal (Segmentation violation) (exc.code b, tid 827) С помощью gdb + catch syscall brk смог получить дамп процесса, однако необходимо патчить вызовы тк все syscall ведут в упакованный бинарик. --- Сообщение объединено, 28 янв 2025 --- Есть большое подозрение, что стоковый gdb работает тк функция /proc/[pid]/status возвращает статус отличный от trace, в отличие от иды или любого другого дебаггера. Код (Text): int __fastcall sub_14100(int a1) { int v2; // r0 int v3; // r0 int v4; // r5 bool v6; // zf int v7; // r4 int v8; // [sp+4h] [bp-174h] BYREF char v9[32]; // [sp+8h] [bp-170h] BYREF char v10[64]; // [sp+28h] [bp-150h] BYREF char v11[272]; // [sp+68h] [bp-110h] BYREF sub_13A8C(v10, 0, 0x40); v2 = sub_13A8C(v11, 0, 0x100); v3 = sub_13C6C(v2); sub_13D14((int)v10, "/proc/%d/status", v3); v4 = sub_13A74(v10, "r"); if ( !v4 ) return 0; v6 = a1 == 1; v7 = a1 - 2; if ( !v6 ) { do { --v7; sub_13A44((int)v11, 0x100, v4); } while ( v7 != 0xFFFFFFFF ); } sub_13A44((int)v11, 0x100, v4); sub_13B1C((int)v11, "%s %d", v9, &v8); sub_13A38(v4); return v8; } Ну и если посмотреть дамп, то тут видно, что он пытается получить статус скорее всего своего процесса. --- Сообщение объединено, 28 янв 2025 --- Статус в иде: Код (Text): Name: ARMimg_maker State: t (tracing stop) Tgid: 870 Ngid: 0 Pid: 870 PPid: 868 TracerPid: 868 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 32 Groups: 0 VmPeak: 192 kB VmSize: 192 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 12 kB VmRSS: 12 kB VmData: 36 kB VmStk: 136 kB VmExe: 20 kB VmLib: 0 kB VmPTE: 4 kB VmSwap: 0 kB Threads: 1 SigQ: 1/963 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000004 SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: 0000001fffffffff CapEff: 0000001fffffffff CapBnd: 0000001fffffffff Cpus_allowed: 1 Cpus_allowed_list: 0 voluntary_ctxt_switches: 2 nonvoluntary_ctxt_switches: 2 Статус в gdb: Код (Text): Name: ARMimg_maker State: D (disk sleep) Tgid: 870 Ngid: 0 Pid: 870 PPid: 868 TracerPid: 868 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 32 Groups: 0 VmPeak: 2004 kB VmSize: 2004 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 660 kB VmRSS: 660 kB VmData: 324 kB VmStk: 264 kB VmExe: 20 kB VmLib: 1308 kB VmPTE: 6 kB VmSwap: 0 kB Threads: 1 SigQ: 0/963 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000004 SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: 0000001fffffffff CapEff: 0000001fffffffff CapBnd: 0000001fffffffff Cpus_allowed: 1 Cpus_allowed_list: 0 voluntary_ctxt_switches: 1974 nonvoluntary_ctxt_switches: 23
Большое спасибо) А какие именно сигнатуры они поломали? Хотелось бы это автоматизировать тк там все файлы этим покрыты. --- Сообщение объединено, 28 янв 2025 --- Ну и самое интересное лежит в файле https://github.com/ludwig-v/wireles...22.12.14.1100/Extracted/usr/sbin/ARMimg_maker --- Сообщение объединено, 28 янв 2025 --- Пробовал восстанавливать сигнатуры с помощью https://github.com/nozominetworks/upx-recovery-tool ну и смотрел сам с помощью https://cujo.com/blog/upx-anti-unpacking-techniques-in-iot-malware/
Сигнатура "UPX!" (байты 55 50 58 21) заменена на 55 22 55 22. В данном файле это сделано 3 раза. После обратной замены распаковывается под Windows обычной командой "upx -d".
Получилось)) Видимо это была старая версия На более новых https://github.com/ludwig-v/wireles...21.07.05.2308/Extracted/usr/sbin/ARMimg_maker так распаковать уже не выходит. Видимо они еще поломали заголовки. --- Сообщение объединено, 28 янв 2025 --- Нашел еще примеры: https://github.com/ludwig-v/wireles....03.1803/Extracted/etc/boa/cgi-bin/server.cgi - если вернуть сигнатуру назад, то распаковка успешна https://github.com/ludwig-v/wireles....08.1306/Extracted/etc/boa/cgi-bin/server.cgi - следующая версия, изменение сигнатуры уже не помогает
Интереснее даже сравнить вот эти файлы: https://github.com/ludwig-v/wireles....16.1452/Extracted/etc/boa/cgi-bin/upload.cgi - файл успешно распаковывается с подменой сигнатуры https://github.com/ludwig-v/wireles....08.1306/Extracted/etc/boa/cgi-bin/upload.cgi - файл НЕ распаковывается Однако если сравнить файлы, то получится вот такое: Разница всего в 100 байт. Такое ощущение, что товарищи заменили все 0x0A на 0x0D 0x0A. --- Сообщение объединено, 28 янв 2025 --- Поменял 0D 0A на 0A. Распаковалось --- Сообщение объединено, 28 янв 2025 --- Чтож следующая эволюция произошла позднее: https://github.com/ludwig-v/wireles....24.1526/Extracted/etc/boa/cgi-bin/upload.cgi - последний файл, который распаковывается успешно https://github.com/ludwig-v/wireles....17.1710/Extracted/etc/boa/cgi-bin/upload.cgi - новый крипт, файл вырос с 14 кб до 22.5. Содержимое уже отличается крайне сильно. Совпадений между версиями нет --- Сообщение объединено, 28 янв 2025 --- Если на старых версиях встречалась строка /etc/bluetooth/temp/addressme /etc/bluetooth/temp/addressit то в новых уже встречается /etc/bluetooth/temp/addressme a7775864862fd6bc7941a434d1cee Последнее это хэш коммита? --- Сообщение объединено, 28 янв 2025 --- А, нет, похоже на хэш файла. --- Сообщение объединено, 28 янв 2025 --- Причем похоже, что у упаковщика есть "злой" режим, которым пакуются самые важные файлы, такие как сама бизнес логика и "лайтовый", которым пакуется все остальное. Кстати от 0D 0A они отказались (с чего бы это вдруг, неужто получили коллизию, где это ломало работающий код?). Ну и в результате имеем: Код (Text): upx: E:\Stuff\ARMimg_maker: NotPackedException: not packed by UPX --- Сообщение объединено, 29 янв 2025 --- Причем особняком стоит файл https://github.com/ludwig-v/wireles...-engineering/blob/master/Reverse/ARMimg_maker он весит 18 кб, вместо 23кб в остальных сборках, но уже содержит в себе новый крипт.
