Using Gargoyle on a Fonera

[Fonel]

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:

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

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

Code: Select all

o5eiqxqqohretdjc2xvbghhagyzaxf4cxfvaddsdwo3a3g0amwzc2qyahjjzkig.sm.fon.com

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

Code: Select all

o5eiqxqqohr****************************************************.sm.fon.com

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

Code: Select all

a=Y1NRQWdqd0NUUEVqUm==

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):

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

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

[skynetbbs]

Hi,

the following problems:

* /etc/resolv.conf is 127.0.0.1
it can not resolve anything due to it
i've removed the 127.0.0.1 and replaced with opendns ...resolving works now
* date -> gives a date in 1970
I tried ntpclient -h pool.ntp.org -c 1
but date is still in the past

-> heartbeat didn't work but my fonera+ is listed at btfon perhaps that's different?
i'll have to get it migrated back




There is no use to use eg DDWRT or Gargoyle to get the Fonera improve.... the FON firmware has it set on 18dBm ... which is 62mWatt; increased with the 2dBm antenna this means 100mWatt which is the max...

the only thing you can overclock is the cpu...from 180 to 200mhz... i believe at 220mhz you will have killed it unless you have it cooled actively
at 240mhz it's friend anyway...

if you really want to improve the wifi then there is only 1 firmware that can do this : http://www.oswave.com
but beware it's a trial version only untill paid for ...
do give feedback i you tested this firmware!
their trick is to change the wifi channels; make them smaller (20mhz steps?) and improve the sensitivity

[Eric]

Thanks for pointing out the issue with the date -- some recent change that was back-ported to the 8.09 branch which Gargoyle is using caused ntp not not start properly. This is now fixed (new firmware uploaded).

I'm not sure where your problem with dns is coming from. It's true /etc/resolv.conf has 127.0.0.1, but this should be fine provided dnsmasq is active -- there IS a DNS server running locally... I haven't had any problem with dns.

I think Fonel (above) is right. Excellent work on his part investigating as far as he has! The heartbeat program in the latest firmware is closed source -- which kind of suggests the people over at FON are a bunch of hypocrites, huh? They only make it look like it's open-source -- but they keep the important stuff off-limits.

If someone wants to be all hard-core about solving what is going on you might be able to compile gdb for openwrt and get cracking on what's going on inside that binary.

However, I wonder if just changing the server might help. I'm guessing the update strategy used in the source of fonosfera.org is newer, and there's bound to be a bunch of older foneras out there that use the old update mechanism. It may be possible to find a server that still uses the old update strategy that we can hack to make this work....

[skynetbbs]

Yes I know about the "closed" part of that fonscmd...
the exec=nothing -> used to be in the "thinclient.sh" on the earlier models of the La Fonera to install "hotfixes"...

Currently FON is recompiling from sourcecode and asks it's users to do a manual full reflash which takes upto 30 minutes each time; they made a plugin for it... There is currently no indication that they will soon start with hotfixes.

That said, I believe dd-wrt & linksys-fon are still using the "freddyfon" heartbeat method?

In december it got added to the xwrt trunk : http://code.google.com/p/x-wrt/source/b ... nheartbeat

because freddyfon website is gone

[Fonel]

I can't believe it, all that time searching online for a heartbeat script that works on newer openwrt versions and I never came by the one in the x-wrt trunk. It would have saved us a lot of time. At least we have a Gargoyle specific version.

Secondly I can confirm that using the old heartbeat method against download.fon.com works even on newer Fonera's, but it would be really easy for Fon to identify that a new Fonera is connecting. Using what Eric posted, but using this fonbeat.sh instead

Code: Select all

MODE=start
VOUCHER=start

# gather the MAC addresses
ETMAC=$( gargoyle_header_footer -i | grep currentLanMac      | sed 's/^[^\"]*\"//g' | sed 's/\".*$//g' )
WLMAC=$( gargoyle_header_footer -i | grep currentWirelessMac | sed 's/^[^\"]*\"//g' | sed 's/\".*$//g' )
FONREV=3
FIRMWARE=0.7.2
DEVICE=fonera
SERVER=download.fon.com
PORT=1937
USER=openwrt
KEY=/etc/fonkey
CHILLVER=1.0-1
THCLVER=1.0


	
echo "mode='$MODE' wlmac='$WLMAC' mac='$ETMAC' fonrev='$FONREV' firmware='$FIRMWARE' chillver='$CHILLVER' thclver='$THCLVER' device='$DEVICE'" | ssh -T -y ${PORT:+ -p $PORT}${KEY:+ -i $KEY} "${USER}@${SERVER}" 

date

together with this key http://x-wrt.googlecode.com/svn/trunk/p ... etc/fonkey should work on any Fonera running Gargoyle.

Also one has to wonder since they bothered implementing a new type of heartbeat will they at one point start filtering new Foneras on the old heartbeat server or even port fonsmcd to the old Fonera's and close the old heartbeat server? There must be reasons for why they keep the fonsmcd closed-source, probably because they don't want the heartbeat to be known so I find it weird that they would keep the old heartbeat server open then for everybody then.

About the Oswave firmware, I don't know if that was intended to me, but to answer that question from my point of view. Oswave seems to be in violation of the GPL, not to mention that they replace redboot with their own version and have as stated on their website "Currently it is not possible to downgrade LaFonera to original firmware. We are planning to add this option at a later time." which means even if you just trial it you are stuck with it, so Oswave is not an option. My problem is that I find the Fonera firmware really slow, it lacks the possibility bridge the WAN with LAN/Wifi without routing and NATing which my modem already does and a lot more I can't remember right now. The Fonera firmware has many features I do not care about, while lacking many features that I do care about. I know you might ask why I purchased the Fonera at all, the answer is easy I liked to idea of sharing my Wifi and wanted to be part of that community, I didn't expect the firmware to be so restricted and once I didn't find a way to deal with the Fonera firmware shortcomings I decided to use another firmware and rather take the important part (heartbeat and captive portal) to the new firmware. That's where I am now, still trying to make my Fonera working as I want it to while trying to still remain a part of the Fon community.

Lastly at this point even if there currently isn't any indication that Fon will start with hotfixes again, I do not like the idea of anyone having that option on my router except for me. Would you let someone install a backdoor on your computer if they told you it is just in case, they don't intend to use it? Since I suspect the old heartbeat server will not be there for ever, I would like to continue investigating fonsmcd. I also seem to recall that the law here states that reverse engineering for the purpose of interoperability is allowed, but I will have to investigate if that is still true (lately it feels like laws change every year) and if this would fall under interoperability, if not a clean room implementation would be the way to go.

Unfortunately I was unsuccessful getting GDB running on openwrt, then again I am new to compiling so I am sure I did something wrong someplace. If someone has a ready package and installing instructions for getting GDB on the Fonera I would really appreciate it if they share it. I continue if for no other reason then that right now I am really curious on what fonsmcd does Hope someone can help me out.

[lwrver]

I have several Fonera 2200's that have been flashed with Open-Mesh firmware using the Linux easyflash method. What is the easiest way to reflash them to Gargoyle?

[Eric]

You can use FonFlash available in the download section of this site. The older AP51 flash should work as well.

Incidentally... next time please post in a new thread. There's now about 3 conversations in this thread going on simultaneously. It's best of separate topics are posted separately.

[skynetbbs]

the xwrt version works indeed very well on my Fonera...
although a Fonera+ is now considered a fonera classic

the only issue with this heartbeat is the "macadres"...
FON filters only 00:18:* fonera adresses;

best is to show the mac adres you are sending; so they can email support@fon.com with it asking to insert it into their database.
I don't think "spoofing" an 00:18 is the best solution; you could be updating someone elses fonera

I don't think they will remove it; the reason behind it is that they noticed lot's of isp's seem to allow DNS (newer system) and not this "ssh" like heartbeat...
the better reason is : "dns" is low weight in comparison to the ssh links. They even increased updates...the DNS updates are almost every 2 minutes whereas the ssh are only every 30 minutes

as soon as the captive portal is there we could ask for better support for gargoyle... they haven't upgraded the linksys/fonera/foneraplus in ages;

and i don't like this constrictions as well...I use "freewlan" on my fonera classic... which also allow bridging without routing
But I don't have an alternative yet (but gargoyle could soon be installed at this rate!!! for the Fonera Plus & LinksysFon

[Fonel]

Would it be possible to run the Fonera firmware or Gargoyle firmware on Qemu MIPS? That would make it much easier to study fonsmcd.

[Fonel]

I must say you do make some valid points skynetbbs, although I don't understand why they then decided to keep the fonsmcd closed source when the rest of the firmware is open source.

Still as long as the old heartbeat works for newer Foneras too the need to understand the new heartbeat is not really there. I still wish to understand the new heartbeat and possible re-implement it, but since I have less and less free time I will have to put that on hold for now.

Additionally since the summer time is the most busy one I will have to put getting the captive-portal working on hold also, but hopefully I will get back working on that after the summer. In the mean time if someone wishes to do it, I would appreciate not having to do it myself

Lastly I have one more observation regarding the fonsmcd heartbeat that I would like to add, I tried running fonsmcd without the public_sm_rsa_key.pem file, but fonsmcd didn't want to run without it. Therefore I decided to make my own public_sm_rsa_key.pem where I had the private key counterpart in an attempt to study what was encrypted with the public key. To my surprise the fonsmcd heartbeat worked just fine using my public key, which would seem to imply that although fonsmcd needs the public_sm_rsa_key.pem file to work, it is not used for the heartbeat. So we can take that out of the equation when trying to figure out how the heartbeat is generated.