Wind_Eagle's blog

By Wind_Eagle, history, 23 months ago, In English

Hello, Codeforces! I have a small question.

Recently I have seen some codes that use assembly, for example, this: code.

Of course, I understand, that this is done to cheat plagiarism checker. But shouldn't assembly code be not allowed? According to the codeforces rules, "it is forbidden to obfuscate the solution code as well as create obstacles for its reading and understanding. That is, it is forbidden to use any special techniques aimed at making the code difficult to read and understand the principle of its work."

Does this rule really work nowadays?

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

| Write comment?
»
23 months ago, # |
  Vote: I like it -95 Vote: I do not like it

If you can't read assembly code, you're not a programmer.

  • »
    »
    23 months ago, # ^ |
      Vote: I like it +39 Vote: I do not like it

    I can read assembly code, thanks for the corresponding course in my University :)

    But I think this point is not valid. If I will erase all new lines and spaces from the code, you still will be able to read it, but it will be very hard. This is called obfuscation of the code.

    Reading assembly is very hard, especially machine-generated, as the example in the blog. In an obfuscated C++ you can rename variables, add spaces etc. to make it readable, but reading assembly code for the hard problem with many lines of code is a very hard task that can't be make easier with just code formatting.

»
23 months ago, # |
  Vote: I like it +22 Vote: I do not like it

If the assembly is not handwritten, but one thinks they have a legitimate reason for submitting assembly (e.g. their language of choice is not supported), they should at least add the original source as comment.

Otherwise it's almost impossible to hack such a solution or to understand and learn from it.

Unless the contestant does work to argue legitimate use, I think by default assembly should be regarded as a violation of the obfuscation-rule and be punished accordingly.

»
23 months ago, # |
  Vote: I like it +94 Vote: I do not like it

It's usually a clever cheating mechanism. You submit an assembly version of a stolen solution, and you're good.

These things should be treated as rule violation. I guess it's fine if you have a short assembly snippet to make something run slightly faster (then it's usually foolish), but entire submission in assembly is a big red flag to me.

»
23 months ago, # |
  Vote: I like it +11 Vote: I do not like it

I would like to make a useless argument: I have tested this assembly thing to see whether I could submit a longer code (and I failed), because codeforces does not accept source codes larger than 65 kilobyters. To a certain degree of difficulty, the code gets very long, and as such its assembly version may surpass 65 kilobytes. So, even if one would obfuscate their code as such, they can't get too far (as it could be seen in the recent such case of the winner of the div2, who did not submit assembly code in E and F)

»
23 months ago, # |
  Vote: I like it -36 Vote: I do not like it

»
23 months ago, # |
  Vote: I like it -13 Vote: I do not like it

sir u r right, but plz supot Botswana thx

»
23 months ago, # |
  Vote: I like it +10 Vote: I do not like it

it is forbidden to obfuscate the solution code as well as create obstacles for its reading and understanding. That is, it is forbidden to use any special techniques aimed at making the code difficult to read and understand the principle of its work

Yes. Is using assembly merely an obfuscation mechanism? Certainly not. What I'm afraid of is that after a series of posts about this (there were at least two where I made the same argument before), assembly will be banned from Codeforces entirely.

Is transpiling a language a compiler for which Codeforces lacks to illegible C code wrong? No: generating non-human-readable code is not ideal, but that's what the output of transpilers usually look like and we are fine with that. Then why would submitting assembly be wrong? It's about as intelligible as script-generated C code, it takes a lot of time to understand exactly what is going on in both cases, so both are about the same level of 'bad' when it comes to hacking.

Cheating? Duh, there are lots of ways to circumvent it that don't involve assembly. A few months ago, inserting enough no-op instructions and/or a template was enough. Then why ban a way that few pursue? Protecting the service from infinitesimal cheating risk is less than useful.

To say nothing of the common cases when inline assembly is used for optimization. Every time you use compiler intrinsics, you are using inline assembly, after a fashion, and then there are people, like me, who sometimes optimize tight loops the hard way.

  • »
    »
    23 months ago, # ^ |
    Rev. 2   Vote: I like it 0 Vote: I do not like it

    Protecting the service from infinitesimal cheating risk is less than useful

    that is true, but considering that this new cheating method is getting more attention and using it is as easy as it gets, I think it won't be "infinitesimal" soon, and will become new cheating meta, if you can say so.

  • »
    »
    23 months ago, # ^ |
      Vote: I like it +1 Vote: I do not like it

    Excuse me, I want to disagree with you. Worth mentioning, I don't know assembly and therefore don't use it in the programs.

    Well, is it really a big loss, to have assembly banned? We already don't have it in the list of available languages. The way you insert it in the code is just clever workaround. Common user doesn't expect to find such instructions in a C++ code.

    You mention script-generated C code. Sure, it isn't readable either, but at least it satisfies the label — it's C code. Well, it's weak reasoning, but you just say something like "assembly code is evil, but it isn't more than transpiled program. So, we have many evils, why would we delete one, while other still being available?"

    The same argument could be applied to cheaters. The anti-cheating system is weak, but assembly is just one more way to bypass it; I suspect, hardly defeatable one.

    Optimization cases are from other matter. I personally don't argue against intrinsics or assembly insertions. However, I don't really like them. I think competitive programming is about thinking of the idea and writing correct code. I dare to say, these hard optimizations are never necessary here, at CF.

    That's being said, I don't want assembly being deleted just because I don't use it and it allows such optimizations that are impossible with some more high-level, slower languages. However, it isn't allowed on CF explicitly and I don't see much benefit from it.

  • »
    »
    23 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    To say nothing of the common cases when inline assembly is used for optimization. Every time you use compiler intrinsics, you are using inline assembly, after a fashion, and then there are people, like me, who sometimes optimize tight loops the hard way.

    Can you show me at least one-two examples where hand-written assembly works faster than machine-generated? To me this sounds impossible. Modern compilers are smart enough.

»
23 months ago, # |
  Vote: I like it +11 Vote: I do not like it

At least source my blog…

»
23 months ago, # |
  Vote: I like it +49 Vote: I do not like it

I think the problem boils down to "Is submitting assembly unfair to other contestants?". There are at least 2 cases.

  1. The assembly is hand-written. This may be either an entire file, or just a few lines of inline assembly. In this case I think it's ok. Yes, assembly is difficult to understand, but so is C++ code that has all variables named a, b, c, aa, etc. plus other bad coding habits. During an official round, a hacker might find them both impossible to comprehend, but if the author wrote (and understands) the same code that the hacker is reading, then there's really no unfairness.

  2. The assembly is generated by a compiler or other programs. In this case, I think it is reasonable to skip such submissions. There are two reasons this can be unfair:

    • It is practically impossible to tell if the original source is plagiarized.
    • Compiled assembly is extremely difficult to read, especially with optimizations. Submitting the original source would yield the same result, so converting code to assembly usually has no purpose other than obfuscation.
      • In the case of "transpiling", for example submitting compiled Nim (which is not supported by codeforces at the moment): I believe it still counts as obfuscation since the author did not write (and most likely cannot understand) the submitted code, so it's unfair for users trying to understand the submission.

Telling between these cases is often easy (at least for a human). For example, in the linked submission, you can see

  • mangled C++ names
  • lots of compiler-generated labels
  • obscure instruction usages (e.g. cltq/cdqe when one can just use rax the entire time)
  • the compiler telling you its version

My conclusion is: If the author submits assembly they wrote, it is ok. Otherwise if it's clear that a submission contains compiled assembly code, then it should be counted as obfuscated.

»
23 months ago, # |
  Vote: I like it +15 Vote: I do not like it

For everyone who legitimately wants to submit compiler-generated assembly (e.g. if you want to locally compile your code with profile-guided optimizations), there's a pretty simple way to do it in a definitely legal way: just include your source code in a comment at the top of the file. I know a few Rust users do something similar, since they submit generated code in order to bundle dependencies in a single file.

(This doesn't necessarily answer whether the recent submission constitutes (intentional?) obfuscation, but there at least is an alternative.)

»
7 weeks ago, # |
  Vote: I like it -13 Vote: I do not like it

How did they convert the codes in Assembly? ?

»
7 weeks ago, # |
  Vote: I like it -10 Vote: I do not like it

Alu lelo