Thursday, May 7, 2020

EvilSSDP: Cómo Poner Dispositivos Maliciosos En La Red En Un Ejercicio De Red Team

El año pasado presentamos en BlackHat Europe 2019 una herramienta llamada HomePwn. A finales de 2018 estuve estudiando un poco el funcionamiento del protocolo SSDP. Un protocolo que sirve para que las máquinas puedan descubrir de manera sencilla otros dispositivos en una red. Es fácil, cuando cualquier usuario se compra, una tele, bombillas inteligentes, un NAS, una tostadora conectada a Internet, etcétera, tiene que existir un procedimiento sencillo para que los dispositivos se encuentren y conozcan los servicios que otros ofrecen.

Figura 1: EvilSSDP: Cómo poner dispositivos maliciosos en la red en un ejercicio de Red Team

Empecé a estudiar el SSDP gracias al ChromeCast, otro dispositivo de "conéctame a una red" y disfruta. Aquí surgió HomePwn, aunque algunos no lo sepan, y fue así como se hizo una prueba de concepto en Ruby. Más tarde, llevé el proyecto a mis compañeros de Ideas Locas donde se hizo un gran trabajo. El objetivo de HomePwn principal era aprovechar este tipo de protocolos y otros para enumerar dispositivos en una red, sobretodo, dispositivos que no fueran ordenadores al uso. El objetivo era integrar módulos de Ethical Hacking para dichos dispositivos.

Figura 2: HomePwn Paper

Más tarde, fueron surgiendo nuevas ideas y llegó la idea del pentesting a todos esos dispositivos que puedes tener en una empresa, que utilizan tecnologías que están en un nuestro día a día, pero que van más allá de un simple pentesting a una máquina al uso. Aparecieron módulos para tratar BLE, para jugar con NFC. HomePwn creció y llegó a BlackHat con un gran número de módulos y pruebas que mostraban el potencial de la herramienta. En el siguiente video se puede ver la demo de BlackHat con HomePwn.


Figura 3: Demo de HomePWN en BlackHat

En el artículo de hoy quería reflexionar sobre una de las opciones que se barajó con HomePwn y, que después de ver esta herramienta, se puede incorporar de manera sencilla. La herramienta EvilSSDP .

EvilSSDP

Esta herramienta implementa una prueba de concepto, mezclando el spoofing con el phishing con un objetivo: capturar credenciales mediante el spoofing de dispositivos en una red empresarial. La idea es muy interesante, ya que se abusa del protocolo SSDP para anunciar que hay un dispositivo en la red, cuando realmente éste no es tal.

Figura 4: EvilSSDP en GitHub

Es la herramienta EvilSSDP la que está "comportándose" como un dispositivo de red que no es. Cuando el usuario accede a dicho dispositivo se encontrará con un panel de login, digamos que "el que toque" en función de la plantilla o "spoofing" hecho.
Figura 5: Libro de "Empire: Hacking Avanzado en el Read Team" de 0xWord

Como se puede ver la idea es sencilla, pero bastante potente de cara a un Ethical Hacking o un ejercicio de Red Team. Como se indica en la descripción del proyecto EvilSSDP permite hacer spoof sobre SSDP y crear dispositivos UPnP "fake". El objetivo es "robar" credenciales e incluso jugar con el protocolo SMB para credenciales de red, en ese caso.

Probando EvilSSDP

La instalación es trivial, simplemente hacer un git clone sobre la URL y tendremos descargado EvilSSDP. Es importante que tengamos Python3 en el equipo, ya que es un requisito. Viendo la ayuda de la herramienta, tal y como se puede ver en la imagen donde lo hemos instalado en nuestro Kali Linux, queda claro la sencillez de la herramienta.

Figura 6: EvilSSDP en nuestro Kali Linux

La herramienta trae una carpeta denomina templates. Esta carpeta muestra las diferentes plantillas que pueden ser utilizadas para spoofear dispositivos. Este es el mecanismo por el que la herramienta puede crecer. Crear plantillas es algo sencillo y que, simplemente, con incluir en dicha carpeta estaría preparado. Al final, cada template consta de:
- El fichero XML device. Aquí viene la descripción de la lista de servicios y la URL de presentación. Apunta también al fichero present, en el tag "presentationURL". 
- El fichero XML service. 
- El fichero HTML present. Es la web que se presentará y que será el phishing.
Visto. Como se puede ver es fácil crear un dispositivo "fake". Lo que hay que hacer es generar el spoof en la red, pero esto no es complejo, hay que generar el tráfico SSDP dando a conocer dicho dispositivo. Los replies se generan cuando hay peticiones de descubrimiento del SSDP, por lo que cuando el usuario acceda a "Network" en un sistema Windows, éste hará el descubrimiento automático y nuestro EvilSSDP responderá.

Lanzando EvilSSDP

Ahora vamos a probar a lanzarlo. Lo primero va a ser crear un dispositivo "fake" de escáner. El típico recurso como una impresora o escáner que podemos tener conectado a la red local en cualquier sitio. La sintaxis de ejecución es muy sencilla:
evil_ssdp.py [interfaz de red] –template [template a utilizar]
Figura 7: Usando la template scanner

En este instante, ya tenemos EvilSSDP en activo. En la siguiente imagen, se puede ver el anuncio y vemos una petición que viene de la dirección IP 10.0.0.2. Esa máquina es un Windows 7 que tenemos preparado. Se puede ver fácilmente, por el User-Agent que utiliza. Solicita la descripción a través del GET.

Figura 8: El usuario hace clic

Cuando el usuario haga clic sobre el dispositivo, se abrirá un navegador y se redirige a la URL de la directiva "PresentationURL" del fichero device.xml. En ese momento, se le presenta una web falsa que, en caso de que el usuario introduzca datos, estos son recogidos. Este tipo de técnica puede ser muy útil en un Ethical Hacking o en un ejercicio de Red Team, como comenté anteriormente. En la imagen siguiente se pueden ver las credenciales introducidas en el navegador del  equipo cliente con Windows 7 en el apartado de  "[CREDS GIVEN]".

Figura 9: Redirección a la URL controlada y Credenciales obtenidas

Ahora vamos a hacer un ejemplo con Office365. La plantilla que viene en EvilSSDP es para spoofear un Backup Online de Office 365. El procedimiento es igual que el anterior, solo que cambiando la plantilla. Como se puede ver en la imagen, veremos un dispositivo llamado "Office365 Backups".

Figura 10: Falso dispositivo de Office365 backups

Si hacemos doble clic en ese dispositivo se nos abrirá un navegador con la siguiente web. Se puede ver fácilmente el ataque de phishing (o no) por la dirección URL. Pero... ¿tienes a todos tus usuarios entrenados para descubrir el ataque?

Figura 11: Phishing de Office365 en la red local

Al introducir credenciales obtendremos algo parecido a lo que hicimos antes. En la siguiente imagen se puede ver todo el intercambio de mensajes que nos da la aplicación con este caso. De nuevo, vemos el CREDS GIVEN.

Figura 12: Captura de credenciales en el ataque de Phishing

Lo más interesante de todo es proceso es el potencial que tiene esto en un Ethical Hacking o ejercicio de Red Team, ya que puede ser utilizado para encontrar caminos en el test de intrusión que antes no teníamos. Los vectores "no comunes" pueden aportar una gran cantidad de casos de éxito, ya que la concienciación y el conocimiento de las empresas pueden ir en su contra ante el pentester.
Figura 13: Hacking Windows

Sin duda, curiosa técnica de Hacking Windows que debemos controlar y, además, la herramienta permite fácilmente reutilizarla para el caso de trabajo que tengamos entre manos. Es decir, si estás en un pentesting y tienes que hacer uso de ella, pero la plantilla o el caso de uso que necesitas no está, puedes fácilmente incorporarlo. Metemos la herramienta EvilSSDP en la mochila del pentester.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  "Pentesting con Powershell" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 14: Contactar con Pablo González

Related news
  1. Google Hacking Database
  2. Hacking Web
  3. Live Hacking
  4. Hacking Ethical
  5. Hacking Desde Cero
  6. Que Estudiar Para Ser Hacker

Tuesday, May 5, 2020

LEGALITY OF ETHICAL HACKING

Why ethical hacking?
Legality of Ehical Hacking
 
Ethical hacking is legal if the hacker abides by the rules stipulated in above section on the definition of ethical hacking.

Ethical hacking is not legal for black hat hackers.They gain unauthorized access over a computer system or networks for money extortion.
More information

OWASP ZAP Project - Zed Attack Proxy Team Releases Two Initiatives

The Zed Attack Proxy team is pleased to announce two recently released initiatives:


ZAP In Ten

The team have just launched a new series of videos called 'ZAP in Ten' in conjunction with AllDayDevOps.

ZAP in Ten is a series of short form videos featuring Simon Bennetts, project lead of the OWASP Zed Attack Proxy (ZAP)  project. Each video highlights a specific feature or resource for ZAP.

ZAP API Docs

As part of OWASP's participation in Google's Season of Docs, the ZAP project has had @sshniro working on API documentation. The first iteration of the documentation is now live.  It includes Java, Python, and shell example snippets all presented in a responsive and accessible design. Which we will continue to build on in the future.

Big thanks to Nirojan for his efforts on this wonderful initiative!  Congratulations and thanks to Google Open Source for helping to bring the open source and technical writer communities together!

Continue reading


  1. Growth Hacking Barcelona
  2. Curso Completo De Hacking Ético
  3. Hacking Linkedin
  4. Herramientas De Seguridad Informatica
  5. Herramientas Growth Hacking
  6. Hacker Seguridad Informática
  7. Hacking The Art Of Exploitation
  8. Hacking Health
  9. Definicion De Cracker
  10. Tutoriales Hacking
  11. Cracker Definicion
  12. Programa De Hacking
  13. Ultimate Hacking Keyboard
  14. Que Es Hacking Etico
  15. Curso De Hacking
  16. Marketing Growth Hacking

What Is Brave Browser And How Does It Compares To Chrome ?

       There are more competing web browsers than ever, with many serving different niches. One example is Brave, which has an unapologetic focus on user privacy and comes with a radical reimagining of how online advertising ought to work.

Brave is based on Chromium, the open-source code that forms the basis for Google Chrome. But is it any good? And for those using Google Chrome, is it worth switching to Brave?

A Brief History of Brave

When Brendan Eich and Brian Bondy founded Brave in 2015, they wanted to address what they perceived as the biggest problem with the modern internet: intrusive advertising.

Advertising is the fuel that powers the modern internet, allowing websites and digital creatives to monetize their content without charging users for each article read or every video watched. That said, Eich and Bondy think it's got some pretty significant downsides, citing the potentially privacy-harming nature of advertising trackers, as well as the negative impact it has on the overall user experience.

Brave's first release came about amidst two significant trends, which ultimately defined the new browser.

First, the cryptocurrency revolution was in full swing. Companies and individuals alike—like the pseudonymous Satoshi Nakamoto—were creating their own decentralized cryptocurrencies, which quickly reached billion-dollar market capitalizations. Second, ad-blocking technology entered the mainstream. By the decade's halfway point, millions of people were blocking ads online across all browsers, desktop, and mobile.

Brave was one of the first browsers to include built advertisement and tracker blockers, leapfrogging the likes of Opera. It also came with its own cryptocurrency, called BAT (or Basic Attention Token), allowing users to reimburse the sites and creators they like.

Essentially, Brave wants to re-imagine how the Internet works: not just on a usability level, but on an economic level. It's an undeniably radical vision, but you wouldn't expect any less, given its founding team.

Brendan Eich is the inventor of the JavaScript programming language and co-founded the Mozilla Foundation, which created the popular Firefox web browser. He also briefly served as the foundation's CEO before resigning following a bitter controversy over his political donations. Brian Bondy is also ex-Mozilla, and spent time at education startup Khan Academy.

Beyond that, Brave is a reasonably standard browser. Like Edge, Chrome, and Opera, it's built upon the Blink rendering engine, which means webpages should work as you expect. Brave is also compatible with Chrome extensions.

To Track or Not to Track?

The Brave browser is characterized by an unapologetically pathological focus on user privacy. Its primary mechanism for delivering this is something called Brave Shields, which combines traditional tracker-blocking technology, paired with several under-the-hood browser configuration tweaks. This feature is turned on by default, although users can easily de-activate it should it cause websites to break.

As you might expect, Brave blocks trackers based on whether they appear in several public blocklists. Going beyond that, it also uses cloud-based machine learning to identify trackers that slipped through the net, in addition to browser-based heuristics.

Brave Shields also forces sites to use HTTPS, where both an encrypted and unencrypted option is available. By forcing users to use an encrypted version of a website, it makes it harder for those on your network to intercept and interfere with the content you visit. While this sounds abstract, it's more common than you think. Public Wi-Fi hotspots, like those found in airports, routinely inject their own ads into websites being visited. Although upgrading to SSL isn't a silver bullet against all security and privacy, it's a pretty significant security upgrade.

Separately from Shields, Brave also includes a built-in TOR browser. TOR allows users to circumvent local censorship — like that which occurs on a national or ISP level — by routing traffic through other computers on its decentralized network.

The tool, which was funded by the US Department of Defence, is frequently used by dissidents living under authoritarian governments to escape surveillance and censorship. Both Facebook and the BBC offer their own TOR 'onion' sites for this reason. Somewhat of a double-edged sword, it's also used by bad actors — drug dealers, hackers, and other online criminals — to operate free from the scrutiny of law enforcement.

Going Batty for BAT

As mentioned, Brave uses its own cryptocurrency, called BAT, for rewarding websites for the content they appreciate. Microtransaction-based tipping is nothing new. Flattr pioneered it almost a decade ago. What's different about BAT is both the implementation and the scale.

While Flattr used traditional fiat-based currencies (by that, I mean currencies like pounds, dollars, and euros), Flattr has its own fungible (essentially, convertible) cryptocurrency based on the Ethereum blockchain. And, as a browser with mainstream aspirations, Brave can deliver this concept to millions of people.

So, let's talk about how it works. Firstly, it's entirely optional. Users can choose to use brave without even touching the BAT micropayments system. By default, it's turned off.

If you decide to opt-in, users can purchase BAT through a cryptocurrency exchange, like Coinbase. They can also earn it by viewing "privacy-respecting" ads. Rather than traditional banner-based advertising, these present as push notifications. Users can choose to dismiss a notification or view it in full-screen.

Unlike traditional advertising networks, the calculations determining what advertisements to show you are performed on your own device. This means the advertiser isn't able to build a profile of you and your interests.

Of all advertising revenue that Brave receives, it shares 70 percent with users, keeping a 30 percent share. It's also worth noting that Brave's advertising program is only available in a handful of countries, mostly scattered across Europe and the Americas, plus Israel, India, Australia, South Africa, the Philippines, Singapore, and New Zealand.

Once you have some BAT, you can spend it. You can choose to automatically contribute to specific sites or tip creators on an ad-hoc basis. You can even tip individual tweets. When you open Twitter through your browser, Brave will automatically add a button to each post within your newsfeed. Pressing it will open a drop-down window, where you confirm your tip.

The sites accepting BAT include The Guardian, The Washington Post, and Slate, as well as popular tech publications like Android Police and The Register. Brave also plans to allow users to spend their rewards for more tangible rewards: like hotel stays, gift cards, and restaurant vouchers. At the time of publication, this system isn't yet available.

How Does Brave Compare to Google Chrome?

Google Chrome commands the majority of the browser market, with other competitors, including Brave, trailing behind. Independent figures about Brave's adoption aren't readily available. It doesn't show on NetMarketShare or W3Counter, as it uses Chrome's user-agent string. In October, however, the company behind Brave reported eight million monthly active users and 2.8 million daily active users.

While that's pocket change in the broader Internet ecosystem, it's still fairly impressive for a young company that's trying to disrupt a market dominated by a small handful of well-entrenched players, like Mozilla, Google, Microsoft, and Apple.

Brave promises to be faster and less energy-intensive than rival browsers, and it delivers on this. Scientific benchmarks, plus my own anecdotal experiences, pay testament to this. Furthermore, when you open a new tab, Brave shows you how much time you've saved by using it.

However, there are small annoyances you perhaps wouldn't get with other browsers. Functionality that comes standard in Chrome, like the ability to automatically translate webpages, is only available through plug-ins.

You also occasionally encounter webpages that force you to "drop" your shield to access it. And while this isn't Brave's fault, it does highlight the fact that a huge part of the conventional Internet isn't quite prepared to embrace its utopian vision of how content should be monetized.

A Brave New World?

Should you ditch Google Chrome for Brave? Maybe. There's a lot to appreciate about this browser. While it's generally fast, it also feels extremely polished. I appreciate the fact that it comes with both light and dark themes and the ease in which it allows users to protect their privacy from cross-site trackers.

But Brave is more than a browser. It's a statement about how the Internet should work. And while most people will agree that the pace and scale of online tracking should be rolled back, many may disagree whether cryptocurrencies are the best way to monetize content that is otherwise funded by traditional in-browser advertising. And are push notification-based advertisements on your desktop really a less irritating form of advertising?

Ultimately, the question is whether you agree with Brave's approach or not.

@£√£RYTHING NT

Continue reading


  1. Hacker Pelicula
  2. Curso Hacking Gratis
  3. Como Ser Hacker

Hacking Everything With RF And Software Defined Radio - Part 3


Reversing Device Signals with RFCrack for Red Teaming


This blog was researched and automated by:
@Ficti0n 
@GarrGhar 
Mostly because someone didn't want to pay for a new clicker that was lost LOL

Websites:
Console Cowboys: http://consolecowboys.com 
CC Labs: http://cclabs.io

CC Labs Github for RFCrack Code:
https://github.com/cclabsInc/RFCrack


Contrived Scenario: 

Bob was tasked to break into XYZ  corporation, 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. 

Items used in this blog: 

Garage Remote Clicker: https://goo.gl/7fDQ2N
YardStick One: https://goo.gl/wd88sr
RTL SDR: https://goo.gl/B5uUAR


 







Walkthrough Video: 




Remotely sniffing signals for later analysis: 

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. We need 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. 

Destroy:RFCrack ficti0n$ python RFCrack.py -k -f 310000000 315000000 390000000
Currently Scanning: 310000000 To cancel hit enter and wait a few seconds

Currently Scanning: 315000000 To cancel hit enter and wait a few seconds

Currently Scanning: 390000000 To cancel hit enter and wait a few seconds

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

Destroy:RFCrack ficti0n$ cd scanning_logs/
Destroy:scanning_logs ficti0n$ ls
Dec25_14:58:45.log Dec25_21:17:14.log Jan03_20:12:56.log
Destroy:scanning_logs ficti0n$ cat Dec25_21\:17\:14.log
A signal was found on :390000000
c0000000000000000000000000008000000000000ef801fe003fe0fffc1fff83fff07ffe0007c0000000000000000000000000000000000000000000001c0000000000000000050003fe0fbfc1fffc3fff83fff0003e00000000000000000000000000000000000000000000007c1fff83fff003fe007fc00ff83fff07ffe0fffc1fff8001f00000000000000000000000000000000000000000000003e0fffc1fff801ff003fe007fc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000001f07ffe0dffc00ff803ff007fe0fffc1fff83fff07ffe0007c000000000000000000000000000000000000000000
A signal was found on :390000000
e0000000000104007ffe0000003000001f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c00000000000000000000000000000000000000000000e0007f037fe007fc00ff801ff07ffe0fffe1fffc3fff0001f00000000000000000000000000000000000000000000003809f641fff801ff003fe00ffc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000003c0bff01bdf003fe007fc00ff83fff07ffe0fffc1fff8001f0000000000000000000000000000000000000000000000380000000000000000002007ac115001fff07ffe0fffc000f8000000000000000000000000000000000000000



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: 

Destroy:RFCrack ficti0n$ python RFCrack.py -n -g -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c
-n = No yardstick attached
-g = graph a single signal
-u = Use this piece of data




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:

  1. down down up up up down down down down
  2. 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 analyze  RF 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. 
Related links

Friday, May 1, 2020

Download Naruto Shippuden Ultimate Ninja Storm 4 Road To Boruto For PS4

Download Naruto Shippuden Ultimate Ninja Storm 4 Road to Boruto For PS4

FPKG | CUSA06210 | Update v1.02 | 

  • Release Date: Out Now
  • Genre: Action / Fighting
  • Publisher: BANDAI NAMCO Entertainment Inc.
  • Developer: CyberConnect2 Co., Ltd.









With more than 13 million NARUTO SHIPPUDEN™: Ultimate Ninja® STORM games sold worldwide, this series has established itself among the pinnacle of Anime & Manga adaptations to videogames! NARUTO SHIPPUDEN: Ultimate Ninja STORM 4 Road to Boruto concludes the Ultimate Ninja Storm series and collects all of the DLC content packs for Storm 4 and previously exclusive pre-order bonuses! Not only will players get the Ultimate Ninja Storm 4 game and content packs, they will also get an all new adventure Road to Boruto which contains many new hours of gameplay focusing on the son of Naruto who is part of a whole new generation of ninjas.
• All Ultimate Ninja Storm 4 Content in One Edition – Includes the Ultimate Ninja Storm 4 game, 3 DLC packs from the Season Pass (Gaara's Tale Extra Scenario Pack, Shikamaru's Tale Extra Scenario Pack, and the Sound Four Extra Playable Character's Pack), the all new Road to Boruto DLC, and all the previously exclusive pre-order bonus content
• New Generation Systems – With development made specifically to leverage the power of PlayStation®4. Road to Boruto will take players through an incredible journey of beautifully Anime-rendered fights!
• Huge Character Roster and New Hidden Leaf Village – Additional playable characters including Boruto, Sarada, Mitsuki, and Sasuke (Wandering Shinobi) and a new setting of a New Hidden Leaf Village
• New Collection and Challenge Elements that extends gameplay


Storium Theory: Don't Count Yourself Out

Today, I'd like to spend a bit of time on something that I've seen here and there on Storium - cases where a person perhaps goes a bit too Weak with a Weakness play...and takes themselves out of a scene.

It feels right - it feels better than right, doesn't it? Isn't it a great expression of a Weakness to not just suffer a setback, not just suffer some kind of injury, but actually get knocked out or otherwise removed from play for a bit?

Well...it is, and it isn't.

Let's start off with the good: This is, undoubtedly, an example of a player being very willing to show his character suffering for his Weakness. That's great, and that's an attitude that I hope people learn on Storium.

But actually taking yourself out...getting knocked out, getting poisoned to the extent that you can't move, draining yourself so much of energy that you're too exhausted to go on...there are times these things are appropriate, but they need to be used with restraint.

Otherwise, they can mess with the flow of a story.

I've seen it happen: A battle happens, one part of a longer sequence of events all taking place in a short period of time. One player plays a Weakness card and portrays themselves as exhausted, or poisoned, or just plain knocked out cold. Then the battle ends.

Now a few things can happen:
  • Somehow, the player character recovers very quickly, and keeps on going, so the story can keep moving. That's unsatisfying, as it feels like a major moment is just brushed over and somewhat ignored.
  • The narrator puts in a point where the group can rest for a while to make it seem more realistic that the player character takes time to recover from his state...but now the story loses momentum.
  • The story goes on, and the player character is put someplace safe to recover in the meantime, which means:
    • The player misses out on part of the story, or...
    • The narrator has to come up with things that happen around wherever the player character was left that they can work with in their current state.
I'm not particularly fond of any of these options. If you address a Weakness play that severe, you're going to find your story either feeling like it doesn't address the weakness properly, losing its momentum, or going on temporarily without a player (which can be harmful both to that player's experience with the story, and to the game as a whole, given how Storium tends to work).

 Now...you can make this work. You can. A good narrator who is used to letting the players have heavy story control, especially, can make this work out great. Maybe the group has to stop to allow the player character to recover, but in the process, the problem they're trying to address worsens. Or maybe that's the next challenge: Can they find things to help the player quickly enough that the next challenges don't worsen in the meantime?

But the thing is, even though you can make this work...it just oftentimes ends up more trouble than it is worth to put in this strong of a Weakness play. You can get some great, great character moments and a strong feeling of struggle and danger and fading hope from injury or tiredness that still leaves the character able to go on to new fights.

Sometimes, that can be even stronger. If a character is knocked out, the group might stop to deal with that and then go on once he's recovered. If that happens, the knockout doesn't add as much tension to the story. If a character is injured or tired but still goes on, though, we see that in everything they do for the next few scenes - they're in a bad way, one arm too hurt to hold up their shield, or dragging themselves forward in the battle. It's powerful.

Stopping the story's progress can add some tension if managed properly, but continuing despite your wounds always adds tension.

I'm not saying that you should absolutely avoid major consequences as part of Weakness plays, mind! There are times when it is appropriate, entirely appropriate. Particularly late in the story, particularly when the narrator has told you this is the final battle, you might pull out these powerful Weakness plays. Because there - there - it won't make the story pause or lose momentum. It'll emphasize just how bad things are currently, just how much of a struggle it is for the characters...but there's nothing ahead that the players need to address.

Keep yourselves within the bounds of the challenge, but that is when you should be safer using some of these powerful Weakness concepts.

Before that? Before that, earlier in the story, don't go that far! Go lighter with what goes wrong...but use what goes wrong more. Pick up some kind of injury and carry it with you for the next few scenes, showing your character struggling with it. Show the tiredness that you're feeling, even as you struggle to move on.

Or almost encounter one of those points...and leave things open. Let someone else save you from them. Those can be amazing moments in a tale too.

Weakness plays don't have to be about solid, absolute consequences for your character. They can be about the threat of those consequences. They can be about what might happen if the battle isn't turned around. If you knock your character out, he's knocked out. That's certain. It's done. But if you put in the possibility, you're giving someone else the chance to write. And that's what Storium is all about - working with each other to write interesting or fun stories.

So I suggest pulling back from the solid a bit - work with possibilities. Get hurt and need help. Or, need help to avoid getting hurt. Get tired and struggle. Need someone's shoulder to lean on. Need someone to fight by your side. But unless the story really, truly demands it, don't get taken out entirely. That cuts off possibilities - like bluntly leaving in the middle of a conversation.

And if you're going to take yourself out at all, try not to do it while you still have card plays left for the scene! Hopefully narrators are taking my advice to not use up all their points, but still, it's useful if players keep open the option to play all their cards if needed.

Now, one more note here: I've already said that late in the story you might be fine pulling out heavier, solid consequences as part of a Weakness play if that's your thing. There are points earlier in the story where you might do that too. The narrator might even set them up specifically. If he does...go with it, obviously! If the Weak outcome is "you're all knocked out," well, that's what the outcome is, so do the normal thing with a Weak outcome if you get it and write your spin on that outcome! You get knocked out.

The narrator, obviously, will have planned for that possibility since he put it in the outcomes, right?

Similarly, you might find a situation where it feels like the consequences should be higher - where the outcomes suggest this battle or event is more dangerous than normal, or where you're already portraying your character in a bad way and it just feels like they should have something more solid happen to them on your next Weakness play. And that's fine...I just suggest that you consider talking to the narrator first. Remember, you're writing collaboratively: Check, when you're thinking about having something this major happen to your character, and work with the narrator to figure out how it can happen but still keep the story moving (and not exclude you as a player).

This isn't a solid "don't ever do this." I want to be clear on that. What it is is a caution: Be careful of how and when you do this. When a hero is solidly defeated in battle or exhausts herself in the service of a cause, that can be a great story moment. It's just important to make sure that it's the right time - and that it doesn't derail the story's momentum or leave it short of players in the process.