Emoji Analysis (Smart Home, 300p)
You find a strange note from your backpack.
PS! There is also a post-it-note on the backside of the paper where are written the following numbers *32 54 80 46 155*.
Figure out what the note means and find the flag.
strange note.
solution
Website contains full of emoji and some letter in-between.
Looking for popular English words and manually decoding emoji by emoji, text is decoded.
document.body.innerHTML = document.body.innerHTML.replaceAll('🎶', 'o').replaceAll('✈', 'p').replaceAll('🗺', 'l').replaceAll('🛹', 'i').replaceAll('🤡', 'a').replaceAll('🌮', 't').replaceAll('😁', 'e').replaceAll('👌', 'd').replaceAll('🥩', 'q').replaceAll('🏃', 's').replaceAll('🧦', 'r').replaceAll('🌭', 'g').replaceAll('🧦', 'r').replaceAll('🤌', 'y').replaceAll('👮', 'f').replaceAll('🔪', 'w').replaceAll('💛', 'n').replaceAll('🐤', 'h').replaceAll('👽', 'b').replaceAll('🍉', 'v').replaceAll('🎃', 'j').replaceAll('🎁', 'k').replaceAll('🐖', 'x').replaceAll('🤩', 'z')Resulting text:
writing small programs is pretty easy stuff. true, there were some details that had to be learned, as well thirty two as new concepts. but, the basic mechanics were simple. writing large programs is quite another matter. there are several reasons why long programs are more difficult to write. one is that short programs are often used just once, and then fifty four discarded. long programs, on the other hand, are often designed for use by others. Consequently, they have to be written more carefully, to anticipate eighty all forms of misuse. they must also be provided with elaborate documentation and manuals. another reason, many believe, is the limitation of a human being's short term memory. Most persons can understand or grasp a short 10-line program in a few seconds. and they can keep it in mind while forty six they contemplate changes. with large programs, the programmer must have all useful information written down so it can be referred to when attempting to understand or change the program. still another reason is the limit of what can appear on single screen or page. short programs that in one hundred fifty five their entirety occupy but one page, or one screenful, are easier to understand than longer programs, which require page-turning or screen-scrolling. whatever the reasons, writing large programs is not easy. even profes- sional programmers have trouble. one hears about rockets crashing because of programming errors. and one hears that large programs may have hun- dreds, or even thousands, of errors many months after they were allegedly completed. it is almost impossible to write a program that has no errors. if for no other reason, we often do not know exactly what the program is supposed to do, to the last detail, until after we have built it. but there is much when can do to bring us closer to that error-free goal. the first step is to understand the stages in developing a large program. these stages are often referred to as the software development life Cycle. it is important to know what the program is supposed to do before starting to build it. this is especially true if the program is being built for someone else. Matters to be determined during this stage include the user interface, algorithms, data structures, generality, and robustness. what should the user have to do to interact with the program? should there be commands to be typed in? should one use menus? how much freedom should be allowed the user, with respect to, say, spelling errors? what should the output displays look like? it is at this stage that you should decide how best to proMpt the user for proper input, and how best to label the output. this is not always as easy as it sounds. if the program requires extensive computation, what methods should be used? for example, if a list of names needs sorting, which sorting algorithM should be used. algorithM is merely the name given to a computational method that (a) might require input, (b) always produces some output, (c) completes its work in a fnite amount of time, and (d) does what it is supposed to do. how should the data of a problem be organized? should one use lists or tables? should the data itself be sorted, or should use be made of an indexed sort? which, if any, data should be stored in files? one should spend as much time answering questions like these as questions of what algorithms to use. for, the efficiency of a well-written sorting algorithm will be lost if the data are stored clumsily. should a program be a special purpose program limited for use in a small number of situations? or should the program be general purpose, of use in a wider variety of circumstances? there are arguments to be made in each choice. a special purpose program is almost always easier to use. fewer commands have to be given, and fewer choices have to be made, to get it to do its job. More general programs, besides being much longer, require the user to make more choices and issue more commands to get it work. and, the user may have to study a much larger manual before using the program. on the other hand, a general purpose program will do more things for the user. and perhaps, only one general purpose program might be needed for a series of tasks, whereas several special purpose programs would be needed. robustness is the degree to which a program responds "gracefully" to being fed bad data or bad commands. for example, does it give the user a second chance if the user misspells the filename? these are but a few of the kinds of questions that must be during the specification or planning stages of building a large program. program design is the most difficult part of building a large program. for the most part, it involves deciding how a large program should be divided into subroutines. a design is often represented by a structure chart, which is simply a chart that shows which subroutines call which other subroutines. for example, a top-level subroutine, which is actually the main program, calls three other subroutines. thats all there is, as the three other subroutines do not call other subroutines. structure charts shows the names of the data that are used and produced by each subroutine. if the data are passed to and from the subroutine as parameters, their names appear next to small arrows close to the line connecting the subroutines. if the data are not passed, we use arrows that originate and terminate inside the rectangles that represent the subroutines. given a particular design (a particular structure chart), there are two important questions that need to be raised. first, how does one evaluate the design? and second, how does one develop a design in the first place? although there are design methodologies whose purpose is to come up with a design, suffice to say, they require a careful and thorough understanding of the underlying problem, and take sometime to explain and understand. the following are a few ideas that can be used to evaluate a design, once one has been made. these ideas are heuristic because following them usually, but not necessarily, leads to a good design. it is better to keep subroutines shorter than one page, or one screenful, in length. if that is not possible, then so be it. but it is much harder understand a subroutine if you must constantly shift pages or screens back and forth. one exception to this principle occurs when a subroutine consist of, say an if structure with a large number of elseif parts. here, the cure (having several short subroutines) is worse than the illness (having one long subroutine.) a subroutine that does one single task is almost always easier to write and test than a subroutine that does several tasks. a single task may, however, be quite complicated. for example, a subroutine that solves a linear programming problem is necessarily quite complicated, and may indeed call other subroutines. but it still has its purpose, a single task. software engineers use the term (cohesion) to describe the degree to which subroutines can range from being single-purpose (functional Cohesion) to being a disjointed collection of unrelated tasks (coincidental cohesion). if a subroutine needs four data elements to do its work, then the calling sequence must contain four parameters. for example, the subroutine person- result needs four parameters (the number of persons, the number of items the price list, and the sales table). four is not too many, but if a calling sequence contains ten or more parameters, perhaps it is time to reconsider the design. as much as it is possible, one should supply the data needed by subroutines through their calling sequences. the reason is that it is then clearer what data are needed by the subroutine and therefore less likely that errors will occur. this goal seems like the antithesis of our third goal. if we commun- icate the data through calling sequences, then the calling sequences will be longer. one recommendation is the use of internal subroutines without para- meters to subdivide a large program into smaller pieces. this is still a good idea. but if all the data needed by a subroutine is provided through its calling sequence, then the subroutine can be made external. external subroutines are much less likely to contribute to errors than internal sub- routines that share data. furthermore, an internal subroutine that has no parameters, but that uses 10 or 15 chunks of data, is likely to be quite complicated.
There is nothing particularly interesting in text, except some uppercase C and M letters. That didn't lead anywhere.
Researching various ciphers, which use numbers as key, lead to book cipher.
Using public book cipher decoder with given numbers 32 54 80 46 155 results in answer LPHMI (first letter of the word) or LARGE PROGRAMS HAVE MORE INFORMATION (the complete word).
Flag is LARGE PROGRAMS HAVE MORE INFORMATION.
