Так суть механизма RETGUARD, не от закрытия каких-то багов, а от предотвращения дальнейшей эксплуатации бага (того же переполнения стека). А так если даже предотвращается эксплуатация, но никак не защитит от DOS и приведёт в любом случае к падению приложения. Если имеется возможность как-то получить результат ксора, то легко можно вычислить ту самую куку, которая непонятно когда вычисляется (формируется) на этапе компиляции или в рантайме, одна ли она для всех ретурнов или разная, и внизу в коментах задали наводящий вопрос - а как валидируется потом реальный адресс возврата (хотя его валидация не важна, приложение будет падать при "хер пойми ретурн адресе", а что когда он неожиданно укажет на валидное место?). Доказано - РОП идеальный механизм, которому нужно противодействовать только, как я думаю, попыткой переосмысления всей Фоннеймановской архитектуры, как минимум вынести хранения адресов возврата из стека куда нить в другое место :)