|
XORing a byte by the previous byte isn't a particularly great encryption system. Crackable in moments.
Also note that the parameter dwLength is basically ignored, after determining whether the requested offset and length is within the buffer. Instead, all the data up to the end of the buffer is 'encrypted'.
If forced to rewrite this rather than use a proper encryption algorithm, I would replace the last line with:
for( DWORD byte = 0; byte < dwLength; ++byte )
{
pData[byte] ^= byFoo;
byFoo = pData[byte];
}Note I'm using array indexing rather than pointer arithmetic. Converting from one to the other is a simple and fundamental optimization which all C++ compilers will implement.
|
|
|
|
|
BadKarma wrote: while(pData < m_lpBufCur) byFoo = *pData++ ^= byFoo;
They wanted to encrypt the encryption algorithm? 
Cheers,
Vikram.
"But nowadays, it means nothing. Features are never frozen, development keeps happening, bugs never get fixed, and documentation is something you might find on wikipedia."
- Marc Clifton on betas. Join the CP group at NationStates. Password: byalmightybob
|
|
|
|
|
Here's one of my favourite functions in a system I'm working on right now. Every time I read this I get an overwhelming feeling of wonder...
bool CReportMethods::IsSalesTypeValid(const CXmlEntry & Entry)
{
if ( Entry.sty.GetValueAsLong() == 4L )
{
return(true);
}
else if ( Entry.sty.GetValueAsLong() == 5L )
{
return(true);
}
else
return(true);
}
|
|
|
|
|
Wow. I just really hope it's result of changes in sales type validity rather than that someone wrote it like this from scratch  Still its just wrong on so many levels. Nice.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
|
|
|
|
|
I saw (Visual Basic)
IF a=1 AND a<>2 and a<>3 and a<>4 THEN ...
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.
|
|
|
|
|
It's that case where another thread accesses a during the call..., oh wait - you said VB
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Even in a multithreaded application the code shown didn't make any sense (at least for me).
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.
|
|
|
|
|
True, but I really should have put a joke icon on the post.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
surely it was coded that way to ensure extensibility?! ![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif)
|
|
|
|
|
Everyones a winner, I wonder if the unit testing picked up on this.
.net is a box of never ending treasures, every day I get find another gem.
|
|
|
|
|
Of course it did. Assert.IsTrue(...); Never fails.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Ah yes, the unit tests don't exist. 
From the method comments, it seems like it should return true only for the two ifs and false for the else. I'm not even sure who to talk to about this; it was coded 3 years ago by a contractor in another country and not part of the packages we're working on.
My prediction is that this baby's here to stay.
|
|
|
|
|
to_be_defined wrote: it was coded 3 years ago by a contractor in another country
Yup, that explains all.
.net is a box of never ending treasures, every day I get find another gem.
|
|
|
|
|
to_be_defined wrote: Here's one of my favourite functions in a system I'm working on right now. Every time I read this I get an overwhelming feeling of wonder...
Hold on, so what you're saying is that you keep looking at a function that does a few checks and returns (true) irregardless of what it checks and what happens.....and _no-one_ has changed it to remove the checks...hmm :\
|
|
|
|
|
Of course not! I works doesn't it?!
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
And, in many installations it would remain the way it is. In order to change code thee must be a request for an enhancement or to fix a problem. If you fix something that's 'working' and introduce a new bug you can be for the high-jump.
Paul
|
|
|
|
|
It probably depends on where you work and if you're the one who has to support the code in the future. If I was the one who had the support the code, I'd change it. At least then if something breaks, I'm also the one who has to fix it.
|
|
|
|
|
If it was my code, my responsibility etc, so would I. I have worked as a contractor for 25 years, and I can assure you it would NOT be changed at many places where I have worked without an RFC (request for change), cost benefit analysis, documentation, code review, test plan, version control, comment out old code and insert new, etc etc.
However, if you are changing a part of the system which incorporates that particular bit of code then kill it, cus you have to do all of the above anyway.
However, sometimes code you think does nothing, may do something. A slight change to the above algorithm, say that it becomes possible to drop through the code and exit without returning a return value. This throws an exception that is caught elsewhere. (That, for example, would happen with Powerbuilder 8+).
Also, there may be a difference in behaviour between just returning true and looking at a passed invalid parameter (say a null pointer).
For these sort of reasons, many sites will use an "if it ain't broke then don't fix it" approach. Chaning code withour permission is loose-cannon behaviour. I am not trying to support this position, all the fibres of my soul want to change code when I see it is badly written, designed or implemented. You just have to learn to sit on your coding hands.
Paul
|
|
|
|
|
Wow, I must say I am still learning the ways of software development but your post is interesting and enlightening in so many ways. Very interesting to try and understand all the ramifications of changing even the smallest and seemingly insignificant piece of code in an already developed project. I suppose to most sobering fact is that there are probably many cases where you just have to put up with bad code purely due to the fact that it is just not cost effective to go and correct the mistake/s.
|
|
|
|
|
Your point is well taken. I can see where a change to this code as innocent as it sounds could cause a large problem for everyone. This without doubt explains why software created by the giants frequently breaks. The Coders don't want to go through the mountain of $xxt and paperwork it would take to fix a seemingly minor problem. And so we go back to a time when we put in NOPs into ASM code to later take it out and call it an update.
|
|
|
|
|
yeah, but its a function that returns true no mater what the conditions are, and judging by the calls it makes, doesnt do anything else.so..
|
|
|
|
|
There could be some side effect of the GetValueAsLong() method call that the rest of the system is depending on. If the code looks bad at face value, you should only assume it gets worse as you dig into it.
|
|
|
|
|
-irregardless-
That's a good one for this discussion. I bet if you changed that to simply return true all the time, it would totally break the application...
|
|
|
|
|
Ihave seen much strangers things happen!
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I can see you have been in the industry a while - I agree. I can think of at least 4 reasons why the code above may behave differently to "return true", depending on the language and hardware.
Paul
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Badger | [badger,badger,badger,badger...]](https://www.codeproject.com/script/Forums/Images/badger.gif)