Еще раз про hwid в новом VMProtect (3.8.7)

VMProtect
1

Вот и мы вступили в проблему, описанную тута: https://forum.vmpsoft.com/viewtopic.php?t=31488

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

В нашем случае, проверка совпадения hwid производится ручками согласно алгоритму, опубликованному где-то (что требует совпадения cpu и еще пары компонентов). Хотелось бы, чтобы привязка, сгенерированная с помощью старого вмпротекта, работала и с новым, и наоборот.

Поэтому хотелось бы видеть оба CPUID в hardware id (наверное это можно сделать, просто поместив старый в hwid под неиспользуемым тэгом).

Тогда логика будет такова:

  • Если присутствует только “старый” тэг cpu, то для привязки используем только его (а мы ничего лучше и не сможем придумать)
  • Если присутствуют оба тэга, то в зависимости от ситуации, мы генерируем привязку, используя либо “старый”, либо “новый” cpu, либо оба.

Как вариант, новый CPUID можно публиковать под новым тэгом, и тогда все будет работать “искаропки”. Новый алгоритм (что в курсе про новый тэг) будет использовать улучшенный компонент CPU, а старые версии тоже будут работать на старом компоненте (если, конечно, алгоритм сравнения игнорирует неизвестные тэги).

Смысл всех этих упражнений - обратная совместимость, которая сломалась при текущем положении дел.

Может эту схему можно малой кровью добавить, пусть даже и под переключателем в проекте? Оченнама нада :smiley:

2

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

3

Иван, мы не в Арбитражном Суде Российской Федерации и не пытаемся выяснить, кто кому сколько виноват.

Мы, как клиенты, платящие деньги, хотим определенную функциональность от приобретенного продукта, и предлагаем свое видение решения проблемы, возникшей в процессе апдейта на более новую МИНОРНУЮ версию.

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

ЗЫ: А вот интересно, заработает ли серийник, сгенерированный на основе нового hwid, в приложении, защищенном старой версией? Люди, бывает, ставят несколько версий одного приложения одновременно.

4

Я вижу следующее решение своей проблемы - вы сами добавляете к HWID любые необходимые данные, в том числе и предыдущий алгоритм подсчета CPUID:

	enum BlockType {
		BLOCK_CPU,
		BLOCK_HOST,
		BLOCK_MAC,
		BLOCK_HDD,
	};
	
...	

	int info[4];
	__cpuid(info, 1);
	if ((info[0] & 0xFF0) == 0xFE0) 
		info[0] ^= 0x20; // fix Athlon bug
	info[1] &= 0x00FFFFFF; // mask out APIC Physical ID
	info[2] = 0;
	
	AddBlock(info, sizeof(info), BLOCK_CPU);
	
...

void HardwareID::AddBlock(const void *p, size_t size, BlockType type)
{
	SHA1 hash;
	hash.Input(reinterpret_cast<const uint8_t *>(p), size);
	uint32_t block = __builtin_bswap32(*reinterpret_cast<const uint32_t *>(hash.Result()));

        // TYPE_MASK = 3
        
	block &= ~TYPE_MASK; // zero two lower bits
	block |= type & TYPE_MASK; // set type bits

...
5

Вот огроменное спасибо! Вы лучший!