Hello,
ok, to test your hypothesis (out of bounds access), there's this
strategy I propose you:
1. Add a counter in the code file right where rc is created
2. map all moves of the pointer onto the counter (eg all increments)
before the loop
3. in the loop: print the counter value (to console for your convenience?)
4. in the loop: increment the counter value right after the pointer is
incremented
If the output says "10" at some point, then there's indeed an
out-of-bounds access and if not, it must be something else.
(silent assumption: "ptr++" of a non-byte ptr actually jumps to the next
object (instead of the next byte), else 40 is the dangerous value)
I hope this helps you :)
BR
JPM
Am 03.09.2016 um 20:48 schrieb Florian K:
> Hello,
>
> I've recently encountered some kind of undefined behaviour and tried
> to ask a question
> <http://stackoverflow.com/questions/39251961/cryptography-bizzare-behaviour-in-release-mode>
> on Stackoverflow. The answers were kind of expected...
> I have a few programs in one solution and have another library using
> CryptoPP classes and adding functionality.
> After days of debugging and checking out various possible causes, I've
> came to the conclusion that either something is wrong in the
> "UncheckedSetKey" function or I am still clueless.
> Debugging simultaneously with two Visual Studios (2015 - SP3) through
> the same solution with different programs it showed that the values
> show a first difference at this line:
>
> |
> while(true)
> {
>
> rk[keylen/4]=rk[0]^_mm_extract_epi32(_mm_aeskeygenassist_si128(temp,0),3)^*(rc++);//<---
> Here
> |
>
>
> While this loop is being run quite a few times, it appears to be that
> the array/pointer to array "rc" is out of bounds. The array itself is
> declared and initialized with 10 values.
>
> |
> staticconstword32 rcLE[]={
> 0x01,0x02,0x04,0x08,
> 0x10,0x20,0x40,0x80,
> 0x1B,0x36,/* for 128-bit blocks, Rijndael never uses more than 10
> rcon values */
> };
> constword32 *rc =rcLE;
> |
>
>
> Obviously it appears that some random memory area is being accessed.
> I cannot spot any kind of error or misuse of CryptoPP in the "faulty"
> program.
> Strange enough, the other programs do not seem to have any issues.
> This behaviour is the same in 32 AND 64-bit.
> Do I see this right ? Or are there by chance some wrong settings /
> compiler flags causing this ?
>
> Regards,
> Florian
> --
> --
> You received this message because you are subscribed to the "Crypto++
> Users" Google Group.
> To unsubscribe, send an email to
> [email protected].
> More information about Crypto++ and this group is available at
> http://www.cryptopp.com.
> ---
> You received this message because you are subscribed to the Google
> Groups "Crypto++ Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected]
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
