Using NiTools

Opening files

Drop a file anywhere on the NiTools page, choose one with the button, or paste one. Each file opens in its own tab, so you can switch between them and compare two. Files up to 1 GB are read; the limit is the browser's memory, not NiTools'.

The analysis runs in a background worker in the tab and takes from a fraction of a second to about ten seconds for a few hundred megabytes. The steps show while it runs. Closing a tab frees its memory.

The views

The sidebar lists the views that apply to the file, in seven groups that fold, with the number of things each view lists; point at a number to see what it counts. A coloured number or dot marks a view with something worth a look. Type in Find a view to narrow the list. The address bar follows the view, so Back and Forward work and a view can be bookmarked while the file is open.

For x86 and x64 programs NiTools reads all the code once, in the background, as soon as the analysis finishes (for up to 16 MB of code; larger files have a Count uses in the code button). The code views and their numbers fill in when it is done, usually within a few seconds.

Summary

• Overview: the score and its top findings, the main facts about the file, its hashes, and a strip of the file from start to end with its sections and entropy.
• Findings: every finding that went into the score, grouped, with a link to the view it came from.

Structure

• Headers: the DOS, file and optional headers and the section table of a Windows executable (or the ELF and Mach-O headers), field by field, with the offset of each field and what its value means.
• Sections, Imports, Exports: the layout and the functions the file uses and offers. Imports carry a one-line description for common Windows functions; imports by number from Winsock and OLE Automation get their names. Exports show forwarders to other libraries.
• Resources: every resource, with the icons drawn, the version information decoded and the manifest shown, including whether the program asks to run as administrator. Any resource can be saved.
• Strings and Indicators: readable text in ASCII and UTF-16, sorted into kinds, and the URLs, domains, IP addresses, paths, registry keys and names found in it.
• Components: what the file is built from, as it says itself: the libraries it loads, version banners such as "OpenSSL 1.1.1t", copyright and licence notices of the code it includes, and the namespaces of its C++ classes.
• Embedded files: executables, archives, images, certificates, keys and code patterns inside the file, found by their signatures. Those with a known size can be saved.
• Signature: the Authenticode signature. NiTools hashes the file as Authenticode does and compares it with the signed hash, verifies the signature with the signer certificate's key, and lists every certificate and the timestamp. It does not check that the chain ends at a root Windows trusts; the file's Properties, Digital Signatures does that.
• Overlay, Debug data, Rich header, Relocations, Timestamps: data after the image, the PDB path and symbol server key, the toolchain that built each object, the load-time fixups, and every recorded time side by side.
• Android package, Archive, ELF, Mach-O: the parts that only those formats have.

Code

• Disassembly: x86 and x64 code, one function at a time, with a list of every known function beside it. Calls and jumps name their targets and link to them; instructions that read an import or a string say which. Type an address or a function name to go there. Bookmark keeps the function under Notes.
• Control flow graph: a function as blocks of straight-line code with the branches between them, taken and not taken in their own colours and loops drawn around the side. A block's name opens the listing there.
• Functions: every function start NiTools knows, from unwind data, exports, symbols, import thunks, virtual tables, TLS callbacks and the calls in the code.
• Call graph: the functions that call one function and the ones it calls, as a picture; any box opens the graph around that function.
• Cross-references: what calls, jumps to or reads an address, a function, an import or a string, and the functions, imports and strings the code uses most.
• Thunks: functions that are a single jump, through an import or on to another function.
• Stack frames: the stack slots a function uses, which are locals and which are arguments, how often each is read and written, and the locals as a C struct.
• TLS callbacks and Unwind data: code that runs before the entry point, and the exact bounds of every function in 64-bit files.

Reconstruction

• Classes: C++ classes named by RTTI, with their bases, derived classes and virtual function tables, and a C++ header of them all to download.
• Class hierarchy: the classes as a tree, with the chain from a class up to its root and everything below it.
• Class layouts: the fields of a class, from the offsets its virtual functions read and write through this, marked where the base class uses them too, and written out as a struct.
• Stack strings: text the code writes onto the stack a few bytes at a time, so that it never appears in the file as a string.
• Dynamic imports: every call to GetProcAddress, LoadLibrary and their kin with the name it asks for, and Windows functions and libraries named in the strings but not imported.
• Demangler: C++ names back to how they were written, for both Microsoft's scheme and the one GCC and Clang use: every such name in the file, and any you paste.

Security

• Capabilities and ATT&CK: what combinations of imports let the program do, and the MITRE ATT&CK techniques they map to.
• Anti-analysis, Crypto, Network, Rule matches: debugger and VM checks, crypto constants, network functions and matches against known malware and tool patterns.
• Packing: the signs that the code is compressed or encrypted and unpacks itself, each with what was found, and a conclusion.
• System calls: syscall, sysenter and int 2Eh instructions in the code, with the service number each one uses. Outside Windows' own system libraries they bypass the hooks security software relies on.
• YARA rule: a rule for this file written from its most specific strings, its import hash and, if you want, the bytes at its entry point, ready to copy or save.
• Anomalies, Mitigations: structure that toolchains do not produce, and the exploit protections the file was linked with.

Visualisation

• Entropy: how random the bytes are across the file, with the runs that look compressed or encrypted.
• Hilbert map: the whole file as one square picture, zeros, text, code and compressed data each in their own colour. Point at it to read the offset; click to open that part in Hex.
• Byte pairs: how often each byte value follows each other one, for the whole file or one section. Text, code and encrypted data each leave their own pattern.

Tools

• Hex: the bytes, with the section each row is in and the values at the cursor as integers, floats, a character and a time. Scroll with the wheel, the slider or Page Up and Page Down; Shift extends the selection, which can be saved or copied as hex. Find takes text or hex bytes.
• Search: every place text (UTF-8 or UTF-16) or a byte sequence occurs, with the bytes around it.
• Struct templates: bytes read as a C struct: the built-in PE, ELF, Mach-O, ZIP, BMP and PNG headers, or structs you write, which stay in your browser.
• XOR: ranks the 255 single-byte keys by how readable a range becomes and whether an executable or a URL appears, and decodes with any key, single or multi-byte.
• Compare: where this file and another open file differ, block by block.
• Match functions: pairs the functions of this build with another open build of the same program by their code, with addresses blanked so moved code still matches. It shows what moved and what changed, and can carry the other build's function names over.
• Notes: your notes, bookmarks and names for addresses in this file, kept in this browser under the file's SHA-256 so they come back when you open it again, and saved to or loaded from a file.
• Export: the reports, and the function names, class tables and your notes as an IDA script, a Ghidra script, an x64dbg database or a plain list.

The score

Each finding has a weight, and the score is 100 × (1 − e^−total/45): the first strong findings raise it quickly, and many weak ones never reach 100. Below 20 reads as few or no indicators, from 20 some, from 50 strong. The weights were set by running NiTools over 1,570 known-good programs and libraries from Windows and Program Files, where it scores 1,549 of them low, 21 in the middle band and none high, so that ordinary software does not look suspicious.

The score is not a verdict. Static analysis cannot tell what a program will do, only what it contains and how it was built. A protected game and a piece of malware can look alike, and a clean score says nothing about code that is downloaded later.

Reports

Report saves one HTML page with the facts, the findings, the sections, imports, capabilities, anomalies, indicators and embedded files; it prints cleanly. Markdown saves the same for a ticket or a wiki, and JSON saves everything the analysis produced. Most tables also have a CSV button for the rows that pass the current search and filter. The Export view has these and the files for IDA, Ghidra and x64dbg.

Keys

What it does not do

• It does not run the file, so anything that only happens at run time (unpacked code, downloaded payloads, decrypted strings) is not seen.
• It disassembles x86 and x64 only. ARM code in Android libraries and Apple binaries gets its structure but no disassembly.
• It does not decompile .NET assemblies or Android DEX files; it shows that they are there and what they are made of.
• It checks a signature against the file but not the trust in the signer.