Exploring IOTA ICT, Reverse engineering the code Part-1

Next we are going to send a message to the ICT via UDP from a different f1-micro instance. Which means just set up another cloud f1-micro instance or use any other linux distribution which is connected to the internet and is not blocked by your ICT client. The easiest way to send an UDP packet to your ICT client I found is this $echo "Hello ICT" > /dev/udp/YOUR_ICT_IP/11111 Which results on your ICT side (once a minute has passed) to immediate boring response [2018-07-22T11:28:30.883] Ict 0.1.12018-07-22T11:28:31.049Number of transactions = 0Number of missing transactions = 02018-07-22T11:30:11.848Number of transactions = 0Number of missing transactions = 0 In order to make sure we receive the packet lets rewrite the code which prints our transmitted UDP message. After the byte[] data = datagramPacket.getData(); we add the following in order to print the incoming packets. String string = new String(data, 0, datagramPacket.getLength());System.out.println(string);System.out.println("----"); In addition we like to see the IP of the sender and we add after the final SocketAddress socketAddress = datagramPacket.getSocketAddress(); the following code to print the address System.out.println("SocketAddress =" + socketAddress); After compiling the ICT.java and moving the *.class file to cfb/ict/ we can rerun our recompiled and changed ICT. Once we send four times the same message again we get this result (leave it a minute time to get the last lines): [2018-07-22T11:46:39.484] Ict 0.1.12018-07-22T11:46:39.585Number of transactions = 0Number of missing transactions = 0Hello ICT----Hello ICT----Hello ICT----Hello ICT----2018-07-22T11:47:44.403Number of transactions = 0Number of missing transactions = 0 We get the messages but no information about the IP address. Revisiting the code that is due to not getting passed this statement: if (datagramPacket.getLength() != 1650) { datagramPacket.setLength(1650);} else { Constructing a message with 1650 chars should be easy with linux, we can even use the SEED generation function and extend to 1650 in order to just get capital A...Z9 cat /dev/urandom |tr -dc A-Z9|head -c${1:-1650} > test.tx we can’t use our echo command here as it breaks our 1650 length message into smaller messages. But we can do the following on our non-ict instance cat test.tx > /dev/udp/10.142.0.4/11111 The result actually won’t print the complete message but we get more {deleted: content of test.tx 1650 chars long}----SocketAddress =/IP:390252018-07-22T11:59:59.169/IP:39025: 2 / 0 / 1 / 0 / 0Number of transactions = 0Number of missing transactions = 0 The bold marked line from the above ICT report is new and needs to be understood — looking at the code Alex from the official developer Discord did a thorough summary. Which at least one of those statement we have just proven invalidTxs ourselfs Description of ICT logs by Alex allTxs = number of UDP packages received at the specified port (default=14265) during a 1min period. newTxs = number of valid transactions, that weren't received before during a 1min period. invalidTxs = number of UDP packages, that don't form a proper transaction (invalid value, invalid address, invalid timestamp, i.e. before Mon Oct 23 12:00:00 UTC 2017, invalid transaction hash). requestedTxs = number of times the ICT could answer a request for a certain transaction from this neighbor. sharedTxs = number of new transactions, that were relayed to that neighbor during a 1min period. Number of transactions = sum of all newTxs of all neighboring nodes during a 1min period. Number of missing transactions = number of all requests, the ICT couldn't answer during a 1min period. And we can extend the statement by our observation. The number of invalidTxs will not increase further than one. As you can see above, I’ve send two times the test.tx invalid transaction and the counter stopped at one. This is most likely as the code for validation of the transaction is not entered again in that epoch (1min. period) once a invalid transaction is found.