Any idea to use ret2csu automatically in setRegisters?

@Arusekk can you update this branch and see if we can get this merged?

Updated. I want to state that I am against merging it as it is now, since:

• ROP imports capstone unconditionally. This is hell slow (from pwn import * takes 3x longer) and capstone is promoted from optional to obligatory dependency (unicorn is also de-facto an optional dep only, I like it this way), so we would move this to a separate file, I guess?
• I think this can be done with a little bit better logic, not sure, though.
• This has no tests! C'mon, how can we trust this code continues to work! (it does work now, at least...)

I changed this to a lazy import, and added tests (and they do work locally, I swear).

I agree with @Arusekk's points.

"From own import *" needs to be as fast as possible. We should probably do some benchmarking of each commit with hyper fine to see where speed regressions lie.

Tests are absolutely critical for anything like this, and should definitely include at LEAST the basic case, if not also cases that do NOT work (eg missing the CSU area) to make sure things break in a clean and resumaable fashion

Alrightee, I have seriously no clue about why is this working every time under python 2, while never working under python 3 on GHA. It also always works locally, so this is a total mystery. Py3 even generates the very rop chain that py2 does, and it writes the same input to the same executable file! If anyone could investigate further, this would be a great relief.

Works fine for me on Python 3.6.9, on which version exactly it didnt work, can you please provide more details?

Works fine for me too, on all py 3 versions from 3.6 to 3.10, does not work on the CI only.

Here are the details:

1. Pwntools test launches an executable file.
2. Then it sends some data on its input.
3. The data is the same on py2 and py3, the same on CI and my box. The executable is the same on CI and on my box, the same on py2 and py3.
4. Something different happens. One executable reliably produces a valid core file on crash, the other reliably produces rubbish on crash. This might be some strange thing related to environment variables or whatever else, or runtime stuff. No idea.

Bug report (unrelated to the mysterious CI crashing): the whole section here makes assumptions about the order of movs that don't apply for a challenge binary I found:

.text:00000000004012D0 loc_4012D0:                             ; CODE XREF: __libc_csu_init+54↓j
.text:00000000004012D0                 mov     rdx, r14
.text:00000000004012D3                 mov     rsi, r13
.text:00000000004012D6                 mov     edi, r12d
.text:00000000004012D9                 call    ds:(__frame_dummy_init_array_entry - 403DF8h)[r15+rbx*8]

The code hyperlinked above assumes that r13-15 are used in setting edi/rsi/rdx, but (apparently) that isn't universal.

Locally, I made a hardcoded solution of changing r13-15 to r12-14, but I'm pretty sure that's not the right thing to do for the actual finalized PR. Not too familiar with capstone and I'm guessing there'll be a lot more horrible edge cases to come.

Update: the core file is not dropped under python 3 at all, supposedly because there already is a core file in current directory. Another thing is why this core file is not passed through apport.