Лидеры

Всем привет! Накануне я решил создать свой полноценный Банк, но пока я его делал, решил, что это будет карта на прохождение и специально допустил пару уязвимостей. (На самом деле я решил сделать карту на прохождение потому, что мне было лень их фиксить :d). Суть карты в том, что необходимо взломать банк и получить 10000$ на банковской карте. Уязвимости довольно скрыты и предстоит помучаться чтобы их найти, уязвимостей всего две. Первая - глобальная, средней сложности. Вторая - очень скрытая, высокая сложность. На карте так же реализовано подобие вышки, которое позволяет отправлять пакеты друг другу не напрямую, а через эту вышку. Так-же эта вышка помогает покрыть этим "интернетом" всю карту (необходимо поставить много вышек по всей карте) и преодолеть ограничение радиуса отправления пакетов. Банковская карта реализована RFID меткой. На карте присутствует банкомат, сервера, ваш домик и немного налички в сундуке. Правила карты (На вашу совесть, чтобы было интересно): Запрещается использовать компьютеры, кроме своего. (Просматривать логи сервера банка и сервера вышки на экране разрешено). Запрещается просмотр исходников серверов. Запрещается ломать блоки. (Карта в режиме приключения, но читы включены) Так-же имеется библиотека на вашем компьютере для работы с внутренним интернетом, находится она по пути: /lib/gsm.lua Строения на карте: 1. Вышка интернета. 2. ДЦ Сбербанк. 3. Офис Сбербанк. (Компьютер не трогать в нём) 4. Банкомат. 5. Домик кулхацкера. Подсказки по прохождению карты можно попросить у меня во ВКонтакте: https://vk.com/superrolan51 Ссылка на небольшой ролик по карте: Клик Ссылка на сборку: Клик Ссылка на портативную сборку от @Asior: Клик (Для версии Forge 1.7.10) Удачи в взломе! P.S. Не пишите в комментариях подсказки к карте

Часто необходимо писать программы для серверов. Это могут быть сервера для чатов, или файловые облака или что то еще, но всегда приходится писать велосипеды. Подумав об этом я решил написать программу для сервера. Программа работает просто. Подгружает модули из папки проекта, а потом начинает слушать все event'ы и обрабатывать. Представляю вам саму программу: Servercore v0.2.1 Исходный код: http://pastebin.com/NASX9sX0 Использование: Создаем папку проекта Создаем в этой папке файл .servercore Запускаем servercore указывая первым аргументом папку которую мы создали. Если не указывать аргумент то servercore запустится в рабочей директории. Наслаждаемся рабочим сервером, который пока ничего не делает. Любые файлы (кроме .servercore) которые находятся в папке проекта будут загружены как модули. Если модуль содержит ошибку наш сервер не полетит, а просто выведет тест ошибки на экран. При создании модулей можно использовать специальные функции, которые находятся в _G.sc. Описание этих функций: sc.info(info_type:string, message:string) - выводит информацию со временем и раскрашивает как на скринах. Принимает тип информации и само сообщение. Типов информации всего 4: ok,err,warn и info. sc.getTime() - возвращает время в формате unix timestamp. sc.on(event_name:string,handler:function) - добавляет слушателя на сигнал. Циклом слушаются все сигналы а потом запускают функцию обработчик для того сигнала который пришел. Пример простейшего модуля: sc.on("touch",function (e) sc.info("info","you touched!")end) Изменения в версии: Патч 1: убрана обязательная поддержка модемов. Старые версии: Произведение «Servercore» созданное автором по имени LeshaInc, публикуется на условиях лицензии Creative Commons «Attribution-NonCommercial-NoDerivatives» («Атрибуция — Некоммерческое использование — Без производных произведений») 4.0 Всемирная. PS: Название проги звучит как поджанр метала)))

По этой теме уже существует отлаженный софт, успешно используемый многими игроками. Однако на днях я заметил забавную особенность местных видеокарт, позволяющую выставлять разрешение большее, нежели получаемое через gpu.maxResolution(). К примеру, если maxResolution для видеокарты третьего уровня вернет числа 160 и 50, то никто не мешает установить разрешение, скажем, в 20x158 пикселей. При этом при проверке валидности устанавливаемого разрешения соблюдается два правила: Результирующее разрешение по числу пикселей не должно превышать результат умножения чисел, возвращаемых maxResolution. То есть для T3 GPU не более 160 * 50 = 8000. Каждый параметр разрешения, будь то ширина или высота, не должен численно превышать значение возвращаемой ширины. То есть для T3 GPU не более 160. Не знаю, баг это или фича, однако подобное грех не использовать в своих целях. К примеру, старая версия программы при вертикально-удлиненном расположении мониторов позволяла выставить разрешение лишь в 30х50 (1500 пикселей в итоге), заполняя тем самым "черные полосы". В то же время обновленная софтина, учитывающая описанные выше особенности, выдает 69x114 (7866 пикселей), максимально приближаясь к предельной отметке в 8000: Согласитесь, лишние пиксели на дороге не валяются, и, думаю, кому-то будет интересно узнать про реализацию подобного софта. Прежде всего нам требуется определить точную пропорцию мультиблочного монитора: то, как относится его ширина к высоте. Взглянем на текстуру блока: она явно состоит из мелких "квадратиков" в количестве 16 штук, причем лицевая часть монитора имеет рамку толщиной в 2 "квадратика" с каждой стороны: Эти "квадратики" мы и будем использовать для расчета пропорции, так как они позволяют идеально точно получить размеры отображающей части монитора в игровом мире. А размеры "в квадратиках" можно посчитать по формуле: число_блоков_монитора * 16 - 4 Следовательно, пропорция монитора будет считается следующим образом: local gpu = component.gpu local screen = component.proxy(gpu.getScreen()) local blockCountByWidth, blockCountByHeight = component.screen.getAspectRatio() local proportion = (blockCountByWidth * 16 - 4) / (blockCountByHeight * 16 - 4) Также не забываем, что высота каждого псевдографического пикселя при отображении в 2 раза больше его ширины, поэтому формула пропорции слегка меняется. Заодно произведем некоторые сокращения, чтобы избавиться от лишних математических операций. Все три варианта эквивалентны: local proportion = 2 * (blockCountByWidth * 16 - 4) / (blockCountByHeight * 16 - 4) local proportion = (blockCountByWidth * 16 - 4) / (blockCountByHeight * 8 - 2) local proportion = (blockCountByWidth * 2 - 0.5) / (blockCountByHeight - 0.25) После вычисления пропорции монитора можно приступить к написанию программной логики. Для начала получим максимальное разрешение видеокарты: local maxWidth, maxHeight = gpu.maxResolution() Обладая этими данными, а также взглянув на условия, описанные в начале поста, мы можем составить систему неравенств для получения итогового идеального разрешения: Помним также, что ширину мы вполне можем выразить через высоту и пропорцию монитора: width = proportion * height Подставим этот вариант в систему: Оставим высоту в левой части неравенств: Подставляем имеющиеся переменные в каждое неравенство, рисуем числовую прямую и выбираем высоту, удовлетворяющую условиям неравенства для конкретного случая. Разумеется, в программировании никаких числовых прямых нет, зато есть любимые math.min() и math.max(): local height = math.min( maxWidth / proportion, maxWidth, math.sqrt(maxWidth * maxHeight / proportion) ) -- Выражаем ширину через пропорцию local width = height * proportion Все. Разумеется, полученные значения ширины и высоты нужно округлить в меньшую сторону, дабы не кормить видеокарту дробями. Заодно добавим поддержку масштабирования, чтобы выставлять половинное или, скажем, четвертичное от идеального разрешение. Сократив код, избавившись от лишних переменных, мы получаем следующее: local component = require("component") -- Получаем масштаб в качестве первого аргумента скрипта и корректируем его значение local scale = tonumber(select(1, ...) or 1) if not scale or scale > 1 then scale = 1 elseif scale < 0.1 then scale = 0.1 end local gpu = component.gpu local blockCountByWidth, blockCountByHeight = component.proxy(gpu.getScreen()).getAspectRatio() local maxWidth, maxHeight = gpu.maxResolution() local proportion = (blockCountByWidth * 2 - 0.5) / (blockCountByHeight - 0.25) local height = scale * math.min( maxWidth / proportion, maxWidth, math.sqrt(maxWidth * maxHeight / proportion) ) -- Выставляем полученное разрешение gpu.setResolution(math.floor(height * proportion), math.floor(height)) Надеюсь, это микро-знание кому-то было полезно. Лично я очень доволен, что могу наконец запилить графонистый интерфейс для контроля реакторов на вертикальных мониках без осваивания профессии "глиномес", да и соответствующая либа для автопобора разрешения в оське пригодится.

То чувство, когда автор карты сделал 2 уязвимости, а хакнул через 3ю 🤣, потом после хака я уже понял идею, как можно было хакнуть ещё причём проще, а когда смотрел уже код, я понял, что автор имел ввиду немного не те дыры (интересно то, что все 3 дыры находятся в разных частях кода), скорее всего первую он имел ввиду ту, которую можно сразу сделать без танцев с бубном, а вторую это уже чисто удача или читать исходники. В принципе со стороны кубика, предназначенного для того, чтобы его ломали и разбирали то довольно не плохо, однако выводить в релиз как работоспособую и безопасную систему явно нельзя 😅

Здравствуй, брат автоматизатор! Сегодня я расскажу тебе, как можно оптимизировать постройку рыбной фермы Asior'а. Если ты слишком слаб для чтения длинных текстов, ни в коем случае не открывай спойлер – для тебя есть несколько скриншотов с их кратким описанием. Но если ты хочешь узнать, как можно достичь такого результата, тебя ждет много текста с картинками, а в качестве бонуса — схема постройки сверхкомпактной масштабируемой фермы. Тема оптимизации сложна и обширна, но я не буду говорить о теории. Я покажу процесс оптимизации на практическом примере, как я делаю это сам. Сразу предупреждаю, что я не буду сильно вдаваться в объяснение механики игры, мода OpenComputers, или языка Lua. Всё это ты можешь узнать в блоке «Полезные ссылки» на главной странице проекта. Я скажу больше – без пользования этими ссылками, я бы даже этот текст не смог написать. Скажу еще больше – я дилетант и в MineCraft, и в Lua, и в OpenComputers. Но это не помешает мне оптимизировать схемы, постройки, алгоритмы и коды некоторых игроков. Итог В результате оптимизации получились две очень компактные и при этом красивые схемы, умещающиеся в объеме 3x5x3. Обе они радуют глаз, сохраняют место для прохода и строятся гораздо быстрее схем Asior'а. По моим тестам работают они не хуже исходных, а схема с нижним размещением робота теоретически может работать даже чуть быстрее, но для этого надо немного подправить задержку. Программу придется править в любом случае, т. к. изменилась сторона приема роботом сигнала и сброса дропа. Получение удочек из сундука следует выполнять контроллером инвентаря. [Схема №1] [Схема №2] Отличия построек незначительны. В первом не требуется тянуть редстоун, а робот может использовать для зарядки солнечную панель. Второй вариант может оказаться более быстрым, но для проверки этого придется переписать код, отвечающий за работу с датчиком. В остальном – одни недостатки: робот от солнечной панели не работает, редстоун дотягивается, но некрасиво, или же требуются провода RedLogic. И для компактного масштабирования потребуются цветные провода того же RedLogic. Кусок красного провода на правом столбе использован для симметрии блока воды, его можно заменить табличкой или стеклом. Место для зарядника имеется в обеих схемах, даже эстетика не сильно пострадает от его установки. Бонус Стать рыбным магнатом теперь стало проще. С незначительной доработкой схема легко масштабируется во всех измерениях, позволяя исключить смежные блоки и за счет этого в идеале получить ячейку с размером 1x4x3. Сколько их можно скрыть в одном чанке под землей, можешь сам посчитать. Но будь осторожен, брат: OKA следит за тобой и является органом, способным превратить твой приват в радиоактивный пепел. А теперь тесты! Устанавливай программу Asior'а, затем в зависимости от выбранной схемы настраивай в программе сторону, с которой расположен сигнал редстоуна, а также сундук для дропа. И получение удочек из того же сундука тоже придется написать. Главное, что интересовало в тестах меня: как часто происходят сбои заброса удочки, как часто вытягивается пустой крючок, и каков диапазон времени ожидания. Для этого придется добавить в программу соответствующие счетчики. Они помогут выявить неправильную работу либо программы, либо общей схемы. Может, крючок удочки за что-то цепляется. Может, дроп не доходит до инвентаря робота. Может, времени ожидания недостаточно. Что именно нужно изменить в программе, пока не скажу, и так уже много текста, но ты ж программист, брат! Может, и Asior что напишет, он шустрее меня. Не прощаюсь. Напоследок перефразирую Asior'а: Грызи знания, брат. В них сила.

@eu_tomat, твои компактные схемы не работают на 1.12. А оригинальный вариант (не эконом, от @Asior) работает. Похоже, робот должен располагаться над нитью. Вот мой компактный вариант:

Мяу, не надо каждый файл, надо одну единственную документацию. Если возникают вопросы или желания по реализации каких-то фич, то пиши в тему либы или мне в личку ВК. Если лень изучать конкретно эту либу или же она по каким-то причинам не устраивает, то есть аналоги, например, forms.