Взлом 1с битрикс

Доброго времени суток!

Сегодня я опишу возможность легального продления демо версии Битрикс.

Зачем это нужно?

Часто бывает что не успеваешь уложиться в отведенное демо версией время. Перенос данных это отдельная долгая тема. Но есть быстрый рабочий вариант, на данный момент к примеру в версии Битрикс Корпоративный Портал 16.0.4″ он не закрыт.

Можно ли создать сайт на 1С Битрикс не имея на него лицензию?

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

Практика:

1. Ставим на локальной машине веб-установщик сборки нового битрикса.

2. После успешной установки, заходим в панель администрирования в только что установленную сборку, в разделе «sql запрос» и вытаскиваем из таблицы b_option хеш:

SELECT * FROM b_option WHERE `NAME`=’admin_passwordh’

Результатом выполнения будет вывод примерно такой:

NAME=>admin_passwordh VALUE=>FVkQfGYUBgYtCUVcBhcECgsTAQ==

Копируем значение «FVkQfGYUBgYtCUVcBhcECgsTAQ==». Затем заходим в панель администрирования битрикса которую нужно продлить. Так же в разделе «sql запрос» выполняем код: 

UPDATE b_option

SET `VALUE` = ‘FVkQfGYUBgYtCUVcBhcECgsTAQ==’

WHERE `NAME`=’admin_passwordh’

3. Так же нужно взять значение из только что установленной версии битрикс, из файла /bitrix/modules/main/admin/define.php

define(«TEMPORARY_CACHE», «ARtsfwYHb2MMdAgebRtkG2sA»);

Забираем хэш и заменяем его в файле битрикс с истекшей лицензией в том же файле. Через любой текстовый редактор.

4. Обязательно очищаем папку /bitrix/managed_cache/ в старом битрикс.

Итого:

Если все действия были выполнены в прямой последовательности, то в старом битрикс, должны обновиться количество дней до истечения демонстрационной версии.

Метод на данный момент проверен и работает.

Он хорош несколькими моментами, а именно:

  1. Вы имеете на руках легальный ключ от демо версии.
  2. 1С не запрещает, устанавливать и использовать многократно демо версии.
  3. Нет взлома и подмены лицензионных ключей.
  4. Всегда есть возможность чуть-чуть продлить срок демо, который иногда очень нужен.

Хочу отметить что статья приведена в ознакомительных целях! Все, что Вы делаете, делаете на свой страх и риск, автор статьи никакой ответственности не несет.

Безопасность сайта складывается из трех вещей:

  1. безопасности программной части (CMS, скриптов)
  2. безопасности сервера (хостинга)
  3. осведомленности и аккуратности администратора сайта или тех, кто работает с сайтом как администратор

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

Надежность программной части

Программная часть — это система управления сайтом (Joomla, WordPress, Bitrix и др) или скрипты, на которых работает сайт. Надежность программной части подразумевает отсутствие уязвимостей («дыр»), позволяющих злоумышленнику получить доступ к базе данных, файловой системе или панели администратора сайта.

Продление демо битрикс

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

Если сайта работает на одной из популярных систем управления сайтом, нужно следить за обновлениями и патчами, и своевременно обновлять CMS до самой последней доступной версии.

Если сайт работает на скриптах собственной разработки, нужно выполнить сканирование сайта доступными средствами поиска уязвимостей (XSpider’ом, Acunetix Web Vulnerability Scanner’ом, утилитами для поиска SQL иньекций, XSS, RFI и другими), проверить исходный код сайта средствами статического анализа исходного кода (RIPS) и, если обнаружатся уязвимости, исправить их. Кроме регулярных обновлений скриптов и CMS есть еще один важный момент, усиливающий безопасность и надежность скриптов — это правильная конфигурация сайта. Необходимо:

  1. грамотно прописать права на файлы и директории
  2. закрыть доступы к внутренностям сайта (каталогам с резервными копиями, конфигурационным файлам и пр)
  3. запретить выполнение скриптов в директориях загрузки
  4. поставить дополнительную защиту на вход в панель администратора
  5. и др.

Данные меры позволяют значительно снизить вероятность взлома сайт, даже при наличие уязвимостей в программной части.

Безопасность сервера (хостинга)

Вторым важным моментом, влияющим на безопасность сайта в целом, является хостинг, на котором размещается сайт. Хостинг может быть shared («общий») или dedicated («выделенный»).

Для shared-хостингов ответственность за безопасную настройку сервера лежит на администраторе хостинг-компании. Для dedicated-сервера (VDS/VPS/DDS) эта ответственность лежит на владельце сервера.

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

Обо всем этом должен позаботиться системный администратор сервера.

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

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

Осведомленности и аккуратности администратора сайта

Владельцы сайта, обычно, уделяют мало внимания вопросам безопасности, предполагая, что программная часть безупречна, настройки сервера надежны и безопасны. Хотя собственная беспечность наиболее часто является причиной взлома сайтов и заражения вирусами.

Ниже приведен чеклист, который должен постоянно держать в голове администратор (владелец) сайта:

  1. Компьютер, с которого выполняется работа с сайтом, должен быть защищен коммерческим антивирусным программным обеспечением и регулярно им проверяться. Если с сайтом работает несколько человек, данное требование применяется к каждому.
  2. Пароли от ftp/ssh/панели администратора нужно менять регулярно, хотя бы раз в месяц
  3. Не хранить пароли в программах (ftp-клиентах, браузере, электронной почте)
  4. Ставить сложные пароли вида «Xhsdf3@4%4»
  5. Работать по безопасному протоколу SFTP или SCP

Итог

Чтобы сайт был защищен от вирусов и хакеров, нужно достаточно много внимания уделять проблеме безопасности: поддерживать программное обеспечение в актуальном состоянии, правильно настраивать хостинг и следить за доступами к сайту. Если хотя бы один из трех элементов будет слабым звеном, сайт останется уязвимым.

По вопросам защиты сайта вы всегда можете обратиться к специалистам.

Способы #1-3 – тривиальные

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

В случае, когда проект размещен на хостинг-площадке, возможности изменить время практически никогда нет. Тут можно посоветовать скачать сайт на локальный компьютер и продолжить работу на нем, опять же подкорректировав время.

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

Способ #4 – отключаем проверку

Для реализации этого способа необходимы навыки программирования на php. Открываем в редакторе файл /bitrix/modules/main/include.php – он в закодированном виде, но код php в нем явно просматривается (по символам ; { } и командам die, while и т.д.). После каждой (или нескольких) из команд пробуем вставлять строку
view source
print
?
1.
die(«works»);

и обновляем страницу в браузере. Как только надпись «works» сменится на «Срок работы пробной версии продукта истек» – мы дошли до проверки и соответствующий блок кода можно закомментировать. В include.php таких блока 2 – один в середине (цикл for) и один в конце файла (цикл while).

Это еще не все, теперь необходимо закомментировать явные проверки в незакодированных файлах, их всего 2:
/bitrix/modules/main/include/prolog_after.php
/bitrix/modules/main/tools.php

Комментируем строки вида
view source
print
?
1.
if(OLDSITEEXPIREDATE != SITEEXPIREDATE)
2.
die(GetMessage(«expire_mess2″));

После этого сайт должен заработать, если что-то не получилось – попробуйте сначала Не забывайте делать резервные копии файлов перед изменением!
Способ #5 – деобфусцируем код

Как оказалось, расшифровать файлы Битрикса довольно несложно. Работать будем опять же с файлом /bitrix/modules/main/include.php. Задача состоит в том, чтобы сделать на его основе удобочитаемый код, в котором видны определения констант и используемые функции. Потом можно будет более осмысленно комментировать\добавлять\удалять строки в оригинальном зашифрованном файле.

Итак, копируем include.php в отдельную директорию, например, /bx/ Далее, открываем его в адекватном текстовом редакторе и видим, что он состоит из 2х массивов, большой функции и некоторого php-кода. Каждый из блоков находится в своих угловых скобках. Первым делом, стандартной функцией замены редактора преобразуем во всем документе
— имя первого массива из вида $GLOBALS[‘_____12332445355′] в $array1
— имя второго массива из вида $GLOBALS[‘_____34434535353′] в $array2
— имя функции из вида ‘___344590092? в ‘func1?

Теперь первые 3 части нужно вырезать и вставить в другой php файл, например decode.php Добавим в него несколько простых строк, которые довольно хорошо расшифруют оставшуюся часть /bx/include.php
view source
print
?
01.
function forArr1($pockets) {
02.
return $array1[$pockets[1]];
03.
}
04.
function forArr2($pockets) {
05.
return $array2[$pockets[1]];
06.
}
07.
function forArr3($pockets) {
08.
return ‘»‘.func1($pockets[1]).’»‘;
09.
}
10.

11.
$fileTxt = file_get_contents(«include.php»);
12.

13.
$newstr = preg_replace_callback(«#array1\[(\d+)\]#s», «forArr1″, $fileTxt);
14.
$newstr2 = preg_replace_callback(«#array2\[(\d+)\]#s», «forArr2″, $newstr);
15.
$newstr3 = preg_replace_callback(«#func1.(\d+).#s», «forArr3″, $newstr2);
16.

17.
file_put_contents(«include-decode.php», $newstr3);

Все, в файле include-decode.php будет содержаться вполне читабельный код.

Что нам это дало?

Стальная CMS

Как минимум, мы можем найти строку где определяется константа DEMO=Y и заменить ее на DEMO=N. Это позволит убрать проверки из других 2х файлов (см. способ 3).

Про более вкусные возможности читаем дальше.
Принцип проверки демонстрационного периода.

Внимательно проанализировав полученный код, выяснилось, что:
— дата окончания тестового доступа хранится в зашифрованном виде в 2х местах – это
1. файл /bitrix/modules/main/admin/define.php
2. в БД в таблице b_option в поле ‘value’ строки name=’admin_passwordh’
— шифруется дата одним алгоритмом, но с 2 разными строками-параметрами

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

Код для записи в файл:
JjdufiwmbmM1diInbS5kJG1jdHJl
Код для записи в БД:
FlsqelcHBwYHC0VTBzcGPlhTARNpVlg=

После замены значения в базе данных обязательно очистите каталог /bitrix/managed_cache/
Способ #6 – все гениальное – просто!

Запись опубликована в рубрике Без рубрики с метками Bitrix, Crack, вечное демо. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Закрыть меню