|
That is never going to work because CString holds a C-style string. C-style strings, by definition, cannot contain embedded 0 characters because the first 0 marks the end of the string. CString is just the wrong class to use in this case.
Also consider what happens when Format() goes to insert the sHeader array in place of the %s. Again, %s means a C-style string, so it looks at sHeader1, sees that the first character is 0, and stops because that's the end of the string.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
You cannot stop me with paramecium alone!
|
|
|
|
|
So is there a way to send leading nulls? Or is this a loosing battle?
This mesage layout is based on the DMPP-2020 layout...which is a packet coming from a PC and going to a mainframe. Do mainframes allow leading nulls?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
I'd just do two separate send calls, one for the block of 0s, then another for the text string. If you have to do it in one send call, you'll need to allocate a BYTE buffer of the right size and fill it in with the 0s and the string.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
Pinky, are you pondering what I'm pondering?
I think so Brain, but if we shaved our heads, we'd look like weasels!
|
|
|
|
|
Michael one last question. If I setup this BYTE buffer and set my string like I want it, will it loose those nulls when I retype it as an LPCTSTR in my Send() method?
The MSDN says:
Pointer to a constant null-terminated string of 8-bit Windows (ANSI) characters. For more information, see Character Sets Used By Fonts.
This type is declared in Winnt.h as follows:
Thanks again for all the help
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
How are you inspecting the packet received? Could it be that your inspection mechanism gets fooled by leading nulls (like for instance if it dumps the packets to the console like they were C-style strings), but these are actually transmitted?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Good point I'll step thru my code and see what's being sent before it's sent.
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
As far as I can think, the closest solution should be replacing those null's with some other characters those otherwise will never be used in your application, for example, if your sure you'll never use the character '#', then:
#define THE_HEADER _T("###...##")
CString sPacket = CString(THE_HEADER) + _T("your real contents");
socket.Send((LPCVOID)(LPCTSTR)sPacket, sPacket.GetLength() * sizeof(TCHAR));
TCHAR szReceived[1024] = _T("");
receiver.Receive((LPVOID)szReceived, 1023);
for (int i = 0; szReceived[i]; i++)
{
if (szReceived[i] == _T('#'))
szReceived[i] = _T('\0');
}
|
|
|
|
|
Neither the Send function nor the corresponding Receive function strip out any characters from the buffer (nulls or otherwise). The Send function does not care what type of data you are sending. It takes a void pointer as a parameter. The data you send does not even have to be text. I send binary data over a socket all the time.
If it helps think of your final send and receive buffers as a block of miscellaneous bytes. It can be a string, a structure, random bytes, whatever. The length value is the number of bytes in the buffer to send. This is not necessarily the same as the number of characters in the string.
There is no need to replace the NULLs with another character unless that is more convenient for the receiving side.
A couple questions to ask:
What does the spec call for? 53 bytes of 0 followed by a variable length string? Is the string null terminated as well? Must the string be ASCII encoded? Can it be Unicode? This is important because the CString type will change depending on how the program is compiled. So, it's usually better to be more specific by using CStringA or a char array.
Another thing to consider is how much data you plan to send? If there are a lot of Send calls in a row, Send can fail as there is no more room in the internal buffer. Then you have to wait and resend the data. And that may not be all of the data either as Send can send part of your data (whatever fills up the buffer). It will always send bytes in the order passed to it, though.
Any way, yet another simple Send example (assumes ASCII bytes and variable null terminated string):
This version is done with two calls to send. In a low-load app, there won't be much of a performance difference between one call and two calls to send. You can replace the const char pointer with CStringA and lstrlen with GetLength if desired.
int SendStringWithLeadingNulls( CAsyncSocket &SendSocket, const char *Str )
{
BYTE NullBuffer[53] = {'\0'};
int BytesSent;
BytesSent = SendSocket.Send( NullBuffer, sizeof(NullBuffer) );
if( BytesSent < sizeof(NullBuffer) )
return(BytesSent);
return( SendSocket.Send( Str, lstrlen(Str)+1 ) );
}
When receiving, examine the buffer as a byte array and not a string and you will see the leading bytes.
BYTE Buffer[1024];
int BytesReceived;
CString Str;
BytesReceived = ReceiveSocket.Receive( Buffer, sizeof(Buffer) );
if( BytesReceived > 53 )
Str = (char *) (Buffer + 53);
|
|
|
|
|
Tom Wright wrote:
So is there a way to send leading nulls? Or is this a loosing battle?
NO! This is done all the time.
Tom Wright wrote:
Sorry your right. After sending I only get 4 bytes...but still not the leading nulls.
This has really got me puzzled.
That is because you don't understand C/C++ strings. They are never going to have leading NULLs since all string library functions interpret the first NULL byte as the END OF THE STRING.
Tom Wright wrote:
I'm thinking that I cannot send anything with leading nulls....which if you think about it, is right....how would the system know the end of one packet and the beginning of another is it did not reference nulls as the end or beginning of something.
Absolutly WRONG!
Tom Wright wrote:
and I got nothing.
Tom Wright wrote:
When I look at the packet on the other end,
How do you know what you got? I thought you sent it to a mainframe?
Tom Wright wrote:
Here is my code snippet:
First we don't know what m_sConnectSocket is?
If we assume it's send() method is equivalent to the socket API send() then Tom you need to get this. send() only knows about the type byte. You give it the starting address of the memory block of bytes you want it to send and the number of bytes to send. It will either send all of them or none or some of them. The return value is the exact number of bytes sent or an error indicator. Are you checking the return value?
So to sum up if you call send( someAddress, 128) and the return value is 128 then the stack sent the 128 bytes of data starting at the address "someAddress" it does not care what freakin values are in those bytes, period. Please respond in the affermative if you understand this.
Tom Wright wrote:
Do mainframes allow leading nulls?
Well if they don't then why would you have a specification to send it leading nulls? 
Watch out! I'm a CPian on the edge!
I have a new Gold rating and I'm not afraid to use it! -pete
|
|
|
|
|
You know what bud, it's 'A' holes like you that come on here late in the game and bitch people out instead of helping them understand what it is that they are trying to do. People like David Crow or Michael Dunn at least take the time to explain how things work instead of giving flaming responses and not explaining, or making someone feel like an idiot.
I do know some things about strings. There are times that I forget stuff (God i hope you never come on here and do that...I have no problem ripping you a new one). And beacause I program in both VC++ and COBOL there are times that I get the two languages confused.
I NOW know that leading nulls can not be passed. I DO understand that they mean the end of something. And I NEVER said that I was testing this between a mainframe and a PC. I'm at the stage where I'm just creating the string to send to the mainframe, but I am testing between two PC's. And while stepping thru my code I see that the nulls are not being sent. So while you roam around the forum like a meandering idiot bitching out people because they are not as smart as you, why don't you get down off your "I am a programming GOD" podium and take a few more seconds and find a better way of replying to people instead of being a jerk!!!
palbano wrote:
Tom Wright wrote:
Here is my code snippet:
First we don't know what m_sConnectSocket is?
Well duh...it is some sort of socket method.....to be exact it's the CAsyncSocket method to send.
Thanks for nothing. So here is your affermative response....UP YOURS! by the way if it were up to me I would take that f-ing gold rating and stick it where the sun don't shine.
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
<humor>Wow, if you had spent as much time reading the documentation on strings and the send() API as you did typing that lovely romp of a post, you would have never started this thread. But then we would have never met. </humor>
And you did post a statement that I interpreted to mean you were sending the data to a mainframe.
Tom Wright wrote:
So is there a way to send leading nulls? Or is this a loosing battle?
This mesage layout is based on the DMPP-2020 layout...which is a packet coming from a PC and going to a mainframe. Do mainframes allow leading nulls?
So you found some of my frivolous statements offensive rather than humorous. Ok my bad. 
However there was a serious explanation of the send() API in there yes? You should have found that helpful right? It did not seem to be covered in the previous posts and it did seem like the main source of the problem. Also the explanation of NULL in strings should have been helpful as well right?
I did not just drop in to bash you or anyone. My coming late in the thread has nothing to do with anything other than the fabric of time. (again with the frivolity) Sorry being serious all the time is just not in my nature. Just like that signature. I feel the ratings are funny so I am poking some fun at it.
I have a Gold rating but it is currently unavailable due to being stuck up my arse. -pete
|
|
|
|
|
Whenever I specify an x and y position(0,0) for SetWindowPos or MoveWindow. I noticed that the OnMove method the x and y position is different(6,44). Any ideas why?
Thanks
|
|
|
|
|
|
|
Hi, I a making an MFC app that needs to save the user's password and username to the registry. How do I go about "encrypting" it before I save it to the registry so no sneaks will look in the registry to see the user's password (for example, a brother or sister or whoever..).
Thanks!
|
|
|
|
|
There are many articles on cryptography if you do a search. However I would advise against it. It would be all too easy for someone to reverse engineer your code to find out out to decrypt it (you must also want to decrypt it at a later stage, right?)
If you *must* save the username and password it needs to be at least as secure as windows encryption is. Try looking at the Crypto API. A search for such on google will give you quite a bit of information.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
In addition to Antony's suggestion, remember to not use key/value names such as username and password.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
If its for NT/2K/XP... isnt there a registry string type that will encrypt automaticly ? (Maybe it was added only starting with XP.
Just a thought.
|
|
|
|
|
darkbyte wrote:
isnt there a registry string type that will encrypt automaticly ?
I only know of:
REG_NONE
REG_SZ
REG_EXPAND_SZ
REG_BINARY
REG_DWORD
REG_DWORD_BIG_ENDIAN
REG_LINK
REG_MULTI_SZ
REG_RESOURCE_LIST
REG_FULL_RESOURCE_DESCRIPTOR
REG_RESOURCE_REQUIREMENTS_LIST
REG_QWORD
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Yeah, my mistake, i was confusing myself with IIS Metabase Data Types.
|
|
|
|
|
See :
CryptProtectData()
CryptUnprotectData()
I generally build a string "<username>\n<userpass>", encrypt it, and store in a single registry key.
The weakness is that anyone able to run as the user that encrypts the data can also decrypt it.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
u should be saving md5 hashes of the username and password in the registry i think
"there is no spoon"
biz stuff about me
|
|
|
|
|
i face similar problem,
therw may be many solution to this problem,the solution is this.
i when ever i save the password in registry i Encrypt using RC4 encryption and when ever i need it i decrypt it and make use of it
-----------------------------
"I Think It will Work"
Formerly Known As "Alok The Programmer" at CP
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
I think it all depends on the level of protection you require on the password
You may or may not need the password to be decrypted which imposes 2 different ways of storing the data.
1) Need to decrypt
This is a weak way of storing a password because it can be decrypted but one might find this easier to handle since they can display the password after or send it by e-mail etc.
2) No need to decrypt
You store a non-decryptable version of the password or user/pass (if it applies) then when you need to validate the password, you encrypt the source data (password or user/pass) and compare versus what's found in your storage (registry). This also has the advantage that you will mostly never have the password unencrypted in process memory except for the source data which isnt guaranteed to match.
Once you decided on how you want to handle storage, you can better decide which encryption method you're going to use. Remember that each encryption system has its strengths and its weaknesses.
|
|
|
|
|
You should never save a password, even an encrypted one, especially in the registry. You should, instead, save a cryptographic hash value that results from the password, and user name if you want to be really secure.
The way this works is that different passwords and/or usernames will produce different consistant hash values and you can not reverse engineer a password and/or user name from the hash value. When a user enters a password you can compare the resulting hash value to the saved value and determine if the password is correct without ever storing the actual password in a data store. If the hash values match you can say with a high degree of certainty that the user entered the correct password.
A 160 bit hash value is currently considered to be the standard for a secure system.
MD5 produces a 128 bit hash value, which is a bit undersized by todays standards, and, additionally, has been known to contain theoretical flaws which have recently been shown to be exploitable for applications like you are describing. It is still a viable hashing algorythm for certain types of applications but not for your application.
I would recommend SHA256 at a minimum (256 bit hash value) or for extreme security SHA384 or SHA512. SHA384 or SHA512 require 64 bit arithmetic and you must be carefull if you are implementing them on a 32 bit processor due to the difference in the way numbers are stored on different architectures. Therefore, since SHA256 exceeds the current standard for security and can be implemented with 32 bit arithmetic I would recommend that you use it as your hashing algorythm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
