So I recently started this high school hacking competition called picoctf. It started on Friday the 31st and goes until the 14th. It's entirely in Linux (in a bash-based web shell), and I was like "yeah, let's try this!'. The only problem is, I've never touched Linux before Friday, so I have relatively no clue what I am doing.

My dad is a computer guy so he taught me a few commands. I understand cd, ls -la, more, find, and stuff like that. He also gave me some books on Linux hacking and computer security, but by the time I read them the competition will already be over.

So I have a few questions for those who can help. I've looked online a lot but all the explanations are meant for people who know what they are doing, so they are far too complex for me to understand at this point.

So I have a few questions, answers would be good, explanations as to why this is the case (in simple form) would be great!

1) The difference between absolute and relative paths, and how this can be used to spoof an auth file with another file

2) How to run a loop (probably using vim) to search for a number

3) Once a public key is made, and put into the "authorized keys" file, how do you use it to log onto a website using ssh

4) how to use ssh to connect to websites with different ports

5) how to grep something



If any of those make no sense, I am probably just totally understanding this wrong.

Thanks for any help!

All of them make sense – but, let me encourage you to "Google it," as well as to do a Search upon this very forum.

All of these questions are legitimate – but you need to be the one to "dive in" and discover the answers.

And, know this: a very popular columnist and software-wizard, back in the day, wrote a column called "A Sip From The Fire-Hose." That is how this stuff is gonna make you feel – especially at first. (And, at sometimes-unpredictable intervals for the rest of your career.)

- - -

For instance, (3) says that if you create a .ssh directory, and(!) set the permissions to -rwx------ (nothing else will do!), create an authorized-keys file and put a public key into it, then ... if you've done everything just right ... you can log on "without a password" provided that you possess the corresponding private key. (Of course, the credential that you possess is far stronger than any "password" could ever be.)

But, here's the rub: "it might not work!" ... And now you are and until ... !! You find the problem and solve it. And this keeps happening, in one form or another, throughout your career. "That's why they pay you the big bucks."

No one ever "knows it all." Instead, they have mastered the art of diagnosis, resolution, and "making it look easy" in the manner of a duck.

We aren't here to do your homework for you, there is a reason these things are put into place and that is to test your knowledge.

But since you have been honest, I will at least give my advice which would be to get a box or a VM spun up with linux and try finding the answers yourself with an actual linux commandline.

By all means discover VirtualBox®.

All programs have manual pages, though they do vary in quality. They are intended as reference documents and not tutorials, so if you are really new to a program you might have to come back to the same manual several times between searching the net for more verbose. So for grep

If you read all the way to the bottom, there is also a see also section and regex(7) is mentioned. That will give you more information about basic regular expressions used by grep(1)

If you've been using OS X, you'll find most things either the same or at least very similar. If you've been exposed to Windoze, well, then you have a tougher row to hoe.

About that drinking from the fire hose concept, you'll have to learn to skim the material for the information you need. Usually you skim first for relevant options, such as -i or IdentityFile. The ssh manual pages are some of the best out there, but they are long.

So you may have to supplement that with other reading such as a chapter on SSH keys or various guides. Though with that particular task you'll find many slightly incorrect guides and many more outdated ones.

Absolute: not qualified or diminished in any way; total.
Relative: considered in relation or in proportion to something else.

/home/user/Downloads
~/Downloads



that is far as I am going.

Hi SPYROHAWK and welcome to LQ.

Kudos to your Dad for giving you some fundamental instruction and pointing you towards more advanced guides. And please note that persons here are basically offering this very same advice, which is some simple answers to the simple questions, and then information to aid you in learning further on the more involved subjects.

I wonder how you derived your list of questions. Care to share that?

You've taken a look and determined that the subject area is vast. This is very true.

My questions are:

1. What intentions did you have with entering this competition? Did you wish to learn something new? Did you have impressions that you could benefit from having said that you competed in this? Or something else?
2. Have you loaded up Linux on a computer?
3. Are there guidelines for what you should satisfy in order to submit something credible for this competition?
4. Are you being realistic with understanding that this may not end in two weeks with a first place, however you have embarked upon learning a lot about Linux?

Please understand that people are not trying to be harsh, we similarly understand that Linux is a broad topic, hacking using Linux is a broad topic, there are tons of references out there in the web as you've seen. Therefore things don't get easier merely by asking some focused questions. While you may get one or two focused answers, will those be worth your while, or will you have further questions coming from them? For instance BW-userx and sundialsvcs have both offered some direct answers. I'm not sure those may entirely clear up your questions on those topics however. Similarly there are suggestions from Turbocapitalist and r3sistance that can aid you a great deal, however you need to do the effort to understand what you are working with.

I'm still new to this forum, so I don't know how to quote stuff like you guys did for me. So I hope this format works?

-

sundialcvcs: I did google it a bunch, but I got lost very quickly. I like your "sip from a fire hose" analogy, which is what brought me here. I was hoping to find some people here to break it down for me. But thanks for the motivation!

-

r3sistance: I am not asking for people to do my work for me. I'm asking if anyone can offer explanations where all the other ones are really complex. If that's more complex than I realized, which I admit may be the case, that's entirely my fault.

-

Turbocapatalist: I have been looking at the man pages, but as you stated, they are very complex. Thanks for the regrex info, ssh_config, and that link. I will look at them right away.

-

BW-userx: Is it possible to see which one a file uses, and is it possible to change that?

-

rtmistler: I got my questions from the concepts I dont understand for a series of the challenges. For example, my key question comes from a challenge called "keyz" where you need to make a public key to let you log onto a website. My grep and loop questions come from a challenge where you need to run a loop to come up with a number the file is thinking of, then grep the responces for the flag.


1) I wanted to see what it was like. I have had background in programing robots so I figured (incorrectly) that it could not be too different. I wanted to see what hacking was like, and perhaps learn a bit.

2) No, only the webshell provided

3) There are levels (I am still on level 1) and each level has a certain number of challenges (10-15). Each challenge you need to find a "flag" which you then imput into an anwser box. For example one challenge called "JustNo" has the flag in a text file that you don't have permission to open. There's an auth file, and the hint says you need to use absolute and relative paths to spoof it into looking at a different auth file. Theres no "submitting something", just using whatever you can to find the flag.

4) I understand that. I have no dream of first place (I'm currently sitting at around 1600th place), and I had no clue what I was getting myself into. If I find this enjoyable and interesting after the two week period, I am seriously thinking about looking into this more, but for now I simply don't know.

I understand people are no trying to be harsh. I had no clue what I was getting myself into, and now I am scrambling to figure things out. No doubt I will have more questions down the road, but my goal right now is to figure out what I am going and then hopefully that will help me figure out later questions as well. I was hoping asking focused questions would yield simple reasponses, but I guess not. I am still grateful for everyone's help though.

Just click on the bottom right hand corner of the post, that says "Quote"

Oh, I'm an idiot. I was looking for a quote or reply button but did not see it

We all were at some point in time

is this challenge purely academic or hands on prove you can do it?

You need to get your hands dirty, and I think even though this seems to have been a good motivator to jump start you into wanting to find out about Linux.

as you stated in your first paragraph. You have never touched Linux until now.Now you told yourself I can do it. I can win or at lest be a contender in this race to see who's the best hacker.


contrary to what TV and the movies show. 98% of that stuff is made up. It's not macgyver where they actually showed how to do stuff that would actually work. so they actually left out a few details so people wouldn't actually be able to able to do what he did.

Me I do not hack, or try to hack into other systems. IP addressees trace back and liability and why go into someones system and destroy it just because I know how. That is not a good reason.

Therefore I do not seek such knowledge. How to cover my tracks on someones else computer so they do not know I was on it is another thing. I am not a hacker in the respect that you seek.


2. you're starting late in the game for this competition. It is not something you can learn over night. Sure you one can learn a few tricks but for someone to tell you how to do what they can do. There is a code of conduct even in the hackers world.

get you hands dirty or learn by experience. trial and error. One of the best ways to learn. because if you make a big enough mistake you'll not do that again. Along with repetition help retain information. Unless you have a photo memory.

3. as stated in here I learned long time ago that Linux/GNU is so vast that one could take their entire life trying to learn everything that one can do with Linux/GNU and still get no where with their life in the end.


you need to start from the start and pick an application or two or a few and learn how to use them. awk, sed, echo, redirection, what are all of the things one can do with just them in a terminal?

all of the different shells - pick one and learn how to change shells so you can work in your favorite one. do your deeds then change it back to what it was before you leave. cover your tracks. that in itself is a hand full.

ftp now most people use ssh that replaced ftp for the most part.

I do not know how to spoof a file using a directory path.

I do know if I gained root then I am home free to change or delete whatever I wanted. just by using my very limited knowledge that I have right now.

I also know that the internet has servers hooked up to them with search engines that can find loads of how to's on everything that anyone has made available to them. As well how to manipulate them into giving me what I want to know if it is out there on the net.

not to say that I do not like to enjoy the quick answer when asked to someone else as we all do from time to time.

So I am going to give you a little hint to help get you started down that road in learning how to spoof a file by taking what I've already told you.

"how to spoof a file linux" and "spoof an auth file linux"


MAC address spoofing

Don't judge yourself too harshly, we all miss stuff like that. It's happened before to any or all of us, and it will happen again.

Best of luck, I would encourage you to continue, but not put a deadline on things. I do realize that the deadline is for the competition, however myself I'd rather "learn" the stuff I set out to learn about, and do so properly. This is actually everyone's intent here, to give you guides to let you go as fast or as slow as you want, can, and can tolerate.

For the shell commands, a few tips are as cited, to use the man page or the info command. Also, consider writing scripts, paying attention to the return values from the commands, and working a lot with the shell, this will be invaluable for you whatever directions you go, for instance using Linux as an administrator, for hacking, or for programming.

1 members found this post helpful.

With most things code, looking at functional code teaches more than bland books on the subject. Understand the code for each and every line. Only then can you see what is broke, and what could be done better. Plus run and debug the code. Sometimes the only way to debug a language is to add code to output hints. In bash, some call that echo location.

Understand some basics, a lot of things have F1, :h, /?, -h, --help and other things to refresh your memory or clue you in on how to use them. On a mainframe, F3 instead of F1. The /? is a lot more common for dos/windows type platforms. There's man pages, man hier, for example attempts to explain the basic directory tree of a linux system. Understand various ways to EXIT a program. Hotkeys like ESC or Control+C or "q" for many linux terminal commands. More exotic keys like ESC + :q + enter for vi(m), and Control+C + Control+X for emacs. Or opening another terminal and using kill, xkill, killall to end a process. Or Control+Z to suspend a running process. Plus the jobs, fg, bg things to manage jobs. With ps, pgrep and other things to get the running process id.

There's more obscure things like stderr(2), stdout(1), stdin(0). With 2>&1 being a redirect to put the output of stderr into stdout, so it can be logged / piped into other things. Or $( echo xyz 1>&2 ) to send information from stdout to stderr so it doesn't get piped into other things when debugging. Where stdin is input and what the other side of the pipe might use with "-" or /dev/stdin. Lots of neat tricks for *nix style operating systems.

$ echo "file contents" > tempfile.txt
$ echo "file contents" > ./tempfile.txt

would be relative paths

$ echo "file contents" > $PWD/tempfile.txt

would be an absolute path.

Where $PWD is an environment variable with your primary working directory, aka your current directory. Relative paths are very useful for development as you can easily setup and use a test system without impacting production or having to change the code base. But they can be abused and exploited. Use the man pages for grep, egrep, strings, less, and other useful tools. They may not be easily understood for those not familiar with the lingo, but most of the information you need to know is there. And knowing things lets you work in air gapped facilities with no internet. Or continue working at home when your ISP sucks or when mother nature hates on you in above average ways. Or when your government / community works against you and leaves you no other option.

$PWD understanding how to figure out acronyms. Print Working Directory. Understanding that sometimes one thing that works on one thing may just work on another, both in Windows and Linux and Unix etc.. -- its called standardization.

Like he said. remembering that if you get stuck in your desktop and cannot do anything always try switching ttys, then log in again and pull the ole killall or pkill on whatever it is that is stopping you. Then switch back to regain your desktop.

ctrl+alt+F[1 thru MAX_NUMBER_TTYS]

it too comes in handy if you do not have gui login.