Lions and tigraas


Peter Ferrie

Symantec Security Response, USA
Editor: Helen Martin


Peter Ferrie describes TIOS/Tigraa, a virus that runs on Texas Instruments calculators.


Texas Instruments makes very advanced graphing calculators. What is particularly interesting is that these calculators are programmable, and the resulting applications can be stored in the memory of the calculator. The applications can also be altered by other applications, and that means they can be infected by viruses. This brings us to TIOS/Tigraa, which is the second known calculator virus (the first having been TIOS/Divo), though Tigraa is the more interesting of the two.

Memory resident

When the virus is first executed, it checks whether the ROM call table is in ROM (at 8Mb or greater) or RAM (below 8Mb). This serves as the memory infection marker. If the call table is in ROM, then the virus allocates some memory for it and copies the call table to the allocated memory. The virus uses a function to allocate memory at the top of the heap, then another function to de-reference the returned handle to get the memory address. This is despite there being a single function that performs both of these actions.

In the same way, the virus also allocates some memory to hold a copy of the virus body itself, allowing it to stay resident in memory after the host application terminates. The virus hooks the SymFindNext() function in the new call table, then replaces the original call table pointer with a pointer to the new call table.


The virus only checks whether the payload should run when an infected application passes control to the virus code. The payload itself activates only if one of the system timers contains the value 119. However, since that timer is updated at a rate of about 1,500 times per second by default, actually seeing the payload is likely to be a rare event.

The payload is very simple: it clears the screen and prints the text 't89.GAARA ' at column 55 of the first row, then returns control to the host. Despite the message, which suggests the virus may be specific to the TI89 calculator, the virus also runs on the TI92+ and Voyage 200 calculators. Older calculators, such as the TI84, use a different CPU (ZiLOG Z80), and the virus does not work on them.

SymFindNext and infection

The SymFindNext() function is a symbol enumeration function. SymFindFirst() begins the search, and the two functions are fairly similar to the FindFirstFile() and FindNextFile() functions on Windows, for example.

When an application executes SymFindNext(), the virus gains control. It executes the original SymFindNext() in order to get the information, and the contents of the returned entry will be examined for the possibility of infection. A symbol is a candidate for infection if it is a file (as opposed to a folder) that is not a twin symbol, archived (because the Flash memory is protected), locked, or deleted.

The virus checks that the file is not infected already by searching forwards through the entire file for the string ‘GAA’. It is unclear why the virus author did it that way, given that the file size is known, and it would be trivial to search backwards instead – especially since the string appears near the end of infected files. Only after searching for the infection marker does the virus check whether the file is an assembly file, which is the only infectable file type.

Once a suitable file has been found to infect, the virus moves the relocation table further down in the file to make room for the virus body. The reason for this is that the relocation table must appear after the image. It seems that the virus author did not realise that the relocation table is always properly aligned, so copying it can be done in just two instructions instead of 11.

This is the point at which this virus really differs from TIOS/Divo. Whereas Divo replaced the first instruction in the file with a branch to the virus body, Tigraa searches the file for the first instance of a specific instruction sequence (‘unlk a6/rts’). If that sequence is found, then Tigraa will replace it with a branch to the virus body. Once again, the virus author appears not to realise that since all Motorola 68000 instructions are 16 bits long, the instruction will always be properly aligned, so the store can be shortened by one instruction. If the sequence is not found, the file will still contain the virus body, but the virus will never gain control.


This virus appears to have been written by a beginner to Motorola 68000 assembler programming, based on the use of ‘lea/mov -(sp)’ instead of ‘pea’, a test for zero after an ‘and’, the apparent inability to decide between ‘clr’ and ‘sub’, and so on. Such things would be forgivable in a true beginner, but the virus author is a well-known security researcher. He released the virus source code under his own name, Piotr Bania, rather than one of his aliases (‘Lord Yup’ and ‘dis69’). It’s funny, in a way, that the first virus that we know he wrote came only after he left the 29A virus-writing group. In any case, it’s still a virus, and that is to be condemned. Just because you can write one doesn’t mean that you should.



Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.