|
In case it's not been clear in the other messages:
A heap corruption message, and specifically that message, is telling you that somewhere, somewhen, the internal stuctures of the heap's memory management have been overwritten (corrupted). Because it did not or could not detect it at the moment it happened, heap corruptions are reported when you do something that requires the heap and that's when the run time library runs a "heap consistency check" and throws the error message.
So, it's not telling you that the particular call you did was wrong, it's just that the call was the first place it detected a previous corruption. So it's important to not focus on that particular call as the source of the problem. However, that call does give you a point in time when the corruption occurred. If you have other allocation / deallocation calls in your code, you know that the corruption occurred sometime between the last heap call and this one. That gives you a chance to narrow down the section of code to look at.
Lastly, heap corruption detection only happens in debug mode code / libraries as it is a performance hog. So, you can have had this bug for a long time and never notice it in production mode code.
|
|
|
|
|
If I had to guess, that line is probably not the problem, your problem is elsewhere. Just happens to break at that point, can you look at the call stack and see what calls happened prior to the error?
|
|
|
|
|
Hello,
I'm working on a project that deals with DLLs extensively. One bit of information that I've learned so far is that an executable will retrieve a DLL's exported function that it needs, and put the function address in the executable's Import Address Table (IAT). One question that I have is "How do functions from one DLL get called to another DLL within Windows?" Does a DLL also have an IAT in which it holds function pointers that it used from another DLL, or are these kinds of function calls also added to the executable's IAT?
Any help would be appreciated!
Thanks!
|
|
|
|
|
ryan2189 wrote: Does a DLL also have an IAT in which it holds function pointers that it used from another DLL
Yes.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
dlls and exes are essentially the same
|
|
|
|
|
I'm sure this is c++ 101
I build a class to encrypt and decrypt, but when I use the function multiple times, it changes the values of the previous buffers I stored the values in.
This is the first time I have called a function multiple times, so I'm not sure how to handle it.
CA_Encryption caEncrypt;
WCHAR *szSecretAnwser_Secure = new WCHAR[12];
szSecretAnwser_Secure = caEncrypt._encrypt_3DES(szSecretAnwser);
WCHAR *szPassword_Secure = new WCHAR[12];
szPassword_Secure = caEncrypt._encrypt_3DES(szPassword);
const int MD5_SIZE = 16;
BYTE *szPassword_Encoded = new BYTE[MD5_SIZE];
szPassword_Encoded = caEncrypt._create_MD5_Hash(szPassword);
|
|
|
|
|
I'm not sure where this code actually exists as you have not shown where in the function it is, or really what it is trying to do. however when you allocate a buffer with a new operator it creates a new buffer every time you pass that line of code (you should also delete[] them when finished with). If you want some permanent buffer then you should allocate it outside the function and pass it in as a reference on the function call. Something like:
int myfunc(buffer* pszBuffer)
{
return 1;
}
char* nbuff = new char[64];
int val = myfunc(nbuff);
delete[] nbuff;
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I didn't want to post the function because I had no idea where my poor use of buffers was. I made a class, and wrote 5 functions in it.
Normally I would of wrote 5 public functions, and do the work in private functions.
But no matter which function I run in the same class, it changes the previous buffer values to the last function ran in the class.
I think I understand now why everyone had there encryption function separated into 3 aspects.
Let me try that first.
|
|
|
|
|
jkirkerx wrote: I build a class to encrypt and decrypt, but when I use the function multiple times, it changes the values of the previous buffers I stored the values in.
What does _encrypt_3DES() look like? I don't need all of the details, just the variable that it returns and how it is declared.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Encrypt 3DES
WCHAR* CA_Encryption::_encrypt_3DES( WCHAR *pzInputW )
{
BOOL bResult = FALSE;
WCHAR *szOutput = NULL;
HCRYPTPROV hProv;
HCRYPTKEY hKey;
ALG_ID Algid;
PBYTE pbKeyBlob = NULL;
BYTE *pbBuffer;
DWORD dwBlockLen = 0;
DWORD dwDataLen = 0;
DWORD cbData = 0;
BOOL bFinal = TRUE;
DWORD errorCode = 0;
DWORD dwResult = 0;
TCHAR szBase64[80];
DWORD cbKeyLen = 24;
int iCharA = WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, NULL, 0, NULL, NULL);
char *szInputA = new char[iCharA];
WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, szInputA, iCharA, NULL, NULL);
keyBlob192.hdr.bType = PLAINTEXTKEYBLOB;
keyBlob192.hdr.bVersion = CUR_BLOB_VERSION;
keyBlob192.hdr.reserved = 0;
keyBlob192.hdr.aiKeyAlg = CALG_3DES;
keyBlob192.cbKeySize = 24;
ZeroMemory(keyBlob192.rgbKeyData, 24);
CopyMemory(keyBlob192.rgbKeyData, KEY_192, cbKeyLen > 24 ? 24 : cbKeyLen);
bResult = CryptAcquireContextW( &hProv, 0, MS_ENHANCED_PROV, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT);
bResult = CryptImportKey(hProv, (BYTE*)&keyBlob192, sizeof(keyBlob192), 0, CRYPT_EXPORTABLE, &hKey);
bResult = CryptSetKeyParam(hKey, KP_IV, IV_64, 0);
dwDataLen = sizeof(ALG_ID);
cbData = sizeof(szInputA);
if (!CryptGetKeyParam(hKey, KP_ALGID, (BYTE *)&Algid, &dwDataLen, 0))
return 0;
if (GET_ALG_TYPE(Algid) != ALG_TYPE_STREAM) {
dwDataLen = sizeof(DWORD);
if (!CryptGetKeyParam(hKey, KP_BLOCKLEN, (BYTE *)&dwBlockLen, &dwDataLen, 0))
return 0;
dwDataLen = ((cbData + dwBlockLen - 1) / dwBlockLen) * dwBlockLen;
if (!(pbBuffer = (BYTE *)LocalAlloc(LMEM_FIXED, dwDataLen)))
return 0;
}
else {
if (!(pbBuffer = (BYTE *)LocalAlloc(LMEM_FIXED, cbData)))
return 0;
}
CopyMemory(pbBuffer, szInputA, cbData);
if (!CryptEncrypt(hKey, 0, bFinal, 0, pbBuffer, &cbData, dwDataLen)) {
DWORD dwError = GetLastError();
if(ERROR_MORE_DATA == dwError) {
DWORD dwSizeNeeded = cbData;
CopyMemory( pbBuffer, szInputA, cbData );
bResult = CryptEncrypt(hKey, 0, FALSE, 0, pbBuffer, &dwSizeNeeded, dwDataLen);
}
LocalFree(pbBuffer);
return 0;
}
if(CryptBinaryToString(pbBuffer, 8, CRYPT_STRING_BASE64, NULL, &dwResult)) {
CryptBinaryToString(pbBuffer, 8, CRYPT_STRING_BASE64, szBase64, &dwResult);
szBase64[dwResult] = 0;
szOutput = (WCHAR*)szBase64;
szOutput[wcslen(szOutput)+1] = L'\0';
}
SecureZeroMemory( keyBlob64.rgbKeyData, 8 );
SecureZeroMemory( pbBuffer, sizeof(pbBuffer) );
delete [] szInputA;
CryptDestroyKey(hKey);
CryptReleaseContext(hProv, 0);
return szOutput;
}
Hash
BYTE* CA_Encryption::_create_MD5_Hash( WCHAR *pzInputW )
{
BOOL bResult = FALSE;
HCRYPTPROV hProv;
HCRYPTHASH hHash;
const int MD5_SIZE = 16;
static BYTE hash[MD5_SIZE];
DWORD hash_size = sizeof(hash);
int iChar = WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, NULL, 0, NULL, NULL);
char *szInputA = new char[iChar];
WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, szInputA, iChar, NULL, NULL);
DWORD dwBufferSize = 0;
DWORD dwPasswordLen = strlen((char *)szInputA);
bResult = CryptAcquireContextW( &hProv, NULL, MS_STRONG_PROV, PROV_RSA_FULL, 0);
bResult = CryptCreateHash( hProv, CALG_MD5, 0, 0, &hHash );
bResult = CryptHashData( hHash, (BYTE*)szInputA, dwPasswordLen, 0 );
bResult = CryptGetHashParam( hHash, HP_HASHVAL, hash, &hash_size, 0 );
delete [] szInputA;
CryptDestroyHash(hHash);
CryptReleaseContext(hProv, 0);
return hash;
}
|
|
|
|
|
As I suspected, szOutput is an auto (i.e., local) variable. Under the right conditions, it will point to szBase64, another auto variable. It sounds as though you need to call _encrypt_3DES() with an additional argument: a buffer to store the result in.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Thanks for checking it out Dave.
I even experimented with changing the name of szOutput to unique names, but it still did the same thing.
I think that's why all the examples I saw had the base64 part in a separate function.
|
|
|
|
|
Thanks for your help. You were right on the money.
I learned alot on this one. Sort of like the post above this one. When you allocate memory, you have to have the exact right size including the null terminator.
So now I call it twice, once to get the size I need, and again with the right size.
I still have 1 bug left, I get 2 extra spaces in the SQL database column that are squares, I may have double null terminators or something. The -2 was just an experiment.
DWORD dwSecretAnwser;
caEncrypt._encrypt_3DES(szSecretAnwser, dwSecretAnwser);
WCHAR *szSecretAnwser_Secure = new WCHAR[dwSecretAnwser];
szSecretAnwser_Secure = caEncrypt._encrypt_3DES(szSecretAnwser, dwSecretAnwser);
WCHAR* CA_Encryption::_encrypt_3DES( WCHAR *pzInputW, DWORD &dwOutput )
{
BOOL bResult = FALSE;
HCRYPTPROV hProv;
HCRYPTKEY hKey;
ALG_ID Algid;
PBYTE pbKeyBlob = NULL;
BYTE *pbBuffer;
DWORD dwBlockLen = 0;
DWORD dwDataLen = 0;
DWORD cbData;
BOOL bFinal = TRUE;
DWORD errorCode = 0;
TCHAR *szBase64 = NULL;
DWORD dwResult;
DWORD cbKeyLen = sizeof(KEY_192);
int iCharA = (WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, NULL, 0, NULL, NULL) - 1);
char *szInputA = new char[iCharA];
WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, szInputA, iCharA, NULL, NULL);
keyBlob192.hdr.bType = PLAINTEXTKEYBLOB;
keyBlob192.hdr.bVersion = CUR_BLOB_VERSION;
keyBlob192.hdr.reserved = 0;
keyBlob192.hdr.aiKeyAlg = CALG_3DES;
keyBlob192.cbKeySize = sizeof(KEY_192);
CopyMemory(keyBlob192.rgbKeyData, KEY_192, cbKeyLen> sizeof(keyBlob192) ? sizeof(keyBlob192) : cbKeyLen);
bResult = CryptAcquireContextW( &hProv, 0, MS_ENHANCED_PROV, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT);
bResult = CryptImportKey(hProv, (BYTE*)&keyBlob192, sizeof(keyBlob192), 0, CRYPT_EXPORTABLE, &hKey);
bResult = CryptSetKeyParam(hKey, KP_IV, IV_192, 0);
dwDataLen = sizeof(ALG_ID);
cbData = iCharA;
if (!CryptGetKeyParam(hKey, KP_ALGID, (BYTE *)&Algid, &dwDataLen, 0))
return 0;
if (GET_ALG_TYPE(Algid) != ALG_TYPE_STREAM) {
dwDataLen = sizeof(DWORD);
if (!CryptGetKeyParam(hKey, KP_BLOCKLEN, (BYTE *)&dwBlockLen, &dwDataLen, 0))
return 0;
dwDataLen = ((cbData + dwBlockLen - 1) / dwBlockLen) * dwBlockLen;
if (!(pbBuffer = (BYTE *)LocalAlloc(LMEM_FIXED, dwDataLen)))
return 0;
}
else {
if (!(pbBuffer = (BYTE *)LocalAlloc(LMEM_FIXED, cbData)))
return 0;
}
CopyMemory(pbBuffer, szInputA, cbData);
if (!CryptEncrypt(hKey, 0, bFinal, 0, pbBuffer, &cbData, dwDataLen)) {
LocalFree(pbBuffer);
return 0;
}
SecureZeroMemory( keyBlob192.rgbKeyData, sizeof(keyBlob192.rgbKeyData) );
delete [] szInputA;
CryptDestroyKey(hKey);
CryptReleaseContext(hProv, 0);
if(CryptBinaryToString((BYTE*)pbBuffer, cbData, CRYPT_STRING_BASE64, NULL, &dwResult)) {
if ((dwOutput > 0 ) && (dwOutput < 4096)) {
szBase64 = new TCHAR[dwResult];
CryptBinaryToString((BYTE*)pbBuffer, cbData, CRYPT_STRING_BASE64, szBase64, &dwResult);
dwOutput = dwResult;
szBase64[dwResult-2] = 0;
return szBase64;
}
else {
dwOutput = dwResult;
return L'\0';
}
}
else {
dwOutput = dwResult;
return L'\0';
}
}
|
|
|
|
|
Hi,
Does anyone know of a compiler that will run under Windows 7 (64 bit) but will compile 16 bit DOS based code? I used to use MSVC 1.52 on XP 32 bit but it will not run on a 64 bit platform. I tried running it under Virtual PC but it is too unstable (it regularly deleted the contents of my source files which is not much fun).
Thanks 
|
|
|
|
|
A quick search gives promising results for running Turbo C using DOSBox: I've not tried that, however.
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 don't often use Windows 7 so I might be wrong on this, but as far as I know it comes with a built in 32 bit Windows XP virtual machine? MSVC 1.52 might work in that.
Personally I use Microsoft C 6.0 in DosBox[^] and MSVC 1.52 in a Windows 2000 guest OS with VirtualBox[^], both works.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
Thanks for the reply.
Win 7/64 Pro does come with XP virtual machine but unfortunately I only have the Home edition which does not. I thought about upgrading but its too much hassle re-installing everything.
I have a copy of Microsoft C 6.0 somewhere so I think I will give that a go in DosBox.
Can you advise how I install it in DosBox please.
Thanks for the tip.
|
|
|
|
|
You can download the VM from here[^].
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
softwaremonkey wrote: I thought about upgrading but its too much hassle re-installing everything.
Upgrading from Home 7 to Pro 7 does not require you to reinstall a thing. All it does, essentially, is replace what's in the Windows folder with the upgraded components, and leave the registry and all program files intact.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hi Richard,
Thanks for this info. This only applies if you buy the Windows 7 Anytime Upgrade. Even though I have a copy of Windows 7 professional, it will not perform the upgrade - unless anyone knows differently.
Thanks again
Tony
modified 23-Dec-11 11:51am.
|
|
|
|
|
Your Product key from your boxed Pro 7 will work as an Anytime Upgrade key. I did that myself on a new netbook I had purchased with Win 7 Starter.
I chose the Anytime Upgrade, and put in my boxed Win 7 product key, and everything went through.
So you're not out of luck.
Rich
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Try [Microsoft QuickC 16 Bit] IDE/Compiler for the C programming language. Its main competitor was Turbo C. (Quick C vs Turbo C , get it?  ), Its from the year 1990.
[This] link mentions this:
Emulation
The easiest way to get Turbo C/C++ to run is using DOSBOX which emulates the environment of an old 16bit MsDOS computer. This works very well and will allow you to run most programs (even CGA/VGA/SVGA graphics).
If you wish to run Turbo C on Linux there is DOSEMU.
Virtualization
Another option is to run the programs on a Virtual Machine. Think of this as running a virtual computer on your computer. The VM emulates a PC and you can load an OS like an old copy of windows (if you have old disks laying about) or you can use FreeDOS as an OS.
|
|
|
|
|
Thanks for the reply.
As I said earlier, I have used Microsoft Virtual PC and loaded Windows XP 32 bit on it but it was very slow and routinely locked up and lost connection to the host HDD, loosing the contents of any source file I had made changes to 
Since them I have installed Oracle VM Virtual Box which seems (so far) to be a much better product.
Thanks again
Tony
|
|
|
|
|
I create MFC application and run its exe on a system where .net is not installed.
What dll i need to copy on new system.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
