A Good Engineer Never Blames the Domain

#devjournal #motivation #softwareengineering

My seniors from Point Blank always told us one thing:

“A good engineer never blames the domain.”

This thought stayed with us while selecting problem statements for the Smart India Hackathon (SIH), and our SIH journey proved this statement.

Selection of Problem Statement

In our team, there were two DevOps engineers, two ML engineers, one frontend developer, and me (an Android developer). From the very beginning, our team Point Blank decided on one thing: we would not limit ourselves to any single domain.

We were open to all problem statements and, more importantly, we wanted to take up the toughest PS.

After going through all the problem statements, we shortlisted two:

QuMail – a cybersecurity-based problem statement focused on building a quantum-secure email system.
The second problem statement revolved around obfuscation of C/C++ code using LLVM, combining compiler design and cybersecurity. This was the problem statement for which we were selected for the SIH finals.

None of us came from a compiler background, but we still chose to take up this challenge and started working on it.

Challenges and How We Tackled Them

We began by researching the problem statement, and the very first question we asked ourselves was why this solution was needed. To understand this better, we spoke to reverse engineers, who helped us realize that reverse engineering plays a crucial role in identifying loopholes, vulnerabilities, and hidden bugs in software.

This led us to our next big question:

What exactly is reverse engineering?

Honestly, it took us a lot of time to understand how reverse engineers work. We spoke to multiple reverse engineers and concluded that their primary focus is on the Intermediate Representation (IR) of a program. While analyzing IR, they mainly look for:

Strings
Symbols
Control Flow Graphs

This gave us a clear direction that these were the areas we needed to work on and then our seniors from Point Blank specially Ashutosh bhaiya was there to help us understand Compilers

Turning Research into Implementation

We started by studying OLLVM (Obfuscator-LLVM). However, OLLVM is quite old and not compatible with LLVM 22, which we wanted to use for our project. To make things more challenging, LLVM 22 had not even been officially released at that time.

So instead of backing out, we studied the implementation of OLLVM in depth and reimplemented it for LLVM 22, making it compatible.

Even after this, we faced several challenges:

String and symbol obfuscation
Making our customized LLVM version compatible with C++ exception-handling code
Many other low-level implementation issues

We divided the work properly among all six team members, and everyone gave their best. For an entire week, we worked every day from 5 in the evening to 7 in the morning.

Below is the architectural diagram we had prepared before going for the SIH finals.

SIH Finals at IIT Jammu

Our real test began at IIT Jammu. During the first mentoring round, the mentors liked our idea, but then came a critical moment.

A mentor asked us:

“Are you doing obfuscation for both C and exe?”

Due to a misunderstanding, one of our teammates answered yes, and at that moment they started asking questions about binary-to-binary obfuscation. Something we knew was practically not possible, as we had already discussed the same with our seniors.

At first, it felt like a mistake — but that mistake turned into a blessing in disguise.

Earlier, me and Akash bhaiya had discussed an idea: what if we use some reverse engineering tool to get the Intermediate Representation and then apply our OLLVM layers? We pitched the same idea to the mentors.

After that mentoring round, we had a clear picture of what we had to do in the remaining time. We divided the work properly — a few of us started adding new features suggested by the mentors, while others worked on the binary-to-binary obfuscation pipeline.

During the final judging round, we delivered everything they asked for. The judges also asked technical questions, similar to interview questions, which we expected — especially since NTRO also offered internships after SIH.

Because we had strong clarity about what we were building, we were able to answer every single question confidently.

The Moment That Made Everything Worth It

There were four problem statements at our SIH center. Ours was announced last.

Many people had told us earlier that our team looked too confident. But in reality, we were nervous. And then the moment arrived — they announced us as winners.

It was an unreal feeling.

We were happy and emotional at the same time. Months of hard work and learning finally paid off, and we proved one thing: