Что делать 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 – это онлайн-платформа для хранения, управления и совместной работы над проектами с открытым исходным кодом. Это инструмент, который стал неотъемлемой частью современной разработки ПО и широко используется в различных сферах, включая науку, бизнес и государственный сектор.
Проекты, которые хранятся в GitHub, представляют собой коллекцию изменений, сделанных в коде, и хранятся в репозитории. Если вы работаете над проектом самостоятельно, вам нужно создать новый репозиторий. Если же вы работаете в команде, каждый разработчик должен клонировать репозиторий первоначального создателя проекта.
Внутри репозитория код сохраняется в виде веток и коммитов, которые позволяют отслеживать изменения и сохранять их историю.
В данной статье мы рассмотрим основы использования GitHub: от регистрации на платформе до работы с репозиториями и советов по использованию. Вы узнаете, как создавать и управлять своими репозиториями, делать коммиты и пушить изменения, работать с ветками и pull-запросами.
Если вы новичок в использовании GitHub, то этот материал поможет вам освоить основы работы с платформой.
Регистрация и создание репозитория
Чтобы зарегистрироваться на GitHub вам нужно:
1. Перейти на официальный сайт GitHub;
2. Нажать кнопку «Sign up» в верхнем правом углу экрана;
3. Ввести свои данные (имя пользователя, адрес электронной почты и пароль);
4. Нажать кнопку «Create account».
После завершения регистрации вы будете перенаправлены на главную страницу GitHub.
После прохождения регистрации, вы можете создать свой первый репозиторий:
1. На главной странице GitHub нажмите кнопку «+» в верхнем правом углу экрана;
2. Введите название вашего репозитория и описание (опционально);
3. Выберите тип репозитория: Public (открытый для всех) или Private (доступ только для вас и приглашенных вами пользователей);
4. Нажмите кнопку «Create repository».
После этого вы можете добавлять свой код, управлять версиями и работать над проектом вместе с другими людьми.
Работа с репозиторием
Сначала вам нужно настроить репозиторий и после этого вы можете начать работать с ним.
Клонирование репозитория на свой компьютер
Клонирование репозитория на свой компьютер позволит вам работать с кодом локально.
Чтобы клонировать репозиторий на свой компьютер, выполните следующие шаги:
1. Откройте терминал (командную строку) на своем компьютере;
2. Перейдите в папку, в которой вы хотите сохранить репозиторий;
3. Введите следующую команду: git clone https://github.com/ваш-username/ваш-repo.git, где ваш-username — это ваш логин на GitHub, а ваш-repo — это название вашего репозитория.
Добавление изменений в репозиторий
После того, как вы клонировали репозиторий на свой компьютер, вы можете вносить изменения в код и сохранять их на сервере.
Чтобы добавить изменения в репозиторий, выполните следующие шаги:
1. Откройте файлы, которые вы хотите изменить, и внесите нужные изменения;
2. Сохраните файлы;
3. Откройте терминал и перейдите в папку с репозиторием;
4. Введите команду git add ., чтобы добавить все измененные файлы в индекс (staging area).
Коммиты и пушинг изменений в репозиторий
После того, как вы добавили изменения в индекс (staging area), вы можете сделать коммит и отправить изменения на сервер:
1. Введите команду git commit -m «Описание ваших изменений», — т.е. краткое описание изменений, которые вы внесли;
2. Введите команду git push, чтобы отправить изменения на сервер.
Работа с ветками и их слияние
Ветки позволяют вам работать с разными версиями вашего кода. Вы можете создавать новые ветки, переключаться между ними и сливать их, чтобы объединить изменения.
Для создания новой ветки нужно:
1. Открыть терминал и перейти в папку с репозиторием;
2. Ввести команду git branch название-новой-ветки, — т.е. название вашей новой ветки;
3. Ввести команду git checkout название-новой-ветки, чтобы переключиться на новую ветку.
Теперь вы можете работать с новой веткой и вносить изменения в нее без влияния на оригинальную ветку.
Чтобы выполнить слияние веток нужно:
1. Ввести команду git checkout ветка-куда-сливаем, чтобы переключиться на ветку, в которую вы хотите слить изменения;
2. Ввести команду git merge ветка-откуда-сливаем, чтобы слить изменения из другой ветки в текущую ветку.
Теперь изменения из ветки ветка-откуда-сливаем будут объединены с текущей веткой ветка-куда-сливаем.
Создание и закрепление тегов
Теги используются для определения конкретной версии вашего проекта. Это может быть полезно, например, когда вы выпускаете новую версию своего приложения и хотите сохранить состояние кода на момент релиза.
Чтобы создать тег, выполните следующие шаги:
1. Откройте терминал и перейдите в папку с репозиторием.
2. Введите команду git tag название-тега, — т.е. название вашего тега.
Теперь вы создали новый тег в вашем репозитории. Однако этот тег еще не закреплен на конкретном коммите. Чтобы закрепить тег на определенном коммите, выполните следующие шаги:
1. Откройте терминал и перейдите в папку с репозиторием;
2. Введите команду git tag -a название-тега коммит-хэш -m «Описание», где название-тега — это название вашего тега, коммит-хэш — это хэш-код коммита, на который вы хотите закрепить тег, и «Описание» — это описание вашего тега;
Теперь вы закрепили тег на определенном коммите и можете использовать его для определения конкретной версии вашего проекта.
Работа с pull-запросами и ревью кода
Pull-запросы (pull requests) — это механизм, который позволяет отправить изменения в вашем репозитории другим участникам проекта для проверки и слияния с основной веткой. Это особенно полезно, когда вы работаете с командой, так как это позволяет контролировать изменения, которые вносятся в проект.
Чтобы создать pull-запрос, выполните следующие шаги:
1. Перейдите на страницу вашего репозитория на GitHub;
2. Нажмите кнопку «New pull request»;
3. Выберите ветку, в которую вы хотите внести изменения, и ветку, которую вы хотите сравнить;
4. Опишите изменения, которые вы внесли;
5. Нажмите кнопку «Create pull request».
После того, как вы создали pull-запрос, другие участники проекта могут оставить комментарии, задавать вопросы и предлагать изменения. Как владелец репозитория, вы можете просматривать комментарии и принимать решение о слиянии изменений в основную ветку.
Чтобы провести ревью кода, выполните следующие шаги:
1. Откройте pull-запрос на GitHub;
2. Прочитайте описание изменений и просмотрите изменения в коде;
3. Оставьте комментарии на коде, если у вас есть замечания или предложения по улучшению;
4. Если вы уверены, что изменения безопасны и не нарушают функциональность проекта, вы можете сливать изменения в основную ветку, нажав кнопку «Merge pull request».
Однако перед тем, как сливать pull-запрос, важно убедиться, что изменения не противоречат основной функциональности проекта, не вызывают ошибок и не нарушают совместимость с другими частями кода.
Для того, чтобы обеспечить более эффективное ревью кода, можно использовать инструменты, такие как GitHub Actions, которые автоматически выполняют тесты и проверки качества кода. Также можно использовать инструменты для статического анализа кода, такие как SonarQube, которые помогают выявить потенциальные проблемы и улучшить качество кода.
Советы по использованию GitHub
Кроме основных функций, о которых мы говорили выше, есть несколько советов, которые помогут вам использовать GitHub более эффективно:
1. Используйте GitHub Issues для управления задачами и багами. GitHub Issues — это инструмент для отслеживания задач и ошибок, который позволяет упорядочить все ваши задачи в одном месте и упростить их управление;
2.Используйте GitHub Pages для создания своего сайта. GitHub Pages — это бесплатный сервис, который позволяет создавать свой собственный сайт, используя статический контент из вашего репозитория на GitHub;
3.Используйте GitHub Actions для автоматизации вашего рабочего процесса. GitHub Actions — это инструмент для автоматизации задач, который позволяет выполнять скрипты и команды при определенных условиях, таких как создание pull-запроса или изменение кода в репозитории;
4.Не забывайте про безопасность. GitHub предлагает множество инструментов для обеспечения безопасности вашего кода, таких как проверка уязвимостей и анализ кода на наличие ошибок. Используйте эти инструменты для защиты своего кода и данных.
Заключение
В заключение, GitHub является мощным инструментом для работы с проектами и управления кодом. В этой статье мы рассмотрели основные функции GitHub.
Также мы дали несколько полезных советов для более эффективного использования GitHub.
Мы надеемся, что эта статья была полезной для вас и помогла разобраться в основных функциях GitHub.
Ограничения репозитория
Некоторые типы ресурсов репозитория могут быть довольно большими, требуя чрезмерной обработки на GitHub. Для обеспечения выполнения запросов в разумные сроки установлены ограничения.
Большинство приведенных ниже ограничений относятся как к GitHub, так и к API.
Ограничения на текст
GitHub отображает форматированные предварительные версии некоторых файлов, таких как Схемы Markdown и Mermaid. GitHub всегда пытается отобразить эти предварительные версии, если файлы небольшие (обычно менее 2 МБ), но более сложные файлы могут истекать и либо вернуться к обычному тексту, либо не отображаться вообще. Эти файлы всегда доступны в необработанных форматах, которые обслуживаются через raw.githubusercontent.com , например https://raw.githubusercontent.com/octocat/Spoon-Knife/master/index.html . Чтобы получить необработанный URL-адрес файла, нажмите кнопку Необработанный.
Ограничения на различия
Так как различия могут стать очень большими, на различия в фиксациях, запросах на вытягивание и представлениях сравнения налагаются указанные ниже ограничения.
- В запросе на вытягивание общий объем необработанных данных различий не может превышать 20 000 загружаемых строк или 1 МБ.
- Объем необработанных данных различий в одном файле не может превышать 20 000 загружаемых строк или 500 КБ. Для одного файла автоматически загружаются четыреста строк или 20 КБ.
- Максимальное количество файлов в одном различии ограничено 300.
- Максимальное число отрисовываемых файлов (например, изображений, PDF-файлов и файлов GeoJSON) в одном различии ограничено 25.
Некоторые части ограниченного различия могут отображаться, но всё свыше ограничения не отображается.
Ограничения на списки фиксаций
На страницах представлений сравнения и запросов на вытягивание отображается список фиксаций между версиями base и head . Эти списки ограничены 250 фиксациями. Если это ограничение превышено, в примечании сообщается о наличии дополнительных фиксаций (но они не отображаются).
Чужой код — потемки: чем опасно скачивание «безобидного» софта с 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-компании