Так как это по сути война, то нужен как бы "солдат", то есть хакер, который будет "воевать". Не уверен, что здесь вообще может быть чёткая задача и критерии её решения.
Предположим, хакер вам сделал супер программу, которая делает мультирегистрацию без бана. В качестве демонстрации прога зарегала 10 аккаунтов без проблем. Вы ему заплатили и попрощались. Но владелец сайта (или его сотрудники) никуда не делся. Он денно и нощно в ручном режиме смотрит, кто там у него зарегался, сколько и т.д. Вот вы зарегали 157 аккаунтов, и владелец сайта заметил какой-то всплеск. Он понял, что что-то здесь не чисто, скорее всего это какие-то боты, потому что он не давал новой рекламы и не должно быть столько новых юзеров. Далее он начинает изучать проблему, пытается понять закономерность в регистрациях, ищет дыры в своём алгоритме детекта ботов. В конце концов находит, конечно же. В крайнем случае он просто заставит всех юзеров ввести новую капчу, об которую ваши боты сломаются. И можно ли после этого считать задачу решенной тем хакером?
Это война снаряда и брони. Как только вы увеличиваете калибр снаряда так, чтобы он пробил броню, владелец сайта увеличивает броню, что ее не пробивали снаряды вашего калибра. И так далее до бесконечности. Выигрывает такую войну тот, у кого больше времени и прочих ресурсов. Так что если вы замахнулись на какой-нибудь гугл, яндекс или хотя бы мейл-ру, то можете сразу сдаваться. Выиграть бой вы сможете, но не войну.
Как вариант, можете сами изучить тему, если вы технарь, и вести эту войну самостоятельно, тратя своё время вместо денег.
olya_097, а вы пытались? С какой именно проблемой столкнулись? Меню не появилось? Или там нет пункта "скопировать"? В чём затык? У меня прекрасно копируется.
EgorBolotow, понятно. Надеюсь, у вас на это уйдёт всего несколько часов, не больше. К сожалению, решение вашей задачи выходит за рамки ответа на вопрос на этом ресурсе. К слову, задачи здесь вообще запрещены. Ну а ответ я вам дал. Удачи в освоении кликера! :)
xmoonlight, и если длина не фиксирована, то так тоже просто. Например, длина в самом начале пакета для удобства. Заранее обговариваем, что она не больше X и не меньше Y, что отсекает сразу кучу вариантов. Далее ждём, когда придут все данные (согласно заявленной длине). Затем смотрим на другие характеристики пакета. Какие-то поля должны тоже удовлетворять каким-то условиям, ограничениям. Если что-то не так, списываем на искажение данных и идём дальше. Ну а если со структурой всё ок, то вишенкой на торте считаем контрольную сумму.
По-хорошему, до прихода всех данных при определении самого первого пакета, нужно пытаться просчитать пришедшие данные с опережением, потому что более мелкий пакет может быть чуть дальше.
Если не секрет, зачем вы перебираете решения для всех возможных кейсов, которые автор даже не назвал? Вы же в курсе, что 100% универсальности не существует. Более-менее универсальный вариант (не 100%) всё же возможен, но за универсальность нужно платить. А у автора вопроса вообще вполне себе конкретный вариант. Просто деталей мы не знаем. Да и они уже не уместны будут в этом абстрактом вопросе, лучше новый вопрос задать.
xmoonlight, ну, очевидно же. К примеру, есть поток данных. По порядку с каждого места пытаемся собрать пакет. Собрался - ура, у нас есть пакет, сразу после него пытаемся собрать следующий. Не собрался - значит это мусор, испорченный пакет или середина пакета, - игнорируем и идём дальше.
EgorBolotow, да, но в случае с кликерами взаимодействие происходит через интерфейс. То есть вам нужно придумать, как скрипт будет различать контакты. Обычно это делается через чтение пикселей с экрана. Например, в ватсапе есть аватары у каждого юзера и там наверняка есть уникальные пикселы по цвету и расположению. С другой стороны, стоит контакту поменять свой аватар, и кликер сломается. Ещё можно попытаться считать номер телефона или имя и т.д.
Кликеры обычно для простых задач используют. Например, контакт уже открыт, его не нужно выбирать, и с фикисрованным интервалом надо что-то писать.
Для сложных задач лучше уже не кликер, а какое-то более продвинутое решение с внедрением в логику работы whatsapp. Например, можно сделать браузерное расширение.
xmoonlight, нет. Если длина не фиксирована, то где-то там сразу до/после (зависит от структуры пакета) будет указана длина, которая будет участвовать в попытке собрать пакет.
Но, как я говорил выше, многое зависит от нюансов. Если нужно шифрование, например, то всё сильно усложняется.
Kalombyr, контрольная сумма - это алгоритм подсчёта. Да, я его предлагаю, но без деталей, которых я не знаю. Например:
- как часто встречаются ошибки
- насколько важно беречь процессор от нагрузки
- фиксированный ли замер пакета (можно ли его сделать таковым)
- какой средний и максимальный размер пакета может быть
- непрерывен ли поток данных, и что там в перерывах
- характер ваших данных (насколько они случайны или есть закономерность)
- нужно ли противодействие хакерам
- соблюдение каких-то стандартов, продиктованных задачей
- и т.д.
Все эти нюансы, конечно же, влияют на выбор. Контрольная сумма здесь - это как бы вилка, которую вы дальше можете прикрутить и обыграть так, как вам нужно. Можете выбрать сложную хеш функцию, можете выбрать разрядность и т.д.
Контрольная сумма выигрывает простотой реализации. Берём для неё 64 бита. Добавляем соль, чтобы исключить типичную ситуацию, когда поток состоит из нулей. Можете сами посчитать, каков шанс, что пакет случайно соберется сам. К тому же сборка следующего пакета начнётся сразу после предыдущего. Так что считать ошибку можно лишь в первом пакете (при условии, что ошибки вообще достаточно редки). Плюс в самом пакете должна быть какая-то структура, скорее всего. Хотя бы его длина (если она не фиксирована). Это тоже как бы плюс к разрядности контрольной суммы.
Конечно, ошибка испортит пакет, и тогда придётся искать начало следующего попытками собрать его. Но если ошибки так уж прям часты, то скорее всего нужно уже не алгоритм искать, а фиксить саму среду, по которой передаются данные. А чисто алгоритмически можно увеличить разрядность. Поднимите её до 128 бит, это уже астрономическая точность, хоть и не 100%. При такой точности ваше устройство скорее сгорит, утонет или будет украдено, чем допустит ошибку в пакете. Поднимите ещё, если мало.
Полностью решать задачу за вас я и не собирался. Просто отвечаю на вопрос про "простой и быстрый алгоритм кодирования/декодирования байт". Ответом является контрольная сумма. Точнее, ссылка на статью вики про хеш-функции. А дальше сами думайте, как вам там удобнее. Хотите разделитель - пожалуйста, делайте. Можете перед пакетом ставить какой-то неповторимый разделитель. Если он вдруг будет искажен в пакете, это тоже будет означать потерю пакета, но как по мне - слишком много информации тратится и слишком мало выхлопа в плане проверки пакетов по сравнению с контрольной суммой, в которой можно просто наращивать разрядность, и точность будет расти по экспоненте.
Kalombyr, да, но в целом не обязательно. Само совпадение с контрольной суммой и может быть сигналом начала. А последующие "пакеты" лишь подтвердят "гипотезу". Главное, чтобы разрядность была достаточно большой. И контрольная сумма - это самый простой вариант, когда лень пилить более сложный алгоритм создания хеша.
Уточните, в чём именно проблема. И что такое "ввести массив". Ведь массив может формироваться разными способами. Например, можно ввести строку, где значения элементов массива разделены запятыми. Для такого способа нужен соответствующий алгоритм. А у вас задумка какая?
К тому же формулировка ужасная. Формальный ответ будет "Да" или "Нет".
Нужно решить задачу? - Нет, не нужно.