|
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? 
|
|
|
|
|
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).
|
|
|
|
|
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 
|
|
|
|
|
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]
|
|
|
|
|
|
Change:
locoone wrote: if (retCode == ERROR_SUCCESS )
{
m_list.InsertItem(index, achValue);
m_list.SetItemText(index, 1, lpData);
index++;
}
to
if (retCode == ERROR_SUCCESS )
{
CString str = (wchar_t *) lpData;
m_list.InsertItem(index, achValue);
m_list.SetItemText(index, 1, str);
index++;
}
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]
|
|
|
|
|
i changed it and i now get this error
error C2440: 'initializing' : cannot convert from 'wchar_t *' to 'ATL::CStringT<BaseType,StringTraits>'
|
|
|
|
|
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++;
}
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]
|
|
|
|
|
that gives the same error 
but why am i only getting the first letter and not the whole value?
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs <--- thats what im tring to get
modified on Sunday, April 12, 2009 11:07 PM
|
|
|
|
|
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 )
{
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++;
}
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]
|
|
|
|
|
that worked thanks man 
|
|
|
|
|
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 />
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);
|
|
|
|
|
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 {
USHORT e_magic;
USHORT e_cblp;
USHORT e_cp;
USHORT e_crlc;
USHORT e_cparhdr;
USHORT e_minalloc;
USHORT e_maxalloc;
USHORT e_ss;
USHORT e_sp;
USHORT e_csum;
USHORT e_ip;
USHORT e_cs;
USHORT e_lfarlc;
USHORT e_ovno;
USHORT e_res[4];
USHORT e_oemid;
USHORT e_oeminfo;
USHORT e_res2[10];
LONG e_lfanew;
} 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?
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
modified on Saturday, April 11, 2009 4:14 PM
|
|
|
|
|
|
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
|
|
|
|
|
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!).
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
