# US 12,007,883 B2 · Automated method and system for finding vulnerabilities in a program using fuzzing

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 12,007,883 B2
- Document ID: US12007883B2
- Status: Granted
- Kind: B2
- Application number: 18/058,662
- Filed: 2022-11-23
- Published: 2023-07-06
- Granted: 2024-06-11
- Earliest claimed: 2022-01-03
- Assignees: Tata Consultancy Services Limited
- Applicants: Tata Consultancy Services Limited
- Inventors: Harshita Vani Nallagonda; Siddhasagar Pani; Vigneswaran Ramachandran; Raveendra Kumar Medicherla; Rajan Mindigal Alasingara Bhattachar
- Web page: https://patentgrep.com/patent/US12007883B2

## CPC

- G06F 11/3692: {for test results analysis}
- G06F 21/577: {Assessing vulnerabilities and evaluating computer system security}
- G06F 11/3688: {for test execution, e.g. scheduling of test suites}
- G06F 11/3696: {Methods or tools to render software testable}
- G06F 2221/033: Test or assess software
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)

## Abstract

A method and system for finding vulnerabilities in a program using fuzzing have been provided. The disclosure provides a vulnerability detection framework using a language agnostic single fuzzer that can fuzz smart contracts written in different programming languages. The idea here is that a smart contract written in a high-level language is converted/compiled into an LLVM intermediate representation (LLVM IR) code and then perform the fuzzing on this LLVM IR code instead of fuzzing smart contract source code directly. The process of generating fuzz driver, report driver is automated by handling the standardization issue by carefully dividing the smart contracts into categories. The present disclosure is proposing processes of automation of fuzz or report driver generation. Further the language agnostic feature (done with intermediate representation) is also achieved. Further profiling is achieved which processes fuzzer output and generates meaningful data points.

## Claims

### Claim 1

A processor implemented method for finding vulnerabilities in a program using fuzzing, the method comprising:
receiving a program under test (PUT) and PUT metadata as input, via an input/output interface wherein the PUT is written in a programming language;
receiving, via the input/output interface, one or more program fuzzers for testing;
generating, via one or more hardware processors, a first modified program using a fuzz and report driver generator, wherein the first modified program comprises PUT along with a signal handling code and a fuzz driver;
generating, via the one or more hardware processors, a second modified program using the fuzz and report driver generator, wherein the second modified program comprises PUT along with a corpus triaging code and the report driver;
generating, via the one or more hardware processors, an intermediate representation (IR) using the first modified program using a LLVM intermediate representation (LLVM IR) generator, wherein the LLVM IR utilizes a language specific LLVM frontend;
providing, via the one or more hardware processors, the intermediate representation (IR) as an input to the program fuzzer to generate corpus and crashes; and
providing, via the one or more hardware processors, the generated corpus and crashes and the second modified program as input to a profiler to generate a plurality of vulnerability parameters indicative of the vulnerability of the program under test and coverage over time, wherein the plurality of vulnerability parameters comprises stack trace, unique crashes, and a first identification time for each crash.

### Claim 2 (depends on 1)

The method of claim 1, wherein generating the first modified program further comprises:
detecting a plurality of fuzz-able application programmable interfaces (APIs) by traversing the PUT, wherein the detected the plurality of fuzz-able APIs takes input from end-users;
receiving the API details for each of the detected plurality of fuzz-able APIs
checking if metadata is available for each of the detected plurality of fuzz-able APIs;
receiving metadata by a user, if the metadata is not available; and
providing metadata and API details to remaining components of the fuzz driver generator to generate the first modified program.

### Claim 3 (depends on 1)

The method of claim 1, wherein generating the second modified program further comprises:
detecting a plurality of fuzz-able APIs by traversing the PUT, wherein the detected the plurality of fuzz-able APIs takes input from end-users;
receiving the API details for each of the detected plurality of fuzz-able APIs;
checking if metadata is available for each of the detected plurality of fuzz-able APIs;
receiving metadata by the user, if the metadata is not available; and
providing metadata and API details to remaining components of the report driver generator to generate the second modified program.

### Claim 4 (depends on 1)

The method of claim 1, wherein the PUT metadata comprises a blockchain platform name, a plurality of API details.

### Claim 5 (depends on 1)

The method of claim 1 further comprises a metadata need identifier configured to identify additional details required to fuzz the APIs.

### Claim 6 (depends on 1)

The method of claim 1, wherein the corpus comprises a set of inputs generated by the program fuzzer to cover the PUT and the crashes comprises a set of inputs that cause PUT to crash.

### Claim 7 (depends on 1)

The method of claim 1, wherein the corpus triaging code is responsible for executing the test driver to reproduce the crash and coverage of PUT from the corpus and crashers generated by the program fuzzer.

### Claim 8

A system for finding vulnerabilities in a program using fuzzing, the system comprises:
an input/output interface configured to:
receive a program under test (PUT) and PUT metadata as input, wherein the PUT is written in a programming language, and
receive one or more program fuzzers for testing;
one or more hardware processors; and
a memory in communication with the one or more hardware processors, wherein the one or more first hardware processors are configured to execute programmed instructions stored in the one or more first memories, to:
generate a first modified program using a fuzz and report driver generator, wherein the first modified program comprises PUT along with a signal handling code and a fuzz driver;
generate a second modified program using the fuzz and report driver generator, wherein the second modified program comprises PUT along with a corpus triaging code and the report driver;
generate an intermediate representation (IR) using the first modified program using a LLVM intermediate representation (LLVM IR) generator, wherein the LLVM IR utilizes a language specific LLVM frontend;
provide the intermediate representation (IR) as an input to the program fuzzer to generate corpus and crashes; and
provide the generated corpus and crashes and the second modified program as input to a profiler to generate a plurality of vulnerability parameters indicative of the vulnerability of the program under test and coverage over time, wherein the plurality of vulnerability parameters comprises stack trace, unique crashes, and a first identification time for each crash.

### Claim 9 (depends on 8)

The system of claim 8, wherein the generating the first modified program further comprises:
detecting a plurality of fuzz-able APIs by traversing the PUT, wherein the detected the plurality of fuzz-able APIs takes input from end-users;
receiving the API details for each of the detected plurality of fuzz-able APIs
checking if metadata is available for each of the detected plurality of fuzz-able APIs;
receiving metadata by a user, if the metadata is not available; and
providing metadata and API details to remaining components of the fuzz driver generator to generate the first modified program.

### Claim 10 (depends on 8)

The system of claim 8, wherein the generating the second modified program further comprises:
detecting a plurality of fuzz-able APIs by traversing the PUT, wherein the detected the plurality of fuzz-able APIs takes input from end-users;
receiving the API details for each of the detected plurality of fuzz-able APIs
checking if metadata is available for each of the detected plurality of fuzz-able APIs;
receiving metadata by a user, if the metadata is not available; and
providing metadata and API details to remaining components of the report driver generator to generate the second modified program.

### Claim 11

One or more non-transitory machine-readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors cause:
receiving a program under test (PUT) and PUT metadata as input, via an input/output interface wherein the PUT is written in a programming language;
receiving, via the input/output interface, one or more program fuzzers for testing;
generating, a first modified program using a fuzz and report driver generator, wherein the first modified program comprises PUT along with a signal handling code and a fuzz driver;
generating, via the one or more hardware processors, a second modified program using the fuzz and report driver generator, wherein the second modified program comprises PUT along with a corpus triaging code and the report driver;
generating, via the one or more hardware processors, an intermediate representation (IR) using the first modified program using a LLVM intermediate representation (LLVM IR) generator, wherein the LLVM IR utilizes a language specific LLVM frontend;
providing, via the one or more hardware processors, the intermediate representation (IR) as an input to the program fuzzer to generate corpus and crashes; and
providing, via the one or more hardware processors, the generated corpus and crashes and the second modified program as input to a profiler to generate a plurality of vulnerability parameters indicative of the vulnerability of the program under test and coverage over time, wherein the plurality of vulnerability parameters comprises stack trace, unique crashes, and a first identification time for each crash.
