What to turn in
Due: Thursday, September 24, 2026, 11:59 PM Eastern Time
Submit one PDF to D2L → CSC 472 → Assignments → Lab 1.
Your report should make it possible for a reader to understand what you tested, what you observed, and why the evidence supports your answer. A collection of screenshots without explanations is incomplete.
Write the report in English. Use your own session in WolfCTF Lab 1. There is no need to install Linux or GDB on your personal computer.
File and page format
| Item | Required format |
|---|---|
| Submission | One readable, non-password-protected PDF: Lastname_Firstname_Lab1.pdf. Example: Chen_Si_Lab1.pdf. |
| Length | A separate title page, then approximately 2–4 pages of main content. Put long supporting logs in an appendix. Use enough space for readable evidence; avoid filler. |
| Page setup | US Letter or A4, portrait, approximately 1-inch margins. Use a consistent 11–12 pt body font, 1.15–1.5 line spacing, and page numbers. |
| Headings | Use the section titles below. Make Q1, Q2, Q3, Q4, and Q5 easy to locate. |
| Code and output | Use a monospace font, normally 9–11 pt. Preserve line breaks and hexadecimal addresses. Use typed text or legible screenshots; do not shrink an entire terminal to fit. |
| Figures and tables | Number each figure/table, add a descriptive caption, and refer to it in the paragraph that explains it. |
| Style | Use precise technical language and mostly third-person descriptions. First person is acceptable when it makes your procedure or reflection clearer. |
Write in Word, Google Docs, LibreOffice, or LaTeX, then export/download a PDF. Open the exported PDF itself and check every page before uploading.
Required report sections
1. Title page — one separate page
Include the lab number and title, CSC 472 Software Security, Fall 2026, your full name, student ID, WolfCTF username, instructor (Dr. Si Chen), date performed, and submission date. This is an individual report. Do not put passwords, activation links, or session tokens in the report.
2. Introduction — one short paragraph
Explain the objective in your own words: how the experiment connects a C function call to stack frames and generated x86 instructions, and what GDB lets you observe. State what you intend to investigate. Do not paste the handout introduction.
3. Environment and method — a reproducible setup
State that you used the WolfCTF browser terminal, GDB + GEF, the lab1 source, and a 32-bit build. Include your working directory, exact compile command, gcc --version, gdb --version, GEF startup/version information, the relevant file lab1 output, and Intel disassembly syntax. Confirm that gef help works. Describe where you stopped the program to collect each snapshot.
4. Analysis and results — five labeled answers
Create headings Q1 through Q5. Under each heading use this pattern:
- Answer: State the claim directly.
- Evidence: Show the relevant command, instruction address/offset, register value, or memory dump from your own session. Refer to a figure, table, or code listing.
- Interpretation: Explain how the evidence supports the claim and connects to the C source or calling convention.
“At [instruction address], [instruction] changes [register/memory]. Figure [number] shows [specific observation] after [command or step]. This supports [claim] because [reason].”
Include all requested details from Q1–Q5. A short answer needs enough reasoning to explain the observation; a screenshot does not replace that reasoning.
5. Discussion and conclusion — one or two paragraphs
State what the evidence established about stack-frame setup, arguments/locals, arithmetic, and return values. Discuss one difficulty or unexpected observation and how you checked it. If your output differs from a slide, distinguish address/compiler differences from a conceptual error. Describe unresolved issues honestly instead of inventing successful output.
6. References and assistance
List the handout/slides and any outside references you actually used. For a website, include its title and URL; for class material, give the class and slide/page. If AI helped interpret an instruction, identify the tool and the help received, explain how you verified it with GDB, and cite that verification in the relevant answer. Your submitted analysis and evidence remain your responsibility.
7. Appendix — optional
Use an appendix for a longer GDB transcript or extra output. Keep the evidence necessary to understand each answer in the main report. An appendix is not a substitute for Q1–Q5 explanations.
Screenshots, code, and diagrams
Capture useful evidence
- GEF is required. Include readable
contextcaptures for the caller immediately before the call and the callee after frame setup. Show the register, code, and stack panes. Usegef config context.layout 'regs code stack'to select them. Explain the relevant observations beside each capture. - Take screenshots from your own WolfCTF session. Show the relevant command and enough output to establish the result. A clear terminal crop is fine.
- Capture at a readable zoom. On Windows, use the screen-snipping tool; on macOS, use the screenshot tool. Do not submit phone photos of a monitor.
- Crop away unrelated browser tabs and private information. Do not alter addresses, values, or results. Arrows and highlights are welcome if the underlying output remains visible.
- Use captions that state the program point, not “Screenshot 1.” For example: “Figure 2. Stack dump immediately before the function call; the current instruction and ESP/EBP are shown.”
- For pasted output, preserve the command and original formatting. Explain only the relevant lines in the surrounding text; do not fill pages with unannotated output.
Draw the caller and callee frames
Include one figure with two panels, or two clearly labeled figures: main immediately before the call, and multiply_by_two after its frame is established. A neat hand drawing photographed/scanned clearly or a digital diagram is acceptable.
- Show addresses from the corresponding snapshot, the direction of increasing addresses and stack growth, and the current
ESP/EBP. - Label the caller's local variables and outgoing argument copies. In the callee snapshot, identify its arguments, saved frame pointer, and return address using evidence.
- Show frame-relative offsets where you can justify them. Distinguish saved registers, alignment space, and values whose purpose you have not established.
- Keep runs and program points distinct. Do not combine an address from one run with a register value from another as if they were one snapshot.
Suggested evidence coverage
| Answer | What the reader should be able to inspect |
|---|---|
| Q1 | The actual frame-setup instructions and your explanation of their effects. |
| Q2 | Initialization instructions plus the location and contents of each local. |
| Q3 | The before-call instruction, register values, stack dump, and an address-labeled diagram. |
| Q4 | The arithmetic instructions and an explanation that matches the C expression. |
| Q5 | A completed return to the caller, GDB's return-value output, and the relevant register at that stop. |
You may reuse a relevant figure within your own report by referring to its number; you do not need five nearly identical screenshots. Cite the exact lines/addresses being discussed.
How the report is graded
Lab 1 is worth 5 points. The report follows the four categories in the earlier course report guide. All five technical questions must be addressed.
| Category | Weight / points | What earns credit |
|---|---|---|
| Technical content | 50% · 2.5 points | Correct, adequately explained Q1–Q5 answers, supported by your own evidence. The five questions contribute equally: up to 0.5 technical points each. |
| Organization | 15% · 0.75 points | Required sections, a clear objective and method, easily located answers, and evidence connected to each claim. |
| Presentation | 15% · 0.75 points | Readable, precise writing; consistent formatting; a complete PDF with appropriate references. |
| Layout and visuals | 20% · 1 point | Legible code/screenshots, numbered captions referenced in the text, and clear, correctly labeled stack-frame diagrams. |
Correct one-line answers alone cannot earn full report credit. Attractive formatting cannot replace correct analysis and genuine evidence.
Submit the PDF to D2L
Deadline: Thursday, September 24, 2026, 11:59 PM Eastern Time. Plan to upload early enough to correct a file or connection problem.
- Export and check. Save your final report as
Lastname_Firstname_Lab1.pdf. Open that PDF locally and confirm that text, screenshots, diagrams, and all pages render correctly. - Open the right course. Sign in at WCU D2L with your WCU credentials. Select your Fall 2026 CSC 472 course/section.
- Find the assignment. Open Assignments in the course navigation (or its course-menu location) and select the Lab 1 submission folder for Stack and Stack Frame. Check the displayed instructions, allowed file types, and due date.
- Attach the PDF. Choose Add a File, select your computer/device, choose the final PDF, and complete the upload using Add or the equivalent confirmation button. Wait for the upload to finish and verify that the correct filename appears.
- Submit. Click Submit. Merely attaching the file, saving a document, or finishing the WolfCTF lab does not complete the D2L submission.
- Confirm. Look for the successful submission confirmation. Reopen the assignment's submission/history area and verify the filename and recorded time. Download/open the submitted PDF if available to make sure it is the correct, readable version.
- Keep a receipt. Save a screenshot of the confirmation/history and retain your PDF. A confirmation email may depend on D2L settings; the on-screen submission record is the check to rely on.
Submit the PDF file itself, not a Google Docs/OneDrive sharing link, Word draft, terminal log alone, or a set of separate screenshots. Include any additional files only if the D2L assignment instructions request them.
If you need to replace a file: use another submission only if the folder permits it, then verify the new record. Do not assume you can delete or overwrite a submission.
If the folder is missing, closed, rejects PDFs, or displays a different due date: contact Dr. Chen at schen@wcupa.edu before the deadline with your course/section and a screenshot of the problem. An email attachment does not replace D2L submission unless the instructor directs you to use it. Follow the syllabus for late work.
Final checklist
- Correct filename and a readable PDF with a separate title page.
- Introduction and enough setup information to reproduce the experiment, including GDB + GEF.
- Readable GEF context captures at both required program points.
- All five questions answered with my own evidence and interpretation.
- Numbered figures/tables and readable code or terminal output.
- Caller/callee diagrams have actual addresses, offsets, registers, and snapshot labels.
- Conclusion discusses results and any difficulty or discrepancy.
- Sources and assistance are acknowledged; no passwords or tokens appear.
- The PDF was opened after export and checked for missing/cropped content.
- I clicked Submit in D2L and checked the recorded filename and submission time.