C / C++ / MFC Discussion Boards

Baltoro11-Apr-09 11:21

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).

Re: Registry REG_BINARY Problem

locoone11-Apr-09 20:09

locoone

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 | :(

Re: Registry REG_BINARY Problem

CPallini11-Apr-09 22:46

CPallini

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]

Re: Registry REG_BINARY Problem

locoone12-Apr-09 2:53

locoone

12-Apr-09 2:53

yes, its not unicode.

Re: Registry REG_BINARY Problem

CPallini12-Apr-09 9:58

CPallini

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++;	
}

Re: Registry REG_BINARY Problem

locoone12-Apr-09 10:46

locoone

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>'

Re: Registry REG_BINARY Problem

CPallini12-Apr-09 11:17

CPallini

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++;
}

Re: Registry REG_BINARY Problem [modified]

locoone12-Apr-09 11:50

locoone

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

Re: Registry REG_BINARY Problem

CPallini13-Apr-09 4:46

CPallini

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++;
}

Re: Registry REG_BINARY Problem

locoone13-Apr-09 12:40

locoone

13-Apr-09 12:40

that worked thanks man Big Grin | :-D

Removing the MS-DOS stub from a PE File

iNoble11-Apr-09 8:05

iNoble

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

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?

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

iNoble11-Apr-09 9:40

iNoble

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

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

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.

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

iNoble11-Apr-09 13:16

iNoble

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?

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

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

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

iNoble12-Apr-09 11:36

iNoble

12-Apr-09 11:36

thank you steve, but that function im trying to make is far all PE files, not just the ones i can compile

maybe Ashkbiz Danehkar , the creator of yoda protector , witch is a member here, can help me abit more on this

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

Baltoro13-Apr-09 5:55

Baltoro

13-Apr-09 5:55

Pablo_Escobar,
I wrote a program like this a couple of monthes ago, except that it wasn't supposed to remove the MS DOS stub,...it was just supposed to analyze the structure of the DLL or executable and write an enormous amount of data to text file. It was a very memory-intensive application. There are no standard Microsoft APIs to do this efficiently. And, what you want to do is definately possible, you're just going to have to read through the available documentation and write alot of code.
You will find this reference invaluable: Microsoft Portable Executable and Common Object File Format Specification[^].
...and, YES, read anything you can find that Ashkbiz Danehkar has written CodeProject Articles by Ashkbiz Danehkar[^], he's excellent.

need help.. [modified]

badboyz8911-Apr-09 7:31

badboyz89

11-Apr-09 7:31

i must finish a project that how to make football schedule..but i don't know how to develop or to coding this program..anyone can help me?? any example, post to mohdameirudin@yahoo.com Smile | :)

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

Re: need help..

CARPETBURNER12-Apr-09 0:06

CARPETBURNER

12-Apr-09 0:06

http://www.codeproject.com/script/Forums/View.aspx?fid=1213656&msg=3000957[^]

I suggest you refer to my answer here on this thread for help.. If you dont know how to develop or code your program please stop using this site as a means to get someone else to do it for you.

who can share the code to intercept iexplore connect send recv closesocket

ernst2002053011-Apr-09 5:19

ernst20020530

11-Apr-09 5:19

extern "C" __declspec(dllexport) bool setHook(DWORD dwThreadId)
{
printf("set Hook!\n");
if (dwThreadId != 0)
{
hkprcSysMsg = GetMsgProc;

hHook = SetWindowsHookEx(WH_GETMESSAGE,hkprcSysMsg,hInst,dwThreadId);
if (hHook != NULL)
{
printf("OK\n");
return true;
}
else
{
int err=GetLastError();
return false;
}
}
return false;
}

LRESULT WINAPI GetMsgProc(int nCode, WPARAM wParam, LPARAM lParam){
printf("Hook!\n");
PROC fpOri = GetProcAddress(GetModuleHandle(TEXT("Wsock32.DLL")),"connect");
HMODULE hmodCaller = GetModuleHandle(TEXT("OpenApplication.exe"));
fp5 connect5=connect1;
ReplaceIATEntryInOneMod("Wsock32.DLL", fpOri,(PROC)connect5, hmodCaller);

return (CallNextHookEx(hHook, nCode, wParam, lParam));
}

this is two functions in my dll file to inject my dll into iexplore, why the hook function GetMsgProc never be called, and when will the function be called?

who can share the complete code from DLL injection and replace my dll file instead of system dll file

Re: who can share the code to intercept iexplore connect send recv closesocket

Green Fuze11-Apr-09 20:00

Green Fuze

11-Apr-09 20:00

What you're looking to do, is to replace functions, and not just hook to the message loop...
I think the easiest and fastest way to do so is to use easyhook.
Check out EasyHook (it's a project in codeplex.com, so you'll have the code).

It's an awesome framework for hooking. you can use it to replace the functions you want (Even works for kernel!).

[ANN] Announcement: NUI C++ multi-platform appllication framework, 3D hardware GUI [modified]

meelooo11-Apr-09 0:17

meelooo

11-Apr-09 0:17

We are happy to announce the release of NUI: http:/www.libnui.net[^]

NUI is a C++ application framework that runs on the iPhone, MacOSX (universal), Win32 and Linux.
Its main distinctive features is its use of 3D hardware to render the UI via OpenGL, GL Es and Direct3D.

Its features include:
- Low level abstraction: string, files, paths, streams, network, timers, threads, mutexes, etc.
- Widget layout engine
- Really many widgets: text, grids, boxes, collumn views, tree views, etc.
- Integrated widget tree visual introspection/debugging
- Web-like CSS engine
- Modern rendering and compositing engine
- Animations for widgets and their attributes
- Attributes to remote control widgets
- Audio IO and Audio file loading/saving (including compressed audio files decoding)
- Stable and proven lib: many applications have been released since 2001 with NUI at their core.
- ...

The lib is dual licensed under the GPL and commercial licensing for non free software developers.

Check out the website for more information: http://www.libnui.net[^]

Thank you very much,

Sebastien

modified on Saturday, April 11, 2009 6:23 AM

Re: [ANN] Announcement: NUI C++ multi-platform appllication framework, 3D hardware GUI

Rajesh R Subramanian11-Apr-09 0:20

Rajesh R Subramanian

11-Apr-09 0:20

Sounds like pretty good stuff! But the link leads to a page saying: Bad Request (Invalid hostname)

It is a crappy thing, but it's life -^ Carlo Pallini

Re: [ANN] Announcement: NUI C++ multi-platform appllication framework, 3D hardware GUI

meelooo11-Apr-09 0:26

meelooo

11-Apr-09 0:26

Woops, sorry, I fixed the URL!

Thanks for the heads up Smile | :)

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.