Sunday, December 22, 2019

A review of my CMSC 131 class offering



Last semester I taught, for the first time, the Introduction to Computer Organization and Machine Level Programming course for undergrads. Traditionally this course mainly teaches students x86 (32-bit) assembly language programming in an Ubuntu environment using NASM. I decided to "upgrade" the course by directing the course towards systems programming and introducing x86-64 assembly language. My main reason for the upgrade is to prepare the students for their Operating Systems class which they will take later and which I also teach. In order to achieve this goal, I needed textbooks to guide me which led me to use the following:
CS:APP was created by professors from CMU and is widely used in many top universities. I used the slides provided by the book. But in my lectures, I have several open terminals to demonstrate the actual operation of the codes. ALPU is a good book also with simple exercises at the end of each chapter.

The topics (based on the CS:APP2e contents) I was able to cover in the lecture are the following:
  • A tour of computer systems
  • Representing and manipulating information
  • Machine-level representation of programs
  • Memory hierarchy
  • Linking

In the lab, I was able to cover most of the chapters in ALPU, excluding DDD, Macros, Stack Buffer Overflow, I/O Buffering, Floating Point, and Parallel Processing.

I introduced GDB in the lab to help students debug their programs. I also used GitHub Classroom for distributing boilerplate code and code submission.

In my lectures,  the emphasis is on how the GCC compiler translates C source code into assembly language and how the processor executes the machine code. I always have terminals open to fire up GCC and GDB during lectures.

For future improvement of the offering of this course, I recommend the following:
  • Use same syntax in both the lecture and lab. CS:APP2e uses AT&T syntax while ALPU uses Intel syntax.
  • CS:APP2e is still 32-bit with a little introduction to 64-bit. It may be possible to use the 3rd edition which I believe is purely 64-bit.
  • Most of the programming exercises do not accept input and produce output interactively. A GDB command/script file can be used to provide input and produce output by explicitly stating the variable names, memory addresses, or registers. Checking of programming exercises can be automated using GDB command scripts.
  • Introduce assembly language programming in Windows environments using Microsoft Native Build Tools.
  • Introduce ARM assembly language programming using an emulator or RPi.

I would like to thank Prof. Rizza DC. Mercado and Prof. Kendall Jaen for sharing their teaching materials. It was fun teaching this course and I learned some new topics in depth.

Saturday, December 21, 2019

How to determine research potential

(Last update: 19 January 2024)

As professors, we are often on the lookout for graduate/undergraduate students (or junior faculty) with research potential to join our research groups.  We want to encourage these students to pursue graduate studies in order to further advance the field by becoming researchers or professors in the future.

We base our evaluation initially on their grades from the courses they took. Our belief/claim is that the higher the General Weighted Average (GWA) of a student, the higher the research potential.  

Research potential, as described in Costromina et. al. (2014), is a multidimensional and multilayered system of individual psychological traits (motivational, cognitive, and behavioral characteristics) that act together to allow an individual to conduct research activity efficiently and fruitfully.  These traits are described below:

Motivational

  • Intolerance for ambiguity - capacity to experience positive feelings in new, unstructured, and varied situations
  • Satisfaction in solving problems - capacity to feel gratification from the process of finding ways and means for coping with scientific tasks
  • Intellectual curiosity - the conscious desire to receive information about objects and to enjoy learning
  • Intolerance for novelty - reveals thirst for experimentation, innovations, etc.

Cognitive

  • Flexible thinking - can overcome conventional thinking
  • Critical thinking - capacity to reveal mistakes and inconsistency, to correct errors, justify the validity of hypothesis
  • Logical thinking - ability to use facts and laws to confirm the accuracy of conclusions promptly
  • Quick thinking - ability to understand the situation and to make decisions in a timely manner
  • Original thinking - capacity to propose new, unconventional ideas

Behavioral

  • Self-organization - structuring of a researcher's personal activity to reach objectives
  • Self-control - following research procedures and completing work tasks
  • Adaptability - reduces time necessary to accept the changing conditions of a research task
  • Assertiveness - maintaining stability while working in unstable conditions

Costromina et. al. (2014) conducted a study to compare undergraduates, master's students, and professors along the above dimensions. In their conclusion, they were able to obtain data on the high predictive validity of theoretical abilities in defining students' level of research potential.


"Theoretical thinking abilities are the aggregate of analytical and synthesizing
skills aimed at identifying common features and qualities of objects, as well as abili-
ties aimed at generalization and abstract thinking. These abilities function at a high
level along with a broad vocabulary range, and they reflect one’s ability to think in
the abstract."


At the undergraduate level, intolerance for novelty, self-control, adaptability, assertiveness and critical thinking are the characteristics that should have been developed, according to the study.

It seems, therefore, that the use of GWA as first screener of a student's research potential is valid. In addition however, a student should also be evaluated based on the traits described above.


Reference

Thursday, November 7, 2019

SRG Authorship Guiding Principles

This post aims to address authorship in research papers produced within our research group. I think that authorship guidelines should be discussed early in the research project or graduate study in order to avoid complications later. I've witnessed colleagues and other individuals who abuse authorship by giving 'honorary' authorships, excluding names from the list of authors, and changing authorship order. The work by Solomon, Programmers, Professors, and Parasites: Credit and Co-Authorship in Computer Science, provides a good discussion of this topic. It presents the following principles that I will adopt for our group.


1. Authorship credit should be distributed only to those researchers directly involved with the paper or project in question. Researchers with indirect or minimal involvement may be mentioned in an additional "acknowledgements" section if necessary. All contributors should appear on paper; "ghost writing" is an invalid way even for a busy researcher to produce publications.

- Should you include your adviser and your committee members?
- Should you include project leader, project staff, research assistants?
- Should you include your research group leader?
- Should you include ALL members of your research group?
- Should you include your special someone?

2. All authors should be paired with short descriptions of their contributions to the project. These descriptions need not be on the title page but should apparent for anybody seeking further information about the research presented. This principle extends to the acknowledgements list. In general, any individuals or organizations mentioned by the paper should be identified to avoid "honorary" authorship and make explicit the division of work leading to the final results.

3. The list of authors should be divided by level of contribution. Within each division, authors should be ordered by the amount they contributed to the particular paper in question. Truly equal co-authorship relationships should be marked as such, with none of the authors identified as a "corresponding" author. The lack of a single corresponding author can be addressed by creating a simple email that alias that contacts all the principal authors simultaneously. Those researchers who would be considered "inventors" should be marked as such for the purposes of verifying future patent applications.

4. Upon publication, authors should be required to sign that the work in the paper is at least partially their own and that no other authors should be given credit.

5. Any and all decisions involving authorship should involve the mutual consent of all authors, which should be established via individual contact.

6. Any discovered cases of authorship fraud should be dealt with in much the same way as data fabrication. Once they are caught, authors should be required to explain their incorrect practices in a published statement and rectify any disadvantages suffered by parties not receiving appropriate credit.


References:

[1] Solomon, Justin. (2009). Programmers, Professors, and Parasites: Credit and Co-Authorship in Computer Science. Science and engineering ethics. 15. 467-89. 10.1007/s11948-009-9119-4.

[2] Allison Gaffey. (2015). Determining and negotiating authorship. Retrieved October 6, 2019 from https://www.apa.org/science/about/psa/2015/06/determining-authorship.    



Wednesday, October 30, 2019

Using VBoxManage to run BioLinux, headless


1. Import the appliance

$ vboxmanage import bio-linux-8-latest.ova

2. Check if the VM was imported

$ vboxmanage list vms
$ vboxmanage showvminfo "Bio-Linux-8.0.7" | less

3. Modify the VM to use bridged network connection

$ vboxmanage modifyvm "Bio-Linux-8.0.7" --nic1 bridged --bridgeadapter1 eno1

4.  Start the VM in headless mode

$ vboxmanage startvm "Bio-Linux-8.0.7" --type headless

5. Check if the VM is running

$ vboxmanage list runningvms

6. Get the assigned IP address to the VM

$ vboxmanage guestproperty enumerate {`VBoxManage list runningvms | awk -F"{" '{print $2}'` | grep IP | awk -F"," '{print $2}' | awk '{print $2}'

7. Hard shutdown of the VM

$ vboxmanage controlvm "Bio-Linux-8.0.7" poweroff

8. Use SSH to connect to the VM

Sunday, October 13, 2019

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)


Sunday, October 6, 2019

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.