Piper Wright's Notebook

Spring 2026

Week 15

We have the presentation on Thursday.

I met with Carter and Aly Aadil on Wednesday to discuss the presentation. I'm going to be working on the password checker part, Carter will do AES and Aly Aadil will work on the goals slide.

I've been working on gathering stats all week and running things overnight, which dump into csv files to get more stats. I've been working with both a volatile password checker attack in one file, and one that is separated into a password checker .rs file and an attacker .rs file. You can see that one here but I didn't run a lot of stats on it because, aside from just doing a lot of runs, I was also working on the number of iterations needed for do_per_char_work (more on that later) for the amplification and the number of samples (the number of times the attacker measures how long check_password takes for a single candidate character before computing its score) and to get these stats it made more sense to do it in one single file because the point of having two files is to have a blackbox, but the things I am changing are in the actual password checker.

I added the stats files from an overnight run of the separate file volatile password checker in this commit.

One of the things I measured was number of iterations for do_per_char_work. This is a function that runs every time a character matches, there is a loop of chained multiply-add operations on that character’s byte value to amplify the timing difference. I ran it with 20 runs and 101 samples, and changed the number of do_per_char_work iterations to be 50000, 10000, 1000, 500, 50, 20, and 1. The results showed that 100 iterations is the minimum viable threshold to get mostly correct results. 10000 iterations is needed for a 100% success rate.

I added the csv stats files for do_per_char_work in this commit.

I added the visualization images (using python visualisation script that uses the CSV output) for do_per_char_work in this commit. Here are also some of the images. This one shows the number of iterations for do_per_char_work vs the per character success rate, which really shows how much we need the amplification to accurately guess the password:

The average gap is the average difference in nanoseconds between the timing score of the character the attacker picked as best and the timing score of the second best character. A bigger gap means the attacker is more confident (the correct chracter stands out more clearly from the noise) and the gap being closer to 0 would mean it's more of a random guess. Here is a graph showing this:

The rest of the images can be found here.

I also tried removing do_per_char_work entirely and the attack failed completely so it's definitely necessary to have some kind of amplification.

I have also set up an overnight run with varying samples, trying samples - 1, 10, 20, 50, 100, 200 and fixed number of iterations = 10000 and runs = 50 which output to sample_sweep_stats.csv and sample_sweep_position_stats.csv to make more visualizations for the presentation in the morning when it finishes running.

I added the sample stats in this commit.

Here are the results of the overnight run:

I added the pictures for the graphs after running a visualizer script here.

Here is the most relevant one, showing the per character accuracy for each number of samples:

and here is the overal success rate (fully guessed password) for each number of samples:

Carter, Aly Aadil and I met one more time before the presentation on Thursday. We finalized our slides and I added my audio to the slides as I will be in a different class during the presentation.

Week 14 - April 13 - April 17

I met with Carter, Aly Aadil and Estelle on Wednesday. We talked about getting some more stats for the volatile attack and turning it into a two-file attack. We also talked about how the attack is very dependent on the amount of noise, regardless of number of samples.

I did not have a lot of time to work on it this week. I'll be showing most of my stats results next week and doing some extra runs and visualizations next week.

Week 13 - April 6 - April 10

We did not meet this week. I've been working on getting stats for my volatile password timing attack. I changed the code so that it will run the attack 20 times each time the file is run, and output the stats to a .csv file. I ran this several times (with the 20 times each) but with different sample sizes. The number of samples is the number of timing measurements that the program takes for one candidate guess. The more samples, the longer it will take to run. I ran this with 201, 101, 50, 10, and 1 samples. I noticed that with all numbers of samples, it is possible for the program to guess the password correctly, but that with lower numbers of samples, it becomes heavily dependent on the amount of noise from my computer. For example, when I ran it with number of samples = 1, at first it was guessing the password correctly:

but when I googled something on Chrome, it started failing badly:

Having a greater sample size makes the program much more tolerant to noise. If I am doing something on my computer while running the program with a greater sample size, it is much more likely to be closer to guessing the password or to actually correctly guess the password than if I were doing it with a smaller sample size.

I've added the main data file to the repo in this commit. The data is in this format: samples,run,position,chosen_char,correct_char,chosen_score_ns,second_char,second_score_ns,gap_ns,was_correct,partial_guess.

• samples - number of timing measurements taken for one candidate guess before computing its score
• run - which run you're on (there's 20 total)
• chosen_char - character that was picked as best guess for that position in that run
• correct_char - the actual correct character at that position
• chosen_score_ns - the timing score for the chosen character in ns (the trimmed one)
• second_char - character with second highest timing score
• second_score_ns - timing score for second highest
• gap_ns - difference between highest timing and second highest. bigger gap is better (means you are more sure)
• was_correct - boolean val for if the chosen character is correct
• partial_guess - currently built guess password

Here are the results for the different runs for each number of samples:

The results are not perfect (the percentage correct does not go up in accordance with sample size) because of varying runtime noise from other applications on my computer. But in general, the more samples, the greater the accuracy. I may run them again later and try to do it without runtime noise, however it is difficult to have no noise because with more samples it takes longer and it's more difficult to prevent noise for a long time. Here is the file that includes runtimes.

Here is a graph plotting the full password recovery rate (y axis) vs number of samples (x axis):

And here is a graph plotting average total runtime per run (y axis) vs number of samples (x axis):

Week 12 - March 30 - April 3

Carter, Aly Aadil and I met on Monday. We are planning on moving from password checker to AES. We will be writing an attack on Aly Aadil's vulnerable AES function. We are also planning on asking for a Chipwhisperer to do more side channel analysis.

After the Thursday class, Carter sent some notes, including to simulate chipwhisperer tutorials using simulated data, and also to get some statistics from the password timing attacks.

I'm going to try different number of samples for the volatile password checker attack. I'm going to make a graph of samples vs success rate, and samples vs average attack time.

I've started working on getting some statistics for the volatile password checker attack (mostly running the attack many times using different numbers of samples). Next week I'll finish up and show the statistics.

Week 11 - Spring Break

Week 10 March 16 - 20

I worked on my password checker with volatile. I started with having number of iterations in this loop

in the vulnerable function be 500, but that wasn't high enough because this was the result: so even though I am not using sleep() I've still had to artificially increase the time difference. I increased the number of iterations to 50,000. I got this result which is closer:

So I increased samples, which is the number of times I measure the same guess. I increased it to 101. Somehow this made my guess even worse. I changed sample size to 201 and changed the code so that it throws out the very first values and the last ones. So, I'm now using a trimmed mean. This worked.

Next I can work on changing number of samples and number of iterations so that it's as little as possible. However I also want to stop working on password checkers and work on something else instead.

I added the changes in this commit.

We did not meet this week because of conflicting schedules. We messaged each other with updates instead.

Week 9 March 9 - 13

I met with Estelle, Carter, and Aly Aadil Monday to discuss progress and our next plans. I was extremely busy last week and wasn't able to do much for VIP. Estelle said she had started working on Rust password checker that doesn't use sleep by using blackbox, and we decided I would try to figure out how to do it without using sleep or blackbox.

I've been working on making a Rust password checker without using sleep() and a script that can attack it to recover the password.

The issue with not using sleep() is that the timing gap gets very small. So instead of amplifying the checker I need to amplify the measurement in the attacker. The black box prevents compiler optimizations that could remove the timing differences we are trying to measure. I’m not sure if it’s possible to make and attacking script that can attack a normal password checker that doesn’t use sleep, doesn’t use black box, or doesn’t do anything similar to prevent compiler optimizations, but I’m going to try to make one. If it doesn’t work then I will have to alter the password checker.

I wasn't able to get that working. I'm going to use write_volatile and read_volatile instead. This tells the compiler to do the memory operation but not to optimize straight away. It is different from black box because black box works by pretending a value escapes to an unknown outside caller so the compiler can't optimize based on knowing a value and volatile works by making the actual memory operation mandatory.

Fill rest out later

Week 8 March 2 - 6

I met with Estelle on Wednesday to discuss what to do next. In the presentation, we had decided to work on reverse engineering binaries. However, we also need to work on making a password checker in Rust that doesn't use sleep(), so we thought we would focus on that first.

Week 7 Feb 23 - 27

• make attacking script

I made an attacking script that could crack the password of my vulnerable_check function: I originally did not have a sleep timer but I added it because before, my attack script did not work as you can see here: but after adding the sleep it does, although it takes a long time:

Everything done with python password checker up to this point is in this commit.

I'm also working on making a python script that attacks the rust binary function, but right now it's guessing the password completely wrong: I realized I had a bug with the password length, so I pushed my changes in this commit.

Carter, Estelle, Aly Aadil and I met on Wednesday to work on the slides for the presentation. I'm going to be presenting password checker, Estelle will present AES, Carter will present goals and Aly Aadil will present tasks.

At the presentation, we were told that we need to present our statistics better, such as for the sample size and the sleep time, and to use graphs to present. We need to work on creating a password checker that doesn't need sleep.

Week 6 Feb 16 - 20

I met with Carter and Aly Aadil on Wednesday.

I met with Carter and Estelle on Thursday to discuss what we're going to be doing with aes.

I created new python password checker functions, one that is meant to be vulnerable by returning as soon as it finds a mismatch, and one that shouldn't be because it checks every character even if it finds a mismatch so it's meant to be more constant-time. I made a measurement function that tries out both functions over a very large number of iterations in order to repeat the measurements a lot since a single timing measurement can be noisy and unreliable. I made the password "PASSWORD" and i tried out "PXXXXXXX" where there is a mismatch immediately so in the leaky function it exits immediately and I also tried out "PASSWORX" where it will only stop at the last character. I ran both of these in the leaky and non leaky functions to see the differences. There's also more detailed information made in the comments that can be found in password_checkers.py and measurement.py. Here were the results:

As you can see, the difference in the leaky one is 41 ns and the difference in the less-leaky one is only 1 ns. I'm also going to make a graph visualization tool. I also want to make an attacking script that shows how the vulnerable password checker can be compromised using side channel attack.

Week 5 Feb 9 - Feb 13

I looked into potential project ideas, and I think that we could potentially do a side channel attack with VMs since they share the same CPU. I also found this github which shows some examples of side channel attacks in python, which we could potentially do. I also looked over some of the VM papers and websites, such as Side-channel Attacks and Countermeasures in Cloud Services and Infrastructures and Cross-VM side-channel attacks. The rest are in the google doc from last week.

I met with Carter and Aly Aadil on Wednesday to discuss our progress on making our password checkers and research for project ideas. I showed them my password checker code and we talked about making a visualization for it. We also discussed doing cross-VM side-channel attacks, and we also talked about getting a raspberry pi to do basic side-channel attacks on.

Carter and Aly Aadil said that in class they were told that eventually we will have raspberry pis to work on, to do more things related to password cracking, and to potentially do statistical analysis.

Next, I'll be continuing working on the password cracking for now.

Week 4 Feb 2 - Feb 6

• Work on password checker

I worked on making a password checker in python. I also found some papers/project ideas for side channel attacks. Here is a link to the google doc I created with what I found. We did not meet this week because we met last Friday, we will meet next on Wednesday 2/11.

Week 3 Jan 26 - 30

• Work on kickoff presentation

We met on Sunday, Jan 26 to work on the slides. We also needed to decide on what topics we want to cover this semester. I met with Carter, Estelle, Sam, Aly Aadil, Soyoung, Galadriel, and Favour. We divided up the slides. Favour and Soyoung are working on Physical Unclonable Functions. Galadriel is going to work on disk encryption. Bermet is going to work on fault injection. Estelle, Carter and I decided to work on side channel attacks. We still aren't completely sure what we want to work on this semester so we came up with a basic outline which we won't necessarily be sticking to. For my slide I'm going to be writing about what side channel attacks are and why they're important to learn about in relation to power grids. We will also be meeting on Wednesday night to finalize the slides.

We met on Wednesday at 8 to finalize the slides. I met with Christina, Soyoung, Estelle, Bermet, Sam, and Aly Aadil. We decided to add a skills slide for each subteam with the skills of each person, and decided who will be presenting each slide. I'm going to add my recording to the Side Channel Attacks intro slide since I won't be in class.

I met with Carter, Aly Aadil, and Estelle on Friday for side channel attacks subteam. We decided to individually work on a password checker and to also find papers or project ideas for side channel attacks.

Week 2 Jan 19 - 23

I read through the slide presentation from this week. We need to make a kickoff presentation for the device security team. We made a lettucemeet and decided to meet on Sunday, Jan 26 to work on the slides.

Week 1 Jan 12 - 16

I'm taking VIP online this semester due to a class conflict with reverse malware engineering. I read through the slide presentation from this week. I also filled out the team preference quiz and chose to join the device security team.

Fall 2025

Week 16 dec 1 - 5

• Work on paper

I did the executive summary of the paper, as the networking subteam did not have a large amount to add so Kayden and Alex covered that part.

Week 15 nov 24 - 28

We had Thanksgiving break this week, I didn't do anything.

Week 14 nov 17 - 21

• FINISH database update methods
• work on presentation and demo

Kayden, ALex, Bermet and I met Wednesday to discuss the presentation, and in particular the demo. Since I'm done exposing the database update methods, I'll be showing that. I've tested that all the database update methods can change database values, but I've only added code to enter values in terminal to be updated for analog_output_status_transaction and octet_string_transaction, as seen here:

In the demo I'll also be showing wireshark showing the database update methods working. I'll show this by updating the octet string in the database, and this new string will be shown in a packet in Wireshark. Here is the terminal:

and here, you can see the string I typed in a packet on Wireshark:

Here is the packet, where you can see that it's DNP3:

The unsolicited response is the outstation telling the master that there's data.

Here you can see the string that I typed in terminal above:

And here you can see the set index, 7, that it's being updated at, which is what I wrote in the octet database method:

This demo will show that communication between master and outstation is working. We send updates through the command line through python code. The python code sets values in the database. So it runs through python, and calls methods in C code which calls necessary logic in Rust library.

On a side note, there is an issue when you submit too long of a string for the octet string:

but that's something I am not going to worry about right now because it's not a big deal at the moment.

Here, you can see everything that I've done:

I ran this by doing nix develop and then running:

PYTHON_GIL=0 uv run --python 3.14t --reinstall-package dnp3 run_fork_outstation.py

My changes are in the piperr branch on cps-cosimulation-env. I made this commit for all my database update methods. Kayden made this commit after to add printfs for octet and analog output status transaction. And I have also just made changes so that my terminal text is less messy. The changes in my commits have been in outstation.c, outstation.py, and run_fork_outstation.py.

We had the presentation and I gave my Demo. At the Friday meeting, Alex Kayden and I talked about the paper. We don't have much to add so Kayden and Alex will work on the networking section and I'll do the executive summary when everyone's done with their parts.

Week 13 Nov 10 - Nov 14

• Work on database update methods
• try to move to docker

I'm following Kayden's instructions to move to docker here. I already have Docker installed and Rosetta selected on it. Running this instruction didn't work:

docker run -it --rm --name cps-vip --platform linux/amd64 -v .:/home/vip/cps-cosimulation-env cps-cosimulation-env:latest /bin/bash

and I looked at this but it didn't help. Kayden told me to run this command docker build --platform=linux/amd64 -t cps-cosimulation-env:latest . to build instead. There was still a problem when running ./setup.sh:

which Kayden made the fix for Mac in this commit.

I was able to run the docker image fine after this, but when I ran ./setup.sh it just stayed here for hours:

For now, I'm going to keep working in nix since docker isn't working for me. My nix develop wasn't working, and I realized it was because I wasn't calling dnp3_outstation_transaction(outstation, transaction); in the python wrapper function dnp3_double_bit_binary_transaction. I think that I've finally gotten it to work, as can be seen here:

At the Thursday meeting Kayden tried to help me figure out what was wrong with my ./setup.sh, but we couldn't figure it out and everyone except him had different docker issues. To try to figure out why it was hanging at "Detecting C compiler ABI info", we looked at this page and this one but they weren't helpful. At least my nix works for now so hopefully I can finish up my work before the final presentation.

At the Friday meeting Bermet, Alex, Kayden and I talked about the presentation. Alex and I will work on our code to get it ready in time for the demo.

I've finished testing my database update methods, they all look fine to me. I looked at this while working on them because I got confused, but I actually didn't need to look at that since I'm not implementing it, just making sure we are able to change database from python. For each one, running it changes the database value. I have made it so that analog_output_status_transaction and octet_string_transaction you can change the values by entering one in terminal (this was necessary for octet string transaction because before there was just a constant value in the method and there isn't a way to toggle a string, but for analog output status transaction I added it just because. It will also look better in demo). So, all the methods that I'm done with are binary_input_transaction, double_bit_binary_transaction, binary_output_status_transaction, counter_transaction, frozen_counter_transaction, analog_transaction, analog_output_status_transaction, and octet_string_transaction. I have made it so that we are able to update the database through Python.

Week 12 Nov 3 - Nov 7

• Database update methods

Nov 3 - I tried doing the same thing that I did for dnp3_binary_input_transaction for dnp3_double_bit_binary_transaction to test it, but it didn't work. Here's the error:

At the Thursday meeting Kayden and I tried to get gridlab-d to work on my Mac but when I ran make all-install I got errors:

so we decided to leave it alone.

Bermet, Kayden and I met for the Friday meeting. Kayden is going to move us from Nix to Docker.

I've made some changes on my Python wrappers but then I wasn't able to run run_fork_outstation.py to test so I need to do the switch to Docker and then try again.

Week 11 Oct 27 - 31

• fix cps-cosimulation-env on my device

I'm having problems with nix, where my mac isn't recognizing nix as a command.

I tried this solution but it didn't work https://stackoverflow.com/questions/70733236/nixos-installation-issue-command-not-found-nix.

I fixed it by restoring backup-before-nix files and then doing the multi user installer for nix again. I still can't run my run_fork_outstation.py so I think that I didn't move my files from the old c_api_example properly so I'm going to work on that.

At the Thursday meeting, Kayden and I tried to get a branch of gridlab-d working on my Mac, but it didn't work. At the Friday meeting, Kayden asked if I wanted to work on getting gridlab-d working on Mac, and he showed me this website to do it https://nixcademy.com/posts/nix-on-macos/, or to continue with exposing the database update methods, and I decided to keep working on the database update methods since I've been getting held up by the switch from QEMU.

I need to remember to use this command to work on my database update methods:

PYTHON_GIL=0 uv run --python 3.14t --reinstall-package dnp3 run_fork_outstation.py

Here is what running run_fork_outstation.py currently looks like:

The method names on the left are the methods to use in outstation.py(where methods are created that are run in run_fork_outstation.py to test the python wrapper methods).

For example, here is the binary_input_transaction method in outstation.c in the methods array:

Here it is in outstation.py:

Here in run_fork_outstation.py:

And here is the result:

Week 10 Oct 20 - 24

• Setup cps-cosimulation-env

In the Thursday meeting, I cloned a new cps-cosimulation-env that I'll be working out of from now on. I need to manually move my work from the old version I have. I need to transfer my python wrappers for the database update methods and also run_fork_outstation.py. In class Kayden and I also worked on seeing if the Rust DNP3 library supports Macs. We had to build the library from source using "cargo build"

since it's only unofficially supported on Mac. After running an example to show that this worked, Kayden updated the cps-cosimulation-env repo to include the Rust's library's source code so that we can build it from source and have it work on Macs.

Then later tonight, I was working on trying to setup cps-cosimulation-env. I pulled Kayden's changes. I ran git submodule update --init --recursive and then nix develop, but I was running into a lot of problems and asked Kayden for help. Here was the error:

He said to go into python-dnp3/CMakeLists.txt and change the line checking APPLE and aarch64 to this instead:

I ran nix develop again and then had a new problem:

I removed this line #include <syscall.h> from master.c in python-dnp3. After this it worked:

I tried out Kayden's notebook instructions for testing DNP3 functionality (this here):

and it worked fine. The next steps are to move all of my old work into the cps-cosimulation-env, and then I will carry on with testing my wrapper methods. After class and before Kayden and I started working on debugging the cps-cosimulation-env issues that I just described, I was using the QEMU vm to work on testing the wrapper methods. I had a problem where I wasn't passing in the pointer to my variable and therefore I was getting an error.

I fixed this but then I still wasn't seeing the results I wanted printed when I ran my run_fork_outstation.py. Then when I tried experimenting to solve this, I wasn't able to run ./install_module.sh in the vm properly. I didn't figure it out as I started working on fixing cps-cosimulation-env with Kayden but I'm not going to have to worry about this in the future since we aren't using QEMU anymore.

I also attended the friday meeting.

Week 9 Oct 13 - 17

• Work on python wrappers

I have been very busy with tests and projects this week and will do a lot extra next week to make up for it. I attended the thursday and friday meetings but we didn't go over much.

Week 8 Oct 8 - Oct 10

• Work on midterm presentation
• Work on testing python wrappers

We had the presentation on Thursday. There was not much to change as we have not gotten very far yet.

At the Friday subteam meeting, not much happened, it was very short.

Week 7 Sep 29 - Oct 3

• Work on the paper.

I wrote the explanation for Alex's diagram, which is found under the "Integrating DNP3" section of "Research Sections". Here is his diagram:

And here is what I wrote about it:

Here are the sources that I used when learning about how this master/outstation communication works for my explanation: https://docs.stepfunc.io/dnp3/1.6.0/guide/docs/api/outstation/controls/ https://docs.stepfunc.io/dnp3/1.6.0/guide/docs/api/outstation/database/

Week 6 Sep 22 - 26

• Work on the paper.

Kayden got binary_transaction to work. The problem was that a null pointer was being passed. The next thing I will be working on is checking that my python wrappers for the rest of the database update methods work. In the subteam meeting we talked about the paper. I had previously worked on the networking team's part of previous work, but there wasn't much more to add as we have been working on the same thing for a whiel. My new section will be explaining how the diagram that Alex is making works.

Week 5 Sep 15 - 19

• Work on testing binary_transaction

I found the method to test if my dnp3_binary_input_transaction wrapper method works, but it turns out I was already using it from last semester. I tried to print the result here:

but it's not working and I'm not sure why.

The print methods from the dnp3_binary_input_transaction wrapper method show but not the ones from the binary_transaction method.

Week 4 Sep 8 - 12

• Work on testing binary_transaction

In the main meeting Kayden helped me to get python updated for my files. In class, Kayden and I also discussed what I need to do next, which is finding a method in the dnp3.h file that I can use to access the database (like read values), so that I can check if the python wrapper functions I made last semester are working. We had a very short subteam meeting and did not discuss much.

Week 3 Sep 1 - 5

• Look over my past entries and start working on exposing database update methods

We had the kickoff presentation. I worked on the "Networking Subteam Tasks" slide. I didn't have to change much, as our tasks are basically the same. I removed the task about DNP3 documentation because that's one that we finished last semester. We have added a Security subteam, and that was part of the kickoff presentation. My next task will be continuing with what I was working on last semester, which is exposing the database update methods in outstation.c in c_api_example. First I need to look back over my past entries and look at the code to remember what I was working on and what I need to be doing next.

Week 2 Aug 25 - 29

We had a presentation and then broke into our teams. There was a discussion about dropping the monitoring team and adding a security team. On Friday at 1:30, we had our device modeling meeting. We spoke about the kickoff presentation and divided the slides. I have the "Networking Subteam Tasks" slide. There was also a separate meeting to discuss the new security team but I did not attend that.

Week 1 Aug 18 - 22

We had the intro meeting, with a small lesson about substations.

Week 16: April 21 - 25

• Work on my part of the final paper.

I added to my part of the final paper and added two new sources.

Week 15: April 14 - 18

• Work on my slides of the final presentation

I worked on my slides for the final presentation. In our subteam meeting we discussed the final paper, and I'm going to be editing the same section I did last time, background for networking.

Week 14: April 7 - April 11

• Make binary_input_transaction work in outstation.py and run_fork_outstation.py so that I know how to do the rest.

I added some code to outstation.py and run_fork_outstation.py to include binary_input_transaction.

I tried to run python run_fork_outstation.py after writing code for binary_transaction in outstation.py and run_fork_outstation.py but I got this error.

I fixed this by correcting what I wrote in the methods[] array in outstation.c. The code was able to compile and run when I ran the dnp3 example, but with the command "python run_fork_outstation.py" I ran into some errors. When I looked at simulation.log it wasn't updating the database properly, and somehow I caused a disconnection.

In the picture above you can see that the line I placed in outstation.py printed in the log but the line place after outstation.binary_input_transaction(self._outstation) did not print meaning that something is wrong with this method. Kayden and I tried to figure this out in class and we added some print lines to the method in outstation.c to see where the issue was. Here are the print lines added:

and here is the result of that from again running "python run_fork_outstation.py" in the VM:

This would suggest that the problem is in the dnp3_outstation_transaction method since the print line after it did not print, but we don't know why and are very confused.

Week 13: March 31 - April 4

• Make a copy of run_fork.py and alter it.
• Then update outstation.py

During class, Kayden changed binary_transaction and dnp3_binary_input_transaction. He changed binary_transaction to get the binary input directly from the big database instead of the database_points_t struct in outstation.c that was being used as a local database, although I'm not sure if pulling from the big database is working properly yet.

For dnp3_binary_input_transaction before, I had made a database capsule and context capsule and called binary_transaction with these as inputs. Now, we only have the outstation capsule instead. This gets changed with PyCapsule_GetPointer so it can be used in python. Instead of calling binary_transaction in dnp3_binary_input_transaction like I had before, we call dnp3_outstation_transaction.

The next thing that I need to do is to call my binary_transaction method in outstation.py. Also I think I've exposed all the database update methods incorrectly so after I know that binary_transaction works properly, I will need to go back over all the rest.

Week 12: March 24 - 28

• Finish exposing the database update methods in outstation.c in c_api_example
• Write code to test my new code

Our class was a guest lecture about substation systems. I finished with exposing the database update methods, and on the Friday subteam meeting Kayden went over how to test the code with me which is what I'll be working on next week.

Week 11: Spring break

Week 10: March 10 - March 14

• Finish exposing the database update methods in outstation.c in c_api_example

In class, Kayden and I tried to move my outstation.c code to a different directory because I was working out of the wrong one, but somehow it got deleted so I need to retype everything I did.

Week 9: March 3 - March 7

I started working on the exposing the database update methods to the Python code, and I think it may be finished but I am not sure if it works as I still need to test it.

Week 8: Feb 24 - Feb 28

We had the presentation.

Week 7 Feb 17 - Feb 21

• Write my portion of the paper.

This week I worked on the paper, section 3 part C, the previous work section for the networking team. My task for next week is to expose database update methods to the Python code.

Week 6

I worked on our DNP3 documentation google doc. I wrote the section on DNP3 protocol, and I plan to add more with specific examples/screenshots of how the substations communicate.

Week 5

I installed Linux on my Mac and also ran the DNP3 example again. I also tried to run the main cps-cosimulation-env simulation but I had some problems with the make all-install command.

Week 4

At the Thursday meeting, Kaden showed us a demo of his work from last semester. He also tried to get us set up with the dnp3 example, but there was an error with our Macs so it's not working. Since we couldn't get it to work on our computers, he showed it on his computer. We discussed setting up a Virtual Machine so that we can run the example on our Macs.

On the Friday networking subteam meeting, Kaden walked me through how to run the VM. I was also able to run his DNP3 example on my Mac.

Week 3

We had the kickoff presentation. The Friday subteam meeting was cancelled this week since there was not much to discuss. I also read through Kaden's guide this week. I learned about the DNP3 protocol and looked over his work from last semester. I also read about the OSI model and basics of TCP and IP since I was unfamiliar with them.

Week 2

I chose the device modeling subteam in class and we met briefly to decide on a subteam meeting time. During the subteam meeting on Friday, we discussed the kickoff presentation and I joined the networking subteam.

Week 1

I joined the first meeting virtually on January 9th and completed the welcome quiz.