Что делать raw.githubusercontent.com URLs представляют?
Я хочу научиться использовать rawgit.com для обслуживания других приложений от github.com . Таким образом, у нас есть обычный способ загрузки и установки homebrew на osx.
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" Я не могу найти install файл на GitHub. Где она?
автор: Chris
2 ответов
на raw.githubusercontent.com домен используется для обслуживания необработанных версий файлов, хранящихся в репозиториях GitHub. Если вы перейдете к файлу на GitHub, а затем нажмите Raw ссылка, вот куда вы пойдете.
URL в вашем вопросе ссылается на на master филиала на Homebrew/install хранилище. Остальная часть этой команды просто извлекает файл и запускает ruby на ее содержание.
автор: Chris
raw.githubusercontent.com возвращает необработанное содержимое файлов, хранящихся в github, поэтому их можно загрузить просто на ваш компьютер. Например, страница представляет собой сценарий установки ruby, затем вы получите сценарий установки ruby, который будет понятен вашей установке ruby. Если вы загрузите github.com файл, вы на самом деле будете загружать веб-страницу с кнопками и комментариями, и которая отображает ваш разыскиваемый скрипт в середине — это читаемый человеком, но для компьютера это не скрипт, который может быть выполнен или код, который может быть скомпилирован, но веб-страница для отображения. На этой веб-странице есть кнопка Raw, который отправляет вам соответствующий контент на raw.githubusercontent.com .
чтобы увидеть содержание raw.githubusercontent.com/$/$/$ в обычном интерфейсе github:
- заменить raw.githubusercontent.com простой github.com
- и вы вставляете «blob» между именем РЕПО и именем ветви.
в этом случае, филиал имя «master» (это очень обычное имя ветви), поэтому вы заменяете /master/ С /blob/master/ и так
https://raw.githubusercontent.com/Homebrew/install/master/install https://github.com/Homebrew/install/blob/master/install это обратная сторона поиска файла на Github и нажатия кнопки Raw ссылка.
GitHub
GitHub — это сервис для совместной разработки и хостинга проектов. C помощью GitHub над кодом проекта может работать неограниченное количество программистов из любых точек мира. В GitHub есть система контроля (управления) версий Git: сервис позволяет просматривать и контролировать любые изменения кода любым разработчиком и возвращаться к состоянию до изменений.
«IT-специалист с нуля» наш лучший курс для старта в IT
В целом GitHub — это социальная сеть для разработчиков, в которой можно найти проекты с открытым кодом от других разработчиков, практиковаться в написании кода и хранить свое портфолио.
Проекты в GitHub
Проект в GitHub хранится в репозитории (repository) — коллекции всех изменений создаваемого кода. Если вы будете работать над проектом в одиночку — вам нужно создать новый репозиторий. Если в вашем проекте несколько разработчиков — каждый из них будет клонировать репозиторий первоначального создателя проекта.
Внутри репозитория изменения кода хранятся в виде веток и коммитов.
Коммит (commit) — основной объект разработки, в котором хранятся все изменения кода за итерацию. По сути, это список со всеми актуальными изменениями и ссылка на предыдущую версию коммита. У каждого коммита есть атрибуты: имя, дата создания, автор и комментарии к текущей версии (например, «Создал страницу courses.html» при разработке сайтов с видеокурсами).
Профессия / 8 месяцев
IT-специалист с нуля
Попробуйте 9 профессий за 2 месяца и выберите подходящую вам
Ветка (branch) — указатель на коммит с определенными изменениями. Например, два разработчика взяли коммит, и каждый из них сделал свои изменения в коде, создав по новому коммиту («Создал страницу coursеs.html c личным кабинетом» и «Создал страницу courses.html со свободным доступом на курсы»). Так в проекте появились две ветки с разным кодом: разработчик может выбрать, над каким коммитом ему работать дальше.
Основной веткой проекта, как правило, считается ветка main или master — разработчики создают новые ветки на ее основе. Также можно создать неограниченное количество веток, чтобы вносить новые изменения, не мешая основному проекту.
Слияние веток
Часто разработчики делают параллельные изменения кода. Например, один разработчик работает над внешним видом сайта, а другой занимается размещением контента на нем. По окончании работы ветки каждого из них можно объединить в одну, чтобы создать коммит со всеми внесенными разработчиками изменениями.
Для этого в Git используют функцию pull request (pr). Pull request — это заявка на слияние кода из разных веток. В процессе слияния Git создаст коммит и покажет все изменения в файле кода: добавленные до разветвления строки подсветятся зеленым цветом, удаленные — красным. Так каждый из разработчиков и менеджер проекта увидят, что произошло с кодом после совместной работы над коммитом. Перед окончательным слиянием (merge) все разработчики должны просмотреть изменения кода (code review) и принять их.
Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить
Процесс pull request
Теперь посмотрим на процесс со стороны владельца проекта, который получил новый pull request. Владельцу нужно его обработать и объединить ветку sme-review с master.
Пример ревью кода, где есть разрешение на слияние в главную ветку
Пример ревью кода, где нет разрешения на слияние
Ревью кода
Ревью кода (code review) — процесс обсуждения изменений кода после совместного создания коммита и перед окончательным слиянием. В ревью разработчики оставляют комментарии к строкам с измененным кодом, а в случае ошибок или упущенных моментов предлагают решения по улучшению кода.
После ревью разработчики должны закрыть комментарии и принять предлагаемые изменения (функция approve). Git объединит ветки с помощью функции merge и перенесет созданный коммит в основную ветку main. В истории коммитов останется отметка о проведенном слиянии веток.
Ревью кода, пример
Как учиться работе в GitHub
GitHub — самый популярный сервис для разработки проектов в команде и хранения портфолио собственных проектов. Научиться работе с Git и GitHub необходимо каждому разработчику. Вот несколько материалов, которые помогут новичкам в разработке освоить GitHub:
- шпаргалка по Git/GitHub — вводная статья для новичков с первыми шагами от опытного разработчика;
- Githowto — интерактивный учебник с уроками по основам Git;
- Pro Git — самая популярная книга по работе с Git и GitHub;
- бесплатный видеокурс по основам Git на YouTube;
- список из семи курсов по изучению Git и GitHub.
IT-специалист с нуля
Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.
Статьи по теме:
Что такое GitHub
Простыми словами Гитхаб — площадка, где можно разместить общий проект, совместно управлять всеми изменениями, а в случае неудачи — быстро вернуться к исправной версии. О возможностях GitHub рассказываем в нашем обзоре.
Возможности GitHub
Когда над кодом одновременно работает несколько человек, могут возникать путаницы. Гитхаб автоматически создает копию проекта перед новым сеансом и позволяет каждому члену команды автономно решать локальные задачи без риска испортить общую разработку. После того как правки добавлены, редактор может запросить у других авторов одобрение на внесение новых решений в базу кода. Таким образом, изменения проходят постепенно и по их историям всегда можно отследить что, кем и на каком этапе было внедрено. Чем еще удобен Гитхаб:
- Есть возможность добавить иллюстрацию к текстовому комментарию с описанием проблемы.
- Подсветка синтаксиса помогает быстрее работать с кодом. Сервис может угадать выбранный вами язык программирования, для этого нужно начать строку с трех обратных одинарных кавычек.
- Для создания ссылки на конкретный комментарий достаточно нажать на дату рядом с его названием. Кроме того, можно создать ссылку на конкретный участок кода. Это облегчает процесс совместной работы.
- Следить за состоянием текущих проблем в проекте помогает чекбокс, по мере их устранения можно ставить отметку напротив исправленного участка.
- Можно создать доску проекта, где будут собраны все заметки и ошибки, для эффективного планирования и распределения работы. Некоторые ошибки легче решить, получив комментарии от других авторов.
- Все операции в GitHub атомарны, то есть операция выполняется полностью или не выполняется совсем. Это позволяет избежать повисших операций, которые делают нестабильным все хранилище.
Репозиторий
Репозиторий — это каталог, в котором размещаются все файлы проекта: изображения, видео, аудио и другие данные. Он может быть расположен на общем сервере или в локальном хранилище на устройстве разработчика.
В случае с распределенной системой контроля версий Гитхаб создается общий репозиторий, и каждый член команды сохраняет полный каталог файлов себе. Входе редактирования версии синхронизируются. Это значит, что у всех пользователей есть копия общей базы кода и всех внесенных изменений. Если один из серверов станет недоступным, для продолжения работы достаточно скопировать репозиторий другого участника проекта.
Контроль версий
Обновления в коде происходят на всех этапах жизненного цикла продукта. При создании нового проекта их значительно больше, так как основной функционал только закладывается. Однако они остаются и после запуска разработки: обновляются версии, устраняются ошибки, добавляются новые возможности и т. д. Система контроля версий — Git — помогает отслеживать изменения, внесенные в базу кода. Она сохраняет данные о том, кто внес правки, и позволяет восстановить удаленный код или его версию до редакции. Все изменения внутри репозитория хранятся в виде коммитов и веток.
Чтобы решить задачу автономно, то есть так, чтобы изменения кода не были внесены в общую базу, создается копия репозитория — ветка. В каждой ветке фиксируется история всех изменений, внесенных в участки кода в рамках конкретной задачи. Ветки можно объединять между собой и с центральным хранилищем, предварительно отправив запрос на извлечение. Пользователь отправляет соавторам информационное сообщение о том, что в главный репозиторий были внесены изменения. Другие разработчики могут принять или отклонить корректировки. После открытия запроса можно обсудить проделанную работу с коллегами.
Каждая ветка состоит из нескольких самостоятельных действий или исправлений кода. Такое действие является точкой сохранения проекта и носит название commit. Коммитам присваиваются уникальные идентификаторы и комментарии, позволяющие объяснить другому программисту суть изменений и их назначение.
Безопасность
Использование Git гарантирует подлинность истории изменений исходного кода. Владелец репозитория всегда будет знать, кто и когда вносил правки. Это позволяет быстро обнаружить несанкционированный доступ. Уязвимости могут появиться в открытом коде, поэтому важно проверять свою разработку на их наличие. Приведем несколько инструментов, которые помогут обнаружить уязвимости в коде.
- GuardRails — приложение безопасности, которое можно скачать на маркетплейсе Гитхаба. Оно анализирует код в режиме реального времени, поэтому при выявлении уязвимостей пользователь может оперативно их исправить. Сервис оставляет комментарии в пул реквесты и отображает информацию в панели мониторинга. Приложение поддерживает языки Python, Ruby, JavaScript, Solidity, Go, Java и PHP.
- WhiteSource Bolt — сервис, позволяющий разработчикам создавать сканы репозиториев и находить уязвимости в открытом коде. Приложение сканирует код и создает ошибку при обнаружении угрозы безопасности. Поддерживает Java, Python, PHP, C #, C ++ и другие.
- LGTM — помогает найти потенциальные уязвимости в открытом коде и предотвратить их появление. Поддерживает C, C ++. COBOL, Python, Javascript и Java.
Заключение
GitHub предлагает множество инструментов для работы с кодом и позволяет сделать ее проще. Вы можете объединяться со специалистами из разных стран и совместно работать над проектом, помогая друг другу с исправлением ошибок и ускоряя процесс разработки параллельно решая одну задачу.
Чужой код — потемки: чем опасно скачивание «безобидного» софта с GitHub
Наверное, каждый из тех, кто читает эту статью, хорошо знаком с GitHub — крупнейшим веб-сервисом для хостинга IT-проектов и их совместной разработки. Здесь можно найти почти любой open source-проект. Для компиляции проекта может быть нужен какой-то специфический софт, которого прямо сейчас у пользователя нет, да и сам процесс сборки из исходников требует определенных знаний и опыта. Понимая это, разработчики, помимо исходного кода, очень часто размещают на гите готовые бинарные файлы. Илья Померанцев, специалист по анализу вредоносного кода CERT Group-IB, на примере реального кейса показывает, как использованием непроверенного чужого кода может привести к потере криптовалюты.
Началась эта история с того, что наш клиент загрузил исполняемый файл с одного из доменов GitHub — raw.githubusercontent.com. Наша система TDS Polygon признала объект вредоносным, и он был передан аналитикам.
Источник загрузки — GitHub пользователя под ником faca5. Изучение исходного кода проекта BitTXGenerator, генератора поддельных биткоин-транзакций, не дало никаких результатов. Во всех файлах автором числится некто bunkdeath, датой разработки указан 2010 год, в названиях файлов часто фигурирует DBMS, при этом нет никаких упоминаний про биткоин и криптовалюту.
По имеющимся данным легко найти оригинальный репозиторий и описание оригинального проекта.
Впоследствии нам удалось найти демонстрационное видео автора с использованием BitTXGenerator. Его выложил пользователь под ником Herbert Grün. Интерес привлек кадр, где можно рассмотреть открытые окна автора, в числе которых есть ArtMoney.
Это достаточно известная программа для модификации параметров компьютерных игр. Например, для получения бесконечных виртуальных денег. Это порождает сомнения, действительно ли приложение Electrum отображает реальный баланс кошелька.
Анализ файла
Перейдем к анализу самого сэмпла. Из поведенческих маркеров стало ясно, что перед нами самораспаковывающийся архив, внутри которого находится откомпилированный AutoIt-скрипт:
Анализ в DIE подтвердил эту догадку:
Далее следует обратить внимание на дерево процессов. Мы видим, что файл PXCeHZSXMe.exe, который лежал внутри sfx-архива BitTXGenerator1.2.1.exe, дропнет и запустит скрипт eVMcf.au3, который можно найти среди созданных файлов:
Распаковка
Стадия 1
После декомпиляции и последующей деобфускации PXCeHZSXMe.exe перед нами оказывается незамысловатый AutoIt-скрипт, который извлекает полезную нагрузку из секции ресурсов и сохраняет ее на диск, чтобы потом запустить.
Исполнение начинается с поиска открытых окон антивируса Касперского и Avast. Если они есть, то ВПО засыпает на 20 и 30 секунд соответственно. Видимо, пытается обойти антивирус, но поскольку он таким образом его не обойдет — логика этого действия абсолютно непонятна. Также интересна функция декодирования Base64-строк.
Для этой операции автор решил прибегнуть к помощи Shellcode. Еще одно лишенное логики действие, ведь подобную функцию можно легко реализовать на AutoIt:
В секции ресурсов в закодированном виде хранятся три файла:
- Исполняемый файл AutoIt. Служит для запуска скрипта (HLTH.exe)
- AutoIt-скрипт, содержащий вредоносную функциональность (eVMcf.au3)
- Текстовый файл с именами файлов, в которые будут сохранены AutoIt-скрипт и исполняемый файл AutoIt
Стадия 2
Выполнение скрипта начинается с поиска виртуальной среды, а также открытого диалогового окна Avast. Почему на этот раз диалоговое окно антивируса Касперского перестало пугать автора ВПО — навсегда останется загадкой.
Интересно, каким образом малвара уходит «в спячку». Вернее, то, каким образом она проверяет, что эта «спячка» действительно была. Дело в том, что многие «глупые» песочницы осуществляют перемотку времени. То есть при попытке вызвать WinAPI-функцию Sleep песочница пропускает его, сразу же возвращая управление обратно в поток ВПО. Это отличный индикатор для ее обнаружения. Достаточно взять разницу между системным временем до системного вызова и после него. Однако то, как этот механизм реализован в нашем сэмпле, опять вызывает много вопросов.
Дело в том, что WinAPI-функция GetTickCount возвращает время в миллисекундах, то есть очень точно. Даже если бы код был изначально написан на языке ассемблера, а оптимизация была максимальной — разница во времени никогда бы не была строго равна времени «спячки». Мы же имеем дело с интерпретируемым языком. Это попросту не имеет никакого смысла.
Далее следует опциональная проверка на повторный запуск. Реализована через проверку существования именованного семафора.
Сама полезная нагрузка хранится последней строкой в виде AutoIt-комментария и закодирована при помощи Base64.
Функция декодирования абсолютно аналогична той, что использовалась на первом этапе. Это позволяет предположить, что у обоих скриптов идентичный автор.
Возможно хранение одной или двух полезных нагрузок. Поддерживается инжект в процесс RegSvcs и wscript. Есть поддержка x86 и x64. Опционально возможна обработка пейлоада как batch-скрипта с сохранением его в файл для последующего запуска.
Сама функция инжекта вновь вызывает ряд вопросов. Во всех загрузчиках на AutoIt, которые нам известны, инжект выполняется с помощью Shellcode. В этом же случае вся процедура встраивания в чужой процесс реализована непосредственно на AutoIt. Это вдвойне странно, если вспомнить, как реализовано декодирование Base64.
Стадия 3
После декодирования комментария мы получили два новых исполняемых файла. Первый из них является sfx-архивом. Его оставим на потом.
Второй — это приложение, написанное на Delphi. Главная форма соответствует интерфейсу рекламированного автором софта.
При клике на кнопку Generate Transaction выводится текст Status: Generating Transaction. Затем запускается таймер, по истечении которого появляется один из 16 заготовленных текстов.
Кнопка Broadcast Transaction выведет Status: Broadcasting to all peers и тоже запустит таймер. По итогу будет просто выведена надпись Status: Broadcast successful.
Есть еще несколько таймеров, которые с разной периодичностью выводят захардкоженную информацию о якобы подключенных пирах.
По итогу оказывается, что обещанная автором функциональность — просто фейк.
А теперь зададимся вопросом, зачем же было так пиарить софт, который ничего не делает?
Вот тут мы и вспоминаем про первый файл.
Кое-что он всё-таки делает.
Процедура распаковки аналогична той, что была проведена с исходным файлом. По итогу перед нами оказалось еще одно приложение на Delphi. Главная форма содержит в себе элемент TMemo, большое количество таймеров, которые не имеют обработчиков, и обработчик события onCreate для самой формы.
При создании формы модуль устанавливает перехватчик для буфера обмена. Когда появляется новое содержимое, оно проверяется на соответствие биткоин-кошельку. Если соответствие обнаружено, то содержимое заменяется на кошелек из списка TMemo. То есть происходит подмена адреса кошелька.
Для первого кошелька мы нашли информацию о двух входящих транзакциях на общую сумму $775 (приблизительно 50 000 рублей). Отмечу, что мы также нашли другие экземпляры ВПО с другим набором кошельков.
Это всего лишь один из многочисленных примеров того, чем может закончиться бездумное использование чужого кода, особенно в скомпилированном виде. Да, изучение исходников может занять время, но зато это поможет сэкономить львиную долю нервов, а возможно, и денег.
- GitHub
- malware
- малварь
- малвер
- ВПО
- вредоносное по
- вредоносный код
- вредоносы
- компьютерная безопасность
- компьютерная криминалистика
- cybercrime
- cybercriminalistics
- cybersecurity
- computer security
- Блог компании F.A.C.C.T.
- Информационная безопасность
- Реверс-инжиниринг
- Исследования и прогнозы в IT
- IT-компании