C / C++ / MFC

11-Apr-09 8:35

im trying to get RecentDocs registry info and put it in a listctrl the name part works fine but the data part i only get the first letter

#define MAX_KEY_LENGTH 255
#define MAX_VALUE_NAME 16383
	TCHAR achValue[MAX_VALUE_NAME]; 
	DWORD cchValue = MAX_VALUE_NAME; 
	HKEY hKey;
	dwData = MAX_VALUE_NAME;
	cchValue = MAX_VALUE_NAME; 
	achValue[0] = '\0'; 
	retCode = RegEnumValue(hKey, i, 
		achValue, 
		&cchValue, 
		NULL, 
		&dwType,
		(BYTE*)lpData,
		(LPDWORD)&dwData);

	if (retCode == ERROR_SUCCESS ) 
	{ 
		m_list.InsertItem(index, achValue);
		m_list.SetItemText(index, 1, lpData);
		index++;
	}

im using vs 2008 and mfc can anyone tell me where im going wrong? Confused | :confused:

Baltoro11-Apr-09 11:21

Baltoro

11-Apr-09 11:21

Your attempting to pass a binary string to a function that expects a TCHAR string. You should convert it to some meaningful character string format first. The function will interpret the each byte of the binary value as char (char is a byte).

locoone11-Apr-09 20:09

11-Apr-09 20:09

i forgot to add these

TCHAR lpData[MAX_VALUE_NAME];
 DWORD dwType = REG_BINARY;
 DWORD dwData = MAX_VALUE_NAME;

but it is a TCHAR so im still lost as to what to do to fix it Frown | :(

CPallini11-Apr-09 22:46

11-Apr-09 22:46

Is yours a ANSI build (i.e. not UNICODE)?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

locoone12-Apr-09 2:53

12-Apr-09 2:53

yes, its not unicode.

CPallini12-Apr-09 9:58

12-Apr-09 9:58

Change:

locoone wrote:
if (retCode == ERROR_SUCCESS )
{
m_list.InsertItem(index, achValue);
m_list.SetItemText(index, 1, lpData);
index++;
}

if (retCode == ERROR_SUCCESS ) 	
{ 
  CString str = (wchar_t *) lpData;		
  m_list.InsertItem(index, achValue);
  m_list.SetItemText(index, 1, str);
  index++;	
}

locoone12-Apr-09 10:46

12-Apr-09 10:46

i changed it and i now get this error
error C2440: 'initializing' : cannot convert from 'wchar_t *' to 'ATL::CStringT<BaseType,StringTraits>'

CPallini12-Apr-09 11:17

Re: Registry REG_BINARY Problem [modified]

12-Apr-09 11:17

Try (I haven't ATL here so I may only guess)

if (retCode == ERROR_SUCCESS ) 	
{   
    m_list.InsertItem(index, achValue);
    m_list.SetItemText(index, 1, CW2A(lpData));
    index++;
}

locoone12-Apr-09 11:50

12-Apr-09 11:50

that gives the same error Cry | :((

but why am i only getting the first letter and not the whole value? Confused | :confused:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs <--- thats what im tring to get

modified on Sunday, April 12, 2009 11:07 PM

CPallini13-Apr-09 4:46

13-Apr-09 4:46

locoone wrote:
that gives the same error

It shouldn't.

locoone wrote:
but why am i only getting the first letter and not the whole value?

Because lpData contains a UNICODE string, while you need a ANSI one.

Since seems you've troubles with ATL conversion macros, try using the oldie-goldie WideCharToMultyByte [^] function.

For instance (beware: quick and dirty fix):

if (retCode == ERROR_SUCCESS ) 	
{  
   // supposing UNICODE NOT DEFINED
   char buffer[200];
   WideCharToMultiByte(CP_ACP, 0, lpData, -1, buffer, 200, NULL, NULL);     
   m_list.InsertItem(index, achValue);
   m_list.SetItemText(index, 1, buffer);
   index++;
}

locoone13-Apr-09 12:40

Removing the MS-DOS stub from a PE File

13-Apr-09 12:40

that worked thanks man Big Grin | :-D

iNoble11-Apr-09 8:05

11-Apr-09 8:05

i was looking all over the net for that function and i found it in one of the best PE Protectors (yoda's protector)
i tried to strip that function but i cant seem to get it right , it erase alot more than the DOS Stub

if hope some1 can give me some pointers or the solution i would be grateful

IMAGE_DOS_HEADER	image_dos_header;<br />
	IMAGE_NT_HEADERS	image_nt_headers;<br />
    HANDLE hFile,hFMap;<br />
    LPVOID FBase;<br />
	LPBYTE lpFile;<br />
<br />
	DWORD bufFileSize,dwBytesRead,dwBytesWritten;<br />
<br />
    hFile = CreateFile("C:\\test.exe", GENERIC_READ, FILE_SHARE_READ, NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);<br />
        bufFileSize = GetFileSize(hFile, NULL);<br />
		lpFile = new BYTE[bufFileSize];<br />
	ReadFile(hFile, lpFile, bufFileSize, &dwBytesRead, NULL);<br />
	CloseHandle(hFile);<br />
<br />
	hFMap = CreateFileMapping(hFile, NULL, FILE_MAP_ALL_ACCESS, 0, 0, NULL);<br />
    FBase = MapViewOfFile(hFMap, FILE_MAP_ALL_ACCESS, 0, 0, 0);<br />
<br />
	CopyMemory(&image_dos_header,lpFile,sizeof(IMAGE_DOS_HEADER));<br />
	CopyMemory(&image_nt_headers,lpFile + image_dos_header.e_lfanew,sizeof(IMAGE_NT_HEADERS));<br />
<br />
<br />
	image_dos_header.e_cblp		= 0x0040;<br />
	image_dos_header.e_cp		= 0x0001;<br />
	image_dos_header.e_crlc		= 0x0000;<br />
	image_dos_header.e_cparhdr	= 0x0002;<br />
	image_dos_header.e_minalloc	= 0x0004;<br />
	image_dos_header.e_maxalloc	= 0xFFFF;<br />
	image_dos_header.e_ss		= 0x0002;<br />
	image_dos_header.e_sp		= 0x0040;<br />
	image_dos_header.e_csum		= 0x0000;<br />
	image_dos_header.e_ip		= 0x000E;<br />
	image_dos_header.e_cs		= 0x0000;<br />
	image_dos_header.e_lfarlc	= 0x001C;<br />
	image_dos_header.e_ovno		= 0x0000;<br />
	image_dos_header.e_res[0]	= 0x0000;<br />
	image_dos_header.e_res[1]	= 0x0000;<br />
	image_dos_header.e_res[2]	= 0x6957;<br />
	image_dos_header.e_res[3]	= 0x336E;<br />
	image_dos_header.e_oemid	= 0x2032;<br />
	image_dos_header.e_oeminfo	= 0x6E6F;<br />
	image_dos_header.e_res2[0]	= 0x796C;<br />
	image_dos_header.e_res2[1]	= 0x0D21;<br />
	image_dos_header.e_res2[2]	= 0x240A;<br />
	image_dos_header.e_res2[3]	= 0xB40E;<br />
	image_dos_header.e_res2[4]	= 0xBA09;<br />
	image_dos_header.e_res2[5]	= 0x0000;<br />
	image_dos_header.e_res2[6]	= 0xCD1F;<br />
	image_dos_header.e_res2[7]	= 0xB821;<br />
	image_dos_header.e_res2[8]	= 0x4C01;<br />
	image_dos_header.e_res2[9]	= 0x21CD;<br />
	image_dos_header.e_lfanew	= 0x40;<br />
<br />
	//UnmapViewOfFile(FBase);<br />
	FillMemory(lpFile,image_nt_headers.OptionalHeader.SizeOfHeaders,0x10);<br />
<br />
	hFile = CreateFile("C:\\test2.exe",GENERIC_WRITE,0,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);<br />
    WriteFile(hFile, lpFile, bufFileSize, &dwBytesWritten, NULL);<br />
<br />
	CloseHandle(hFile);<br />
	FlushViewOfFile(FBase, 0);<br />
	UnmapViewOfFile(FBase);

Re: Removing the MS-DOS stub from a PE File [modified]

Baltoro11-Apr-09 9:08

Baltoro

11-Apr-09 9:08

There are a number of good explanations of the Portable Executable file format on the Web. Here's one: Structure of the Portable Executable File Format[^]. A more complete description is Matt Pietrek's original article: Peering Inside the PE: A Tour of the Win32 Portable Executable File Format[^].
Are you trying to substitute a new DOS Stub for the existing one, or just eliminate it altogether? And, why? Is this necessary?
In Matt Pietrek's article, he starts out by saying: "The first few hundred bytes of the typical PE file are taken up by the MS-DOS stub. This stub is a tiny program that prints out something to the effect of "This program cannot be run in MS-DOS mode." So if you run a Win32-based program in an environment that doesn't support Win32, you'll get this informative error message."
Actually, the MS DOS Header is located at the beginning of the PE file: The MS-DOS header occupies the first 64 bytes of the PE file. You obviously know that because the structure is listed in your code:

WINNT.H

typedef struct _IMAGE_DOS_HEADER {  // DOS .EXE header
    USHORT e_magic;         // Magic number
    USHORT e_cblp;          // Bytes on last page of file
    USHORT e_cp;            // Pages in file
    USHORT e_crlc;          // Relocations
    USHORT e_cparhdr;       // Size of header in paragraphs
    USHORT e_minalloc;      // Minimum extra paragraphs needed
    USHORT e_maxalloc;      // Maximum extra paragraphs needed
    USHORT e_ss;            // Initial (relative) SS value
    USHORT e_sp;            // Initial SP value
    USHORT e_csum;          // Checksum
    USHORT e_ip;            // Initial IP value
    USHORT e_cs;            // Initial (relative) CS value
    USHORT e_lfarlc;        // File address of relocation table
    USHORT e_ovno;          // Overlay number
    USHORT e_res[4];        // Reserved words
    USHORT e_oemid;         // OEM identifier (for e_oeminfo)
    USHORT e_oeminfo;       // OEM information; e_oemid specific
    USHORT e_res2[10];      // Reserved words
    LONG   e_lfanew;        // File address of new exe header
  } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

An imporvement on your code would be to read that IMAGE_DOS_HEADER.e_lfanew value, initially, and then attempt to rewrite your file data into the new version. But, your code appears to be correct in that respect, you write the NT Headers at that value without changing it. Your big problem is that you don't move all the rest of the file data forward in the new file, like you did with the initial headers (and change the corresponding header fields to reflect this). Many of these fields are RVAs (Relative Virtual Address, relative to the base loading address), which the Windows loader reads to locate the various PE file sections and their identifying headers.
Also, the CreateFileMapping and MapViewOfFile are executing with a file handle that you just closed. But, you don't seem to be using the address anyway, so it doesn't really matter. When you are initially attempting to get code lke this to work, you should be checking return values (the errors will be obvious).
Just out of curiosity, what happens when the Windows loader attempts to load your new file? Or, are you using a Hex Editor to examine the realigned structure?

iNoble11-Apr-09 9:40

11-Apr-09 9:40

what im trying to do is completely eliminate the DOS header and stub , but when i generate the new file it replace alot more bytes not just the Dos header and stub

Your big problem is that you don't move all the rest of the file data forward in the new file, like you did with the initial headers (and change the corres[ponding header fields to reflect this).

are you referring at the Entry Point? yes im aware than i will need to change the Enty Point so it points to the NT PE instead of the DOS Stub

modified on Saturday, April 11, 2009 4:16 PM

Baltoro11-Apr-09 10:21

Baltoro

11-Apr-09 10:21

If you remove the MS DOS header, the Windows loader will fail to load your executable, because (from what the documentation says), the loader reads the IMAGE_DOS_HEADER.e_lfanew field (which contains the file offset of the IMAGE_NT_HEADERS). {Actually, I think it will load the file, it will just fail to execute properly.) I'm just guessing here, but I would guess that the loader checks alot of things to determine if the Portable Executable is valid. You could test this by calling LoadLibrary and providing your new file as a parameter, instead of just attempting to launch it normally ( with CreateProcess).
Actually, I have no idea what will happen when it encounters that space where the original IMAGE_NT_HEADERS used to be.
Did you actually try loading this new file?
In his article, Matt Pietrek states: "Immediately following the PE header in memory is an array of IMAGE_SECTION_HEADERs." This is the Section Table. Since the size of the NT header is known, I would guess that the loader has a problem resolving where to load the Section Table, if it cannot find it at it's normal location. This table contains it's own set of headers, many of it's fields are RVAs, that tell the loader where to find everything else in the file.
Also, (and I just realized this in re-reading your code) you call CopyMemory for the two PE headers, and then initialize a new IMAGE_DOS_HEADER, and you don't write this structure (nor the IMAGE_NT_HEADERS) to LPBYTE lpFile.
You should re-think your entire appraoch to the problem.

iNoble11-Apr-09 13:16

11-Apr-09 13:16

a thanks for the info , that helped alot , also i know its possible to accomplish this as ive seen it in many runtime PE packers/protectros

can you tell me the APIs or the progress to write the new IMAGE_DOS_HEADER back to BYTE?

Stephen Hewitt12-Apr-09 6:08

Stephen Hewitt

12-Apr-09 6:08

If you're compiling and linking the program yourself using MS compilers then the simplest approach would be to put in a custom DOS stub using the linkers /STUB[^] switch. Put in one which simply does nothing and returns immediately.

Steve

iNoble12-Apr-09 11:36