Я же написал, чем это отличается от фильтра. Фильтр, если, например, мы имеем массив со значениями 1, 2, 3, 1, 2, 3 и правило выхода "n <= 2", вернет массив со значениями 1, 2, 1, 2.
В вышеописанной функции conditionBreak остановка произойдет после первой тройки, то есть значения будут 1, 2 и все. Это более близко поведению break оператора цикла.
Нет, это не так. Map, filter, reduce (а также every и some) мы используем при работе с массивами. Но кроме массивов есть еще какие-то императивные алгоритмы, которые, например, просто должны делать что-то некое количество раз. И не имеют отошения к массивам вообще.
Вредная статья, как и каждая вторая про функциональное программирование в JavaScript. Подчеркиваю — в JavaScript.
JavaScript не рассчитан на функциональное программирование, хоть и с виду кажется, что расчитан. Да, есть хай-ордеред функции, да, всякие там лямбды и замыкания. Но если вы пишете [я понимаю, что это перевод, если что], что циклы не нужны, а вот функции нужны, то советую сравнить скорости работы императивного подхода в JS и функционального. Просто возмите и перепишите любой цикл на рекурсию. И сравните. Ведь в функциональных языках, на сколько я знаю, цикл замещается рекурсией? Ну так вот, вы скорее всего расстроетесь и немного загрустите.
Скажем так, против ФП никаких нареканий нет, но оно должно быть уместно и применено в тех языках, которые расчитывают именно на функциональный подход изначально и не являются просто "поддерживаемой парадигмой", а внутренним устройством.
Лично мой подход — это здравое комбинирование императивного и функционального. Функциональное, обычно, описывает архитектуру, какой-то паттерн. А вот конкретные имплементации отдельных функций/методов уже не брезгуют циклами и прочими вещами, далекими от ФП и близкими императивному подходу.
Тем самым сохраняется чистая архитектура и здравая скорость.
Я чего-то не понимаю? Зачем все это, если есть всякие программы удаленного управления и у многих из них есть вывод картинки в веб? Зачем придумывать всякие фиктивные системы, когда есть настоящие и установить на них можно все, что душе угодно. Управлять этим через браузер тоже можно. Не знаю, как по мне, так это обреченные проекты.
Трояны тестируются в полевых условиях, безусловно. Но не так. За редким исключением компьютерные криминалисты будут запускать подозрительный файл в рабочем пространстве пусть даже чистого компьютера. Обычно все это делается в виртуалках.
Замаскированный под браузер андроида (или что там у автора) запрос. Обычный http запрос с подделанными заголовками user-agent и referer.
Что такое «связка»?
Связка, сплойтпак, експлойт-пак, exploit-pack — это комплекс серверных и клиентских скриптов (и не только), способных пробить ваш браузер и загрузить на компьютер или другое устройство заразу без вашего ведома.
Что такое «скрипт на curl»?
Скрипт на курле (curl) это как пример автоматизированной скачки, можно скачать apk файл и другими способами, просто курл это как швейцарский нож при работе с http, заголовки андроидного браузера там подделать проще простого.
Риск с чем? Что такое «курл»?
Риск с тем, что если вы зайдете на зловредную страницу для андроидов — она может оказаться зловредной не только для андроидов и заразить ваш компьютер (если вы это сделаете без виртуальной машины и других мер безопасности). Обычно у связок выдается javascript-роутер который проверяет устройство/браузер на версии и плагины и исходя из этого выдает нужный эксплойт.
Короче говоря, курл не подвержен пробиву никакой известной на данный момент связкой, поэтому загружать им зловредов и ходить по левым ссылкам безопасно.
Мне не совсем понятно зачем вирус тестить вот так вот прямо в боевых условиях.
Если у вас не пошла скачка по директ-линку с компа, то разве не проще подменить user-agent + реферер? То есть просто напросто передать замаскированный запрос?
Причем я бы не рискнул проводить такое даже со своего компа (разве что только с вм), вдруг там связка стоит а вы вот так лезете… Просто пишите скрипт на том же curl например, пара заголовков, строк 10 кода и все, .apk-файл у вас скачан на сервер, а в случае риска со связкой так курлу на нее все равно.
Ну и далее лучше сперва расковырять сам файл, а уж только потом запускать, примерно представляя что он будет делать.
Если уж делали сниффер на js, то можно было и код всей админки слить — не серверный, разумеется, а тот, что в браузере(document.getElementsByTagName('html')[0].innerHTML в сочетании с созданием формы с method=post и автосабмитом кода админки как одного из полей), и user-agent (navigator) узнать, и адрес админки (location и иже с ним), и доступ в нее соответственно (cookie).
Хакер это исключение из правил. Кнопка удалить сделана не только для хакеров, верно? То есть ради исключения из правил мы убираем возможность удаления. А может лучше все-таки тогда думать над улучшением безопасности? Как сервера, так и пользователя. Возможно для кого-то это будет шоком и грусть-печалью, но кнопка удалить должна удалять, а все остальные моменты — на ответственности серверной защиты и пользовательского образования. Тем более то, что не нужно палить пароль, делать его трудным и прочее прочее прочее — вещь говореная всеми и везде.
Вопрос спорный. Вы мои сообщения восстановили, круто.
А потом, через пару минут, прийдет вопрос — а откуда у вас это, ведь я же удалил. Удалил. Ключевое слово. Я внутри своего аккаунта, никто и так не имеет туда доступа.
И я, зная это, все равно их удалил.
Значит я не хотел их оставлять прежде всего где-то там, на сервере, верно? Но, получается, что «удалил» это фикция. Я понимаю еще хранить бекап комментов (публичных) к чему-либо, на случай разбирательств там или чего-то еще. Но личные сообщения…
Что, если я скажу вам, что это далеко не всегда вебмани? Что, если я скажу вам, что есть партнерки работающие с небольшим количеством партнеров и платящих им так, как им удобно? Что, если я скажу вам, что есть партнерки которые платят вам тогда когда захотите вы? Что, если я скажу вам, что существуют люди которые имеют огромные обьемы трафика и которые льют его исключительно на черное? На связки, алармы и прочее? Что, если я скажу вам, что никакие белые домены в таких делах не нужны и что кроме домена для партнеров, который чаще всего один, рабочие домены меняются постоянно? Что, если я скажу вам что есть люди которые занимаются продажей доменов под чернуху оптом? )
Ну в данном случае вы затрагиваете тему именно ресурсов. Там эти различия во времени не являются значительными, так как среднестатистический впс парсит 1к страниц за 2-5 секунд на мультикурле. Наверное можно даже это дело как-то разогнать на 0.5-2 секунды, но это не такая большая разница во времени, как постоянная нужда ломать капчу или менять проксики. Там 6-10 секунд вполне обычное дело.
Я же написал, чем это отличается от фильтра. Фильтр, если, например, мы имеем массив со значениями 1, 2, 3, 1, 2, 3 и правило выхода "n <= 2", вернет массив со значениями 1, 2, 1, 2.
В вышеописанной функции conditionBreak остановка произойдет после первой тройки, то есть значения будут 1, 2 и все. Это более близко поведению break оператора цикла.
Лучше уж как-нибудь вот так. В отличии от .filter он не отбирает, а реально "выбрасывает" при первом неудовлетворяющем условии.
Нет, это не так. Map, filter, reduce (а также every и some) мы используем при работе с массивами. Но кроме массивов есть еще какие-то императивные алгоритмы, которые, например, просто должны делать что-то некое количество раз. И не имеют отошения к массивам вообще.
Вредная статья, как и каждая вторая про функциональное программирование в JavaScript. Подчеркиваю — в JavaScript.
JavaScript не рассчитан на функциональное программирование, хоть и с виду кажется, что расчитан. Да, есть хай-ордеред функции, да, всякие там лямбды и замыкания. Но если вы пишете [я понимаю, что это перевод, если что], что циклы не нужны, а вот функции нужны, то советую сравнить скорости работы императивного подхода в JS и функционального. Просто возмите и перепишите любой цикл на рекурсию. И сравните. Ведь в функциональных языках, на сколько я знаю, цикл замещается рекурсией? Ну так вот, вы скорее всего расстроетесь и немного загрустите.
Скажем так, против ФП никаких нареканий нет, но оно должно быть уместно и применено в тех языках, которые расчитывают именно на функциональный подход изначально и не являются просто "поддерживаемой парадигмой", а внутренним устройством.
Лично мой подход — это здравое комбинирование императивного и функционального. Функциональное, обычно, описывает архитектуру, какой-то паттерн. А вот конкретные имплементации отдельных функций/методов уже не брезгуют циклами и прочими вещами, далекими от ФП и близкими императивному подходу.
Тем самым сохраняется чистая архитектура и здравая скорость.
Я чего-то не понимаю? Зачем все это, если есть всякие программы удаленного управления и у многих из них есть вывод картинки в веб? Зачем придумывать всякие фиктивные системы, когда есть настоящие и установить на них можно все, что душе угодно. Управлять этим через браузер тоже можно. Не знаю, как по мне, так это обреченные проекты.
можно изменить на
Вопрос не из праздного любопытства.
Замаскированный под браузер андроида (или что там у автора) запрос. Обычный http запрос с подделанными заголовками user-agent и referer.
Связка, сплойтпак, експлойт-пак, exploit-pack — это комплекс серверных и клиентских скриптов (и не только), способных пробить ваш браузер и загрузить на компьютер или другое устройство заразу без вашего ведома.
Скрипт на курле (curl) это как пример автоматизированной скачки, можно скачать apk файл и другими способами, просто курл это как швейцарский нож при работе с http, заголовки андроидного браузера там подделать проще простого.
Риск с тем, что если вы зайдете на зловредную страницу для андроидов — она может оказаться зловредной не только для андроидов и заразить ваш компьютер (если вы это сделаете без виртуальной машины и других мер безопасности). Обычно у связок выдается javascript-роутер который проверяет устройство/браузер на версии и плагины и исходя из этого выдает нужный эксплойт.
Короче говоря, курл не подвержен пробиву никакой известной на данный момент связкой, поэтому загружать им зловредов и ходить по левым ссылкам безопасно.
Если у вас не пошла скачка по директ-линку с компа, то разве не проще подменить user-agent + реферер? То есть просто напросто передать замаскированный запрос?
Причем я бы не рискнул проводить такое даже со своего компа (разве что только с вм), вдруг там связка стоит а вы вот так лезете… Просто пишите скрипт на том же curl например, пара заголовков, строк 10 кода и все, .apk-файл у вас скачан на сервер, а в случае риска со связкой так курлу на нее все равно.
Ну и далее лучше сперва расковырять сам файл, а уж только потом запускать, примерно представляя что он будет делать.
А потом, через пару минут, прийдет вопрос — а откуда у вас это, ведь я же удалил. Удалил. Ключевое слово. Я внутри своего аккаунта, никто и так не имеет туда доступа.
И я, зная это, все равно их удалил.
Значит я не хотел их оставлять прежде всего где-то там, на сервере, верно? Но, получается, что «удалил» это фикция. Я понимаю еще хранить бекап комментов (публичных) к чему-либо, на случай разбирательств там или чего-то еще. Но личные сообщения…
Вы думаете мало схем серого вывода денег?
Сервис-то новый, на ачате еще его рекламили одно время, о каких годах идет речь?