Привет, Хабр!
Хочу поделиться историей разработки и последним обновлением нашего проекта — ChameleonLab. Это кроссплатформенное десктопное приложение для стеганографии и стегоанализа. С момента первого релиза мы не только добавили новые функции, но и столкнулись с целым рядом интересных технических вызовов, решениями которых и хотим поделиться.
И, конечно же, мы наконец-то готовы представить версии как для macOS, так и для Windows.
Сила сообщества: работа над ошибками
Когда первая версия нашего приложения разошлась по Хабру и торрент-трекерам, мы получили то, на что даже не рассчитывали — шквал обратной связи. Нам стали приходить десятки отчетов о сбоях, скриншоты с багами, подробные описания недочетов и, что самое ценное, — свежие идеи по развитию.
В этот момент мы поняли, что наша программа далека от совершенства. Стало очевидно: в одиночку можно создать работающий инструмент, но сделать по-настоящему качественный и стабильный продукт без сообщества — невозможно.
Именно ваши отзывы и стали главной движущей силой для этого релиза. Каждое исправление и каждая новая функция — это результат нашего с вами диалога.
Что нового в версии 1.4.0.0?
Мы сосредоточились на улучшении пользовательского опыта и расширении аналитических инструментов.
? Светлая и тёмная темы
Понимая, что разработчики и специалисты по безопасности часто работают по ночам, мы добавили полноценную поддержку светлой и тёмной тем. Интерфейс полностью адаптируется, чтобы снизить нагрузку на глаза.
? Локализация (RU/EN)
Приложение теперь доступно на двух языках — русском и английском, с возможностью переключения на лету.
?️ Полная автономность
ChameleonLab не требует подключения к интернету. Вся обработка данных, шифрование и анализ происходят исключительно на вашем устройстве, что гарантирует полную конфиденциальность и безопасность ваших данных.
HASH: Анализатор хешей
Появился новый инструмент — "Анализатор хешей". Его цель — наглядно продемонстрировать лавинный эффект хеш-функций (MD5, SHA256 и др.). Вы можете ввести две почти одинаковые строки и увидеть, как даже изменение одного бита в исходных данных кардинально меняет финальный хеш, с подсветкой различающихся битов.
Под капотом: Трудности и решения
Путь к этому релизу был тернист.
Битва с «зомби»-потоками при закрытии приложения
Собранное под macOS приложение стабильно падало при закрытии с ошибкой EXC_CRASH (SIGABRT). Причина — некорректное завершение фоновых потоков (для пакетного и HEX-анализа), которые оставались работать после закрытия главного окна.
Решение: Мы полностью переписали метод closeEvent, реализовав надежную и последовательную процедуру остановки потоков: вежливый запрос на завершение (.quit()), ожидание с таймаутом в 3 секунды (.wait(3000)), и только в крайнем случае — принудительное прерывание (.terminate()).
Вот фрагмент кода из ui/main_window.py:
# ui/main_window.py
def closeEvent(self, event):
print("Closing application. Stopping threads...")
# 1. Собираем список всех потенциальных потоков
threads_to_stop = []
# ... (код для безопасного сбора всех потоков) ...
# 2. Корректно останавливаем каждый поток
for thread in threads_to_stop:
if thread.isRunning():
thread.quit()
# Ждем до 3 секунд, иначе завершаем принудительно
if not thread.wait(3000):
print(f"Thread {thread} did not stop gracefully. Terminating.")
thread.terminate()
thread.wait()
print("All threads stopped. Closing.")
self.tray_icon.hide()
event.accept()
Это полностью решило проблему с падениями при выходе.
Последняя миля — сборка с PyInstaller
Сборка под Windows преподнесла сюрприз: .exe файл получался очень маленьким и не запускался. Оказалось, что в .spec файле была ошибочная опция exclude_binaries=True, которая запрещала включать в сборку все нужные .dll. После ее удаления и корректной настройки datas все заработало.
Финальный .spec файл для Windows теперь выглядит так:
# ChameleonLab.spec (фрагмент)
a = Analysis(
['main.py'],
datas=[
('chameleon.png', '.'), # Иконка
('styles', 'styles'), # Папка со стилями
('icons', 'icons') # Папка с иконками
],
# ...
)
exe = EXE(
# ...
console=False, # Для GUI-приложения
icon='icons\\cha.ico',
version='version.txt' # Информация о версии из файла
)
Пасхалка: Классика всегда в моде
Какая же программа без "пасхалки"? Чтобы немного отвлечься от анализа данных, мы встроили в приложение классический Тетрис!
Мы решили не делать очевидную кнопку в меню. Игра спрятана. Скажем так: для самых внимательных и любопытных пользователей наш хамелеон в углу экрана не так прост, как кажется...
Системные требования
Чтобы приложение работало стабильно, ваша операционная система должна соответствовать минимальным требованиям.
-
Windows: Windows 10 (версия 1809 и новее) и Windows 11.
Почему? Приложение использует современный графический фреймворк PyQt6 (Qt 6), который официально прекратил поддержку Windows 7 и 8.1 для обеспечения лучшей производительности и доступа к новым API.
-
macOS: macOS 11 (Big Sur) и все более новые версии (Monterey, Ventura, Sonoma и т.д.).
Почему? Аналогично, Qt 6 требует для работы как минимум macOS Big Sur. Это обеспечивает полную совместимость как с компьютерами на базе Intel, так и с новыми Mac на Apple Silicon (M1/M2/M3).
Заключение
Этот релиз — прямое доказательство того, что сделать по-настоящему качественный продукт без помощи сообщества нереально. Мы продолжим прислушиваться к вам и развивать ChameleonLab. Огромное спасибо за ваше участие и помощь!
Скачать:
Скачать последнюю версию на Windows: ChameleonLab 1.4.0.0
Скачать последнюю версию на macOS: ChameleonLab 1.4.0.0
-
Наш Telegram-канал: t.me/ChameleonLab
Будем рады вашим отзывам и вопросам в комментариях!
Комментарии (14)
Demmidovich
28.08.2025 13:52В программе не работает EXIF перенос метаданных. Мне не понятно, как они могут работать с PNG файлами, если этот формат только для JPG?
Lomakn Автор
28.08.2025 13:52Здравствуйте. Все верно! EXIF только для JPG формата. Перенос будет только с DCT методом для файлов JPG. Сейчас работаем над этой реализацией и все тестируем. Мы более подробно расскажем про метод DCT. К сожалению, в этом методе есть проблема: меньшая вместимость контейнера.
Новая версия с DCT стеганографией
Sazonov
Вы молодцы, но вы опять предлагаете задавать вопросы, а потом напишите что у вас нет времени на них отвечать.
Почему вы выбрали виджеты, а не qml?
Почему вы встраиваете svg в код, вместо использования штатного rcc?
Почему у вас бизнес логика (пул потоков) частично реализована в ui логике? И что там за потоки, которым нужно делать terminate? Это же не безопасно.
Кстати, если не использовать qml и встраиваемый браузер, то 6 кутэ вполне себе можно собрать под windows 7, конечно если есть необходимость.
Lomakn Автор
Здравствуйте. Спасибо за интересные вопросы. Мы сначала должны сделать продукт и ответить всем в порядке очереди. Ещё сайт нужно собрать, а потом отвечать на вопросы. Ваш вопрос заслуживает глубокого анализа. Быстро на него дать развёрнутый ответ нельзя.
Lomakn Автор
Под Windows 7 мы не тестировали, у нас его просто нет :)
Lomakn Автор
Отличные, глубокие и очень правильные вопросы! Спасибо, что нашли время их задать. Мы также постарались найти время на их ответы. Это как раз тот уровень технической дискуссии, который помогает делать проекты лучше. Постараюсь ответить на все по порядку.
1. Почему вы выбрали виджеты, а не QML?
Это фундаментальный архитектурный вопрос. Для этого проекта выбор пал на QWidget по нескольким причинам:
Тип приложения: "Steganographia" — это, по своей сути, утилита или "инструмент", а не мультимедийное приложение. Его интерфейс состоит из классических десктопных элементов: кнопки, поля ввода, таблицы, панели с вкладками. Для такого рода "data-driven" интерфейсов, где основное внимание уделяется не анимациям и плавным переходам, а функциональности и плотному расположению элементов, традиционный подход с виджетами часто оказывается более прямым и предсказуемым.
Интеграция с библиотеками: Проект активно использует `matplotlib` для построения графиков ("Научный анализ") и `PIL`/`Pillow` для манипуляций с изображениями. Интеграция `matplotlib` в `QWidget`-приложение через `FigureCanvasQTAgg` — это стандартный и хорошо отлаженный процесс. Хотя интеграция с QML возможна, она часто требует больше "обвязочного" кода для связи между C++/Python бэкендом и frontend-частью на QML.
Прагматизм и скорость разработки: Кодовая база изначально была построена на QWidget, и для данного типа задач этот подход позволяет быстро и эффективно реализовывать новую функциональность. Переход на QML потребовал бы значительных временных затрат на переписывание уже существующих компонентов.
При этом я полностью согласен, что для приложений с более современным, кастомным и анимированным UI, особенно для мобильных платформ, QML был бы более предпочтительным выбором.
2. Почему вы встраиваете SVG в код, вместо использования штатного `rcc`?
Вы абсолютно правы, штатный механизм ресурсов Qt (`.qrc` файлы и компилятор `rcc`) — это более мощный и правильный подход для управления ресурсами в больших проектах.
В данном случае встраивание SVG-кода для двух иконок (солнца и луны) было сознательным упрощением по следующим причинам:
Минимальное количество ресурсов: Речь идет всего о двух крошечных иконках. Встраивание их в код избавляет от необходимости создавать файл `.qrc`, прописывать в нем ресурсы и добавлять в процесс сборки дополнительный шаг компиляции ресурсов (`pyrcc6 ...`).
Самодостаточность модуля: Файл `main_window.py` остается полностью самодостаточным и не требует наличия рядом сгенерированного `resources_rc.py`, что немного упрощает тестирование и отладку отдельных компонентов.
Для проекта, где количество иконок, изображений и других ресурсов исчисляется десятками, я бы однозначно использовал `rcc`. Для двух иконок в небольшом проекте я счел встраивание приемлемым компромиссом в пользу простоты.
3. Почему у вас бизнес-логика (пул потоков) частично реализована в UI? И что за потоки, которым нужно делать `terminate`?
Это самый острый и важный вопрос, который затрагивает как раз те проблемы, с которыми мы боролись.
Бизнес-логика в UI: Вы правы, в идеальной MVC/MVVM архитектуре UI-классы (`page_*.py`) должны быть максимально "тонкими". В этом проекте используется более простой подход, где класс виджета страницы выступает в роли "контроллера" для этой страницы. Он не выполняет саму бизнес-логику (все вычисления, шифрование, анализ вынесены в `workers.py` и `utils`-модули), но он занимается оркестрацией: созданием, запуском и обработкой результатов от фоновых процессов (`workers`). Для приложения такого масштаба это позволяет избежать излишнего усложнения кода и сохранить логику, связанную с одной страницей, внутри одного класса. В более крупных системах я бы определенно выносил эту оркестрацию в отдельные классы-контроллеры.
Потоки, которым нужен `terminate`: Вы совершенно правы — `terminate()` является небезопасным и крайним методом, и его следует избегать любой ценой. Его появление в коде — это результат долгой и сложной отладки постоянных сбоев `QThread: Destroyed while thread is still running` при закрытии приложения.
Проблема: Некоторые фоновые процессы (особенно выполняющие сложные вычисления в `numpy` или `matplotlib`) не всегда корректно реагировали на стандартный сигнал `thread.quit()`, который лишь просит поток завершиться. Если поток в этот момент находится в середине долгой синхронной операции, он не может обработать этот запрос.
Решение-компромисс: Логика в `closeEvent` построена по принципу "от мягкого к жесткому":
1. Сначала мы вежливо просим поток завершиться (`thread.quit()`).
2. Затем мы ждем его завершения полсекунды (`thread.wait(500)`).
3. И только если он не ответил за это время (то есть "завис"), мы вызываем `thread.terminate()`, чтобы принудительно его "убить" и предотвратить гарантированный сбой всего приложения.
Это выбор меньшего из двух зол: риск утечки ресурсов из-за `terminate` против 100% вероятности аварийного завершения программы. В идеальном мире все циклы внутри `worker`-ов должны были бы иметь флаг `is_interruption_requested`, но для внешних библиотек это не всегда возможно реализовать
4. Сборка под Windows 7
Спасибо за полезное замечание! Это действительно ценная информация для разработчиков, которым может потребоваться поддержка старых операционных систем. Qt 6 действительно очень мощный и гибкий фреймворк, и возможность его сборки под Win 7 без QML — это важное преимущество.
Еще раз большое спасибо за ваш фидбэк! Именно такие вопросы помогают посмотреть на проект под другим углом и задуматься об архитектурных решениях.
Sazonov
Если бы я хотел спросить чатгпт - я бы спросил. Это и смешно и грустно. Но всё теперь понятно с вами. Новый печальный тренд Хабра, теперь не только тексты, но и комментарии пишут чат боты.
Я, конечно, догадывался что конструктива не получится. Но не думал что настолько. Предлагать в статье задавать вопросы, а потом выдавать тупые ответы от llm - это как плевок в лицо всем хабраюзерам.
Lomakn Автор
Я очень ценю хороших троллей и всегда стараюсь отвечать взаимностью. Давайте разберем ситуацию с самого начала.
С точки зрения психологии, ваш первый комментарий — это классический пример провокации под маской критики. Вы задали серию очень узких, технических вопросов, требующих максимально развернутого и формального ответа, и сопроводили это сарказмом, что ответов, скорее всего, не будет. Вы сами задали тон и формат общения.
В ответ вы получили именно то, чего ждали — исчерпывающий, структурированный и технический разбор каждого пункта. Такой ответ по своей природе всегда будет казаться "машинным". Ситуация, в которой вы сначала требуете сложного технического отчета, а потом обижаетесь на его "бездушность", выглядит как намеренно созданный парадокс.
А теперь самое интересное. Вы обвиняете в использовании ChatGPT автора проекта, который легко находится в веб-архивах за 2019 год. Тогда, как вы понимаете, нейросетями для комментариев еще и не пахло. Более того, наша команда сама занимается разработкой LLM, что делает ваши обвинения вдвойне ироничными.
Так что конструктива действительно не получилось. Но причина не в мифических ботах, а в том, что его и не было в вашем изначальном запросе. Вы получили ровно тот ответ, на который провоцировали.
Sazonov
Демагогия и враньё. Я в предыдущем вашем посте спросил один конкретный и тривиальный вопрос. По теме вашей статьи. При том что вы написали «задавайте вопросы». Но от вас была отмазка, что вы заняты разработкой сайта и доработкой приложения. Вот пруф: https://habr.com/ru/articles/940180/comments/#comment_28753946
И тут от вас появляется новая «статья», написанная явно ради раскрутки аккаунта. С очередным призывом задавать вопросы и, причём, с примерами кода. Я кратко резюмировал свои вопросы, все по существу вашей статьи, никакого троллинга. И в ответ получаю кучу сгенерированного чатботом текста, который вы даже не потрудились как либо оформить. О каком конструктиве идет речь? И причём тут психология?
Lomakn Автор
Здравствуйте! Спасибо за ваш развернутый и эмоциональный отзыв. Давайте разберем ваши претензии по порядку и перейдем от общих слов к технической конкретике.
Вы обвиняете меня в игнорировании вашего предыдущего вопроса. Действительно, я не дал на него мгновенный и развернутый ответ, так как в тот момент был полностью сфокусирован на запуске проекта. Мой ответ был не «отмазкой», а констатацией факта о приоритетах в моменте. Прошу прощения, если такая форма показалась вам неуважительной.
Теперь по существу. Вы пишете о «сгенерированном чатботом тексте» и «раскрутке аккаунта». Если вы знакомы с принципами продвижения в поисковых системах, то для вас не будет секретом, что релевантность контента, плотность ключевых слов и объем текста по-прежнему играют важную роль. Статьи пишутся не только для узких специалистов, но и для широкой аудитории, которую нужно сначала привлечь, в том числе и с помощью SEO. Это прагматичный подход, обеспечивающий видимость материала.
А теперь, раз уж мы говорим о технологиях, у меня есть к вам встречный вопрос. Вы так уверенно критикуете, словно обладаете глубоким пониманием возможностей и, что важнее, ограничений современных нейросетей. В таком случае, поделитесь своим экспертным мнением:
На что сегодня реально способен ИИ в написании крупного, комплексного ПО с нуля? Не телеграм-бота или простого сайта-визитки, а полноценного enterprise-решения?
Попробуйте с его помощью создать что-то действительно новаторское, а не очередную оболочку для существующего API. Каков будет результат?
Как вы будете использовать ИИ для доработки и рефакторинга существующего, сложного проекта с тысячами строк унаследованного кода?
Сможет ли ИИ исправить ошибки, возникающие в уже скомпилированном ПО, не имея прямого доступа к исходному коду?
И, наконец, ключевой технический вопрос: как вы обойдете фундаментальное ограничение в виде размера контекстного окна («памяти» модели) при работе с задачами, требующими удержания в фокусе всей архитектуры большого проекта?
Было бы очень интересно почитать не просто критику, а конструктивный анализ. Возможно, вам стоит написать свою первую статью на эту тему? Уверен, глубокий технический разбор с практическими примерами будет высоко оценен сообществом.
Я всегда открыт к диалогу по существу.
Sazonov
@moderator - скажите, это нормально что ответы на комментарии строчит бот вместо живого человека?
Lomakn Автор
Очень интересно ... Откуда такие выводы? Мне хочется тоже от Вас получить ответы на заданные мной вопросы ... Факты нужны и развернутые ответы!
Demmidovich
Да нейронки только смогут писать нармальное ПО не раньше чем через пару лет. Они и змейки не могут нормальную рабочую сделать, а сайты так породия !!!