Размещение файлов в экзешнике

[Kultura]

пусть файл сделает свою копию и туда записывает изменения. А при окончании работы пусть подменяет себя копией

собственно, как подменить: сделать в своей программе ключ, при запуске с которым программа смотрит параметры - что скоировать, куда скопировать. Копирует и завершается

3 вопроса 

1) Как сделать ключ?
2) Реализовать запуск при одном ключе одного, а при другом - другого.
3) Сделать копию самого себя ?

[Алексей++]

1)
запуск экзешника с параметрами

Код:

STARTUPINFO si;
PROCESS_INFORMATION pi;
memset(&si,0,sizeof(si));
si.cb=sizeof(si);
memset(&pi,0,sizeof(pi));
::CreateProcess(0,"111.exe -copy \"xxx\" \"yyy\"",0,0,0,NORMAL_PRIORITY_CLASS,0,0,&si,&pi);

при запуске в экзешнике смотришь, что передано в параметры. Еси там есть строка "-copy " , то берёшь оба пути из кавычек и копируешь

Код:

::CopyFile(csPathFrom,csPathTo,0)

затем, раз был указан ключ, завершаешь работу

Код:

//в initinstance
m_pMainWnd->PostMessage(WM_QUIT,0,0);
return 0;

[Kultura]

Алексей1153++ понятно, спасибо.
А пока все еще пытаюсь преобразовать массив - картинку в HBITMAP

[Алексей++]

Kultura, для битмапа ресурс описан вот так

IDB_xxxx - идешник

*.rc

Код:

/////////////////////////////////////////////////////////////////////////////
//
// Bitmap
//

IDB_xxxx     BITMAP  DISCARDABLE     "res\\xxxx.bmp"

грузится так

Код:

The LoadBitmap function loads the specified bitmap resource from a module's executable file. This function has been superseded by the LoadImage function. 

HBITMAP LoadBitmap(
  HINSTANCE hInstance,  // handle to application instance
  LPCTSTR lpBitmapName  // name of bitmap resource
);
Parameters
hInstance 
[in] Handle to the instance of the module whose executable file contains the bitmap to be loaded. 
lpBitmapName 
[in] Pointer to a null-terminated string that contains the name of the bitmap resource to be loaded. Alternatively, this parameter can consist of the resource identifier in the low-order word and zero in the high-order word. The MAKEINTRESOURCE macro can be used to create this value. 
Return Values
If the function succeeds, the return value is the handle to the specified bitmap.

If the function fails, the return value is NULL. 

Windows NT/2000/XP: To get extended error information, call GetLastError.

Remarks
If the bitmap pointed to by the lpBitmapName parameter does not exist or there is insufficient memory to load the bitmap, the function fails. 

LoadBitmap creates a compatible bitmap of the display, which cannot be selected to a printer. To load a bitmap that you can select to a printer, call LoadImage and specify LR_CREATEDIBSECTION to create a DIB section. A DIB section can be selected to any device.

An application can use the LoadBitmap function to access predefined bitmaps. To do so, the application must set the hInstance parameter to NULL and the lpBitmapName parameter to one of the following values. 

[Kultura]

Алексей1153++, спасибо, но это не совсем то

Я пытаюсь массив, сгенерированный хекс-редактором (способ хранения любых файлов в экзешнике, предложенный RuNTiME, см. ответ 7) преобразовать в HBITMAP.
Т.е. картинки у меня - обычные unsigned char константные массивы.

Пока из успехов - прочитал BITMAPFILEHEADER и BITMAPINFOHEADER тупым копированием из начала массива (эти структуры в формате bmp идут сначала друг за другом см. , например, http://jenyay.net/index.php?id=bmp). Дальше пытаюсь выделить массив цветов, пока не получается

[Алексей++]

Kultura, не занимайся ерундом массивы хексов - это неудобно и негибко, а ещё гора текстового кода. Который компиляторушка компилирует

Сделай картинки ресурсами и не парься. А редактировать сможешь хоть в паинте.

[zubr]

Алексей1153++, это точно работает (вариант в твоем посте #31)?
 Что то мне сомнительно, ведь копирование происходит все равно на работающий экзешник.

[Алексей++]

zubr, работает, но этот код надёрган из MFC проекта и всё MFC-шное не показано (так как человеку нужно только АПИ), поэтому так куцо. Тут только идея показана. А насчёт копирования на работающий экзешник - происходит синхронизация:

1) exe1 запускает exe2 с ключом и тут же останавливается себя
2) exe2 пытается удалить exe1, пока это не удастся (можно ещё учесть флажок ReadOnly, чтоб не зависнуть, если это на CD), затем копирует.

У меня так сделано обновление экзешника, когда доступна новая версия Он сам себя обновляет и перезапускет

[Kultura]

Алексей1153++, не, массивы хексов - тоже вариант. Музыка у меня уже в таком виде, надо придерживаться общего стиля 
И я так понял, ресурсы будут отдельно от экзешника, а массивы хексов в экзешнике + позволяют защитить художественный арт (см. рис.) от недобросовестных пользователей   

[Алексей++]

Kultura, по твоему - защитить, это что ?

[Kultura]

Алексей1153++, защитить - это поставить рядом от 2-х крепких ребят   
А мне надо скрыть, запрятать, в общем убрать с глаз долой (об этом и вся тема).

Кстати, так же напрямую дописывают в конец экзешника нужные данные. Может кто умеет так?  Научите

[Алексей++]

Kultura, скрыть с глаз не получится - принт скрин и всё
берёшь всё тот же бинарный ресурс, шифруешь - вот тебе и защита в некотором роде

[zubr]

Алексей1153++, от принт-скрина тоже можно защитить, к примеру перехватом и блокировкой определенных API-функций.

[Алексей++]

zubr, Всё не перехватишь. А ещё можно сфоткать экран цифровиком

[zubr]

Алексей1153++, ну их (функций) не так и много - BitBlt, StretchBlt, GetDIBits.
Ну или ставишь видео-драйвер минипорта, который есть в примерах DDK.
Насчет цифровика - против лома не приема, если нет другого лома

[Алексей++]

да, то есть остаётся

поставить рядом от 2-х крепких ребят   

- с ломами, чтобы отгонять цифровики )

[RuNTiME]

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

[Kultura]

RuNTiME, нет такой задачи не стоит. Все, что от меня требуется - скрыть все файлы в экзешнике, просто что бы не мешались.

Впринципе, вариант - все в архив и под шифр - тоже подходит. Но так будет 2 файла: архив и экзешник.
И задача уже другая. Проблема - как шифровать + нужно разместить этот шифрованый архив в экзешнике.

Может быть тогда этот шифрованый архив из хекс-редактора и в массив?

[RuNTiME]

Kultura, если тебе 100% нужно засунуть все ресурсы в исполняемый файл, то смысла запихивать ресурсы в архив думаю нет. Смысл был бы если хранить архив отдельно от исполняемого модуля. А если ты уж собрался шифровать ресурсы (только понять не могу зачем?), то зашифровать их можно и по отдельности, а потом запихнуть в массив. Что касаясь шифрования, лучше всего взять готовые алгоритмы из таких модулей как openssl или libcrypto, ну и подобных опенсорс библиотек. Но если подумать, смысл шифровать ресурсы? Говоря простым языком ты помещаешь зашифрованную информацию и пароль доступа в одном месте Если перед тобой стоит задача просто скрыть ресурсы от стандартных распаковщиков, то с успехом можно использовать операцию XOR и не мучаться

[zubr]

Говоря простым языком ты помещаешь зашифрованную информацию и пароль доступа в одном месте

Ну, не обязательно ключ ложить в ресурс. Что мешает программе его генерировать по специальному алгоритму?

[RuNTiME]

Ну, не обязательно ключ ложить в ресурс. Что мешает программе его генерировать по специальному алгоритму?

zubr, это не намного затруднит задачу а в итоге получиться то же самое. Никто не помешает зареверсить алгоритм генерации, или вообще тупо скопировать ключ, после его генерации. (я подобным образом вытаскивал забытые пароли из программы QIP, 5 минут в OllyDbg).

Есть неплохой способ спрятать ключи:
1. Выделяется достаточно большой кусок памяти, к примеру 1МБ.
2. Инициализируется случайным мусором.
3. Генерируется случайный ключ и записывается в произвольное место на выделенных просторах
4. Ключом расшифровываются ресурсы.

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

[Алексей++]

Kultura, налепи водяные знаки и успокойся

[Kultura]

Решена проблема с картинками:

1) Как и со звуком использовал массивы, сгенерированные хекс-редактором.

2) Может быть, есть способ проще, но устройство бмп-формата изучить пришлось.
Был написан класс для преобразования картинок из бинарного вида в HBITMAP. Речь шла о выполни двух различных преобразований. Преобразование исходного формата картинки (1,4,8,16,32 б/т) в тот же самый формат и в формат 32 б/т. Выкладываю исходник сюда. Когда создавал эту тему, мне такой класс был нужен (хотя узнал это только через несколько постов  ), может быть еще кому пригодится.
   

[Алексей++]

Kultura, изучи GDI+ , там любой формат картинок хорошо выводится

[Kultura]

Алексей1153++, а для меня, в данном случае, именно по HBITMAP задача стояла. Ну а дальше эти картинки через xxxBlt выводятся, и больше ничего с ними не происходит.

[Kultura]

Функцию нашел для добавления записи в таблицу строк или изменения существующей.
В ней есть какая-то ошибка, помогите найти

Код:

void AddRTString (LPCTSTR lpFileName, WORD id, WORD wLanguage, LPCWSTR lpStr)
{
	DWORD dwResSize;
	WORD wStrLen, wStrIndex;
	WCHAR *pRes, *pOldRes;
	HANDLE hHeap;
	HANDLE hUpdateRes;
	HMODULE hModule;
	HRSRC hResInfo;

	wStrIndex = id&0xF;
	wStrLen = (WORD) lstrlenW (lpStr);
	hHeap = GetProcessHeap ();
	hModule = LoadLibrary (lpFileName);
	hResInfo = FindResource (hModule, MAKEINTRESOURCE ((id>>4)+1), RT_STRING);
	if (hResInfo)
	{
		WORD i, wLen;
		WCHAR * pTmp;
		DWORD dwOldResSize = SizeofResource (hModule, hResInfo);
		dwResSize = dwOldResSize + sizeof (WCHAR) * wStrLen + sizeof (WORD); // Пофигу.. и так сойдёт %)
		pTmp = pRes = (LPWSTR) HeapAlloc (hHeap, 0, dwResSize);
		pOldRes = (WCHAR *) LockResource (LoadResource (hModule, hResInfo));
		for(i = 0; i < 16; i++)
		{
			wLen = * pOldRes;
			if (i == wStrIndex)
			{
				*pTmp = wStrLen;
				lstrcpyW (++pTmp, lpStr);
				pTmp += wStrLen;
			}
			else 
			{
				*pTmp = wLen;
				lstrcpynW (++pTmp, ++pOldRes, wLen + 1);
				pTmp += wLen;
			}
			pOldRes += wLen;
		}
		dwResSize = (LPBYTE)pTmp - (LPBYTE)pRes;
	}
	else
	{
		dwResSize = sizeof (WORD) * 16 + sizeof (WCHAR) * wStrLen;
		pRes = (LPWSTR) HeapAlloc (hHeap, HEAP_ZERO_MEMORY, dwResSize);
		pRes [wStrIndex] = wStrLen;
		lstrcpyW (&pRes [wStrIndex + 1], lpStr);
	}
	FreeLibrary (hModule);

	hUpdateRes = BeginUpdateResource (lpFileName, FALSE);
	UpdateResource (hUpdateRes, RT_STRING, MAKEINTRESOURCE ((id>>4)+1), wLanguage, pRes, dwResSize);
	EndUpdateResource (hUpdateRes, FALSE);
	HeapFree (hHeap, 0, pRes);
}

Передаем название экзешника, ид строки, и новую строку (которую пишем).

Проблема в следующем: функция нормально записывает новые строки и, в большинстве случаев, не работает для перезаписи. BeginUpdateResource (lpFileName, FALSE) возвращает 0.
При этом все таки перезаписываются некоторые строки (в моем приложении всего одна).

Вот фрагмент таблицы строк из *.rc файла:

Код:

IDM_HIGHSCORES				  " Player best results"
IDS_LEVEL1_1					"3333333333333333333"
IDS_LEVEL1_2					"3111111113111111113"

Строка IDS_LEVEL1_1 перезаписывается в любых вариантах. Для всех других строк перезапись не работает и  BeginUpdateResource (lpFileName, FALSE) возвращает 0.

Помогите разобраться, в чем проблема?

Дополнение от 25.04:
1) Функция выполняет перезапись только для номеров ид, которые при операции (id & 0xF) выдают 0xF, т.е. оканчивающиеся на 1111 в двоичном виде
2) Функция выполняет запись новых строк для всех номеров ид, кроме оканчивающихся на 1111 в двоичном виде.
Ошибку исправить все еще не могу, т.к. не совсем понимаю, что происходит в цикле и после else.