Use a while loop and get rid of the goto statements.

I request elaboration

Why cant you use a while(PC!=limit && user!=limit) instead of a do-while and replace the goto statements with a continue?

coz i set a target score as limit and i need to repeat the rounds till it reach the score

You can do the same with a while loop. And it will also work when user enters 0 as input for limit variable. Even otherwise you should still not use a goto. You can instead replace it with a continue statement.

Use a while loop and get rid of the goto statements.

#include<iostream> int main() { int limit; std::cout << "\nEnter the score\t:"; std::cin >> limit; int pc = 0, user = 0; do { label: int random = 1 + (rand() % 3); int button, choose; std::cout << "\n****ENTER YOUR CHOICE****\n 1. ROCK \n 2. PAPER \n 3.SCISSOR\n"; std::cin >> choose; if (random == choose) { std::cout << "\n!!!![SAME CHOICE]!!!!"; goto label; } if (random < choose) { if ((random + choose) == 4) { std::cout << "\n\n PC SCORED\t:\t" << ++pc; continue; } std::cout << "\n\nUSER SCORED\t:\t" << ++user; } if (random > choose) { if ((random + choose) == 4) { std::cout << "\n\n USER SCORED\t:\t" << ++user; continue; } std::cout << "\n\nPC SCORED\t:\t" << ++pc; } } while ((pc != limit) && (user != limit)); if (pc == limit) std::cout << "\n\n!!!!PC WINS!!!!"; else std::cout << "\n\n!!!!USER WINS!!!!"; return 0; }

Why? ..Code seems to be clear & precise of what is intended there...Unless goto messes with the code clarity I see no harm in here ...

Why? ..Code seems to be clear & precise of what is intended there...Unless goto messes with the code clarity I see no harm in here ...

It will eventually when the code size increases. Most of the uses of goto start with a small code base and then get left behind when the code size increases. And using continue instead of goto in his code does exactly the same thing. So why use something which has a dubious distinction when there is a perfectly valid replacement

i know its a bad practice but i found it as a minimal approach there

i know its a bad practice but i found it as a minimal approach there

Continue does the same thing that goto does here except that the condition in the while loop is checked again.

No no .. ..It's not a bad practice ...Just matter of clarity n style ...Linux Kernel is full with goto code ...Even today people commit code with goto ..Some times it's very logical sometimes it make code messy ...That's it ..

No no .. ..It's not a bad practice ...Just matter of clarity n style ...Linux Kernel is full with goto code ...Even today people commit code with goto ..Some times it's very logical sometimes it make code messy ...That's it ..

depends upon the logic i used i guess

I am saying that if you replace goto with a continue in your code, it would work just the same way

I am really struggling in pattern printing with nested for loops in , somebody please help me to improve my logic for this types of problems. 😔

Try jeeny 's video 👆

hello can anyone help me understand a small c code

How can help you

i want to understand this code

i want to understand this code

Okay, I can help you write me inbox

#include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <seccomp.h> #include <sys/mman.h> #include <limits.h> #include <fcntl.h> #include <sys/stat.h> #include <sys/types.h> #include <string.h> void setup_seccomp() { scmp_filter_ctx ctx; ctx = seccomp_init(SCMP_ACT_KILL); int ret = 0; ret |= seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(sendfile), 0); ret |= seccomp_load(ctx); if (ret) { exit(1); } } typedef void (*void_fn)(void); int main(void) { setbuf(stdout, NULL); FILE * fptr = fopen("flag.txt","r"); puts("Goodbye flag!"); int ret = remove("flag.txt"); if (ret == 0) { puts("Flag file successfully removed."); } else { puts("Error removing flag file"); exit(-1); } puts("What do you have to say about us so carelessly removing your precious flag?"); void * buf = mmap(0, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0); void_fn sc = (void_fn) buf; ssize_t num_read = read(0, buf, 100); setup_seccomp(); sc(); return 0; }

This program exhibits Undefined behavior. Firstly it expects the memory mapped page to be allocated within the code segment which is not the case. Secondly it expects whatever bits may be present in the memory mapped page must be of an executable code and then proceeds to execute it. As far the rest of the code, it just sets a Linux kernel filter to kill this process if it tries making any system call other than sendfile.

so my question is how can i read the flag file before the program deletes it

You wont know where the flag file was stored in memory. If you want to read it after it has been deleted, you should try finding out the memory location where it was mapped to by reading the /proc/self/maps file and then create a mmap around this boundary. Not guaranteed to work. Even if that was your aim, why did you have to create those filters?

i am learning exploit development and this is the challange that he send to me

i think he was preventing me from running execv by using that function?

i have to write a shellcode to do it

so my question is how can i read the flag file before the program deletes it

File is not closed right.....May be you can list the file descripotor used by this process ...Then read from it in the script..

She can just get it from the FILE* ptr.

Thought he has to write a script to exploit..If iam nit wrong..

In C code within the same process you can get a descriptor from a FILE* pointer.

I guess the solution will be sendfile(1, fileno(fptr), NULL, 100);

I am not sure sendfile can write to stdout though.

It has to be done through another process. So the file descriptors wont work as the ones returned by fileno are per process entries. She has to read the vnode table to get the file descriptors that are maintained system wide and not per process.

That mmap() with PROT_EXEC allows you to give a payload as the code. It reads from stdin. So you need to write an Assembly code that perform that syscall. I guess.

That is what I assumed as well. But she said that is not the case. And even if we allowed it to write our own payload (should be less than 100 bytes) then all that has to be done is an assembly code that sets the eax register to fileno call number, followed by a trap into the kernel and reads the return and then follow it up with a sendfile system call. But the problem is that fileno call wont work because it is not allowed.

No, the eax will be 40, because sendfile syscall number is 40. And fileno is not a syscall, it actually just takes something from FILE * struct (it contains a file descriptor).

No, the eax will be 40, because sendfile syscall number is 40. And fileno is not a syscall, it actually just takes something from FILE * struct (it contains a file descriptor).

i guess the file will be in the same directory

It has to be done through another process. So the file descriptors wont work as the ones returned by fileno are per process entries. She has to read the vnode table to get the file descriptors that are maintained system wide and not per process.