DEC{}DE 2019: Gear UP Experience

We again attended this year's DEC{}DE event sponsored by Trend Micro. This is my third year attending the event (2018, 2017). The talks were really interesting especially the Keynote by Jay Yaneza.  I also liked the talk given by Jon Oliver about the role of Machine Learning in Cybersecurity where he emphasized that ML must be layered to existing security solutions. The hands-on session was on Powershell for the Blue Team.

(Photo from Trend Micro)

Read More

Video: Basic Malware Analysis Workflow

The setup is using a Whonix Gateway VM and a Windows XP VM running in VirtualBox. Our objective is to capture the network traffic generated by malware. The malware is run on the Windows XP VM configured to use Whonix as the gateway.

Read More

Introduction to debugging C programs using GDB

Instead of just reading the code, a debugger such as GDB, can be used to find errors in C programs. GDB is available in linux distributions.

Example code, prod.c :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#include <stdio.h> #include <stdlib.h> int mul(int x, int y){ int prod; int i; prod=0; for (i=0;i<y;i++){ prod=prod+x; } return prod; } int main(){ int a=4; int b=3; printf("The product of %d and %d is %d\n",a,b,mul(a,b)); return 0; }

The following are the typical activities when debugging C programs:

1.  Create the executable with debug information

$ gcc -g -o prod.exe prod.c

For assembly language programs:

$ nasm -g -F dwarf -felf64 prod.asm
$ ld -o prod.exe prod.o

2.  Load the program in GDB

$ gdb prod.exe

3. View the source code listing

(gdb) list
 
4. Set a breakpoint

(gdb) b * main

5. Execute until breakpoint

(gdb) r

6. Execute next line

(gdb) n

7. View current line being executed

(gdb) frame

8. Step into a function

(gdb) s

9. View local variables

(gdb) info locals

10. Print variables

(gdb) print a

11. Set new values for variables

(gdb) set variable a=5

12. Continue execution until next breakpoint

(gdb) c

13. Quit

(gdb) quit

Read More

Notes from "It's not how good you are, it's how good you want to be"

• All creative people need something to rebel against, its what gives their lives excitement.
• There is no instant solution, the only way to learn is through experience and mistakes.
• Aim beyond what you are capable of.
• People who are conventionally clever get jobs on their qualifications (past), not on their desire to succeed, (the future).
• Do not seek praise. Seek criticism.
• If you accept responsibility, you are in a position to do something about it.
• If you give away everything you have (ideas), you are left with nothing. This forces you to look, to be aware, to replenish.
• Don't look for the next opportunity. The one you have in hand is the opportunity.
• Accentuate the positive. Eliminate the negative.
• Do not put your cleverness in front of the communication.
• Don't promise what you can't deliver.
• Give your client what he wants and he may well give you what you want.
• Don't take no for an answer. Work out a new approach.
• When it can't be done, do it. If you don't do it, it doesn't exist.
• If you can't solve a problem, its because you're playing by the rules.
• The pesron who makes mistakes is unlikely to make anything.
• It is wrong to be right, because people who are right are rooted in the past, rigid-minded, dull and smug.
• It is right to be wrong. Being wrong isn't in the future, or in the past. 
• Don't be afraid of silly ideas.
• Play your cards right.
• It's not what you know, it's who you know.
• Don't give a speech. Put on a show.
• Getting fired can be a positive career move.
• Rough layouts sell the idea better than polished ones.
• If you get stuck, draw with a different pen.
• Don't be afraid to work with the best.
• Do not try to win awards.

Read More

How to solve problems

Some notes from the book How to Think Like a Mathematician by Kevin Houston. I found this chapter in the book interesting because I was able to relate to the  process when solving competitive programming problems.

Definitions

• Exercise - something that can be solved by a routine method
• Problem - something that will require more thought; will require the application of routine methods learned in exercises

"The best way to learn how to solve problems is to solve problems."

Sample Problems

1. How many zeroes are at the end of 100! (100 factorial)
2. Suppose that X and Y are two infinite sets. Find a formula that relates |X|, |Y|, | X intersection Y| and |X union Y|.
3. Show that the equation x^2 + y^2 = z^n has positive integer solutions for every n = 1,2 ,3, ...

Polya's four-step plan

Understanding the problem

1. Understand all the words and symbols in the problem - Know the meaning of the symbols as well as the important definitions and theorems
2. Guess - use your intuition - Make an educated guess
3. What do you know about the hypothesis and conclusion? - Write down what you know about the hypothesis and conclusion
4. Work backwards and forwards - You can start with the conclusion and think what it would imply.
5. Work with initial and special cases - Some problems have an index (n in P3). Solve for the initial cases to get a 'feel'.
6. Work with a concrete case - For abstract problems, look at a concrete case. Create instantiations of the variables. (P2)
7. Draw a picture - Venn diagrams (P2)
8. Think about a similar problem - Recall problems you've solved before that may be related to the problem you are solving.
9. Find an equivalent problem - Reformulate a problem, say to show that two functions are equal, they can be represented as a new function with difference of zero.
10. Solve an easier problem - In P1, solve 10! first to get a feel.
11. Rewrite in symbols or word -

Devising a plan

1. Break the problem into pieces -
2. Find the right level - there are many ways to approach a problem so select the right one
3. Give things names - "Let X be ..."
4. Systematically choose a method - A proving problem can be solved solve using different approaches.

Executing a plan

1. Check each step - don't use intuition

Looking back

1. Check the answer - Test.
2. Find another solution
3. Reflect - Think about what solved the problem.

Read More

Internship at KAIST

This Midyear (June 24-August 16, 2019), I am a research intern at the Computer Architecture Laboratory of the School of Computing in KAIST under the supervision of Prof. Youngjin Kwon.  KAIST ranks high in the areas of Systems that I am really interested so this internship is a very good opportunity for me. My teammate for the internship project is Jongyul Kim who is a PhD student in the lab. We are working on improving the performance of distributed storage systems using RDMA, programmable NICs, and NVM.

Read More