Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

/prog/ Challenge #1872 - Exploit slock

Name: Anonymous 2016-01-28 14:57

slock is a simple X display locker utility.

After invoking slock, the only way to get out of it is to enter your password.

The challenge: find a way to exploit it, so that the you get out of slock without knowing the victim's password.

The source code is less than 400 LOCs.
http://git.suckless.org/slock/tree/slock.c

Good luck.

Name: Anonymous 2016-01-28 15:12

Alt + SysRq + k

Name: Anonymous 2016-01-28 15:18

>>2
Gave me a kernel panic and I had to shutdown the computer.
Not an exploit unless it kills slock only and puts the attacker back at the X11 session or a logged in tty.

Name: Anonymous 2016-01-28 16:05

>>3
It meets the goal of ``get out of slock without knowing the victim's password''.

Name: Anonymous 2016-01-28 16:38

>>4
Then you could just reboot the computer.
You exploited my description of the challenge, not slock itself.
Good job, anyway.

Name: Anonymous 2016-01-28 22:25

#ifdefs everywhere, multi-line function headers, and excessive declaration spam. What a shitty thing to try to read.

Name: Anonymous 2016-01-28 22:48

#define _XOPEN_SOURCE 500
Don't do this inside the file.

#ifdef __linux__
Any compiler can define that even if you do not use linux as a kernel

die("buffer too small\n");
Shitty program, there are many places where you use such buffers.

Name: Anonymous 2016-01-28 23:27

>>6
That's because of Linux and BSD differences.
I don't think there's any way to make the program work on both.
Is there?

Name: Anonymous 2016-01-28 23:49

>>8
Link in different source files per platform, offering the functionality you need.

Use proper compatibility libraries.

Write it in any language other than fucking C shit.

Name: Anonymous 2016-01-28 23:52

Also, why aren't #ifdefs against suckless design style? Those add bloat and brittleness to the source code.

Name: Anonymous 2016-01-29 6:43

>>10
ifdef add bloat
ifdef are processed at preprocessor stage and if they don't match conditions, they are discarded before the lexer stage: in fact they prevent the #define's from even reaching the lexer. Its zero-overhead for compile-time C code.

Name: Anonymous 2016-01-29 8:10

>>11
Wasn't there a thread where some /prog/rider did a test and found the cost of stripping comments is non-negligible for sufficiently large amounts of comments? How much more time is wasted by preprocessing? As they say in the FIOC community "programmer seconds are valuabler the computer seconds". How long are you willing to spend compiling before #ifdef bloat gets out of hand?

Name: Anonymous 2016-01-29 8:21

>>12
It takes far less than templates.
C++ rotten template mess is thousands of times slower than gigabytes of #ifdef which are processed sequentially: in fact C preprocessor will beat any parser/lexer in speed due specialization - its practically the fastest text processor on the planet.
Also, I don't add much comments - my code is self-documenting.

Name: Anonymous 2016-01-29 8:46

C preprocessor is an esoteric language.
Clues:
1.Limited function set (define,ifdef,include)
2.Depends on another language (e.g. C) to actually run: is interpreted, not compiled.
3.Is a Turing Tarpit:requires extreme verbosity for minimal gain.
4.Is useless at actually programming anything.
It should be included in https://esolangs.org/wiki/ as a new member

Name: Anonymous 2016-01-29 9:09

>>15
C preprocessor is not limited to producing C code. It can produce assembler, LISP, Shakespeare poems, bitmap images.
It isn't a Turing Tarpit:
OrderPP proves that is roughly equivalent in abstraction power to any functional-paradigm language.
The only valid claim is verbosity: this could be reduced with some preprocessor extensions like _TokenOf() ( see http://w11.zetaboards.com/frozenbbs/topic/11501531/ ), #recmacro(recursive macro see http://w11.zetaboards.com/frozenbbs/topic/11512081/ ) and lifting the restrictions of defining macros in macros (see http://w11.zetaboards.com/frozenbbs/topic/11445035/ )

Name: Anonymous 2016-01-29 10:54

>>11
They add source code bloat. They obfuscate what's going on, and interfere with the language semantics.

If the whole point of the project is to seek bug resistance through clean, simple, straightforward, easy to understand code, then they're a dangerous and stupid thing to use.

Name: Anonymous 2016-01-29 11:02

>>16
Its not my fault they choose to pepper their code with #ifdef'z that could be encapsulated inside headers which would provide macros which #ifdef produce in the header preprocessing.

Name: Anonymous 2016-01-29 12:33

>>15
see http://w11.zetaboards.com/anusbbs/topic/11501531/
HOW ABOUT NO

Name: Anonymous 2016-01-29 12:49

>>16
Lisp adds real bloat, Abstraction Bloat. That is empirically verifiable and measurable.
C preprocessor only exist in compile time constructs and has no effect on performance of the C code that results from using it(zero-overhead).
The only cost of using C preprocessor is time/memory spent in preprocessing stage.

Name: Anonymous 2016-01-29 13:31

>>19
---> the argument

0 <- your head

Name: Anonymous 2016-01-29 14:07

---> reddit
>>20 <- your post

Name: Anonymous 2016-01-29 14:13

>>21
You are correct, my post wasn't on reddit. What's yoor point?

Name: Anonymous 2016-01-30 6:56

>>19
I am >>16. I am talking about writing C code that meets criteria of not sucking. What in all of the fuck are you rambling about?

Name: Anonymous 2016-01-30 7:24

criteria of not sucking
Purely subjective Unix hipster drivel. Real code bloat is measured in kilobytes.
What units you employ to empirically measures code "suckiness"?
Give concrete criteria beyond "i have an irrational hatred for preprocessor and can't read macros".
Also explain how you will replace #ifdef's... I'll be eager to listen.

Name: Anonymous 2016-01-30 8:49

>>24
I'm not affiliated or even a fan of the suckless shit. I'm just pointing out that suckless's own code sucks by very basic metrics of suckiness. >>16 points out their own failure at their own game. Replacements are obvious and are in >>9. Anybody who'd done any properly abstracted C code knows this basic shit. Suckless fails at writing C, even ignoring other languages completely.

Name: Anonymous 2016-01-30 21:46

>>12
Compiling separate translation units and linking them together will be way slower than parsing #ifdefs - especially if you want LTO to match the performance of a single TU.

Name: Anonymous 2016-01-31 1:16

>>26
Is the point speed, or is the point to reduce the amount of bugs in software that come from brittle coding practices?

Suckless seems to harp most on the bugs that come from their various definitions of "suck" and how the codebases run out of control of their programmers in complexity, editability, and straightforwardness. Inline #ifdefs are in that specific code smell.

Name: Anonymous 2016-01-31 11:02

>>26
Parsing asm statements is much faster than parsing C. That basically makes C a useless abstraction.

Name: Anonymous 2016-01-31 15:25

>>27
``Never use conditional compilation ever'' is cargo cult nonsense.
They only needed to support two different optional features in this case, so using a couple #ifdefs is the correct choice.
If they add more in the future it might be time to break it out into separate files with a common interface, but there's no point doing that from the beginning because *that* brings about bloat and bugs in the form of over engineering.

Name: Anonymous 2016-02-01 1:35

Cargo cults worship the holy cargo.

Name: Anonymous 2016-02-01 5:45

>>29
In other words, it's a slippery slope that suckshit is happy to be on.

How bad your current location on a slippery slope is, is subjective. The fact that you're on one is objective.

Name: Anonymous 2016-02-02 2:41

>>29
A cargo cult is not a universal declaration with no nuance. It's adopting a behavior that everyone else seems to be doing, without having a clue why. ``We're switching to Bonerlang and building our new stack on the KVM write any time run all the time. Why? Cuz it's the fucking future dood, wooo~!''. An aversion to preprocessor bullshit is healthy and normal.

Name: Anonymous 2016-02-02 8:54

>>32
healthy and normal

You sound like a far-right misogynist racist.

Name: Anonymous 2016-02-02 11:25

>>33
far-right
It's called "reactionary" these days, your sjw speak is weak.

Name: Anonymous 2016-02-02 11:40

>>34
I'll improve and fight the white male patriarchy better, I promise.

Name: Anonymous 2016-02-03 5:50

Preprocessor hacks are worse than the white male patriarchy and SJWs combined.
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -