Слив Поиск забытых BTC кошельков
Дополнительные параметры
Запускаем установщик, обязательно кликаем на галку (на фото) 
Кликаем Installl Now и ждём завершения установки
Когда увидим такое сообщение, кликаем Close, Python установлен
Кликаем на кнопку Code, после чего на кнопку Download ZIP и качаем скрипт
Получаем вот такой путь /bitgen-v3-main/Bitgen-v3
Установка модулей
Запускаем https://install_modules.bat, ждём завершения установки
Вам могут вылезать ошибки, предупреждения, игнорируем
Можем установить все модули вручную, нажав WIN+R и написав в поле cmd
После, построчно введите в консоли эти команды:
Настройка скрипта
Открываем https://main.py через любой текст. редактор
Где находятся настройки:
В тг идём в бота @BotFather, пишем ему команду /newbot
Пишем боту любое имя, например BTCLOGSBOT
Теперь пишем боту любой тэг, например kdjd_logs_bot
Бот присылает нам сообщение с токеном (выделен красным на фото)
Копируем его и вставляем в 21 строку между «»
Далее идём в бота @userinfobot и пишем ему любое сообщение
В сообщении от бота копируем цифры после текста Id: и вставляем в 22 строку
Остальные настройки можно не менять
Для запуска бота открываем файлик https://run.bat и наслаждаемся работой
Так-же можно запустить скрипт написав в cmd
cd /bitgen-v3-main/Bitgen-v3python https://main.py 
Всё супер,бот работает.
Как убрать бан по IP?
Просто качаем VPN / подключаемся к проксям
Мобильные устройства изнутри. Разметка памяти, структура файлов описания и разметки памяти
1. Введение
Как оказалось, разметка физической памяти мобильных устройств (МУ) это малоописанный раздел знаний, необходимых разработчику. Т.к. память существует во всех устройствах, созданных на основе микропроцессоров или микроконтроллеров, а их уже миллиарды, то это еще и очень-очень востребованный раздел знаний.
Эта статья посвящена аспектам разметки памяти только МУ, т.к. именно здесь существует тесно свитый разными производителями клубок из файлов описания разметки при почти полном отсутствии теоретических данных о структуре самих этих файлов.
Разметка физической памяти МУ формируется на основании таблиц или списков описаний параметров разделов памяти. Практически каждая фирма-производитель МУ имеет свою форму (структуру) этих таблиц. Тем не менее, все описания параметров разделов имеют много общего, что позволяет рассматривать их в едином контексте.
На основе таблиц описаний затем формируются файлы разметки памяти, которые в виде образов разделов прошиваются непосредственно в память МУ.
2. Что такое разметка памяти?
Подробнее, что представляет собой разметка памяти МУ и для чего это нужно, можно посмотреть, например, в [1]. Вот еще одна публикация, в которой доступно объясняется устройство памяти и ее разметка [2].
Если кратко, то разметка памяти, как процесс, выполняет распределение всего объема внутренней физической памяти МУ на отдельные разделы, которые могут иметь разное функциональное назначение, вплоть до разных файловых систем, и разные права доступа. Это позволяет выделить в памяти отдельно области для хранения данных и работы пользователя, отдельно для работы операционной системы, шифровать или форматировать разделы при необходимости и независимо друг от друга и т.д.
При выполнении разметки разработчик МУ должен придерживаться некоторых правил, которые называются схемами разметки памяти. Схема разметки описывает размещение всех разделов физической памяти: их очередность, смещение и название, т.е. метку или имя раздела. Могут указываться и другие параметры: его размер, тип, регион, флаги и т.п.
Для выполнения разметки памяти используют файлы двух видов: текстовые и бинарные (двоичные RAW-файлы).
Текстовый файл представляет собой перечень (список) всех разделов памяти, каждая запись которого содержит описание основных параметров этих разделов. Он используется при выполнении нескольких операций:
Процесс создания разметки памяти можно описать следующим алгоритмом:
3. Схемы разметки памяти
Чаще всего применяются две схемы разметки памяти: Mbr и Gpt.
При любой схеме разметки памяти первым по порядку разделом в пользовательском регионе МУ всегда должен быть раздел разметки (Mbr, Gpt, Parameter).
3.1.Mbr-схема разметки памяти
Согласно Mbr-схеме память МУ представляется как последовательность разделов, дополненная главной загрузочной записью или Mbr (Master Boot Record), содержащей таблицу описания разделов. Mbr физически располагается в первом (нулевом) секторе памяти МУ:
рис.1. Главная загрузочная запись.
Mbr содержит сигнатуру, т.е. признак Mbr, и непосредственно саму таблицу описания разделов.
Внутреннее строение Mbr [3] позволяет разместить в ней только 4 записи о разделах, что является в современных условиях существенным недостатком. Если требуется разбить память на большее количество разделов, то используется дополнительная (расширенная) загрузочная запись Extended Boot Record (Ebr). При этом в Mbr вместо записи об одном из разделов помещается запись о дополнительном (extended) разделе, содержащем только Ebr.
Сама Ebr устроена аналогично Mbr, и использовать ее нужно точно также. Т.е., если при заполнении таблицы Ebr опять не хватает места под записи о разделах, то создается следующая Ebr-таблица и т.д.
Mbr и все Ebr могут помещаться в отдельные файлы-образы, которые размещаются и прошиваются в соответствующих отдельных разделах памяти. При этом все файлы, содержащие Ebr, имеют имена нумерованные последовательно: Ebr1, Ebr2,…
При другом варианте Ebr помещаются в один файл-образ последовательно, тогда этот образ, соответственно, размещается в одном Ebr-разделе памяти.
3.2. Gpt-схема разметки памяти
Gpt-схема разметки (GUID Partition Table) является частью EFI (Extensible Firmware Interface) — стандарта, используемого вместо BIOS для разметки памяти и загрузки ее разделов. Переход на другой формат описания разделов позволил устранить самый существенный недостаток Mbr-схемы — малое число разделов, т.к. в таблице описания разделов Gpt можно разместить до 128 разделов. Структуру самих таблиц можно посмотреть в [4].
Согласно Gpt-схеме память МУ тоже представляет собой последовательность разделов, необходимых для работы МУ, дополненную спереди Gpt-таблицей описания разделов, называемой основной. При этом после всех разделов размещается дополнительная Gpt-таблица, называемая резервной. Такое расположение таблиц, теоретически, повышает надежность разметки, т.к. при сбое или порче основной Gpt-таблицы ОС может использовать для работы, или восстановления основной, резервную.
4. Таблицы описания разделов памяти
Таблицы описания разделов памяти МУ содержат информацию о всех разделах, необходимую для создания разметки памяти. Каждая строка (запись) таблицы описывает один раздел и содержит, как правило, следующие параметры:
4.1. Parameter-файл
Прошивка МУ на чипе RK содержит текстовый файл PARAMETER, который предназначен для описания построения (настройки и загрузки) физической памяти блочного типа. Причем использовался он и на ОС LINUX.
Оригинальный вид содержимого файла PARAMETER для МУ Cube u30gt-M приведен ниже:
FIRMWARE_VER:4.0.4
MACHINE_MODEL:U30GT-M
MACHINE_ID:007
MANUFACTURER:RK30SDK
MAGIC:0x5041524D
ATAG:0x60000800
MACHINE:3066
CHECK_MASK:0xFF
KERNEL_IMG:0x60408000
RECOVERY_KEY:0,4,C,6,0
COMBINATION_KEY:0,4,C,6,0
CMDLINE: console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00008000@0x00008000( boot),0x00008000@0x00010000(recovery),0x000C0000@0x00018000(backup),0x00040000@0x000D8000(cache),0x00200000@0x00118000(userdata),0x00002000@0x00318000(kpanic),0x00120000@0x0031A000(system),-@0x0043A000(user)
4.1.1. Описание параметров файла PARAMETER
Файл PARAMETER может содержать следующие параметры:
4.1.2. Параметр CMDLINE и его возможности
Формат командной строки, т.е. CMDLINE, имеет следующий вид:
CMDLINE: ключ1=значение1 [ключ2=значение2], где
mtddef — описание разметки памяти устройства блочного типа (БУ). Если МУ содержит несколько БУ, то может содержать и несколько описаний, которые располагаются последовательно без промежутка и разделяются символом «точка с запятой».
Описание разметки памяти каждого БУ имеет следующее строение:
Параметр part_size описывает размер раздела в блоках, выраженный в hex-системе счисления. Если вместо размера указан символ «минус» («-«), это означает максимально возможный размер, т.е. до физического конца памяти.
Параметр part_offset представляет смещение раздела в блоках, выраженный в hex-системе счисления. Смещение всегда выравнивается на границу в 0х1000.
Параметр label (имя раздела) это строковый идентификатор раздела, заключенный в круглые скобки, например, (boot).
Параметр flag (флаг) может принимать только одно значение — «ro«, означающее, что раздел предназначен только для чтения. Отсутствие флага означает, что раздел доступен для чтения и записи.
Несколько очень важных замечаний:
4.2. Rawprogram0-файл
Файл rawprogram0.xml предназначен для описания разметки памяти МУ на основе чипов Qualcomm и имеет следующее строение:
Рис.3. Вид файла rawprogram0.xml от Lenovo s90a
Он содержит таблицу описания параметров разделов в виде xml-элементов типа program. Все разделы перечисляются строго в порядке их размещения в памяти МУ.
Каждый xml-элемент может содержать следующие xml-атрибуты:
4.3. Ota-файл
Это единственный файл описаний, который описывает строение файла прошивки, а не разметку памяти.
Например, файл ota-обновления МУ на чипе МТ6582 фирмы MTK, имеет следующий вид:
Он содержит описание тех разделов, чьи образы присутствуют в файле прошивки для ota-обновления, каждое из которых имеет следующее строение:
label part_offset, где
4.4. Scatter-файл
Файл scatter содержит описание разметки памяти МУ, построенных на основе чипов МТК. Существует три версии структуры этого файла, что связано с историческим развитием возможностей как самих чипов памяти, так и чипов процессоров фирмы MTK.
4.4.1. Версия 1
Файл описаний разметки первой версии содержит список описаний каждого раздела памяти, и имеет следующий вид:
Рис.5. Scatter-файл первой версии
Каждый раздел памяти описывается следующей структурой:
Такое описание разделов памяти предполагает, что:
4.4.2. Версия 2
Scatter-файл описаний разметки памяти второй версии содержит заголовок и непосредственно таблицу описаний каждого раздела памяти. Он имеет следующий вид:
Рис.6. Scatter-файл второй версии
Заголовок содержит параметры прошивки целиком и содержит следующие поля:
Для чипов МТ6572-МТ6577 в качестве значения Begin Address флешером используется значение поля linear_start_addr, отражающее истинное смещение раздела в памяти (представляющей один сплошной регион), т.к. чипы не умеют работать с регионами, а используемая память имела только один регион для размещения разделов. При этом значение поля «physical_start_addr» всегда равно нулю.
Чипы МТ6582 уже умеют работать с регионами, но используемая память еще имеет только один регион. Поэтому в качестве значения Begin Address флешером уже используется значение поля physical_start_addr, отражающее смещение раздела в пределах регионов, создаваемых в памяти программно, а поле linear_start_addr содержит значения смещения от начала чипа памяти.
В связи с тем, что, начиная с чипа МТ6592, МУ от МТК используют полноценную работу с регионами памяти, то для чипов МТ6592 и выше флешером в качестве значения Begin Address используется значение поля physical_start_addr.
Значение поля Format Length флешер всегда получает из поля partition_size.
5.Файлы разметки памяти.
Файлы разметки памяти содержат образ раздела разметки памяти МУ. Их структура зависит от схемы разметки (Gpt или Mbr) и от назначения, например, резервные файлы разметки Pmt или Gpt.
Встречаются следующие виды файлов разметки:
5.1. Mbr-файл
Mbr-файл представляет собой образ раздела разметки памяти по Mbr-схеме, имеющий размер 1 сектор, т.е. 512 байт.
В МУ применяется так называемая классическая структура Mbr-файла [5]:
Рис.7. Классическая структура Mbr-файла
Каждая запись параметров раздела содержит следующие поля, значения которых отличается от принятых в классической структуре Mbr:
Поле IsBoot имеет размер 1 байт и используется для обозначения активности раздела, старший бит которого указывает на загрузочный раздел:
Поле Type имеет размер 1 байт и используется производителями МУ для обозначения типа описываемого раздела. Обозначение типа раздела у разных производителей могут отличаться, но есть некоторые общепринятые значения:
Поле Offset имеет размер 4 байта и содержит значение смещения раздела, выраженное в секторах.
Поле Size имеет размер 4 байта и содержит значение размера раздела, выраженное тоже в секторах.
По адресу 0x01FE расположена сигнатура Mbr-файла, имеющая значение 0xAA55.
5.2. Ebr-файл
Ebr-файл представляет собой образ расширенного раздела разметки памяти, выполненной по Mbr-схеме. Он имеет такое же строение и размер, как и Mbr-файл:
Рис.8. Классическая структура Ebr-файла
Отличия заключаются в том, что в Ebr-файле признак активности всегда установлен в 0, да и этих файлов, при необходимости, может быть уже не один, а 63. Соответственно, для их размещения тоже понадобится создавать до 63 разделов, что приводит к расточительному расходованию памяти МУ.
Если разделов памяти относительно немного, например, как в МУ Star Z2, то используются отдельные файлы Ebr1 и Ebr2, размещаемые в отдельных разделах. Но, если разделов много, например,, то все файлы Ebr можно сложить в один и разместить общий файл в одном разделе памяти.
5.3. Gpt-файл
Gpt-файл содержит образ разметки памяти по Gpt-схеме. Чаще всего МУ имеют стандартную структуру Gpt-схемы, поэтому, фактически, в прошивке имеется два Gpt-файла: основной, называемый pgpt (primary) или gpt_main, и вторичный (резервный), называемый sgpt (secondary) или gpt_backup.
Основной Gpt-файл располагается в памяти МУ, начиная с нулевого сектора, занимает 34 сектора и имеет следующее строение:
5.4. Parameter-файл
Parameter-файл, т.е. образ раздела, содержащего разметку памяти, содержит только сам текстовый файл PARAMETER, причем независимо от размеров этого раздела. Вот как Parameter-файл выглядит, например, внутри прошивки для устройства U30GT-H фирмы RK [6]:
Рис.9. Parameter-файл от U30GT-H на процессоре RK3066
5.5. Pmt-файл
Pmt-файл представляет собой образ резервного раздела разметки памяти, используемой разработчиками МУ фирмы МТК, и имеет размер 4096 байт.
Образ раздела PMT состоит из двух таблиц описания разделов памяти. В начале расположена базовая, а следом за ней резервная или зеркальная (mirror) таблица описания разделов.
Каждая из таблиц состоит из:
Для резервной таблицы эта строка имеет вид «‘MPT1’\х01\х00\х03\х01»:
Рис.13.Сигнатура конца резервной таблицы
Структура каждой записи имеет размер 0х58 (88) байт состоит из 4 полей и имеет следующий вид:
5.6. Pit-файл
Pit-файл (Partition Information Table) представляет собой образ раздела разметки памяти, используемой разработчиками МУ фирмы Samsung, и имеет размер 4096 байт. Информация по строению образа взята из [7, 8].
Pit-файл состоит из заголовка и таблицы описаний параметров разделов.
Заголовок имеет размер 28 байт и содержит следующие поля:
Следом располагается таблица описаний параметров разделов, состоящая из записей о разделах. Признак конца таблицы — пустая запись. Каждая запись содержит следующие поля:
Поле binary содержит тип операционной системы. Допустимы следующие значения:
Поле device содержит тип устройства. Допустимы следующие значения:
Поле id содержит порядковый номер раздела в прошивке.
Поле flags содержит флаги раздела. Может принимать значения:
Поле update содержит флаги раздела при обновлении. Может принимать значения:
Поле part_off содержит смещение раздела в памяти, выраженное в блоках.
Поле part_len содержит размер раздела в памяти, выраженный в блоках.
Поле offset содержит смещение файла-образа в прошивке, выраженное в блоках.
Поле file_size содержит размер файла-образа, выраженный в блоках.
Поле label имеет длину 32 байта и содержит метку раздела памяти, завершенную нулем (0х00).
Поле file_name содержит имя файла-образа раздела прошивки, завершенное нулем (0х00).
Поле fota_name содержит имя файла-образа раздела прошивки FOTA-обновления, завершенное нулем (0х00).
PowerShell. Дешифруем файлы после воздействия «вируса»
В неком городе России
(Может быть, что даже в вашем)
Есть не маленькая фирма.
Арендует помещенье
У НИИморгорворпрома.
В этой фирме есть сотрудник, почту любящий читать. Открывает как-то файл, кем-то вложенный нарочно, в недра письмеца пришедшего. Запустив без задней мысли «Благодарственное письмо.hta» и не увидев поздравления, покурить решил немного. Возвращаясь с перекура, он читает в беспокойстве:
Если Вы читаете это сообщение, значит Ваш компьютер был атакован опаснейшим вирусом.
Вся Ваша информация (документы, фильмы и другие файлы) на этом компьютере была зашифрована
с помощью самого криптостойкого алгоритма в мире RSA1024.
Восстановить файлы можно только при помощи специальной программы. Чтобы её получить, Вам необходимо
написать нам письмо на адрес unblockme@tormail.orgПри попытке расшифровки без нашей программы файлы могут повредиться!
К письму прикрепите файл, который находится на рабочем столе «READ_ME_NOW. TXT», либо этот файл
Письма с угрозами будут угрожать только Вам и Вашим файлам! НЕ ЗАБУДЬТЕ: только МЫ можем расшифровать Ваши файлы!
pz8FkWJXdijcajJcWfhJ27TGPgcNNEKXDBcsdyzfX+lUoq68eAptVmGNIYLD8eti1kwicdOR59pwOC7XM7T+YLccqyeJqc5loxMCKy4pklzbMJBRm и т.д.
Смотрим дальше (у отдела началась истерика от смеха насколько всё гениально и просто):
Примерно поняв, что главное — выкачивается PowerShell с аккаунта на dropbox.com теряем интерес к этому куску.
Далее:
Читаем, читаем и облегчённо выдыхаем. Ни о каком тотальном шифровании файлов речи не идёт.
Итак. Первым делом ищем ключи. Видим строки:
и понимаем, что для ключа используется UUID компьютера. С этого момента становится ещё легче и почти смело забываем про первую часть, где формируется страшный ключ, который добавляется в *.TXT
Из этого выясняем, что шифруется не весь файл, а только первая его часть если размер файла больше 40кб, если меньше, то весь файл.
Остается узнать UUID компьютера и написать скрипт для дешифровки.
UUID узнаем той же командой
Запустив в PowerShell, который зловред заботливо закачал и не удалил из %TEMP%.
Теперь за написание скрипта. Сложность возникла только в понимании (и то из-за нехватки знаний, т.к. не приходилось раньше сталкиваться), что по примерам у M$ подобные функции передают в качестве параметра строку, а тут используют просто массив.
Собственно, что поучилось. Данный код — рабочий, без изменений и с лишними выводами для отслеживания процесса работы.
Что он делает, что надо изменить если понадобиться самим:
1)задаем в ручную переменную $ek c нужным ключом (в нашем случае UUID)
2)Описание функции декодирования, которая возвращает массив. Задаём переменные $salt и $init согласно тем, что были в исходном коде зловреда.
3)Просим запускающего указать путь, начиная с которого будет поиск файлов (ищем по вложенным папкам)
4)Каждый найденный фаил с указанным расширением (.BMCODE) декодируем и переименовываем в нормальный вид.
5)Попутно удаются файлы с именем READ_ME_NOW. TXT, которые насоздавал зловред.
Код не идеален и многое можно упростить и переписать, но главное — он работает и помогает.
Вот и всё. Надеюсь эта статья поможет всем кто уже столкнулся с подобной проблемой и не знает, что делать. Как пишут в рунете злоумышленники требуют за расшифровку от 3000 до 10000 руб, но и встречаются более сложные варианты зловредов, где просто так ключ уже не узнать.
За сим прощаюсь и надеюсь, что всёже найду время и напишу как мы в своём НИИморгорворпроме устанавливали видео наблюдение и вешали мышку в качестве звонка на двери отдела.
В коде зловреда реализована своеобразная проверка на повторный запуск
Если в файл уже записано good значит ключ уже так просто не найти. Так, что если случайно запустили зловреда или заметили, что файлы начали менять расширения, немедленно выключайте компьютер, чтобы остановить процесс шифровки и сохранить ключ.
Советы по применению файла ads.txt, которые помогут избавиться от спуферов в digital-рекламе
Коммерческий директор programmatic-платформы Getintent в России Надежда Бабиян — о пользе технологии Authorized Digital Sellers.
Обстановка с мошенничеством в российском сегменте programmatic-рекламы сегодня напоминает отечественный ритейл 1990-х годов. Количество подделок дорогих брендов в бутиках тогда соперничало с откровенным контрафактом Черкизовского рынка. Так продолжалось до тех пор, пока не придумали маркеры, голограммы и чипы для настоящего товара, а владельцы брендов не выстроили отношения с проверенными продавцами.
В интернет-рекламе наших дней мошенники продают на RTB-бирже и напрямую инвентарь «мусорных» ресурсов, выдавая его за рекламу на премиум-сайтах уровня The New York Times по ценам оригинала.
От этого нехитрого способа подмены данных (доменного спуфинга) страдают все — рекламодатели, продавцы, посредники, издатели. В результате с рынка неизвестно куда уплывают миллиарды долларов, клиенты несут прямые убытки, крупные селлеры и биржи теряют в репутацию.
В мае 2017 года IAB Tech Lab выпустила новый инструмент борьбы с незаконной торговлей инвентарем — ads.txt (Authorized Digital Sellers). Это файл, в котором издатели прописывают, кто имеет право продавать их инвентарь. Файл содержит имя партнёра и идентификатор учётной записи издателя.
В случае изменения информации владелец контента может с лёгкостью внести корректировки в содержимое ads.txt. Для активации технологии издатель должен разместить файл на своём домене в корневой папке. Тогда его могут анализировать programmatic-платформы, агентства и рекламодатели.
Поначалу компании-издатели неохотно работали с файлом ads.txt. Профильные специалисты по рекламе с опасением смотрели на новый инструмент, одной из главных причин было недоверие к новой технологии.
Но с ростом экспертизы через полгода на рынке США технологию ads.txt внедрили 44% паблишеров из списка Alexa Top 10k. Во многом это случилось стараниями Google, где сразу взялись продвигать Authorized Digital Sellers. Помогли и крупные медиабаеры, которые один за другим вводят обязательную «сертификацию» ads.txt при работе с издателями.
В России ситуация иная. Здесь антиспуфинг продвигают programmatic-платформы, которые кровно заинтересованы в чистоте трафика. Самые технологичные из них представляют свои варианты использования ads.txt.
В результате рынок становится прозрачнее. Рекламодатели точно знают, что и у кого они покупают, и могут компетентно общаться с поставщиками рекламы. DSP и SSP-платформы выдают более качественный трафик, а агентства закупают инвентарь только у авторизованных продавцов.
Технология ads.txt не только бесплатна, но и проста. Нужно совершить несколько простых действий.
1. Создать файл ads.txt.
Файл содержит данные о рекламных инструментах, доменах, где они размещены, и продавцах, которые имеют право торговать этим инвентарём. Данные пишутся в строчку, например, так:
В каждой строчке заполняются четыре поля (первые три обязательны).
2. Отправить файл администратору сайта для установки в корневой каталог
Издателям и медиабайерам легче понять, какие SSP имеют право продавать конкретный инвентарь. Ads.txt помогает всем участникам транзакций привести отчёты об инвентаре к общему стандарту. DSP также могут создавать алгоритмы работы с авторизированными продавцами для каждого издателя или домена.
Например, Getintent, поддержав инициативу IAB, создала на основе технологии ads.txt универсальное решение по использованию списка авторизованных продавцов.
В интерфейсе пользователя платформы Getintent есть возможность отфильтровать непроверенных продавцов.
Так клиенты могут сами настроить рекламные кампании. Данные ID биржи и аккаунта сопоставляются с данными в списке авторизованных продавцов в файле ads.txt конкретного издателя.
Технология полностью решает проблему подмены домена (domain spoofing), когда запрос идёт с одного сайта, а реальный показ происходит на другом, менее качественном.
Рекламодатели полностью уверены в чистоте домена и не рискуют получить фейковые показы.
Медиабаеры могут проверить, связаны ли определённые SSP с теми доменами, рекламу на которых они продают.
Впрочем, некоторые недобросовестные SSP и тут нашли лазейки: перепродавцы, которые не попали (и не должны были) в файл ads.txt, начинают бомбардировать письмами паблишеров с целью туда добавиться. Что интересно, некоторым это удаётся.
Также продавцы-мошенники, обладающие собственными площадками, размещают файл ads.txt на них, где разрешают сами же себе продавать фродовый трафик. Сейчас это невозможно победить, но решить данную проблему должна технология ads.cert (о ней — в конце).
В основном все существующие недоработки связаны с «болезнями роста»: сервису ads.txt не исполнилось и года. Пока он применим только на браузерном трафике (и мобильном вебе), однако IAB уже работает над in-app-решением.
Возможно, будет расширено и количество полей в файле, а заодно упрощена функция их заполнения (например, с помощью единой веб-формы). Более гибкие протоколы позволят всем заинтересованным участникам видеть, через каких продавцов, посредников и агрегаторы проходит рекламный трафик.
Это, конечно, несколько снизит возможности для арбитража и доходы SSP от перепродажи трафика. Следовательно, может снизится и выручка издателей из-за отказов в покупке трафика посредниками. Но в целом это только оздоровит рынок.
Со стороны DSP основная сложность заключается в том, что паблишеры неточно следуют стандарту от IAB. Встречаются незначительные отклонения — когда ads.txt составлен в соответствии со спецификацией, но расположен в неверном месте.
Также попадаются совсем невалидные ads.txt: в строчках файла не хватает полей, либо они размещены в неправильном порядке. Особый случай — очень длинные ads.txt (с количеством строчек в десятки тысяч), которые сгенерированы какими-то автоматическими инструментами, но не соответствуют реальности. Иногда ads.txt размещают не на корневом домене, а на поддомене, что тоже не согласуется со спецификацией.
Для помощи паблишерам появляются такие ресурсы, как adstxtvalidator.com, на которых можно проверить соответствие ads.txt файла стандарту с пояснениями ошибок.
По данным Getintent, отработавшего данные тысячи ведущих издателей, размещённых на платформе, сегодня ads.txt используют 22,3% владельцев российских доменов. В США этот показатель более чем втрое выше – 76,4%.
Количество показов через авторизованных продавцов с сайтов, имеющих ads.txt-файл на платформе Getintent, составляет 39,78%.
Неавторизованные продавцы составляют 14,9% общего трафика.
