Re: Using Gargoyle on a Fonera
Posted: Fri Apr 24, 2009 7:30 pm
Thanks Eric for the script, it is about that far I got too, but your script was much cleaner then mine. Unfortunately it didn't work and after some searching I found that Fon had changed their heartbeat, it now works by making a DNS request to cthulhu.fon.com (213.134.45.88) every minute. I found a report of this here http://fonblog.wordpress.com/2007/08/30 ... us-review/ with a picture of tcpdump capturing the heartbeat. I also found this information:
This is taken and cleaned some from the translated page here http://translate.google.com/translate?h ... php?p=6539 where I believe it is confirmed by someone working at Fon.
So I started to try to understand the new heartbeat and first I use Wireshark to make a capture, which revealed that what the Fonera does is make a DNS request type TXT to a host similar to where the string before .sm.fon.com changes every time except for the first 11 characters, so what is common in every DNS request is I believe the first 11 characters are static because they are seeded from the mac address which of course does not change, while the rest of the string is seeded by the time together with other information, so it changes all the time.
The response received from the DNS server contains a data string such as which seems to first of all validate that this is a response from Fon and secondly tell the Fonera what to do. The reason I say validate is because apparently inside the string sent to the DNS server is an id only Fon can decrypt and so if the response contains the same id the answer is validated to be from Fon.
Now my first thought was to find what process on the Fonera does this job and then look at its source, unfortunately the file responsible for the new heartbeat is the only one that the source is not released for, that is the fonsmcd. So finding out what it does by looking at its source is not an option. The second idea I had was to try to extract the fonsmcd and see what it does, fortunately it seems that running fonsmcd in non-daemon mode prints out debugging information so I ended up with this (while running fonsmcd on Gargoyle):
The trid is the one used to validate the response which i suspect might be related to the time. The "fonera" and firmware version (2.2.3.0) is taken from fon_version and fon_revision in /etc, this seems to be hardcoded so the files have to be there. Also fonsmcd relies on libdaemon.so.0 and libfonrsa.so.1 existing in /usr/lib while it expects to find fonsmcd.conf in /etc/fon. The file fonsmcd.conf contains references to public_sm_rsa_key.pem and to a aes_key in /etc, but I can only find public_sm_rsa_key.pem which seems to indicate that the string sent to the DNS server is encrypted so that only the Fon server can decrypt and respond with the trid. By studying the libfonrsa source I see references to RIPEMD160 so I guess that is used together with Base64 and possible a Privat/Public key scheme. Unfortunately exactly how the string sent to the DNS is generated is still unknown, but I hope someone might give some input there.
This is as far as I got, but I really want to get the heartbeat going on Gargoyle so I hope anyone that has any idea might suggest them so that we can make more progress with the heartbeat. In theory we could use the files taken from the Fon firmware and use them with Gargoyle, but I feel uncomfortable with the last line received from fonsmcd. It is only reasonable to believe that since "exec=nothing" exists then there is a possibility that in the future a command might be issued which the fonsmcd executes so I would like to avoid having to use the fonsmcd. So does anyone have any thoughts, opinions or suggestions to the information I found?
The fonsmcd files:
http://trac.fonosfera.org/fon-ng/browse ... n_revision
http://trac.fonosfera.org/fon-ng/browse ... on_version
http://trac.fonosfera.org/fon-ng/browse ... in/fonsmcd
http://trac.fonosfera.org/fon-ng/browse ... /libdaemon
http://trac.fonosfera.org/fon-ng/browse ... fon/fonrsa
http://trac.fonosfera.org/fon-ng/browse ... nsmcd.conf
http://trac.fonosfera.org/fon-ng/browse ... sa_key.pem
Code: Select all
This is usually because the Fonera heartbeat is blocked by your ISP, company or school network.
If you use a Fonera (1.0), please check if the following port is blocked:
download.fon.com (213.134.45.191) TCP port 1937
If you use a Fonera+ (1.5), please check if the following port is blocked:
fatserver.fon.com (213.134.45.190) TCP port 1938
cthulhu.fon.com (213.134.45.88) UDP port 53
So I started to try to understand the new heartbeat and first I use Wireshark to make a capture, which revealed that what the Fonera does is make a DNS request type TXT to a host similar to
Code: Select all
o5eiqxqqohretdjc2xvbghhagyzaxf4cxfvaddsdwo3a3g0amwzc2qyahjjzkig.sm.fon.com
Code: Select all
o5eiqxqqohr****************************************************.sm.fon.com
The response received from the DNS server contains a data string such as
Code: Select all
a=Y1NRQWdqd0NUUEVqUm==
Now my first thought was to find what process on the Fonera does this job and then look at its source, unfortunately the file responsible for the new heartbeat is the only one that the source is not released for, that is the fonsmcd. So finding out what it does by looking at its source is not an option. The second idea I had was to try to extract the fonsmcd and see what it does, fortunately it seems that running fonsmcd in non-daemon mode prints out debugging information so I ended up with this (while running fonsmcd on Gargoyle):
Code: Select all
root@OpenWrt:~# /usr/sbin/fonsmcd -n
fonsmcd[2294]: (Main) DEBUG: SMC_resolv_host: About to call dns_ip4() for cthulhu.fon.com
fonsmcd[2294]: (Main) DEBUG: SMC_resolv_host: cthulhu.fon.com resolved as 213.134.45.88
fonsmcd[2294]: (Main) WARNING: SMC_find_boarddata: found b8oard config /dev/mtd6ro
fonsmcd[2294]: (Main) DEBUG: wlmac [XX-XX-XX-XX-XX-XX]
fonsmcd[2294]: (Main) WARNING: SMC_find_boarddata: found board config /dev/mtd6ro
fonsmcd[2294]: (Main) DEBUG: QUERY [XX-XX-XX-XX-XX-XX,regular_start,fonera,2.2.3.0,st=0,trid=4ac383ef,retries=0]
fonsmcd[2294]: (Main) DEBUG: SMC_do_regular_query: Query succeeded
fonsmcd[2294]: (Main) DEBUG: BUFFER [26] [a=aW4wdkhRa1B0cU9ua2pFV1==]
fonsmcd[2294]: (Main) DEBUG: ANSWER [exec=nothing, trid=[4ac383ef], data=[]]
fonsmcd[2294]: (Main) DEBUG: QUERY [XX-XX-XX-XX-XX-XX,regular_online,fonera,2.2.3.0,st=0,trid=53734f44,retries=0]
fonsmcd[2294]: (Main) DEBUG: SMC_do_regular_query: Query succeeded
fonsmcd[2294]: (Main) DEBUG: BUFFER [26] [a=JLRXdBdzNpWm4yTThhRG5W==]
fonsmcd[2294]: (Main) DEBUG: ANSWER [exec=nothing, trid=[53734f44], data=[]]
fonsmcd[2294]: (Main) CRITICAL: Got SIGINT or SIGQUIT
This is as far as I got, but I really want to get the heartbeat going on Gargoyle so I hope anyone that has any idea might suggest them so that we can make more progress with the heartbeat. In theory we could use the files taken from the Fon firmware and use them with Gargoyle, but I feel uncomfortable with the last line received from fonsmcd. It is only reasonable to believe that since "exec=nothing" exists then there is a possibility that in the future a command might be issued which the fonsmcd executes so I would like to avoid having to use the fonsmcd. So does anyone have any thoughts, opinions or suggestions to the information I found?
The fonsmcd files:
http://trac.fonosfera.org/fon-ng/browse ... n_revision
http://trac.fonosfera.org/fon-ng/browse ... on_version
http://trac.fonosfera.org/fon-ng/browse ... in/fonsmcd
http://trac.fonosfera.org/fon-ng/browse ... /libdaemon
http://trac.fonosfera.org/fon-ng/browse ... fon/fonrsa
http://trac.fonosfera.org/fon-ng/browse ... nsmcd.conf
http://trac.fonosfera.org/fon-ng/browse ... sa_key.pem