RSS
 

Posts Tagged ‘C’

20 controversial programming opinions

06 May 2018

This is my response to the 20 controversial programming opinions stated in this Software Engineering Stack Exchange blog post.

  1. Programmers who don’t code in their spare time for fun will never become as good as those that do.
    I somewhat agree with this statement. Being interested in programming in your spare time by creating side projects and reading programming related material make you a better programmer. However, I don’t think one needs to devote their entire life to programming to become very capable. Even an hour or two a week working on a side project can make a difference.
  2. Unit testing won’t help you write good code.
    I disagree with this statement. Unit testing and test driven development (TDD) can help you write good code. With TDD you can write a test that fails and then write/alter code until it passes meaning you solved the problems. Edge cases can of course be discovered during development and a good programmer will revise/update tests if they encounter edge cases when creating their solution.
  3. The only “best practice” you should be using all the time is “Use Your Brain”.
    I agree with this statement. You don’t always have to apply a method, pattern, framework to every problem.
  4. Most comments in code are in fact a pernicious form of code duplication.
    I somewhat agree with this statement. I myself am guilty of writing some redundant comments. Actually I tend to over-comment quite a bit (which I still believe is better than under-commenting). Comments like this are obviously redundant but aren’t very common overall:
  5. “Googling it” is okay!
    I agree with this statement. Googling is always okay. Referring to references/documentation is efficient. Sitting down and struggling for an hour or recreating the wheel when you could have looked up a solution/idea/etc is just a waste of time.
  6. Not all programmers are created equal.
    I agree with this statement. There will always be a difference (minor or major) in the skill set of every programmer. Some will be more knowledgeable in some areas and others may be able to churn out code faster.
  7. I fail to understand why people think that Java is absolutely the best “first” programming language to be taught in universities.
    I agree with this statement. I think C is by far the best programming language to learn as your “first programming language”. Its very low level, bare bones and makes you take care of almost everything (memory management, complex data structures, etc). I had to code in purely C for my first programming class in University and it was a great start.
  8. If you only know one language, no matter how well you know it, you’re not a great programmer.
    I agree with this statement. A programming language is simply some predefined human-friendly syntax which is then compiled into machine code or parsed. A good programmer should know general programming concepts. They should in theory be able to pick up any language after a quick tutorial and become more advanced after learning language specific quirks.
  9. It’s OK to write garbage code once in a while.
    I somewhat agree with this statement. Sometimes to meet a deadline or address a time sensitive issue, you may have to write ‘garbage code’. This can always be refactored at a later date but keep in a mind its much more time consuming to refactor bad than to write good code initially. Thus, writing garbage code is rarely OK. 
  10. Print statements are a valid way to debug code.
    I agree with this statement. Although many don’t like it, a quick print statement for a very small bug may be more than sufficient. However, with more complex bugs, you’ll find a debugger is basically a necessity and print statements won’t cut it. I still don’t understand why some programmers have very strong opinions about using print statements to debug small bugs.
  11. Your job is to put yourself out of work.
    I agree with this statement. Writing code that is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned makes you great at your job. I also believe programmers that do this become very valuable over time.
  12. Getters and Setters are highly overused.
    I agree with this statement. Obviously this depends on the specific case but typically having a standard getter and setter for a private field means its more or less public.
  13. SQL is code. Treat it as such.
    I agree with this statement. A lot of people are careless when writing SQL statements making them inefficient, prone to security flaws or hard to understand. Treat SQL like code and design clean, clear and efficient statements.
  14. UML diagrams are highly overrated.
    I agree with this statement. I don’t believe UML diagrams are required for planning a well designed solution. They can be useful for documentation/showcasing a solution though.
  15. Readability is the most important aspect of your code.
    I agree with this statement. Readability often comes from the code itself. However, code style, variable names and comments can also contribute to the readability of your code. It would be fine to optimise some frequently used code at the cost of less readability if the changes are properly documented.
  16. XML is highly overrated.
    I somewhat agree with this statement. Depending on the scenario, using XML can be great.
  17. Software development is just a job.
    I disagree with this statement. For some people it may be. For others (like myself) its also very much a hobby. I wrote my first program and studied basic programming as a young kid. I wasn’t doing it because I was prepping for a job in 10 years, I was doing it because it was fun and interesting. I’m happy that I can do something I enjoy as a job rather than something menial.
  18. If you’re a developer, you should be able to write code.
    I agree with this statement. For obvious reasons.
  19. Design patterns are hurting good design more than they’re helping it.
    I agree with this statement.  I think trying to apply a design pattern in every scenario is problematic. Design patterns are useful and its good to be aware of them when designing solutions.
  20. Less code is better than more!
    I disagree with this statement. Sometimes less code can be better but lines of code (LOC) is a useless metric. The readability of the code is more important. I would take 1000 lines of readable, well designed code over 200 lines of garbage.

 

It looks like I agree with 17 of the 20 controversial programming opinions made.
As a graduate software engineer, I’m interested to know how my opinions will change in a couple of years when I’ve gained more real world experience.

 
No Comments

Posted in Programming

 

HACKvent 2016: Day 5

05 Dec 2016
CTF: Hackvent 2016
Link to challenge: http://hackvent.hacking-lab.com
Date Completed: 5 December 2016

Challenge

everybitisimportant

 

Solution

This seems like a series of boolean logical operators. As the hint tell use to use 32 bits, we will solve this problem with a quick C++ program so we can guarantee the data type used is 32 bits. Furthermore, we will try both signed and unsigned variants, it turns out that we need to use signed integers for this problem.

We come up with C++ code (splitting up the operations into 3 steps):

We run the program and the the printed result is:

I enter this into the ball-o-matic and get the daily QR code and daily flag!

Day 5 Solution Ball

 

Flag:  HV16-2wGq-wOX3-T2oe-n8si-hZ0A

 
No Comments

Posted in Hackvent 2016

 

HACKvent 2015: Day 14

14 Dec 2015
CTF: Hackvent 2015
Link to challenge: http://hackvent.hacking-lab.com
Date Completed: 14 December 2015

Challenge

The following Windows binary was also provided: Download EXE File

 

Solution

I download the binary and run it and am presented with the following program:

Hackvent Day 14 Program

It turns out that this program will tell you (via a messagebox) if you enter in the correct daily nugget or not!
So all we have to do is check the binary to see what causes the successful message box to appear.

Note: You can do this challenge using IDA or a .NET disassembler like ILSpy (link).

If using IDA, its useful to be familiar with CIL instructions.

ILSpy Approach
I decided to use ILSpy as it is apparently a very good .NET disassembler. I open the program and load the binary and it disassembles it into various classes as you would expect.
We are mainly interested in the hv15 class. By searching for strings like yes, that is the key! we realise the only important functions we need to look at are Button1_Click and  Encrypt .

This is the code for both:

Button1_Click

 

Encrypt

 

It becomes super simple to solve this challenge at this stage. The input parameter is just the text we enter into the textbox and the pass parameter is  Form1.GlobalVariables.assembly which is defined to be the string  __ERROR_HANDLER. All we have to do is reverse the encryption starting with an input that equals  zV5/UFU8PUD3N2T49IBuCwvGzCLYz39tkMZts7rfBU4=. We first decode the base64 string into a byte array and then run the program again but with  rijndaelManaged.CreateEncryptor() changed to rijndaelManaged.CreateDecryptor().

I wrote a small C# program that accomplishes what we want to do:

We run the above program and get our flag!

Flag:  HV15-uQEJ-4HPX-Qcau-Xvt7-NAlP

 
No Comments

Posted in Hackvent 2015

 

HACKvent 2015: Day 12

12 Dec 2015
CTF: Hackvent 2015
Link to challenge: http://hackvent.hacking-lab.com
Date Completed: 12 December 2015

Challenge

The following C code is also provided:

 

Solution

Clearly the issue here is that this program is very inefficient.
So what does the program do? First it sets the unsigned 64 bit integer variables  val and i  to 0. Then 0xC0DE42 iterations occur and the val is recomputed each calculation. The previous val  and i  values are used to recompute the new val  value.

After all this, it appears as if the nugget we need is printed out! The 4 missing blocks in the nugget are based on 4 groups of 16 bits which come from the final val value.
So we begin to optimize the code!

 

foo and bar

We start with the foo and bar  functions which are very similar to each other.
It turns out that they simplify to:

So we have just optimised these two functions slightly. The next step is go through the code and replace all calls to foo  and bar  with simply increments or decrements. I’m not going to show the changes I made to each call as that would make this post too long but you get the idea.

Optimized functions:

 

baz

baz  should look like this at this stage:

It is clear from the code that baz  can be optimised. First the variable r  is set to zero and then a 1 is added to r , a times. Then 1 is added to rb times.
This is simply the same as adding a  to b  and storing the result in r .

Optimized function:

 

spam

Spam should look like this at this stage:

This function is simply setting r  to a and then taking away 1 from rb times before returning the result in r .
This is the same as returning a - b .

Optimized function:

 

eggs

eggs  should look like this at this stage:

Well all that is happening here is r  is increasing by b, a times. That means we are adding a number of b’s to r .
This is the same as returning a * b .

Optimized function:

 

merry

merry  should look like this at this stage:

So at this stage, we are taking away b  from a  while a  is still bigger than b . The value of  i is then returned which is the number of times we took away b  from a .
This is clearly a simple division operation: a / b

Optimized function:

 

xmas

xmas  should look like this at this stage:

This one is a little more tough. a  is divided by b  then multiplied by b  and this result is subtracted from a . You may be tempted to think that this returns 0 all the time but it does not.
This is because the division operation that occurs is integer division and multiplying that result by b  may not result in the original a  being restored.
A small example: 10/3 = 3.33 but is stored as 3 in an integer. However, 3*3 = 9 and not 10!

In this case, a modulo operation is happening: a % b

Optimized function:

 

hackvent

hackvent should look like this at this stage:

This is a fun one. Notice how r is set to 1 initially, that is important. r is then multiplied by ba number of times.
This is the same as calculating b to the power of a.
However, we cannot just use the pow function defined in <math.h>.
We are dealing with uint64_t data types and must thus get a power function that can handle these larger numbers.
I decide to find one online and use it.

Optimized function ( ipow  and hackvent):

 

Putting it all together

At this stage you can do two things.
You can either run your program as is to find the answer or you can inline your function or convert the function calls in main so you save making all those function frames.
In this case it doesn’t really matter but this is what the calculation of val in main should look like with no function calls:

Then you run your program and within a few seconds you get the flag!

Flag:  HV15-mHPC-067e-751e-f50e-17e3

Note: You can download my final solution C file here:
Download hv15-d12-solution.c

 
No Comments

Posted in Hackvent 2015