Спайдер хаб не работает

Spyder не запускается

У меня есть две среды, в которых Spyder просто не хочет запускаться. Я нажимаю на иконку, там есть курсор ожидания, тогда ничего не происходит. Один из двух совершенно новых, которые я только что сделал сегодня. После установки некоторых пакетов (pip install pytrends был последним) он прекратил открываться.

Примечание. Общий шпион по адресу: C:\ProgramData\Anaconda3\Scripts\spyder.exe запускается, но не для сред.

Это решает проблему:

Просто попробуйте это:

1. удалить pyQt с помощью

conda uninstall pyqt

conda uninstall sip

1. затем установите эти пакеты в следующем порядке

conda install sip

conda install pyqt

conda upgrade spyder

это сработало для меня.

Я не смог запустить ноутбук Spyder и Jupyter из среды анаконды (Mac OS).

У меня работала следующая команда:

Просто удалите tornado и переустановите его.

Я столкнулся с аналогичной проблемой при запуске spyder от навигатора anaconda или терминала conda.
Чтобы решить эту проблему, вам нужно выполнить несколько простых шагов.

откройте анаконду навигатор. (Вы также можете использовать приглашение anaconda и набрать “anaconda-navigator” на консоли)

Откройте приложение и затем следуйте инструкциям, как показано на рисунке.
здесь мы создаем новую среду с питоном версии 3.6. Я думаю, что версия 3.7 нестабильна и не работает должным образом. У меня это сработало, надеюсь на тебя тоже .

см. изображение здесь и следуйте инструкциям.

загрузка ресурсов для первоначальной настройки среды займет некоторое время.

после выполнения шагов запустите приложение. Убедитесь, что сначала запустили среду, чтобы иметь возможность запустить приложение.

Источник

(Python) Spyder не запускается

По какой-то причине мой Python IDE spyder больше не работает. При попытке запустить его не открывается. Попытка

$ spyder в консоли выдает следующую ошибку:

я пытался sudo apt-get install —reinstall spyder и даже sudo apt-get purge spyder && sudo apt-get install spyder но это тоже не помогло. Я также не нашел решение своей проблемы в Интернете.

Может кто-нибудь сказать мне, что не так?

4 ответа

У меня была связанная проблема. Spyder (версия 2.2.5) разбился. Я попытался снова открыть его после перезагрузки компьютера, но ничего не произошло — нажатие на символ в модуле запуска ничего не делало, просто набирая

в командной строке не приводит к запуску графического интерфейса, это также не приводит к сообщению об ошибке. Тем не менее, набрав

в результате графический интерфейс был запущен. Глядя в файл

стало ясно, что следующие строки кода были проблемой:

Итак, какой-то экземпляр spyder был создан ранее и создал файл

что привело к пустому списку аргументов, данных командой

передается в spyder, в результате чего никаких действий:

Следовательно, переименование файла spyder.lock привело к тому, что spyder снова запустился, просто используя приложение запуска или терминал.

Решил проблему (вид):

Сделал sudo gedit /home/USERNAME/.spyder2/.spyder.ini посмотреть на файл, который в основном содержит ваши локальные настройки / настройки spyder. Если вы знаете, что должны говорить ошибочные строки, вы можете просто изменить их.

Поскольку я этого не сделал, я просто удалил всю папку.spyder2. Затем он был создан заново, когда я сделал sudo apt-get purge spyder && sudo apt-get install spyder ,

Просто делаю sudo apt-get purge spyder или же sudo apt-get install —reinstall spyder не будет работать, так как это не влияет на ваш личный файл конфигурации. Вы должны восстановить или удалить файл.spyder.ini вручную.

В моем случае я не получил сообщение об ошибке. Spyder 2.2.5 просто и тихо не запускался, использовал ли я командную строку или меню рабочего стола.

/.spyder2 показал висящую (красную) символическую ссылку [email protected] ,

Удаление этого файла заставило Spyder запускаться как положено.

У меня такая же проблема. Когда я попытался открыть Spyder из терминала, я получил следующее сообщение об ошибке:

Откройте файл spyder.ini, используя nano /home/.spyder2/spyder.ini

Затем удалите [строка 55]: «шрифт / курсив»

Источник

Исследуем Spyder – еще один бэкдор группировки Winnti

В конце прошлого года в нашу лабораторию за помощью обратилась зарубежная телекоммуникационная компания, сотрудники которой обнаружили в корпоративной сети подозрительные файлы. В ходе поиска следов вредоносной активности аналитики выявили образец весьма интересного бэкдора. Его анализ показал, что мы имеем дело с очередным модульным APT-бэкдором, использующимся хакерской группой Winnti.

Последний раз деятельность Winnti попадала в наше поле зрения, когда мы анализировали модификации бэкдоров ShadowPad и PlugX в рамках расследования атак на государственные учреждения стран Центральной Азии. Оба эти семейства оказались схожи концептуально и имели примечательные пересечения в коде. Сравнительному анализу ShadowPad и PlugX был посвящен отдельный материал.

В сегодняшней статье мы разберем бэкдор Spyder — именно так окрестили найденный вредоносный модуль наши вирусные аналитики. Мы рассмотрим алгоритмы и особенности его работы и выявим его связь с другими известными инструментами APT-группы Winnti.

Чем примечателен Spyder

Вредоносный модуль представляет собой DLL-библиотеку, которая на зараженном устройстве располагалась в системной директории C:\Windows\System32 под именем oci.dll. Таким образом, модуль был подготовлен для запуска системной службой MSDTC при помощи метода DLL Hijacking. По нашим данным, файл попал на компьютеры в мае 2020 года, однако способ первичного заражения остался неизвестным. В журналах событий мы обнаружили записи о создании служб, предназначенных для старта и остановки MSDTC, а также для исполнения бэкдора.

Также мы нашли следы запуска других служб со случайными именами, их файлы располагались в директориях вида C:\Windows\Temp\ \ , где random1 и random2 являются строками случайной длины из случайных символов латинского алфавита. На момент проведения исследования исполняемые файлы этих служб отсутствовали.

Интересной находкой стала служба, свидетельствующая об использовании утилиты для удаленного исполнения кода smbexec.py из состава набора Impacket. С её помощью злоумышленники организовали удаленный доступ к командной оболочке в полуинтерактивном режиме.

Исследуемый вредоносный модуль oci.dll был добавлен в вирусную базу Dr.Web как BackDoor.Spyder.1. Это название пришло к нам из артефактов бэкдора. В одном из найденных образцов остались функции ведения отладочного журнала и сами сообщения, при этом те из них, которые использовались при коммуникации с управляющим сервером, содержали строку «Spyder».

Бэкдор примечателен рядом интересных особенностей. Во-первых, oci.dll содержит основной PE-модуль, но с отсутствующими файловыми сигнатурами. Заполнение сигнатур заголовка нулями предположительно было сделано с целью затруднения детектирования бэкдора в памяти зараженного устройства. Во-вторых, полезная нагрузка сама по себе не несет вредоносной функциональности, но служит загрузчиком и координатором дополнительных плагинов, получаемых от управляющего сервера. С помощью этих подключаемых плагинов бэкдор выполняет основные задачи. Таким образом, это семейство имеет модульную структуру, как и другие семейства бэкдоров, используемые Winnti, — упомянутые ранее ShadowPad и PlugX.

Анализ сетевой инфраструктуры Spyder выявил связь с другими атаками Winnti. В частности инфраструктура, используемая бэкдорами Crosswalk и ShadowPad, описанными в исследовании Positive Technologies, перекликается с некоторыми образцами Spyder. График ниже наглядно показывает выявленные пересечения.

Пожалуйста, масштабируйте страницу для чтения надписей, спасибо 🙂

Принцип действия

Бэкдор представляет собой вредоносную DLL-библиотеку. Имена функций в таблице экспорта образца дублируют экспортируемые функции системной библиотеки apphelp.dll.

Функционально образец является загрузчиком для основной полезной нагрузки, которую хранит в секции .data в виде DLL, при этом некоторые элементы DOS и PE заголовков равны нулю.

Работа загрузчика

Загрузка выполняется в функции, обозначенной как malmain_3, вызываемой из точки входа DLL через две промежуточные функции-переходника.

Далее следует стандартный процесс загрузки PE-модуля в память и вызов точки входа загруженного модуля (DllMain) с аргументом DLL_PROCESS_ATTACH, а после выхода из нее — повторный вызов с DLL_PROCESS_DETACH.

Работа основного модуля

В основном модуле значения всех сигнатур, необходимых для корректной загрузки файла, приравнены к нулю.

Кроме того, TimeDateStamp и имена секций также имеют нулевое значение. Остальные значения корректны, поэтому после ручной правки необходимых сигнатур файл можно загрузить для анализа в виде PE-модуля.

Анализ основного модуля затруднен, так как периодически используются нетипичные способы вызова функций. Для хранения и обработки структур используется библиотека UT hash. Она позволяет преобразовывать стандартные C-структуры в хеш-таблицы путем добавления одного члена типа ut_hash_handle. При этом все функции библиотеки, такие как добавление элементов, поиск, удаление и т. д., реализованы в виде макросов, что приводит к их принудительному разворачиванию и встраиванию (inline) компилятором в код основной (вызывающей) функции.

Для взаимодействия с управляющим сервером используется библиотека mbedtls.

Функция DllMain

В начале исполнения проверяется наличие события Global\\BFE_Notify_Event_ , режим исполнения (из конфигурации) и командная строка, затем происходит запуск рабочих потоков.

Модуль имеет встроенную конфигурацию следующей структуры:

Поле hash содержит некое значение, которое может являться идентификатором. Это значение используется при взаимодействии с управляющим сервером и может быть представлено в виде строки b2e4936936c910319fb3d210bfa55b18765db9cc, которая по длине совпадает с SHA1-хешами.

Поле string содержит строку из одного символа: 1.

CA_cert — сертификат центра сертификации в формате DER. Он используется для установки соединения с управляющим сервером по протоколу TLS 1.2.

В функции DllMain предусмотрено создание нескольких рабочих потоков в зависимости от ряда условий.

Основной поток — thread_1_main

Поток запроса нового сервера — thread_2_get_new_C2_start_communication

Поток исполнения зашифрованного модуля — thread_4_execute_encrypted_module

Основной поток

Вначале бэкдор проверяет версию ОС, затем подготавливает структуру для инициализации функций и структуру для хранения некоторых полей конфигурации. Процедура выглядит искусственно осложненной.

В структуру funcs_struc типа funcs_1 заносятся 3 указателя на функции, которые будут поочередно вызваны внутри функции init_global_funcs_and_allocated_cfg.

В функции set_global_funcs_by_callbacks происходит вызов каждой функции-инициализатора по очереди.

Общий порядок формирования структур выглядит следующим образом:

1) каждой функции передаются две структуры: первая содержит указатели на некоторые функции, вторая — пустая;

2) каждая функция переносит указатели на функции из одной структуры в другую;

3) после вызова функции-инициализатора происходит очередное перемещение указателей на функции из локальной структуры в глобальный массив структур по определенному индексу.

В итоге после всех нестандартных преобразований получается некоторое количество глобальных структур, которые объединены в один массив.

В конечном итоге вызов функций можно представить следующим образом.

Сложные преобразования — копирование локальных структур с функциями и их перенос в глобальные структуры — вероятно, призваны усложнить анализ вредоносного образца.

Затем бэкдор при помощи библиотеки UT hash формирует хеш-таблицу служебных структур, ответственных за хранение контекста сетевого соединения, параметров подключения и т. д.

Фрагмент кода формирования хеш-таблицы.

Стоит отметить, что здесь располагается значение сигнатуры, которое позволяет определить используемую библиотеку: g_p_struc_10->hh.tbl->signature = 0xA0111FE1;.

Для рассматриваемого бэкдора характерно распределение значимых полей и данных по нескольким создаваемым для этого структурам. Эта особенность при анализе затрудняет создание осмысленных имен для структур.

После подготовительных действий переходит к инициализации подключения к управляющему серверу.

Инициализация соединения с управляющим сервером

После ряда подготовительных действий бэкдор разрешает хранящийся в конфигурации адрес управляющего сервера и извлекает порт. Адреса в конфигурации хранятся в виде строк: koran.junlper[.]com:80 и koran.junlper[.]com:443. Далее программа создает TCP-сокет для подключения. После этого создает контекст для защищенного соединения и выполняет TLS-рукопожатие.

После установки защищенного соединения бэкдор ожидает от управляющего сервера пакет с командой. Программа оперирует двумя форматами пакетов:

пакет, полученный после обработки протокола TLS, — «транспортный» пакет»;

пакет, полученный после обработки транспортного пакета, — «пакет данных». Содержит идентификатор команды и дополнительные данные.

Заголовок транспортного пакета представлен следующей структурой.

Данные располагаются после заголовка и упакованы алгоритмом LZ4. Бэкдор проверяет значение поля signature, оно должно быть равно 0x573F0A68.

После распаковки полученный пакет данных имеет заголовок следующего формата.

Поля tag и id в совокупности определяют действие бэкдора, то есть обозначают идентификатор команды.

Данные структуры заголовков используются в обоих направлениях взаимодействия.

Порядок обработки команд сервера:

отправка информации о зараженной системе;

обработка команд по идентификаторам.

В структуре, отвечающей за взаимодействие с управляющим сервером, есть переменная, которая хранит состояние диалога. В связи с этим перед непосредственным выполнением команд необходимо выполнение первых двух шагов, что можно рассматривать как второе рукопожатие.

Этап верификации

Для выполнения этапа верификации значения полей tag и id в полученном от управляющего сервера первичном пакете должны быть равны 1.

Процесс верификации состоит в следующем:

1. Бэкдор формирует буфер из 8-байтного массива, который следует после заголовка пакета и поля hash_id, взятого из конфигурации. Результат можно представить в виде структуры:

2. Вычисляется SHA1-хеш данных в полученном буфере, результат помещается в пакет (после заголовка) и отправляется на сервер.

Отправка информации о системе

Следующий полученный пакет от управляющего сервера должен иметь значения tag, равное 5, и id, равное 3. Данные о системе формируются в виде структуры sysinfo_packet_data.

Поле sysinfo_packet_data.id содержит константу — 0x19C0001.

Примечателен процесс определения бэкдором значений MAC-адреса и IP-адреса. Вначале программа ищет сетевой интерфейс, через который прошло наибольшее количество пакетов, затем получает его MAC-адрес и далее по нему ищет IP-адрес этого интерфейса.

Версия ОС кодируется значением от 1 до 13 (0, если возникла ошибка), начиная с 5.0 и далее по возрастанию версии.

Источник