Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

something fishy here in px1kcr-clarify.py #1

Open
themaddoctor opened this issue Jun 23, 2024 · 9 comments
Open

something fishy here in px1kcr-clarify.py #1

themaddoctor opened this issue Jun 23, 2024 · 9 comments

Comments

@themaddoctor
Copy link

If I remove these lines:

    if not s.solution(plaintext.get_byte(curChar), vp.get_byte(curChar), extra_constraints=[key == vk, ciphertext==ct]):
        print()
        IPython.embed()

then the program never finishes. It appears that the expected solution is built into the attack.

@stef
Copy link
Owner

stef commented Jun 23, 2024

it might be related to this bug: angr/claripy#241 (comment)

@themaddoctor
Copy link
Author

But if we only remove "IPython.embed()", and replace ONLY the ct with the test ct, it also does not finish.

@stef
Copy link
Owner

stef commented Jun 23, 2024

it would be interesting to see how all those asserts work with a solver that has not seen any asserts before. so making a copy of the solver before the solution() and throw it away afterwards... it might be indeed that z3 somehow uses the extra constraints from the asserts to keep some internal state, which it should not...

@stef
Copy link
Owner

stef commented Jun 23, 2024

or alternatively use asserts with known good testvectors, do the final solve with an unrelated target vector.

@stef
Copy link
Owner

stef commented Jun 23, 2024

i'll try that. i'm afraid you are right that somehow the "the expected solution is built into the attack" by leaking through the asserts.

@themaddoctor
Copy link
Author

I will stay tuned.
Thanks for your attention.

@stef
Copy link
Owner

stef commented Jun 23, 2024

hmm, it seems that if i solve for a different ciphertext (using a different key as well) while having the asserts for the original ciphertext/key in there the code in line 318:

sol = s.eval(key, 1, extra_constraints=[ciphertext == ct_test])

indeed times out, and thus it seems invalidates my attack.

what is strange though, is that (this was a few years ago) i seem to remember actually testing the attack by first building the model (which takes ~50 sec) and then feeding it different ciphertexts and it solved them each in about 4 sec while reusing the model. maybe my memory plays games with me, but until i can recover exactly how and why that worked back then, i guess i have to say that the attack is broken. :/

@stef
Copy link
Owner

stef commented Jun 23, 2024

however painful the (hopefully temporary) result, thank you for your feedback and your interest in all this, it is much appreciated.

@themaddoctor
Copy link
Author

I am truly bummed. I was hoping to learn from this in anticipation of an upcoming challenge on MysteryTwister.

If you can find any old files from this attack, I have about three weeks that I can use to help figure it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants