Skip to content
SIH Buddyby Ganeev Singh
Dev

πŸ”₯ Roast My Pick Β· SIH26148

Creation of scripts/functions with new programming language to commence Computer & Network forensic analysis without triggering security solutions

National Technical Research Organisation (NTRO)

Incinerated99/100

Ah. This one. Take a breath β€” you have picked the statement that bites, and it bites in four specific places.

High risk high reward. As written this asks for an antivirus-evasion and covert-C2 toolkit, which a student team should not build or demonstrate β€” if you engage the organisation at all, reframe it toward authorised, allow-listed forensic collection rather than the evasion tradecraft the description details, and confirm scope with them directly. Roughly 70–160 teams are expected to go here.

The receipts

Every red flag on this statement, in full. These are the four places it bites.

  1. Exhibit A

    The described capability β€” polymorphic evasion, BYOVD kernel access, domain-fronted C2 β€” is offensive malware tradecraft, and building it produces a weaponisable toolkit regardless of the stated defensive intent

  2. It gets worse

    Demonstrating it means showing security products being defeated, which is the harmful outcome and cannot be responsibly presented

  3. Still reading?

    Anti-forensic and evasion tooling is exactly the kind of dual-use capability that should not be developed as a student project without a sanctioned framework

  4. And the finisher

    Even setting ethics aside, the technical scope is nation-state-grade and unreachable in a hackathon

The damage report

Every score this statement earned, and what each one actually costs you.

  • Feasibility

    1/5

    You have picked a fight with physics, procurement, or both. One of them always wins.

    Beyond the ethical problem, each named element β€” a custom polymorphic language frontend, BYOVD kernel access, in-memory injection, domain-fronted C2 β€” is individually a serious specialist undertaking, and integrating them is a nation-state-grade offensive tooling effort far outside a hackathon's reach.

  • Innovation scope

    2/5

    Nothing here is new. Your only edge is execution β€” and execution is also everyone else's only edge.

    The techniques named are established offensive tradecraft rather than open ground, so the work is reproducing known evasion methods, and the framing leaves little legitimate room to be creative in.

  • Clarity

    3/5

    Clear enough to start, vague enough to drift. Write the scope down and stop reinterpreting it weekly.

    The techniques are named specifically, but the stated forensic purpose sits incoherently on top of a description of malware evasion tradecraft, so what a legitimate deliverable would even look like is genuinely unclear.

  • Acceptance potential

    1/5

    The numbers do not like you. Bring something the numbers cannot see.

    This should be avoided β€” the described capability is an antivirus-evasion and covert-C2 malware toolkit whatever the forensic framing, it is not something a student team should build or demonstrate, and the technical scope is nation-state-grade regardless.

  • Effort

    Massive

    A semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.

    A custom compiler frontend, polymorphic engine, kernel-level driver exploitation and covert channel infrastructure is an enormous undertaking quite apart from whether it should be built.

  • Demo-ability

    Hard

    Near impossible to show working in five minutes, which is roughly five minutes more than you get.

    Demonstrating success means demonstrating evasion of security products and covert control, which is both the harmful outcome and something that cannot be shown responsibly.

  • Data

    None supplied

    No dataset comes with this one, so every accuracy figure you quote is a number about labels you invented.

    Nothing is provided with the statement. You are sourcing, cleaning and labelling it yourself, and that work is invisible in the demo but very visible in the questions.

The demo they will have already seen

Somewhere around 70–160 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly β€” you have built predictably, which costs exactly the same and hurts more.

What survives

The ground worth standing on when the questions start.

  • The legitimate need behind it β€” forensic tools being blocked by security software on systems an investigator is authorised to examine β€” is a real problem worth solving in a sanctioned, allow-listed way
  • The forensic-analysis and evidence-gathering portion, done openly and with proper authorisation, is a legitimate area to work in
  • The domain is one NTRO genuinely cares about, so a responsibly reframed submission could still resonate

None of that means do not pick it. It means do not walk into that room having heard any of this for the first time from a judge.

The framing is a joke. The findings are not β€” they are the same analysis on the statement page, and every line above is attached to a score or a fact in the record. It is one opinion with its reasoning attached, so argue with it before you trust it.