FAQ

What we propose is paradoxical, and surprises many at first. Here are some questions people have asked us, and our responses:

Q: What it malware refuses to get swapped out?

That is not a problem. We do not assume that it will agree to be swapped out with all the legitimate processes. In fact, we assume that it will try to remain active in RAM, in order to attempt to modify the results of the scan.

But to be active, a malware agent has to take up space in RAM. Either empty space, or part of the the space of our routine. We overwrite the entire space that should be free with a pseudo-random string. If malware does not want to be overwritten, it can selectively block writes, of course. It can even write those values elsewhere – like secondary storage – in order for the checksum to be possible to calculate later on.

But accessing secondary storage is slower than accessing RAM. Our routine will accentuate the differences by creating access patterns that are fast in RAM, but slow for flash and other storage technologies. By timing the computation of the checksum, cheating can be detected. The external verifier in charge of determining whether a given client is infected would know.

Q: Do you need to know how much RAM a device has?

Yes. But that will be determined when the device registers, mostly automatically and from the serial number. The consumer would never have to worry.

In cases where extra RAM is added, or RAM is simply replaced, the new hardware can be reported when the device is first started up. (To avoid that the device is infected and this report is not made, one can run the scan right before installing the new hardware.)

Q: Do you need to know how much free RAM a device has?

Yes. But that is easy. The amount of free RAM is the difference between the amount of RAM and the size of the detection routine (and kernel, if that is not swapped out). We know the amount of available RAM. We know the size of the detection routine. The remainder should be free. If it is not, that is because of malware.

Q: What if malware infects the kernel or your detection routine?

It does not really matter. It is not possible to do that without changing the contents of RAM. The external verifier knows what these contents should be – since it knows the binary of the detection routine and the kernel, and it sets the seed used to compute the pseudo-random string used to fill RAM. Therefore, the external verifier would notice if the checksum is wrong. See the argument above.

Q: What if malware fudges the timing results, or forges the right checksums?

You cannot fudge the timing results. The client does not submit “it took me half a second”. It receives the seeds and keys from the external verifier, computes intensively for a while, and submits the responses. The timing results are simply the time it took between receiving seeds and keys and returning the result.

You can also not fudge the checksum. It is computed as a non-linear accumulator of the RAM contents, which consist of the detection routine and the pseudo-random string. You cannot pre-compute this value, since the keys and seeds are needed.

Q: What happens if the latency variance is substantial?

That could be bad, since that could make a clean device appear infected.

However, we have developed an array of tricks to minimize latency variance, involving use of SIM cards, tethered devices, and base stations. Common for all: low variance.

Note that the latency does not matter much, since that is predictable, it is only latency variance we need to be concerned with.

Q: What do you do if you detect an infection?

The first thing we must do is notify the service provider as handling it is a policy decision by the service provider. For example, if a user swipes their mobile phone over an NFC device at a retail counter, the service provider immediately initiates a FatSkunk scan before PIN entry; if a threat is not detected, the user can enter their PIN and the service provider knows with certainty that there is no malware spying on the entry, and they are executing in a safe state. If malware is detected, then the bank who issued the mobile credit card may choose, depending on the dollar amount, to proceed with the transaction, or deny it until the device is backed up and recovered to the last known clean state. Regardless, the user can continue to use their phone for all sorts of applications, but not for that particuar transaction until the phone is once again in clean state.

After detection, an active and persistent threat on the device can be characterized. It can also be removed by walled garden techniques, and we can re-scan to verify success. If the threat becomes inactive by moving to secondary storage, we can detect it by backing up any changed executables to our cloud, and remove it there. We use a patented technique to make certain malware has not changed the backup logs in order to hide itself in the cloud.

Q: What if the malware hides in secondary storage?

Yes, that is certainly possible. We first determine that there is no active malware. Assume that this has been done. Now, there are two principal approaches that can be taken.

1. You can start scanning secondary storage for malware, whether using a whitelisting or blacklisting approach. Since we know that there is no active malware at this stage, scanning is not done in an adversarial setting, and we can trust the results.

2. In some settings, you may not care whether there is dormant malware. You know now that there is no active malware, so now it is safe to perform sensitive transactions. Set up an SSL connection; cast a vote; perform a payment.

In other words, it depends on who runs the scan, and what they care most about. Removing malware or just transacting securely?

Q: Do you quarantine detected malware?

We currently do not, simply because (with our solution) its not important to do so. Its more important to dynamically detect infection, with certainty, day ZERO. We also dont need to charachterize the threat. Since we can guarantee detection, it means a service provider can with 100% confidence transact if we have determined there is no infection; if there is, there are other companies that are good at then quarantining and cleaning, or, our backend backup and recovery server can be employed. We can guarantee that your mobile wireless service is in a malware-free state before it transacts; the others cannot. This is a big paradigm shift in how threats are percieved.

Q: How can one ever avoid zero-day attacks?

A zero-day attack is a threat that is not yet known of by anti-virus vendors. But it does not matter to us whether the threat is known or not. Does it try to be active? If so, it takes up space, and we detect it. If no, then we would detect the modification of legitimate applications when we whitelist secondary storage.

Q: Why not simply reboot instead?

Rebooting is slow, we can do things much faster. But the important difference is that bootloaders can be infected, which would avoid detection, but if our routine is infected, this will be detected.

Q: Can’t malware simply overwrite the scanner?

Yes, that is possible. Or simply disable it. But if the external verifier tries to initiate scans, and nothing happens, that is a sign of problem in itself. Yes, it could mean that the device is turned off, and therefore cannot respond. Any device that generates network activity and refuses to perform a scan for some period of time will be considered corrupted.

Q: How long does the scanning take?

This depends on many factors. The amount of RAM, the speed of the processor, and the speed of the connection between the device and the external verifier. In general, it takes significantly less than 100 milliseconds. That is for the scanning of RAM only; the whitelisting or blacklisting of flash is on top of that.

Q: Does this only work for smartphones?

Our solution is not just for smartphones. Any device with a processor and RAM.-tablets, e-readers, game consoles, netbooks, laptops, settop boxes, industrial machines … car infotainment systems..anything with a WiFi or wireless connection; modern cameras, refrigerators, etc … you name it.

Q: Is it an application?

Our client solution is not a downloadable app- it needs root privileges. (Like most other anti-virus software.)

Q: Have you implemented it?

Yes. We have a beta product for the Android platform. But we are not restricted to Android, our solution can be implemented for any device, and any OS.

Q: Are you selling this product?

Our mobile client software is free for device manufacturers. We will be offering our back-end software servers for sale by the end of this year.