- Регистрация
- 01.10.2015
- Сообщения
- 227
- Благодарностей
- 927
- Баллы
- 93
Приветствую всех! 
В этой статье мы рассмотрим создание профилей для своих проектов, особенности их генерации, проверки, загрузки. Также в статью включены пара полезных сниппетов по этой теме.
Статья рассчитана на «новичков» и «середнячков» в ZennoPoster.
Кратко и под спойлером о том, что такое профили для самых новичков.
Долгое время ZennoPoster имел "базовую" реализацию профилей, в которой учитывались самые основные параметры и настройки виртуального браузера. Интернет не стоит на месте, и сайты обзаводятся всё более и более мощными отслеживающими и анти-бот системами. Базовой реализации профилей ZennoPoster стало не хватать, в результате чего появились варианты решения этой проблемы в виде замечательной статьи «Анонимность в каждый ZennoPoster» в двух частях от @ibred, а потом и готовых шаблонов Spoofer и SpooferJoiner от @YrKa. Однако, если следовать статьям, нужно было внедрять в свои шаблоны достаточно много кода, и суметь сделать это грамотно и удобно для дальнейшего использования (что без хорошего знания кода, опять же, реализовать проблематично). Готовые шаблоны избавляли от этого, но были платными и имели некоторые свои проблемы и неудобства.
К счастью, весной 2018 разработчики ZennoPoster выпустили обновление 5.17, в котором представили новую систему генерацию профилей, которая включала почти все вещи, описанные в статье «Анонимность в каждый ZennoPoster». У пользователей появилось решение «из коробки», для использования которого теперь достаточно проставить несколько «галочек».
Как именно это работает, можно ознакомиться по следующим ссылкам: раз, два.
Тем не менее, на практике для совсем полноценного использования нужно немного больше, чем установка и настройка галочек и ползунков в статическом блоке «Профиль» - и именно такие нюансы предлагаю разобрать.
Рассмотрим создание отдельного шаблона-генератора профилей и сниппета, который будет загружать сгенерированные профили. То есть, по факту, создадим современные аналоги Spoofer и SpooferJoiner.
Отдельный шаблон-генератор профилей удобен тем, что можно заранее сгенерировать пачку профилей с нужными параметрами. Сниппет загрузки профиля предназначен для загрузки профиля и донастройки второстепенных параметров браузера.
Для начала просто настроим базовую версию генератора (т.е. только с «галочками») и посмотрим, что будет.
1. Заходим в статический блок «Профиль», включаем ручной режим на вкладке «Браузер» и включаем все эмуляции.
2. В соседнем блоке «Настройки проекта» желательно сразу ставить «галочку» напротив «Выделенный процесс» (отдельный инстанс под каждый браузерный поток, чтобы не могло быть никаких случайный пересечений между разными инстансами даже в теории).
3. Либо кубиками, либо сниппетом устанавливаем прокси и сохраняем профиль.
Предварительная установка прокси в инстанс нужна для того, чтобы далее в профиль сохранился сам прокси, а также его данные по часовому поясу, геопозиции и IP в WebRTC (в ином случае, соответственно, эти данные в профиль не попадут).
Так как при каждом запуске шаблона ZennoPoster сам генерирует случайный профиль (ещё перед выполнением, учитывая при этом наши настройки из блока «Профиль»), то остаётся только сохранить этот сгенерированный профиль.
Теперь запустим созданный шаблон в ZennoPoster, в результате чего получим сгенерированный профиль.
Создадим ещё один шаблон, который будет представлять проект, в котором будет использоваться созданный профиль.
Помимо непосредственно кода или кубика загрузки профиля рекомендую так же устанавливать прокси, как это делалось в шаблоне-генераторе (только тут после загрузки). Почему – если Вы вдруг начнёте использовать, например, backconnect-прокси с регулярно меняющимся внешним IP, то возможна ситуация, когда данные таймзоны и геопозиции нового IP не будут соответствовать данным старого, сохраненного в профиле (хотя, возможно, в последних версиях ZennoPoster этот момент уже учитывается автоматом).
После загрузки профиля нужно проверить, всё ли правильно у нас эмулируется. Существует достаточно много сайтов для этих целей, лично я предпочитаю проверять по следующим 3, в большинстве случаев этого вполне достаточно.
http://f.vision/
https://whatleaks.com/
https://whoer.net/
У каждого из таких сайтов есть свои особенности и свои косяки, поэтому ограничиваться проверкой по одному точно не стоит.
По «f.vision» обнаружились следующие проблемы.
1. DNS определяются рабочей машины, а не DNS прокси.
2. В WebRTC обнаружился какой-то левый IP, который не является ни IP прокси, ни локальным IP, сгенерированным Zenno.
3. Параметры экрана (Screen) - рабочая область в ProjectMaker оказалась больше, чем сгенерированная Zenno.
Далее, по «whatleaks».
1. DNS также определяются рабочей машины, а не DNS прокси.
2. В WebRTC установлено всё правильно (и IP прокси, и локальный IP, сгенерированный Zenno) – сайт ругается чисто на то, что лучше выключать WebRTC.
3. Passive OS Fingerprint (операционная система, на которой поднят прокси) не соответствует Browser Useragent (операционной системе, которая эмулируется в профиле).
И по «whoer».
1. Всё та же проблема с DNS.
2. Не включён DoNotTrack.
3. Включён Flash.
Помимо того, что подсвечивают ошибками сами сайты, крайне рекомендую проверять конкретные параметры отпечатков браузера. Открываем в ленте «Текущий профиль», вкладку «Профиль», и сравниваем значения с теми, что показывают сайты.
Впрочем, этим заниматься стоит главным образом сразу после перехода на новую версию ZennoPoster (особенно, если меняется первое или второе число в названии версии), так как бывает, что в обновах что-нибудь ломается.
В итоге, проверив профиль на 3 сайтах, имеем 6 возможных проблем самой простой версии генератора профилей.
1. DNS.
Скрыть DNS можно следующей строчкой C#-кода:
2. WebRTC.
Лично я предпочитаю не поручать Zenno установку IP-адресов в WebRTC по следующим причинам:
1) в случае использования backconnect-прокси с регулярно меняющимся внешним IP – при смене в WebRTC может остаться старый IP, что дискредитирует бота в глазах сайта;
2) обычно меня не совсем устраивают диапазоны локальных адресов, которые использует Zenno.
В связи с этим можно вставлять в WebRTC исключительно сгенерированный локальный IP. На мой взгляд, это лучше, чем вообще ничего не вставлять в WebRTC, в то же время шансов спалить что-то лишнего практически нет. Код вставки:
3. Параметры экрана (Screen).
Данная проблема по большей части касалась только PM, так как именно там по умолчанию есть расхождение между сгенерированным рабочим экраном и реальной рабочей областью в PM. Тем не менее, отладка в основном производится в PM, и лучше сразу позаботиться об этом (да и мало ли, вдруг однажды и в ZP забагует).
Рабочая область задаётся с помощью метода SetWindowSize. В последних версиях ZP он как раз стал нормально работать в ProjectMaker.
4. Passive OS Fingerprint
Этот отпечаток эмулируется со стороны провайдера прокси. Соответственно, если необходимо точное совпадение, есть следующие варианты:
1) найти провайдера, который поднимает прокси на нужной ОС;
2) найти провайдера, который предоставляет услуги эмуляции нужной ОС;
3) поднять свои прокси на нужной ОС или сэмулировав нужную ОС (нужны соответствующие знания).
А так, по моему опыту, этот отпечаток далеко не критический, и в большинстве задач можно закрывать глаза (траст с истории и кукисов куда важнее в наше время, и почти всегда перекрывает подобные вещи).
5. DoNotTrack
На мой взгляд, спорный вопрос насчёт того, стоит его включать или нет. Лучше смотреть конкретные случаи, включён ли обычно DoNotTrack у той ЦА, на основе которой Вы генерируете профили. Тем не менее, код включения занесём в шаблон.
6. Flash
Тоже спорный параметр. С одной стороны, его принято отключать в Zenno, с другой – не помню, когда Zenno палил IP или что-то ещё через Flash. Плюс, отключение Flash автоматом означает отключение сэмулированных плагинов – что, в свою очередь, тоже может быть триггером для вызова подозрений. В общем, на какой стул садиться – решать Вам.
Добавляем весь вышеупомянутый код сразу после загрузки профиля и заново загружаем профиль, вновь смотрим сайты. Видим, что все проблемы решены.
Единственное, «f.vision» ругается на DNS, показывая при этом DNS прокси, и совпадение страны прокси со страной DNS. У этого сайта всё ещё встречаются баги (что, впрочем, разработчики не отрицают), поэтому надо сверять с другими. Тем не менее, лично мне этот сайт нравится больше других уже хотя бы тем, что не цепляет счётчики Яндекс.Метрики и Гугл Аналитики, как это делает тот же «whoer».
Ещё небольшая оговорка – код генерации локального IP лучше вставлять в шаблон-генератор, чтобы IP сохранялся непосредственно в профиле и брался из него, а не генерировался заново с каждой новой загрузкой профиля.
Как итог имеем, что с введением системы генерации профилей в ZP 5.17 большая часть эмуляций и отпечатков хорошо работает «из коробки», но в то же время, некоторые мелочи всё равно надо учитывать и дописывать.
Также хочется упомянуть такой момент. На мой взгляд, отдельный шаблон для генерации профилей – вещь очень удобная. Однако, тот момент, что все настройки системы профилей задаются только в статическом блоке «Профиль», и не доступны для редактирования ни кодом, ни кубиками – делает его нормальную реализацию невозможным.
Например, для одной задачи нам нужно подготовить 100 хромовских профилей с версиями 71-73, для другой задачи – 200 профилей FF с версией 63. Вместо того, чтобы иметь возможность вынести эти параметры во входные настройки:
Приходится каждый раз лезть в PM и изменять там вручную. Очень надеюсь, что разработчики что-нибудь придумают, как добавить такую возможность в новых версиях ZP (по крайней мере у меня есть проекты, в которых это востребовано, в тикеты писал, очень жду).
В заключение хотелось бы привести пару сниппетов безопасного сохранения и загрузки профилей.
Бывают случаи, когда профиль может тупо не загрузиться из файла, и в работе шаблона использоваться новый автопрофиль, сгенерированный Zenno при старте шаблона. Если такой профиль сохранить обычным способом после работы, то он перезапишет старый профиль, тем самым ряд сохраненных данных и куки от предыдущих сеансов будут потеряны.
Также при выполнении шаблонов при определенных условиях текущий профиль может «слететь» (например, падение инстанса или некорректная его перезагрузка), в результате, опять же, куки и много данные могут быть потеряны.
Причины таких исходов могут быть разные, как неверная логика, кривой код или баги новых билдов самой ZP (в отношении профилей лично я встречался со всеми этими вещами). Поэтому для более-менее серьёзных браузерных шаблонов – на мой взгляд, такие сниппеты очень полезны.
Загрузка профиля
Сохранение профиля
На этом всё, спасибо за внимание.
PS: демо-шаблоны, которые использовались для написания статьи, прикреплены к теме.
PPS: На всякий случай отмечу, что целью статьи не является показать, как создавать наиболее "защищённые" профили с системой генерации Zenno 5.17+. Цель - показать базовые моменты создания профилей относительно высокого уровня защищенности на основе свежей системы генерации, при минимуме усилий и без случайных фейлов из-за незнания каких-либо базовых нюансов.
Для тех, кого волнует именно задача максимализации всех возможных эмуляций - рекомендую заниматься более глубоким аудитом и допиливанием профилей, с учётом как статей на форуме, так и в других источниках в интернете.
В этой статье мы рассмотрим создание профилей для своих проектов, особенности их генерации, проверки, загрузки. Также в статью включены пара полезных сниппетов по этой теме.
Статья рассчитана на «новичков» и «середнячков» в ZennoPoster.
Кратко и под спойлером о том, что такое профили для самых новичков.
Профиль представляет собой виртальную личность-пользователя и параметры его браузера, работу которого эмулирует ZennoPoster.
К личности относятся такие данные, как логин, пароль, имя, фамилия, возраст и т.п., к параметрам браузера - UserAgent, парметры экрана, отпечатки браузера, куки, прокси и т.п.
С каждым запуском шаблона в ZennoPoster, а также просто с простым запуском ProjectMaker, программа генерирует случайный профиль, который применяется к виртальному браузеру (инстансу).
Профиль можно сохранить в файл соответствующим кубиком, в результате чего на диске появится файл с расширением ".zpprofile", в котором будут храниться все данные виртальной личности и её параметров браузера.
Так как в файле профиля хранятся кэш, куки, различные хранилища сайтов - сайты "узнают" конкретный профиль, который вы загрузили из файла и использовали до этого. Это позволяет, например, не залогиниваться заново на сайтах, на которых шаблон залогинивался с этим профилем в прошлые запуски.
Иными словами, загрузка/сохранение профиля работают по тому же принципу, как и Ваш обычный браузер - т.е. хранит данные, где вы залогинены, на какие сайты заходили и т.п. Тем самым система профилей позволяет эффективно эмулировать реальных пользователей в ZennoPoster.
К личности относятся такие данные, как логин, пароль, имя, фамилия, возраст и т.п., к параметрам браузера - UserAgent, парметры экрана, отпечатки браузера, куки, прокси и т.п.
С каждым запуском шаблона в ZennoPoster, а также просто с простым запуском ProjectMaker, программа генерирует случайный профиль, который применяется к виртальному браузеру (инстансу).
Профиль можно сохранить в файл соответствующим кубиком, в результате чего на диске появится файл с расширением ".zpprofile", в котором будут храниться все данные виртальной личности и её параметров браузера.
Так как в файле профиля хранятся кэш, куки, различные хранилища сайтов - сайты "узнают" конкретный профиль, который вы загрузили из файла и использовали до этого. Это позволяет, например, не залогиниваться заново на сайтах, на которых шаблон залогинивался с этим профилем в прошлые запуски.
Иными словами, загрузка/сохранение профиля работают по тому же принципу, как и Ваш обычный браузер - т.е. хранит данные, где вы залогинены, на какие сайты заходили и т.п. Тем самым система профилей позволяет эффективно эмулировать реальных пользователей в ZennoPoster.
Долгое время ZennoPoster имел "базовую" реализацию профилей, в которой учитывались самые основные параметры и настройки виртуального браузера. Интернет не стоит на месте, и сайты обзаводятся всё более и более мощными отслеживающими и анти-бот системами. Базовой реализации профилей ZennoPoster стало не хватать, в результате чего появились варианты решения этой проблемы в виде замечательной статьи «Анонимность в каждый ZennoPoster» в двух частях от @ibred, а потом и готовых шаблонов Spoofer и SpooferJoiner от @YrKa. Однако, если следовать статьям, нужно было внедрять в свои шаблоны достаточно много кода, и суметь сделать это грамотно и удобно для дальнейшего использования (что без хорошего знания кода, опять же, реализовать проблематично). Готовые шаблоны избавляли от этого, но были платными и имели некоторые свои проблемы и неудобства.
К счастью, весной 2018 разработчики ZennoPoster выпустили обновление 5.17, в котором представили новую систему генерацию профилей, которая включала почти все вещи, описанные в статье «Анонимность в каждый ZennoPoster». У пользователей появилось решение «из коробки», для использования которого теперь достаточно проставить несколько «галочек».
Как именно это работает, можно ознакомиться по следующим ссылкам: раз, два.
Тем не менее, на практике для совсем полноценного использования нужно немного больше, чем установка и настройка галочек и ползунков в статическом блоке «Профиль» - и именно такие нюансы предлагаю разобрать.
Рассмотрим создание отдельного шаблона-генератора профилей и сниппета, который будет загружать сгенерированные профили. То есть, по факту, создадим современные аналоги Spoofer и SpooferJoiner.
Отдельный шаблон-генератор профилей удобен тем, что можно заранее сгенерировать пачку профилей с нужными параметрами. Сниппет загрузки профиля предназначен для загрузки профиля и донастройки второстепенных параметров браузера.
Для начала просто настроим базовую версию генератора (т.е. только с «галочками») и посмотрим, что будет.
1. Заходим в статический блок «Профиль», включаем ручной режим на вкладке «Браузер» и включаем все эмуляции.
2. В соседнем блоке «Настройки проекта» желательно сразу ставить «галочку» напротив «Выделенный процесс» (отдельный инстанс под каждый браузерный поток, чтобы не могло быть никаких случайный пересечений между разными инстансами даже в теории).
3. Либо кубиками, либо сниппетом устанавливаем прокси и сохраняем профиль.
Предварительная установка прокси в инстанс нужна для того, чтобы далее в профиль сохранился сам прокси, а также его данные по часовому поясу, геопозиции и IP в WebRTC (в ином случае, соответственно, эти данные в профиль не попадут).
Так как при каждом запуске шаблона ZennoPoster сам генерирует случайный профиль (ещё перед выполнением, учитывая при этом наши настройки из блока «Профиль»), то остаётся только сохранить этот сгенерированный профиль.
Теперь запустим созданный шаблон в ZennoPoster, в результате чего получим сгенерированный профиль.
Создадим ещё один шаблон, который будет представлять проект, в котором будет использоваться созданный профиль.
Помимо непосредственно кода или кубика загрузки профиля рекомендую так же устанавливать прокси, как это делалось в шаблоне-генераторе (только тут после загрузки). Почему – если Вы вдруг начнёте использовать, например, backconnect-прокси с регулярно меняющимся внешним IP, то возможна ситуация, когда данные таймзоны и геопозиции нового IP не будут соответствовать данным старого, сохраненного в профиле (хотя, возможно, в последних версиях ZennoPoster этот момент уже учитывается автоматом).
После загрузки профиля нужно проверить, всё ли правильно у нас эмулируется. Существует достаточно много сайтов для этих целей, лично я предпочитаю проверять по следующим 3, в большинстве случаев этого вполне достаточно.
http://f.vision/
https://whatleaks.com/
https://whoer.net/
У каждого из таких сайтов есть свои особенности и свои косяки, поэтому ограничиваться проверкой по одному точно не стоит.
По «f.vision» обнаружились следующие проблемы.
1. DNS определяются рабочей машины, а не DNS прокси.
2. В WebRTC обнаружился какой-то левый IP, который не является ни IP прокси, ни локальным IP, сгенерированным Zenno.
3. Параметры экрана (Screen) - рабочая область в ProjectMaker оказалась больше, чем сгенерированная Zenno.
Далее, по «whatleaks».
1. DNS также определяются рабочей машины, а не DNS прокси.
2. В WebRTC установлено всё правильно (и IP прокси, и локальный IP, сгенерированный Zenno) – сайт ругается чисто на то, что лучше выключать WebRTC.
3. Passive OS Fingerprint (операционная система, на которой поднят прокси) не соответствует Browser Useragent (операционной системе, которая эмулируется в профиле).
И по «whoer».
1. Всё та же проблема с DNS.
2. Не включён DoNotTrack.
3. Включён Flash.
Помимо того, что подсвечивают ошибками сами сайты, крайне рекомендую проверять конкретные параметры отпечатков браузера. Открываем в ленте «Текущий профиль», вкладку «Профиль», и сравниваем значения с теми, что показывают сайты.
Впрочем, этим заниматься стоит главным образом сразу после перехода на новую версию ZennoPoster (особенно, если меняется первое или второе число в названии версии), так как бывает, что в обновах что-нибудь ломается.
В итоге, проверив профиль на 3 сайтах, имеем 6 возможных проблем самой простой версии генератора профилей.
1. DNS.
Скрыть DNS можно следующей строчкой C#-кода:
C#:
instance.SetBrowserPreference("network.proxy.socks_remote_dns", true);Лично я предпочитаю не поручать Zenno установку IP-адресов в WebRTC по следующим причинам:
1) в случае использования backconnect-прокси с регулярно меняющимся внешним IP – при смене в WebRTC может остаться старый IP, что дискредитирует бота в глазах сайта;
2) обычно меня не совсем устраивают диапазоны локальных адресов, которые использует Zenno.
В связи с этим можно вставлять в WebRTC исключительно сгенерированный локальный IP. На мой взгляд, это лучше, чем вообще ничего не вставлять в WebRTC, в то же время шансов спалить что-то лишнего практически нет. Код вставки:
C#:
// Установка локального IP в WebRTC
string ipLocal = "192.168.{0}.{1}";
ipLocal = String.Format(ipLocal, Global.Classes.rnd.Next(2), Global.Classes.rnd.Next(2, 255));
// 1-й параметр - локальный IPv4, 2-й - IPv6, 3-й - внешний IPv4, 4-й - режим работы WebRTC
instance.SetWebRTCAdresses(ipLocal, null, null, ZennoLab.InterfacesLibrary.Enums.Browser.WebRTCMode.Emulate);3. Параметры экрана (Screen).
Данная проблема по большей части касалась только PM, так как именно там по умолчанию есть расхождение между сгенерированным рабочим экраном и реальной рабочей областью в PM. Тем не менее, отладка в основном производится в PM, и лучше сразу позаботиться об этом (да и мало ли, вдруг однажды и в ZP забагует).
Рабочая область задаётся с помощью метода SetWindowSize. В последних версиях ZP он как раз стал нормально работать в ProjectMaker.
C#:
instance.SetWindowSize(project.Profile.AvailScreenWidth, project.Profile.AvailScreenHeight);4. Passive OS Fingerprint
Этот отпечаток эмулируется со стороны провайдера прокси. Соответственно, если необходимо точное совпадение, есть следующие варианты:
1) найти провайдера, который поднимает прокси на нужной ОС;
2) найти провайдера, который предоставляет услуги эмуляции нужной ОС;
3) поднять свои прокси на нужной ОС или сэмулировав нужную ОС (нужны соответствующие знания).
А так, по моему опыту, этот отпечаток далеко не критический, и в большинстве задач можно закрывать глаза (траст с истории и кукисов куда важнее в наше время, и почти всегда перекрывает подобные вещи).
5. DoNotTrack
На мой взгляд, спорный вопрос насчёт того, стоит его включать или нет. Лучше смотреть конкретные случаи, включён ли обычно DoNotTrack у той ЦА, на основе которой Вы генерируете профили. Тем не менее, код включения занесём в шаблон.
C#:
instance.SetHeader(ZennoLab.InterfacesLibrary.Enums.Browser.NavigatorField.DoNotTrack, "1");Тоже спорный параметр. С одной стороны, его принято отключать в Zenno, с другой – не помню, когда Zenno палил IP или что-то ещё через Flash. Плюс, отключение Flash автоматом означает отключение сэмулированных плагинов – что, в свою очередь, тоже может быть триггером для вызова подозрений. В общем, на какой стул садиться – решать Вам.
C#:
instance.UsePlugins = false;Добавляем весь вышеупомянутый код сразу после загрузки профиля и заново загружаем профиль, вновь смотрим сайты. Видим, что все проблемы решены.
Единственное, «f.vision» ругается на DNS, показывая при этом DNS прокси, и совпадение страны прокси со страной DNS. У этого сайта всё ещё встречаются баги (что, впрочем, разработчики не отрицают), поэтому надо сверять с другими. Тем не менее, лично мне этот сайт нравится больше других уже хотя бы тем, что не цепляет счётчики Яндекс.Метрики и Гугл Аналитики, как это делает тот же «whoer».
Ещё небольшая оговорка – код генерации локального IP лучше вставлять в шаблон-генератор, чтобы IP сохранялся непосредственно в профиле и брался из него, а не генерировался заново с каждой новой загрузкой профиля.
Как итог имеем, что с введением системы генерации профилей в ZP 5.17 большая часть эмуляций и отпечатков хорошо работает «из коробки», но в то же время, некоторые мелочи всё равно надо учитывать и дописывать.
Также хочется упомянуть такой момент. На мой взгляд, отдельный шаблон для генерации профилей – вещь очень удобная. Однако, тот момент, что все настройки системы профилей задаются только в статическом блоке «Профиль», и не доступны для редактирования ни кодом, ни кубиками – делает его нормальную реализацию невозможным.
Например, для одной задачи нам нужно подготовить 100 хромовских профилей с версиями 71-73, для другой задачи – 200 профилей FF с версией 63. Вместо того, чтобы иметь возможность вынести эти параметры во входные настройки:
Приходится каждый раз лезть в PM и изменять там вручную. Очень надеюсь, что разработчики что-нибудь придумают, как добавить такую возможность в новых версиях ZP (по крайней мере у меня есть проекты, в которых это востребовано, в тикеты писал, очень жду).
В заключение хотелось бы привести пару сниппетов безопасного сохранения и загрузки профилей.
Бывают случаи, когда профиль может тупо не загрузиться из файла, и в работе шаблона использоваться новый автопрофиль, сгенерированный Zenno при старте шаблона. Если такой профиль сохранить обычным способом после работы, то он перезапишет старый профиль, тем самым ряд сохраненных данных и куки от предыдущих сеансов будут потеряны.
Также при выполнении шаблонов при определенных условиях текущий профиль может «слететь» (например, падение инстанса или некорректная его перезагрузка), в результате, опять же, куки и много данные могут быть потеряны.
Причины таких исходов могут быть разные, как неверная логика, кривой код или баги новых билдов самой ZP (в отношении профилей лично я встречался со всеми этими вещами). Поэтому для более-менее серьёзных браузерных шаблонов – на мой взгляд, такие сниппеты очень полезны.
Загрузка профиля
C#:
// Путь к профилю
string profilePath = Path.Combine(project.Path, "1.zpprofile");
// Создавать ли отстутствующие переменные
bool createVars = false;
#region Load
Action<string,bool> Load = (path, createVariables) =>
{
string oldUA = project.Profile.UserAgent;
string oldName = project.Profile.Name;
string oldEmail = project.Profile.Email;
int oldLength = project.Profile.ToString().Length;
project.Profile.Load(path, createVariables);
string newUA = project.Profile.UserAgent;
string newName = project.Profile.Name;
string newEmail = project.Profile.Email;
int newLength = project.Profile.ToString().Length;
if (oldUA == newUA && oldName == newName && oldLength == newLength && oldEmail == newEmail)
{
throw new Exception("Ошибка загрузки профиля. Путь: " + path);
}
};
#endregion
// Загрузка профиля
Load(profilePath, createVars);
C#:
// Путь к профилю
string profilePath = Path.Combine(project.Path, "2.zpprofile");
// Переменные проекта, которые нужно сохранить
var saveVars = new[] { "var1", "var2" };
#region Save
Action<string,string[]> Save = (path, saveVariables) =>
{
if (File.Exists(path))
{
string profilePathAlt = profilePath.Replace(".zpprofile", "_ForCheck.zpprofile");
// Сохранение копии профиля
project.Profile.Save(profilePathAlt, true, true, true, true, true, true, true, true, true, saveVariables);
var infoOld = new FileInfo(profilePath);
var infoNew = new FileInfo(profilePathAlt);
// Допустимая погрешность в байтах
long diff = 5 * 1024;
// Если новый файл тот же или больше, с учётом допустимой погрешности
if (infoNew.Length >= infoOld.Length - diff)
{
// Сохранение профиля и удаление копии
project.Profile.Save(profilePath, true, true, true, true, true, true, true, true, true, saveVariables);
File.Delete(profilePathAlt);
}
else
{
string text = String.Format("Обнаружено уменьшение размера профиля в байтах. Старый размер: {0} Новый размер: {1}. Путь: {2}",
infoOld.Length, infoNew.Length, profilePath);
throw new Exception(text);
}
}
else
{
project.Profile.Save(path, true, true, true, true, true, true, true, true, true, saveVariables);
}
};
#endregion
// Сохранение профиля
Save(profilePath, saveVars);На этом всё, спасибо за внимание.
PS: демо-шаблоны, которые использовались для написания статьи, прикреплены к теме.
PPS: На всякий случай отмечу, что целью статьи не является показать, как создавать наиболее "защищённые" профили с системой генерации Zenno 5.17+. Цель - показать базовые моменты создания профилей относительно высокого уровня защищенности на основе свежей системы генерации, при минимуме усилий и без случайных фейлов из-за незнания каких-либо базовых нюансов.
Для тех, кого волнует именно задача максимализации всех возможных эмуляций - рекомендую заниматься более глубоким аудитом и допиливанием профилей, с учётом как статей на форуме, так и в других источниках в интернете.
- Тема статьи
- Генерация
- Номер конкурса статей
- Одиннадцатый конкурс статей
Для запуска проектов требуется программа ZennoPoster или ZennoDroid.
Это основное приложение, предназначенное для выполнения автоматизированных шаблонов действий (ботов).
Подробнее...
Для того чтобы запустить шаблон, откройте нужную программу. Нажмите кнопку «Добавить», и выберите файл проекта, который хотите запустить.
Подробнее о том, где и как выполняется проект.
Думаю, выводов уже можно прилично сделать.)
