Are there known special cases where the first 160 bits of keccak256 can be null ? Or does finding a collision is required? In the Tronix contract code (a large ICO listed on many exchanges) lies this modifier which is used for all token transfers :

modifier validAddress {
    assert(0x0 != msg.sender);
    _;
}


The code is written by serious professionals : not the kind of Ponzi scheme coder leaving useless code that cost money to everyone while processing transactions. As the contract is no longer maintained, developers are no longer replying on such questions (mailto:service@tron.network).
The point is msg.sender is set by the network : contract cannot act on that value.

Most of time unofficial answers I’m getting is it’s indeed possible to send transactions as 0x0 : that is Keccak256(ECDSASIGN(transaction_data_to_sign,e, c, v)[1:])[12:] where Secp256k1 is used would returns NULL.

So… First, are there known keccak256 values that would return NULL once truncated or does NULL involve bruteforcing like all other values ?
No. SHA-2, Keccak, and serious alternatives to those two are all assumed to be model-able as a random oracle. Given an valid input it will return back a bit string chosen from a uniform random distribution. 

The probability of any one such string starting with an all zero 160 bit prefix is $2^{-160}$. That's too small to find by chance. The amount of work to search for such a string should therefore be about equivalent to $2^{160}$ hash evaluations. That would consume a lot of time and a lot of power. So much so that it's impossible for any of us Earthlings to acheive.

If there is a way to search for inputs whose outputs have a certain property which is faster than by brute force, then that means the algorithm is broken. An attack that lets you easily find inputs that result in output bits set to a certain value is called a (partial) preimage attack.

Edit: I answered only the cryptography part of the question. Not the cryptocurrency. That's off topic for this site. Also off topic is the contract code. There could be some subtle (or obvious) problem in the code that causes problems or enables scams. Maybe there is some type conversion rule that mixes up zero values, null pointers, none-value. Maybe errors propagate as null pointers or zero return values. Do not interpret my not covering non-cryptography material as endorsement of a product.