Revisão 22-Dezembro-2000.
INTERCONEXIÓN PALM PILOT III/V/VII
By QuasaR - UNDERSEC Security Team
INTRODUÇÃO
Lá por março do 96 a companhia 3com se invento uma aparatito do mas
curioso que cumpria perfeitamente as labores da agenda eletrônica
aparecida anos antes (veja-se casio) mas que ademais ia mas lá com
características mas acercadas às necessidades de hoje em dia. A política lhe
funcionou bem, porque o numero de vendas de Palms se tem ido incrementando
notavelmente, ao igual que se têm ido ampliando as possibilidades e
características destes dispositivos.
Uma das possibilidades mas grandes que oferecem as palm pilot é sua
possibilidade de interconexión independentemente do Hardware ou VOS
o que a desejemos conectar. Se alguém sabe das mesmas possibilidades com
pocketwin que me envie um email.
Os textos sobre palm pilot (& howto's) que podemos encontrar por aí, em seu
maioria em virilhas, tocassem-nos temas muito concretos. Baseados principalmente em
instalação & programacion de aplicações sobre palm. Pelo que echando um
detento vistazo me decantei por este texto (mini-howto a fim de contas)
sobre interconexión da palm, muito menos documentado em virilhas e quase zero
em castelhano.
SINCRONIZACION
Uma das possibilidades iniciais que trouxe palm desde sempre foi o
processo de sincronização. É o processo mediante o qual é possível
realizar instalação & backups da palm ao computador e vice-versa mediante
o cradle ou base.
Não existe nenhum mistério sob plataforma windows, mas que nada porque o
software que traz a própria palm em sua caixa, já é mas que suficiente para
abastecer todas as necessidades de sincronía da palm. Ademas em a
própria pagina de Palm (http://www.palm.com) esta disponível todos os updates
deste software para plataformas windows.
O tema se volta um pelin mas exigente para plataformas Linux e FreeBSD.
Para ambos os existem um pacote de utilidades+librerias para uma correta
sincronização, tanto em modo consola como em modo grafico.
Não provei utilidades como Kpilot (http://www.slac.com/pilone/kpilot_home/)
e similares sobre meio grafico. O que se esta claro é que oferecem maior
comodidade e certas melhoras sobre as de consola. Entre elas a possibilidade de
realizar a maioria das operações desde um mesmo programa (não assim em
consola). E a possibilidade de deixar em segundo plano um applett que reconheça
a pulsacion do botão de sincronía da base e realize o processo
automaticamente.
Para consola neste apartado temos as pilot-link
(ftp://ryeham.ee.ryerson.ca/pub/PALMOS/).
Um pacote de ferramentas bastante completo. O problema é que segundo o que
queiramos fazer precisaremos de um programa ou outro. Ainda que as possibilidades
são practicamente, tirando alguns detallitos, as mesmas que sobre a
plataforma windows.
Para informação mas detalhada sobre as pilot-link há já que ler-se as man
(man pilot-link) uma vez instalado o pacote. Existe tambien o port com
o patch para versões de FreeBSD q funciona correctisivamente.
Só nomear aqui um par de detalhes facilmente pasables por alto. A partir do
Palm VOS 3.3 a sincronía se pode realizar a uma velocidade de 57600. Em
windows acedendo a um simples menu é possível variar a velocidade. Para linux
e FreeBSD há que atribuir um valor a uma variável de meio:
export PILOTRATE=57600 (ou a velocidade que desejemos)
O segundo é também para plataformas linux & FreeBSD. É muito recomendável
um simbólico ao série onde tenhamos a palm metida:
Linux:
ln -s /dev/pilot /dev/ttyS0 (ou ttyS1)
FreeBSD:
ln -s /dev/pilot /dev/ttyd0 (ou ttyd1)
Pára mas informação sobre sincronía há que procurar já em lugares
oficiais (http://www.palm.com) ou menos oficiais (http://www.handango.com)
E agora passámos a uma das opções mas interessantes de palm...
CONEXION PPP
A palm leva uma pilha TCP/IP bastante resumida mas com enormes possibilidades
e ademas é capaz de suportar conexões ponto a ponto. Já seja com um modem,
através de IR (IRDA) sobre um celular (ou portátil) ou bem ao série de outro
equipe.
A interconexión da palm ao movil/modem nos dá a possibilidade de aceder a
qualquer lugar desde qualquer lugar que nos encontremos enquanto tenhamos
cobertura. Existem clientes de telnet, web, wap, vnc, correio.... para poder
conferir o que queiramos.
A interconexión da palm desde outro computador por exemplo é mas discutida.
Para que queremos usar a palm, se já temos o computador? Pois nunca se sabe.
Em casa de um amigo que o tio esta ocupando o computador todo o momento. Ou em
uma party ou numa reunião.... o caso é que temos um acesso transparente
desde esse computador ao resto da rede ou internet.
E agora nos vamos a centrar neste segundo ponto:
a) Conexion ppp + palm + windows
A conexão da palm através de plataformas windows é muito singela.
Todo se resume a baixar-se o programilla Mochappp (http://www.mochasoft.dk) e
configurá-lo, sem nenhum mistério, adequadamente. O programa espera uma
conexão ppp da palm e lhe asigna a ip e as dns que possui à palm.
Desta forma a palm é completamente transparente a todo e todos.
Já veremos que não ocorre o mesmo em outras plataformas, onde a palm se
comportara como uma maquina mas.
Tão só há que ter em conta que no menu de configuração de rede de
a palm:
Prefer (preferências) -> Rede -> Detalhes
Devemos selecionar que todo este atribuído automaticamente e em PPP.
Em windows 98 o Mochappp com Palm VOS 3.3 funciona perfeitamente.
Outra coisa que também recalcar mas adiante, é que esta possibilidade de
conexão ppp a velocidades por em cima de 19200 é viable sempre que se tenha
o VOS 3.3 ou superior. Em caso de não ser asi, existe a utilidade linkdirect.prc
(http://http://www.vmlinuz.org/palmos/linkdirect.html) para palm que soluciona
esta decadência em Palm VOS anteriores. Eu tive a possibilidade de prová-lo com
VOS 3.0 e salvo evolução, o programa é de duvidoso funcionamento. Ia quando
queria. Mas bom, é o que há.
b) ppp + palm + linux
Chegámos a plataformas Linux. As provas se realizaram sobre debian e um
2.2.17 e todo funciona perfectisimanente.
Para poder realizar a conexão ppp precisaremos ter habilitado o
forwarding e o masquerade em nosso sistema.
Terá que ter compilado no kernel ou como modulo todo
o relacionado com o forwarding e o masquerade. Ejemplillo de turno:
#
# Networking options
#
# CONFIG_CIPE is not set
CONFIG_PACKET=e
CONFIG_NETLINK=e
CONFIG_RTNETLINK=e
CONFIG_NETLINK_DEV=m
CONFIG_FIREWALL=e
# CONFIG_NET_SECURITY is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=e
CONFIG_INET=e
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=e
CONFIG_RTNETLINK=e
CONFIG_NETLINK=e
CONFIG_IP_MULTIPLE_TABLES=e
CONFIG_IP_ROUTE_MULTIPATH=e
# CONFIG_IP_ROUTE_TOSSE is not set
CONFIG_IP_ROUTE_VERBOSE=e
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
CONFIG_IP_ROUTE_NAT=e
# CONFIG_IP_PNP is not set
CONFIG_IP_FIREWALL=e
# CONFIG_IP_FIREWALL_NETLINK is not set
# CONFIG_IP_ROUTE_FWMARK is not set
CONFIG_IP_TRANSPARENT_PROXY=e
CONFIG_IP_MASQUERADE=e
# CONFIG_IP_MASQUERADE_ICMP is not set
# CONFIG_IP_MASQUERADE_MOD is not set
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_ALIAS=e
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=e
# CONFIG_INET_RARP is not set
CONFIG_SKB_LARGE=e
# CONFIG_IPV6 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_BRIDGE is not set
# CONFIG_LLC is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
# CONFIG_CPU_IS_SLOW is not set
Agora e após recompilar há que ativar a opção do forwarding:
echo "1" > /proc/sys/net/ipv4/ip_forward
E carregar os módulos pertinentes segundo o serviço que vamos usar....
cd /lib/modules/2.2.1x/ipv4.
Aí temos todos os módulos dos serviços a enmascarar. Ejemplillo
de turno:
-rw-r--r-- 1 root root 11308 Oct 25 15:26 ip_gre.ou
-rw-r--r-- 1 root root 4832 Oct 25 15:26 ip_masq_autofw.ou
-rw-r--r-- 1 root root 2632 Oct 25 15:26 ip_masq_cuseeme.ou
-rw-r--r-- 1 root root 4888 Oct 25 15:26 ip_masq_ftp.ou
-rw-r--r-- 1 root root 3548 Oct 25 15:26 ip_masq_irc.ou
-rw-r--r-- 1 root root 6276 Oct 25 15:26 ip_masq_mfw.ou
-rw-r--r-- 1 root root 4904 Oct 25 15:26 ip_masq_portfw.ou
-rw-r--r-- 1 root root 3216 Oct 25 15:26 ip_masq_quake.ou
-rw-r--r-- 1 root root 5260 Oct 25 15:26 ip_masq_raudio.ou
-rw-r--r-- 1 root root 5244 Oct 25 15:26 ip_masq_user.ou
-rw-r--r-- 1 root root 3080 Oct 25 15:26 ip_masq_vdolive.ou
-rw-r--r-- 1 root root 9324 Oct 25 15:26 ipip.ou
Há que carregar o que queiramos (modprobe).
Uma vez carregados os modulos correspondentes temos que ativar o
enmascaramiento (masquerade). Bastasse com:
ipchains -A forward -s 0/0 -d 0/0 -j MASQ
Se se requer de um maior controle sobre o masquerade é melhor do que vos
leiais certa documentação sobre ipchains.
Bem, agora o que faremos é criar o server pppd e que espere uma conexão
ponto a ponto no série que lhe digamos. A linha de comandos a utilizar séria,
em seu formato mas básico, algo como:
pppd /dev/série velocidade :ipdepalm parametros
Ejemplillo:
pppd /dev/pilot 57600 :10.0.0.2 local debug passive crtscts noauth
/dev/pilot -> pilot é link a nosso série
57600 -> velocidade que queiramos
:10.0.0.2 -> Aqui metemos a ip que a palm vai ter (inventada mas em
nossa mesma subred). É um fato muito curioso ver como sobre
linux a palm se vai a comportar como um dispositivo
completamente distinto e que vai formar parte de nossa rede.
local -> o usámos para que não espere o tom da linea telefonica.
debug -> mostra todo o processo de conexão (syslog)
crtscts -> para o controle da comunicação, a palm o suporta.
passive -> Quando o LCP não envia um pacote correto invés de sair
aguanta até um reset by peer.
noauth -> sem solicitar autorização para o uso da linha ppp.
Em princípio com estes parâmetros o server ppp (pppd) deberia de ficar à
escuta. Sempre poderemos enriquecer mas nosso pppd adicionando-lhe mas
parâmetros.
pppd /dev/pilot 57600 :10.0.0.2 local debug passive crtscts nodetach proxyarp
auth &
nodetach -> para manter o terminal ocupado enquanto se executa pppd
proxy-arp -> asigna uma direção mac à ip da palm. A fim de
contas é uma alias da do computador ao que esta conectada.
auth -> Pede autorização para o uso da linha. Utiliza o
pap-secrets.
& -> ao ter o nodeatch isto fará que se meta em segundo plano
;)
A opção ms-dns aparece em alguns documentos como valida para atribuir
umas dns's à palm (a palm suporta isto), no entanto não nos funciono
pelo que recomendo atribuir manualmente as dns desde a própria palm:
Prefer (preferecias) -> rede -> detalhes --> kitar checkbox de dns autmaticas
O seguinte passo é assegurar que as rotas são as corretas. Há que pensar
que vamos realizar uma conexão ppp e que portanto um de nossos
dispositivos PPPx vai ser usado (seja ppp0 ou ppp1... dependendo de as
conexões ponto a ponto que tenhamos estabelecidas).
Em princípio, o adequado séria que a rota por defeito da palm utilizasse
a nossa maquina de gateway por defeito, e deveria funcionar. Igual o que
vem a continuação não é necessário. No entanto, pelas diferentes
configurações das rotas estáticas do route pode ser que não faça o
acesso até internet ou não passe mas lá de nossa maquina. É dizer, pode
que chegue o caso de que com nosso computador se funcione mas fora de o
já não, por culpa do gateway ou que os dns são inalcanzables. Aí vão
diferentes opções:
route add ipdepalm dev dispositivo gw ipmaquina
ou bem tambien tenhamos que reconfigurar a rota por defeito do gateway.
route do gateway
route add gateway dev dispositivo-inet
OLHO!!!! aqui o dispositivo é o de acesso a internet!. Não o que a palm vai a
criar.
exemplos:
route add 10.0.0.2 dev ppp0 gw 10.0.0.1
ou tambien:
route do default
route add default dev ppp0.
Neste segundo caso, ppp0, é o de inet, o da palm então séria de ppp1.
em adiante.
e como pap-secrets de exemplo:
quasar * password *
NOTA: os * são necessários.
Uma vez feito todo isto (muito embaraçoso de explicar, muito fácil de realizar)
teremos uma conexão ppp com a palm. Só há que lhe dar ao connect da
palm para que funcione...
Passemos à explicação com FreeBSD e logo exporei dados curiosos e
conclusões....
c) ppp + palm + FreeBSD
A configuração para a conexão da palm e a Free é muito similar à de
Linux, mas não igual. Aliás, pela pouca documentação existente quase os
mesmos passos custaram um pouco mas.
Para começar, e ao igual que em Linux, precisámos que o kernel traga
suporte para gateway osease, firewalling e forwarding.
options INET #InterNETworking
options IPFIREWALL #packet filtering
options IPFIREWALL_VERBOSE #logging of packets through syslogd
options IPFIREWALL_VERBOSE_LIMIT=10 #num max logging packets
O resto de opções necessárias já vêm no fichero de conf do núcleo
genérico. As três ultimas se devem de pôr porque com o generico, por o
menos na versão 4.0 da FreeBSD, não vêm.
Na opção:
options IPFIREWALL_VERBOSE_LIMIT=10.
o numero séria acertado que estiver entre 10 e 100.
Agora creiamos o enlace simbólico já comentado anteriormente:
ln -s /dev/pilot /dev/ttyd0 (ou ttyd1)
E ativámos a opção de forwarding. Duas maneiras:
a) Adicionar linea: gateway_enable="YES" ao fichero
/etc/rc.conf
b) Ou desde a shell: sysctl -w net.inet.ip.fw.enable=1
A diferença reside em que com o a) esta já para sempre ativado, não assim em
o b) que terá que teclearlo cada vez que se acenda o computador.
O curioso da FreeBSD é que quando se ativa a opção de firewalling, o
núcleo, por defeito, pilha o file por defeito de etc / que
normalmente filtra todos os pacotes de todos os dispositivos e não
deixa passar absolutamente nada por nenhum lado. NÃO como em linux. Pelo que nos
toca dar um passo intermédio.
Duas opções pois. A primeira é modificando a configuração script do
firewall. Um exemplo vem a continuação.
No fichero /etc/rc.conf temos que adicionar o seguinte:
gateway_enable="YES"
firewall_enable="YES"
firewall_script="/etc/firewall/fwrules"
A primeira linha já a tínhamos posto anteriormente. Nas outras duas, a
primeira nos permite trabalhar com ipfw (ipchains em linux) e a segunda
permite-nos passar-lhe as rules ao ipfw desde um file (ipchains-restore em linux)
Uma vez adicionadas estas lineas creiamos diretório em etc /chamado 'firewall':
mkdir /etc/firewall
e creiamos ali o fichero 'fwrules' que vai conter:
--- CUT ----
# Firewall rules
# QuasaR of UNDERSEC Security Team
# Obrigado a Marc Silver ([email protected])
# Definimos um alias sobre o que trabalhar
fwcmd="/sbin/ipfw"
# Apagamos as rules que possamos ter estabelecidas de antemão. Nunca se
# sabe e asi nos poupámos um ovo de problemas.
$fwcmd -f flush
# E agora vou a piñon, deixo-o passar absolutamente todo
$fwcmd add allow ip from any to any via o0.
$fwcmd add allow ip from any to any via ed0.
$fwcmd add allow ip from any to any via ppp0
--- EOF ----
Se, já se que deixei passar todo. Mas é que não me quero enrolar agora
explicando rules e tal. Que cada um se o faça a medida.
A segunda opção é mas rápida e possivelmente pratica, mas menos
segura. Há que recompilar o kernel com a opção:
options IPFIREWALL_DEFAULT_TO_ACCEPT
Agora já podemos executar o pppd ao serial. Funciona exatamente igual
que em linux. Pelo que a opção séria (mas info ver seção linux):
pppd /dev/pilot 57600 :ipdepalm local crtscts passive proxyarp noauth
E com isto, a palm deveria de funcionar perfeitamente. Salvo bagunças com as
rotas estáticas do route. Estai atenciosos. Mas já digo que deveria de
funcionar. Só lhe faz defeituosa o connect da palm para que se conecte.
CURIOSIDADES
Uma vez conectada a palm ao computador, em plataformas windows não permite
encontrar a palm como um dispositivo a parte do próprio windows.
No entanto , não ocorre igual desde o resto de plataformas.
No resto de plataformas (entenda-se Linux e FreeBSD) ao atribuir-lhe uma ip
e inclusive uma direção MAC à palm, esta se considera como um dispositivo
aparte, podendo-se aceder através da ip. Isto nos permite usar scaneos,
pings, traceroutes e qualquer outra utilidade de rede contra a palm. E é
então quando nos encontrámos com as coisas mas curiosas.
É divertido ver como um traceroute desde a RH passa pela FreeBSD e
chega até a palm. Ou o caminho contrário, Ver como a palm acede ao IRC
desde a FREEBSD passando por NAT pela RH.
Ejemplillo?:
NÓTESE que estou desde quasar (RH) passa por nekroid (FreeBSD) e chega a
INET.
%[root@quasar ]# traceroute palm
traceroute to palm.undersec.org (192.168.2.5), 30 hops max, 38 byte packets
1 nekroid (192.168.2.4) 2.212 ms 1.129 ms 1.233 ms
2 palm (192.168.2.5) 35.443 ms 36.549 ms 34.745 ms
%[root@quasar ]#
Mas cosillas. A palm é agora um terminal na rede e claro, suporta tcp.
MMMMMmm... sera nukeable?. Correto se. Qualquer nuke com igmps ou flood deixa
a palm completamente torrada!. A pilha TCP/IP não é nenhuma maravilha e claro
sai a reluzir. Aliás, até um scanneo de fingerprints do nmap a deixa
torrada.
Falando de tostamientos, recomendo a utilidade crash.prc que detecta um crash
e resetea a palm em quente por ti, sem dar-lhe a volta e dar-lhe ao
boton de reset. Busquese a susodicha utilidade em http ://www.palmgear.com
por esse mesmo nome.
Podria seguir explicando cosillas, como o das passwords vulneráveis em
o backup da palm no file Unsaved_Preferences.prc mas quase que isto
é outra história.... ;)
CONCLUSÕES
O bichito chamado palm é uma maravilha e eternamente flexível ainda que deve
ficar claro que esta concebida como agenda pessoal e nunca há que esquecer
essa idéia.
As provas deram sempre resultado positivo. Realizaram-se com os
os elementos indicados a continuação:
Palm V - Palm VOS 3.3
FreeBSD 4.0 STABLE
Linux Debian 2.2.17.
AGRADECIMIENTOS E SAUDAÇÕES
Pois tenho que agradecer eternamente aquelas primeiras provas que se fizeram
na benagua party com o superportatil a Pope.
Tenho que agradecer quase o resto das provas sobre Linux a Sp4rk e sua
Debian chunga quando a Hackmeeting.
Tenho que agradecer a minha mãe que me desse pelas para poder ir aos lugares
anteriores e poder ter feito as provas.
E tenho que agradecer a pessoas mas indirectas o dar animos quando estas em
momentos de bajon e sem vontades de fazer nada... Neko^_^ , Raise :*
E agora as saudações: UNDERSEC :* (http://www.undersec.com) & Netsearch
(http://www.netsearch-ezine.com) ..... guarris!
DESPEDIDA
Espero que o articulo sirva a muitas pessoas e contribua para que alguém
não se tenha que deixar os cornos mas....já mos deixei eu.
Para qualquer sugestão ou dúvida estou em: [email protected] até que
voe-me o correio.
Ta outra....
----
Original: 25 - Outubro - 2000.
1ª Revisão: 22 Dezembro - 2000