весь код переписывать

ну такое

Что-то никак не пойму по этой статье как они хакают строки, объясните?

нужно написать функцию для выстрела себе в ногу

и воспользоваться ей

значит, gsub ', '' все ещё безопасен и параметры не нужны, чудненько

ну вроде как да

вообще постгрес в этом плане хорош

да он вообще во всех планах красавчик

https://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html

Используйте параметры и не будет проблем Так же это удобнее и читаемее на мой взляд

я именно так, кстати, и делаю. Точнее nginx-postgres и из кода дёргаю его локейшны с параметрами :)

чй чат умер? :(

Нет, в нём ещё много спамеров : )

А я на днях попробую записать что-то похожее на мануал по сокетам, типа, видеоурок "Пишем http-сервер, вводный курс для дебилов".

А я сишку учу, буду рад твоему курсу, если он на сишке!

Слушаете 80 порт, Читаете заголовки, Открываете RFC чтоб ответить правильно ??? Охуеваете^WИзобритаете велосипед^W^WПрофит!

Рома Язык не главное, главное понимание алгоритмов

Рома Язык не главное, главное понимание алгоритмов

главное им хорошо дви^Wвладеть :D

ага, и в том месте его применять

Хех, я ведь про ДЕБИЛОВ говорю, которые не могут просто открыть википедию и прочитать, а понять им нужно ))) 1. Сокет - это типа файла или некоторого устройства, которое программа арендует у операционной системы. Айпи - адрес пека, порт - адрес приложения, на конкретном пека, поэтому открыть несколько программ арендующих один и тот же порт не выйдет (точнее, выйдет, но через жопу). Когда мы что-то пишем сокетом, с другой стороны это можно прочитать (если дошло) 2. TCP. Потоково-ориентированный протокол. Потоковый - значит тут нет деления на отдельные сообщения, то что мы пишем - просто дописывается в конец буфера на другом конце провода, и программы сами определяют, что является разделителем. Чаще всего - \r\n. 3. UDP - сообщенько-ориентированный протокол, бла-бла. 4. Протокол http (заголовки, что они значат, содержимое, post/get/body/querry и прочая хуета) 5. Библиотека luasocket, что это такое, что там есть. 6. Слушаем 80 порт, 7. Читаем заголовки, 8. Открываем RFC чтоб ответить правильно ??? Охуеваем^WИзобритаем велосипед^W^WПрофит!

В tcp/udp уходить не надо. Это уже борсч

видел я людей у которых инкапсуляция портоколов была вся пофачена в голове

чем меньше знают, тем лучше

Почему не надо? Я бы почитал что-нить приятное по RUDP. Но по голому UDP наверно смысла нет

http over udp

Почему не надо? Я бы почитал что-нить приятное по RUDP. Но по голому UDP наверно смысла нет

Я написал RUDP ))) Похоже на эту фигню, только чутка сложнее: проверки хешей, куча флагов (нужно подтверждение/не нужно) и т.п. https://habrahabr.ru/post/250227/

В tcp/udp уходить не надо. Это уже борсч

А я - с презентацией и схемками, что где находится, в несколько этапов )))

Я знаю что написал, просто еще бы описать - что есть что, зачем и почему, при желании, конечно

Ну глянь в том протоколе, описано что-почему.

Ой, а схема передачи у меня как раз проще. 1. Один передаёт пять пакетов, третий теряется, в пятом - запрашивает подтверждение приёма. 2. Второй отвечает: "последний принятый пакет - второй" 3. Первый продолжает передачу с третьего пакета Это не очень оптимально, согласен.

Кстати, пока вспомнил, кто-нить юзал движок Gideros?

обычно хватает чтения RFCшек (чтоб понять что в рот оно всё ебись, беру готовое)

Ну глянь в том протоколе, описано что-почему.

Это почитаю, конечно

Да, RFC тоже можешь глянуть.

обычно хватает чтения RFCшек (чтоб понять что в рот оно всё ебись, беру готовое)

а) Мне нужен был протокол поверх udp, чтобы использовать тот же luasocket с udp, и не фигачить кучу новых сишных либ/расширений луасокета (пользуюсь одновременно большим количеством платформ). б) Лимит на длину сообщения - 65529 байт (6 на заголовок). Это офигенно мало, я своим протоколом передаю гигабайты, в одном сообщении. в) я не хочу терять возможность принимать и отправлять обычные udp-сообщения на данный порт, иначе я не смогу, например, пробивать соединение через NAT. г) RUDP из RFC не умеет в приём коротких сообщений без подтверждения, в моментальное использование принятого, если соединение ещё открыто а мы уже всё приняли, и всё такое

tftp?

Но в общем писать свой протокол это весело :)

tftp?

Ориентирован на "дай фигню" -> "держи фигню", а не "вот тебе крошечная и незначительная или ниибацца огромная и ужасно нужная куча фигни, сделай с ней что-нибудь"

Но в общем писать свой протокол это весело :)

Особенно отладка и байтоёбство.

отладка совего кода - самый сок

особенно если ошибка в один символ где-то

особенно если ошибка в один символ где-то

Логическая ошибка - это проблема. Но просто тыкаешь кучу логов, смотришь где начинается неправильное. Логи эффективнее тыкать не просто как "текст", но и с мини-трейсбеком.

Тесты для реализации протокола необходимая вещь

Логическая ошибка - это проблема. Но просто тыкаешь кучу логов, смотришь где начинается неправильное. Логи эффективнее тыкать не просто как "текст", но и с мини-трейсбеком.

есть тут одна система, в которой если логирование поднять до уровня - всё понятно - она логами всё засрёт. Но это так, лирика

Ну тестовый сурц болтается где-то тут: https://pastebin.com/fWJCiVBm https://pastebin.com/sn6sdTVL

есть тут одна система, в которой если логирование поднять до уровня - всё понятно - она логами всё засрёт. Но это так, лирика

Бо-о-о-о-ольше логов! Хе, в некоторых рабочих системах, логи плодятся со скоростью 100-150мб/с. Но недолго, да, несколько секунд и это только на тесте, ясное дело. И активно используется поиск по огромным файлам, не открывая их полностью, выдирая нужные кусочки.

Хочешь маленькую задачку? Накатай свой формат для "архива", где типа [любые данные] [заголовок с внутренним путём до файла, длина файла] [тело файла] [любые данные] [следующий заголовок] [следующее тело] [любые данные] Чтобы работало на любых размерах файлов. Это весело, ибо нужно учесть кучку мелочей. А такой свободный формат - чтобы можно было делать rarjpeg'и :) Ну, или двойной архив, который разными программами открывается по разному.

а старый добрый rarjpeg чем не устаривет?

Видел я дискуссию по этой теме лет 7 назад в /b

Ну, тут специфика определённая : ) а) можно ебошить произвольное сжатие (и вообще, свои алгоритмы) б) конкретно картинка весом в 100мб вызывает подозрение (я хочу паковать ресурсы love-игрулек в zip + данный формат, чтобы важные скрипты были скрыты внутри данного формата, а основные ресурсы - на виду, в zip'е)

Правда, я уже сделал подобный парсер/упаковщик, правда без сжатия, хм.

zip64 :)

там в принципе то что нужно

Я не хочу распространённых вариантов, потому что они легко вскрываются. Свои форматы/своё сжатие/свои ништяки - чтобы сложнее было ломать. Особенно обфусцированное/скомпиленное в бинарь.

правда с различными вариациями

zip64+AES

[ключ][длина пути][путь][размерность длины данных][длина данных][crc заголовка][данные...][crc данных][общее crc]

Смотри какая Самая Главная Проблема защиты lua-ресурсов: 1. Код - интерпретируемый. 2. Все хвосты для расшифровки - на виду (с минификацией/обфускацией - не так на виду, но тоже на виду), ну, типа "опа, он вскрыл этот архив этой функией, давайте её посмотрим или перепишем прогу чтобы всё вскрытое писалось в файлы! Так я распакую вообще всё!". 3. На каждый компилятор найдётся декомпилятор. Поэтому, остаётся только идти на уловки, чтобы вскрывали о-о-о-о-очень медленно, вроде ручной обфускации видимой части программы, чтобы автоматика не справилась.

Я не хочу распространённых вариантов, потому что они легко вскрываются. Свои форматы/своё сжатие/свои ништяки - чтобы сложнее было ломать. Особенно обфусцированное/скомпиленное в бинарь.

легко это ломается, если кому-то это нужно. А пока речь идет о бесплатных или не дорогих тайтлах то можно брать открытые шутки

Ну, если кому-то особо нужно - да, я просто хочу создать сложности для тех, кто будет пытаться читерить в сетевых играх, с игроками-хостами : ) Максимум неочевидности, в общем.

[ключ][длина пути][путь][размерность длины данных][длина данных][crc заголовка][данные...][crc данных][общее crc]

А в чём проблема переписать данные, и CRC?

Хочешь маленькую задачку? Накатай свой формат для "архива", где типа [любые данные] [заголовок с внутренним путём до файла, длина файла] [тело файла] [любые данные] [следующий заголовок] [следующее тело] [любые данные] Чтобы работало на любых размерах файлов. Это весело, ибо нужно учесть кучку мелочей. А такой свободный формат - чтобы можно было делать rarjpeg'и :) Ну, или двойной архив, который разными программами открывается по разному.

А как ты поймешь, что в этих "любых данных" не попадётся нечто, что похоже на заголовок?

Хитро : ) Придумай. Сначала тебе надо найти этот самый заголовок. Как ты будешь прочёсывать файл на заголовки? Он может быть на много гигов, поэтому file = io.open('file.txt'):read('*all') - не покатит.

ERROR: S client not available

file:seek тоже не работает на много гигов

file:seek тоже не работает на много гигов

Хм, у меня работает.

Хитро : ) Придумай. Сначала тебе надо найти этот самый заголовок. Как ты будешь прочёсывать файл на заголовки? Он может быть на много гигов, поэтому file = io.open('file.txt'):read('*all') - не покатит.

Тут можно забить, и просто проверять на то, что бы после данных шла копия заголовка и подтверждала, что да, так оно всё и есть. Если нет, заголовок неправильный и мы идём дальше. Если длинна больше или равна остатку файла - неправильный. Насчет поиска по файлу - вроде какие-то есть способы "блочного" чтения файлов, но тогда придётся изворачиваться на платформозависиммых методах для такого.

Т.е. запрашивать файл по кускам, сканить, дальше идти.

Не идти дальше, а откатываться назад на длину заголовка и дальше идти, потому что мало ли, прям на разбивке буферов сидит заголовок распополамленный )))

Хм, у меня работает.

Это платформо зависимо. У меня file.write может писать файл лубого размера. Но seek толко на 2 гига

А, спасибо за такой случай

Я пишу zip архивы ~3 гига

Ну ладно, ладно. Считаем что file:seek работает. Например, ограничение архива на два гига. Ничо страшного, для бОльших данных возьмём lua64.

Тогда надо так - сохранить последние Н (где Н - самая большая длинна заголовка, и желательно заголовок корневого уровня сделать маленьким) байт блока, пойти к следующему, и через хитрую функцию поиска искать в этих двух кусках - маленьком и большом.

А, спасибо за такой случай

А как сделать заголовки которые будут нормально читаться?

Тогда надо так - сохранить последние Н (где Н - самая большая длинна заголовка, и желательно заголовок корневого уровня сделать маленьким) байт блока, пойти к следующему, и через хитрую функцию поиска искать в этих двух кусках - маленьком и большом.

Можно проще.

А как сделать заголовки которые будут нормально читаться?

Ну... некая фиксированная сигнатура, плюс длинна данных, плюс чексумма/хеш заголовка.

Потом данные, потом копия заголовка. Данные сами по себе могут иметь дальнейшую упаковку, или метаданные для извлечения настоящих данных, и т.д.

Две сигнатуры: начало и конец заголовка, каждый на три-пять символов, например. Между ними - данные с разделителем, который тоже формализован. Если нашли два начала заголовка подряд - считаем что второе истинное, мотаем до тех пор пока не наткнёмся на конец, считываем. Если и то и то верно но середина не парсится (неправильное количество разделителей, например) - значит это не заголовок. Это я придумал ))

Две сигнатуры: начало и конец заголовка, каждый на три-пять символов, например. Между ними - данные с разделителем, который тоже формализован. Если нашли два начала заголовка подряд - считаем что второе истинное, мотаем до тех пор пока не наткнёмся на конец, считываем. Если и то и то верно но середина не парсится (неправильное количество разделителей, например) - значит это не заголовок. Это я придумал ))

Почему отбрасываешь первое начало? Может это другой "блок" данных нашего формата?

Заголовок - сам себе сигнатура, полностью, панимаищь? )))

* Инородные данные * Сигнатура заголовка - Разделитель - Длинна (закодированная в плавающее число байт) - Разделитель - Чексумма длинны - Разделитель - Хеш всего сверху * Наши данные (либо данные, упакованные во второй формат, с чексуммами и т.д., но это уже другое) * Копия первого заголовка

Копия - уже избыточность. И так заебись.

Эм, а если у тебя имя файла - "cool thing [[[ awesome ||| thing ]]]!"?

Я тут подумал, а чего б данные не пихать до заголовка

Копия - уже избыточность. И так заебись.

Избыточность в таком не есть плохо

Неправильное количество данных в разделителе )) А вот если вот такое: "крутой файл [[[очень крутой файл|||5124|||deflate]]]" - то да, не покатит. Найди человека который будет так называть файл )))

О, кстати. Можно и это обойти.

В сигнатуре начала-конца заголовков присутствуют непечатаемые ascii-символы.

Неправильное количество данных в разделителе )) А вот если вот такое: "крутой файл [[[очень крутой файл|||5124|||deflate]]]" - то да, не покатит. Найди человека который будет так называть файл )))

Или мой ||| крутой ||| файл ]]]

Заголовок неверен, а хвост реального не замечен.

Не распарсится. Вместо "крутой" - должны быть цифры, вместо "файл" - должно быть слово из набора.

рандомные данные [[[данные|||сигнатура|||длинна]]] рандомные данные

Не распарсится. Вместо "крутой" - должны быть цифры, вместо "файл" - должно быть слово из набора.

И ты будешь делать избыточные проверки, пытаться найти такую конфигурацию заголовка, что у тебя он нормальный?