TinierCheck

TinyCheck is an existing app that helps survivors of abuse find installed spyware. But it has a flaw: it's difficult for individuals to use. TinierCheck is an entirely web-based version of TinyCheck.

Comment

Inspiration

I work as part of a group known as the Clinic to End Tech-Abuse, or CETA, out of Cornell Tech. That clinic employs a combination of policy, legal, and technology volunteers to assist victims/survivors of intimate partner violence (IPV) in securing themselves digitally. This is extremely important as technological abuse becomes increasingly prevalent.

As someone who's always been passionate about cybersecurity, I've been driven by a desire to help people with my skills. So when I heard about this program, I was immediately interested in learning more. Through a combination of my personal experiences, anecdotes from others, and my programming knowledge, I recognized a point of improvement for TinyCheck.

What it does

TinyCheck is a piece of software that is used to scan a victim/survivor's device for spyware. It has a few ingrained requirements, including being non-intrusive and undetectable. This is to protect users whose devices may be actively monitored. However, the current design of TinyCheck requires that a user has access to a copy of the program installed on some device like a Raspberry Pi. While these can easily be located at clinics and shelters, that may not be a viable or feasible option for some people. That's where TinierCheck comes in.

The idea was to come up with a way to implement TinyCheck's functionality without requiring users to go to a physical location or own extra piece of equipment. That meant the ideal would be accessibility over the internet.

How I built it

The first step in building this new implementation was gutting a lot of the original code that was now obsolete and unnecessary. I spent approximately two hours on my first pass through of the code, trying to understand it as deeply as I could. Once I did, I started to remove everything that wasn't necessary - this was particularly in regards to the generation of access points for nearby users, something that wasn't necessary for a remote service.

Once the codebase had been reduced, I set about designing my implementation. The idea was to utilize the ability of most devices to rely on proxy servers for Wi-fi connections. If I could set up an online proxy server for any device to connect to, and link it to a graphical site for obtaining results of scans, the traffic emanating from the device could be analyzed without requiring any apps to be installed. With that, I began writing the code to make it happen.

Challenges I ran into

One of the most significant challenges I ran into was completely comprehending an existing codebase. In past hackathons, I've started from relative scratch with a new idea. That has the added benefit of allowing me to write code, albeit sometimes with teammates, that I can fully understand because I or my teammates wrote it. In this case, I had to not only understand the operation of an entire application in a framework I hadn't used before, but I had a limited amount of time to do it in.

Another challenge that I faced was in capabilities. The original idea for this project was to create a portable version of TinyCheck that could be installed on a second mobile device, thereby eliminating the need for a Raspberry Pi. What I quickly discovered was that mobile devices have locked down themselves down to prevent reading packets from mobile hotspots or devices on the same network. It ultimately required me to shift ideas after getting about four hours into the hackathon.

Accomplishments that I'm proud of

Firstly, I'm proud of the fact that I was able to learn the codebase in such little time. It was a challenge for sure, and it helped to reassure me of my abilities as a programmer - not just in writing code, but in fundamentally understanding it.

I'm also incredibly proud of my work to setup a proxy server. While that sounds relatively easy, it took intense precision and attention to detail to integrate it into TinyCheck with minimal negative impacts on the software's analysis functionality.

What I learned

I definitely learned a lot from this project. For one, I taught myself how to use Vue and Flask for web application development. That was a previously unknown stack that I'm glad to add to my repertoire. I'm also excited to have learned more about spyware indicators of compromise (IOCs), which are essentially just domains and patterns in network traffic that are indicative of potential spyware on a device.

What's next for TinierCheck

There's still a lot of room left for TinierCheck to improve. It needs to be stabilized a bit more, and the work flow can definitely be improved. Additionally, the user interface (while looking decent thanks to being built off of TinyCheck's UI) could use some improvements, especially in being more explicit in directions and perhaps more colorful and engaging.

This is definitely a project and a larger field of software development that I'm interested in continuing, which is why I've already started mapping out milestones and next steps for this project.

Share this project:

Updates