Kognition's blog

By Kognition, history, 6 years ago, In English

I posted this as a comment on the last contest, but upon request, I turned it into a blog post so that it may get more attention.

Is there any way to hack consistently with regard to a segfault? There were a few times that I've seen people accessing, say, s[n] when s only had n elements allocated to it, which should cause a segfault, but because of the magic of operating systems, segfaults only happen sometimes. These people will probably fail during systests, but I can't reliably hack because even if I submit a hack, the OS might not complain about a segfault and I'll get an unsuccessful hack. Is there any way around this or should I just not try to induce a segfault in a hack?

  • Vote: I like it
  • +29
  • Vote: I do not like it

6 years ago, # |
  Vote: I like it +3 Vote: I do not like it

I too have faced a similar situation and got disappointed when a user got Runtime error on main test cases, while on hacking, they somehow manage, and the hacker got -50.

For the case, you mentioned that someone wants to access s[n], while it's not allowed. I suggest you to not to go for hack if they've used vector instead of an array in C++, because, on my IDE, I've noticed that vector somehow manages that kinda situation itself. They don't display segfault, but they used to assign value 0, so in many situations, it adjusts automatically.

Well, I too want a rigid solution for the que you've asked in your blog. Thanks

6 years ago, # |
  Vote: I like it +30 Vote: I do not like it

No, there is no way to cause a segfault consistently. It is very hard to hack a solution with UB. I usually aim for causing wrong answer and only succeed like once in 20 times (in educational rounds). I copy solution into custom invocation tab, select the exact compiler the person used and add print statements to understand how incorrect values look like for various lengths of the input. It is also helpful to print addresses of local and global variables to understand where data ends up when indices go out of bounds. If I see that the value I need for wrong answer is too far way from incorrect values I get in practice or the space between variables is too big to overflow one into another, I move on. Because incorrect values are similar for different programs, I can filter out most of programs with UB as unexploitable in a few minutes per program. So I can do more experiments and put more thought into programs where UB looks more exploitable. It is so satisfying when hack finally works after dozens of custom invocation tab attempts... In a normal round, you can't copy paste solution and check it in the custom invocation tab, so I wouldn't try to exploit UB.