• XSS.stack #1 – первый литературный журнал от юзеров форума

Чистый UnixAPI

Отслеживать
DildoFagins

DildoFagins

TPU unit
Забанен
Регистрация
11.08.2020
Сообщения
4 315
Решения
2
Реакции
5 265
Пожалуйста, обратите внимание, что пользователь заблокирован
Друзья, олдскульные малварщики часто любят хвалиться тем, что их малварка написана на "чистом WinAPI", то есть не использует каких-то "внешних" от системы библиотек и не вкомпиливает их в себя (в том числе и рантаймы самих языков программирования). Я даже недавно статью этому феномену посвятил: https://xss.pro/threads/76417/ - в этом есть что-то прекрасное, но не суть... Внимание вопрос. А что если нам подумать о "чистом UnixAPI"? Какие библиотеки наиболее вероятно предустановлены на подавляющем большинстве Линуксовых машин и на Маках (предлагаю пока подумать только о десктопах и простых мирских серверах, без мобилок и всяких изотерических железок). Нам, очевидно, понадобится шифра (наиболее вероятный кандидат тут скорее всего OpenSSL), нам понадобится библиотека для сжатия данных (наверное, Zlib, не?), нам понадобится библиотека для сети (ну libcurl, видимо), что еще? Какая по вашему опыту вероятность найти такие библиотеки на Линуксах и Маках? Есть какой-то выбор лучше? Еще какие гипотезы? Повторюсь, задача не таскать библиотеки с собой, а по максимуму разжиться тем, что будет наиболее вероятно установлено на любой Юниксовой системе. Какие идеи?
 
"Чистый UnixAPI" понятие не определенное, набор библиотек и их наличие в принципе в системе рандомное, даже в пределах одной glibc присутствуют выебоны на версию этой либы от системы к системе. Совсем низко, до сисколов в никсах я не опускался, хотя ядро там, сишные эти приколы вроде fopen, из коробки дает. А там как всем известно - "Все есть файл". Так что, я думаю, транспортабельную малварь под никсы вполне себе можно.
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
В линуксах пиздец как всё с этим туго.
Вот недавно писал код, который загружал либу через dlopen и брал функции оттуда через dlsym. (Аналоги виндовых LoadLibrary и GetProcAddress)
Компилил на арче со статиком gcc версии 1.12.x (не помню какая точно). Так оно мне варнинг выкинуло, что dlopen в glibc на конечной системе должен быть такой же (то есть glibc должен быть такой же версии).
Запускал на бубунте и дебиане - нигде не завелось. В итоге просто на конечной системе скомпилил и всё заработало. (на дебиане был gcc старее, чем на арче само собой)
Так что если хочешь что-то рабочее, что будет в бинаре, то нужно юзать олдовый компилятор...

waahoo сказал(а):
"Все есть файл".
Этим кстати и можно заменить отчасти
DildoFagins сказал(а):
libcurl
Я так понимаю, если начать писать в файл /dev/tcp/127.0.0.1/8080, то можно установить коннект с 8080 на локалхосте (ip/port и протокол (вероятно) меняется).
Как там с этим файлом правильно взаимодействовать мне сходу сложно сказать. По идее, он должен работать на всех юниксах.

Либо остаётся компилить со статическими либами старым компилем и оно будет работать. Но опять таки до каких-то пределов.
waahoo сказал(а):
до сисколов в никсах я не опускался
Кстати сисколы вроде на всех никсах одни и те же)
По крайней мере я когда читал книжку по асму в линуксе, там всё работало, хотя книга была древняя.
Так что даже если версии гцц не совпадают, то всегда есть сисколлы))))
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Нет, это понятно. Идея в том, чтобы во всем зоопарке найти некий набор библиотек и апи, который можно стабильно использовать почти везде. Например, у меня получалось собирать эльфов, которые работали на всех системах с условием некой общей версии glibc или musl условно 10 летней давности. При этом они не были статически слинкованы ни с чем и были достаточно маленькими (но мало что умели). Понятно, что проще не трахать мозг и статически слинковать пару мегабайт кода, и это будет работать везде, но разве мы ищем легких путей?)

CheckerChin сказал(а):
Я так понимаю, если начать писать в файл /dev/tcp/127.0.0.1/8080, то можно установить коннект с 8080 на локалхосте (ip/port и протокол (вероятно) меняется).
Ну проблема в том, что нужно будет реализовать протоколы поверх простой записи. Например, нужен нам HTTPS, то придется делать HTTP и TLS, для реализации TLS придется делать хотя бы AES и RSA (по-моему, не помню точно), для реализации RSA нужна реализация больших чисел и тд. Как бы, если можно заложиться на libcurl, который уже умеет в HTTPS, то можно не париться, или на тот же OpenSSL.
 
Сомневаюсь что можно скомпилить Elf-файл, который будет запускаться и нормально работать одновременно на всех юниксах.
Даже если сделать статик линковку, то на разных системах могут отличаться фактические номера системных вызовов, сигналов, разные errno коды и т.д.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Bertor сказал(а):
Сомневаюсь что можно скомпилить Elf-файл, который будет запускаться и нормально работать одновременно на всех юниксах
Я имел ввиду Линуксы, на Маках вообще другой формат исполняемых файлов (мачо), Фряху не беру в расчет пока в принципе. На Линуксах номера сисколлов довольно стабильны.
 
DildoFagins сказал(а):
Я имел ввиду Линуксы, на Маках вообще другой формат исполняемых файлов (мачо), Фряху не беру в расчет пока в принципе. На Линуксах номера сисколлов довольно стабильны.
Вряд ли можно придумать что-то универсальнее, чем статик билд с musl. Даже с базовой libc на линухах обычно зоопарк.

Алсо, /dev/{tcp,udp} это вообще фича bash'а, реально в файловой системе таких девайсов нет.
 
Bertor сказал(а):
Вряд ли можно придумать что-то универсальнее, чем статик билд с musl. Даже с базовой libc на линухах обычно зоопарк.

Алсо, /dev/{tcp,udp} это вообще фича bash'а, реально в файловой системе таких девайсов нет.
Кажется musl может сильо проигрывать по производительности в ряде случаев
С практической точки зрения проще скомпилить на чем-то вроде Centos7 c относительно старым glibc, нет?
 
Encommerce сказал(а):
Кажется musl может сильо проигрывать по производительности в ряде случаев
С практической точки зрения проще скомпилить на чем-то вроде Centos7 c относительно старым glibc, нет?
libc для статик линка вообще не подходит. Динамик линк тоже не вариант. У меня была ситуация, когда софт не стартовал, потому что на целевой тачке в libc была не та версия функи memcpy lol.
По производительности к musl претензий не было.
Еще была ситуация, когда на тачке не запускался статик (!) билд. Расследование показало, что софт юзал сисколл epoll_create1, котрого в старом линухе просто не было
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Bertor сказал(а):
Сомневаюсь что можно скомпилить Elf-файл, который будет запускаться и нормально работать одновременно на всех юниксах.
Одно существо из гугла - https://github.com/jart
создало - https://github.com/jart/cosmopolitan
чтото типа - build-once run-anywhere bin format
на видне это совсем мрачный костылина, но на никсах уже чуть лучше смотртся,
а single file webserver - созданый усилиями того же существа дак вообще что-то с чем то
все это конечно колдунское-колдунство, но я думаю вам DildoFagins самое то раз вы стартуете такие топики
вместо того чтоб статически компилеть по 3-4мб бинари - ничего не имею против таких топиков, а даже только за, почему и необсудить.

Вот как существо само это описывает:
Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine.
Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs
natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable.

с хабра по поводу /jart/cosmopolitan:
  1. "Не миллион а тысячу, не в казино а в карты, не выиграл а проиграл". Ни то, ни другое.
    Её изобретение — способ эмулировать PE формат файла как sh скрип, как тут рядом написали. Список новинок на этом заканчивается. Этот Cosmopolitan по сути просто libc + POSIX, т.е цель — создать кросплатформенную libc, а также дать людям инструмент который позволит создавать их собственные кроссплатформенные библиотеки без особого геморроя. Как я понял, про явные ioctl в пользовательском коде речи не идет — на "неверной" платформе они тупо вернут ошибку (но программу не уронят, вроде как).
    Как реализовано конвертирование syscall-ов я и сам толком не разобрался, извиняйте.
    Насчет ABI — безальтернативно x86-64 Linux ABI (без обязательного "фи" в сторону Windows calling convention не обошлось). Ваши функции вот прям обязаны использовать другие соглашения? Для вас есть вариант с трамплинами, которые любезно генерирует компилятор — только пропишите определение функции вот в хэтотъ(https://github.com/jart/cosmopolitan/blob/master/libc/nt/master.sh) файл (именно так реализована привязка в WinAPI).
  2. Как я понял, особых ограничений нет, статическая линковка она и Африке статическая линковка, но все библиотеки (если делают системные вызовы) должны быть специальным образом перекомпилированы чтобы быть совместимыми с этим чудо-форматом. И да, либо x86-64 Linux ABI, либо специальная прослойка типа той что для WinAPI.
  3. Ученый изнасиловал журналиста. x86-64 only, плюс есть способ внедрить qemu в бинарник и эмулировать, эмулировать, эмулировать! Написано что выходит вроде как шустро, но черт его знает, сомнения гложут меня.
  4. Смотрите пункты 1 и 3. Ваш камень x86-64 и система System V Compatible? Поздравляю, вы знаете толк в baremetal в деле! Нет? Для вас есть вариант с qemu, выводы о драйверах и MMU делайте сами.
    Вроде как пишут что умеет в BIOS, то есть можно использовать бинарник в качестве загрузчика на IBM PC.
  5. Смотрите пункты 1 и 2. Не думаю что кто-то будет тратить на это время

зы - написало https://github.com/jart/cosmopolitan - то что раньше было мужчиной а потом стало чем то похожим на женчину или наоборот хз -
потому не знаю как и именовать это, какой так сказать calling convention придерживатся)))
 
Пожалуйста, обратите внимание, что пользователь заблокирован
yellow сказал(а):
все это конечно колдунское-колдунство
Да, я видел, это забавно, но это непрактичная вещь чуть более, чем полностью)

Bertor сказал(а):
Расследование показало, что софт юзал сисколл epoll_create1, котрого в старом линухе просто не было
Ну более низкая версия libc работала бы с более низкой версией ядра Линукс. Смысл в том, что в этом случае, который ты описываешь, libc была слишком новой, чтобы работать на такой старой версии ядра.

Нашел сравнительно интересное направление в этой теме. Компилятор FreePascal https://www.freepascal.org/ не зависит от libc и создает статически слинкованных эльфов под Линуксы. Потыкал чуток и выяснил, что хеллоу ворлд с адекватными настройками оптимизации (LTO там и тд) компилится в 34кб, что в принципе довольно приемлемо, и вряд ли для статической линковки я смогу получить что-то сравнимое по размеру (ну если только на Цэ делать). Что-то не нашел, какую минимальную версию Linux ядра FreePascal ожидает иметь, но зная, насколько это старый проект, скорее всего он будет поддерживать очень старые системы. Еще есть интересный проект https://github.com/LongDirtyAnimAlf/fpcupdeluxe - это гуишка в том числе и для сборки кросс компиляторов (то есть, например, с Венды компилить эльфов под Линукс или мачосов под Маки). Ну и самое главное... у Free Pascal есть библиотека под названием "Indy": https://wiki.freepascal.org/Indy_with_Lazarus 😆 - как бы все более менее складывается в полную картину, но пока я до сих пор не решил, настолько ли я хочу писать проекты под Линуксы и Маки, чтобы страдать с Паскалем (таки бесконечные begin-end'ы, точки с запятыми с поводом и без него и код стайлы из 70ых, я уже слишком избалован современными языками программирования).
 
Пожалуйста, обратите внимание, что пользователь заблокирован
DildoFagins сказал(а):
А что если нам подумать о "чистом UnixAPI"?
Хз, наверное все эти open, read, fork, т.е. системные вызовы. Но в линукс это не особо актуально. В малваре суть "не использует црт, только винапи" было показателем лет 10-15 назад, что автор гуру , а не пишет на компонентах (ну и что такой софт легко криптуется). Сейчас же..я промолчу, потому что обещал.

Bertor сказал(а):
Сомневаюсь что можно скомпилить Elf-файл, который будет запускаться и нормально работать одновременно на всех юниксах.
esxi локеры, работают на большинстве линуксов.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Quake3 сказал(а):
esxi локеры, работают на большинстве линуксов
Если статически слинковать, то проблема может возникнуть только с системным вызовом, которого нет на текущем ядре (если старое или урезанное ядро). Раньше еще была проблема, что более менее современные ELF файлы не хотели загружаться ldd на очень старых системах. Фиксилось вроде одним параметром для линкера, если кому интересно, пишите, могу поискать, как я решал это в старых своих исходниках.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
DildoFagins сказал(а):
Фиксилось вроде одним параметром для линкера, если кому интересно, пишите, могу поискать, как я решал это в старых своих исходниках.
Напиши, может кому пригодится.
Насколько мне известно, подобный софт собирался каким-то древним GCC.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Quake3 сказал(а):
esxi локеры, работают на большинстве линуксов.
как минимум 2 версии делают. все упирается в то что нужно поддерживать старые версии libc (musl тоесть) вплоть до 2 версии ядра.
ESXi в начале жизни базировался на linux kernel нынче там ядро собственой разработки(скорее всего на базе линукса - но суть оно - не linux совместимое, сисколы не те etc etc).
есть еще Xen - который 90% "маминых вымогателей" не умеют обрабатывать - оно из семейства nix-ов также
не все не так очевидно как кажется.
Quake3 сказал(а):
на большинстве линуксов.
если говорить строго про дистры с линуксовым ядром Linux - то на большенстве из них побежит код с некоторыми правками - тот же код что на esxi работал.
но очень часто в крупных сетях у ентерпраза зоопарк осей. недавно приходилось под PowerPC собирать стаб для IBM AIX. В юсе серваки Sun-a много где еще вполне себе процессят банковские транзации, хотя уже и по договору с ораклом. все это начинается от 500кк чистого дохода и в сетьях с лесом от 5к хостов - почти всегда какой-то реликт из 90х все еще трудиться на полную.

>> подобный софт собирался каким-то древним GCC. - я выбираю компилятор так - если ядро определеной версии собирается компилятором -
то и код должен собрираться в рабочую билдачину, если конечно не в коде косяк
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
Quake3 сказал(а):
Напиши, может кому пригодится.
Еле нашел у себя, кто меня за язык тянул я хз. В общем, в ELF формате может быть два вида хеш таблиц для резолюции символов в рантайме: gnu или sysv. Например, если ельф был собран с хеш таблицой в стиле gnu, то он не запуститься на системе, загрузчик которой работает с sysv, и наоборот. Но можно запихать в эльфа сразу две таблицы обоих стилей, для этого нужно указать линкеру параметр --hash-style=both.
 
DildoFagins сказал(а):
Да, я видел, это забавно, но это непрактичная вещь чуть более, чем полностью)


Ну более низкая версия libc работала бы с более низкой версией ядра Линукс. Смысл в том, что в этом случае, который ты описываешь, libc была слишком новой, чтобы работать на такой старой версии ядра.

Нашел сравнительно интересное направление в этой теме. Компилятор FreePascal https://www.freepascal.org/ не зависит от libc и создает статически слинкованных эльфов под Линуксы. Потыкал чуток и выяснил, что хеллоу ворлд с адекватными настройками оптимизации (LTO там и тд) компилится в 34кб, что в принципе довольно приемлемо, и вряд ли для статической линковки я смогу получить что-то сравнимое по размеру (ну если только на Цэ делать). Что-то не нашел, какую минимальную версию Linux ядра FreePascal ожидает иметь, но зная, насколько это старый проект, скорее всего он будет поддерживать очень старые системы. Еще есть интересный проект https://github.com/LongDirtyAnimAlf/fpcupdeluxe - это гуишка в том числе и для сборки кросс компиляторов (то есть, например, с Венды компилить эльфов под Линукс или мачосов под Маки). Ну и самое главное... у Free Pascal есть библиотека под названием "Indy": https://wiki.freepascal.org/Indy_with_Lazarus 😆 - как бы все более менее складывается в полную картину, но пока я до сих пор не решил, настолько ли я хочу писать проекты под Линуксы и Маки, чтобы страдать с Паскалем (таки бесконечные begin-end'ы, точки с запятыми с поводом и без него и код стайлы из 70ых, я уже слишком избалован современными языками программирования).
ради интереса посмотрел, команда file пишет что минимальная версия ядра 2.4
 
Выше в теме упомянули проект Cosmopolitan, в эту сторону и стоит смотреть.
Физическая основа всего - ассемблерная инструкция SYSCALL. Что в винде, что в линухе.
Вот это вот из POSIX и glibc, read open socket и все такое, оно в итоге транслируется в эти инструкции, к которой прилагается номер (вектор), который описывает точку входа и контекст обработчика системного вызова.
Так вот, чувиха подметила, что в *BSD и Linux очень многие системные вызовы имеют одни и те же номера (а некоторые отличаются), сами процессорные инструкции одинаковые, так что мешает выполнять код как есть? если ограничиться узким спектром сисколов. И на этом делает портабельные на все системы программы.
 
На маке я в принципе не представляю как можно работать с чистым юникс апи,и в принципе с таким я не сталкивался ни разу за всю свою разработку там. Если конкретно под юникс апи на маке ты подразумеваешь shell-вызовы как openssl ...,то я видел чистые малвари на bash для мака.соответственно на любом маке начиная с 10.9 если не ошибаюсь предустановлен openssl,curl и тп.
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх