Tuesday, 19 May 2020

youtube-dl (how to) - best guide to get you started

####################################################################
###        youtube-dl - the best guide to get you started        ###
###                                                              ###

>> Installing
[Note]: Before you start; 
If you have upgraded to Catalina (on never have installed xcode and gcc before), then you will need to:
install Xcode (from Apple's App Store), then run the command: xcode-select --install 
then install gccand then install youtube-dl

[TIP]: You must run brew update first. Then you can either use the brew upgrade to update all packages, or, run brew upgrade youtube-dl to update only youtube-dl

//To install youtube-dl [1] under MacOS use:
brew install youtube-dl

//Once it is installed, update the application:
sudo youtube-dl -U

Friday, 1 May 2020

Re-encode screen recordings to work in iMovie

There was a case where I did some screen recordings but iMovie refused to see the video files .mp4 format. Video captures can be very useful as proof-of-concept and/or evidence of actions performed, for example during a security assessment, such as penetration testing sessions. 

In my case, it was showing only a "green screen" instead of what it was actually captured during the screen recording. Bear in mind that VLC could play the video file without any issues, but when loaded in iMovie, the same video file was failing to show properly.

If you have ffmpeg installed on your MacOS, you can very easily fix this problem, by re-encoding e.g. from an .mp4 file to a .mov file. 

Keep in mind, simply changing the "container" from an .mp4 video to .avi/.mov in most cases won't fix your problem. Hence, doing something like the following, as many others advice online, it will simply not work for you:
- ffmpeg -i Video.mp4 -c copy Video.mp4
- ffmpeg -i Video.mp4 -acodec copy -vcodec copy -f mov Video.mov


Re-encoding however, will fix your problem and ensure that iMovie can see the video as they were captured:

ffmpeg -i ScreenRec.mp4 -c:v libx264 -preset fast -profile:v baseline outRec.mov 

Of course, if you want to keep the same format, you can do:

ffmpeg -i ScreenRec.mp4 -c:v libx264 -preset fast -profile:v baseline outRec.mp4


Sunday, 26 April 2020

New iOS text bug (aka text bomb) can crash your iPhone

A newly discovered bug is capable of crashing your Apple iPhone or iPad by simply receiving a text notification. The bug occurs when an iOS device user receives a text message or tries to read a tweet which is written using some Sindhi characters. 
This type of bug is known as a "text bomb", because a malicious individual can use it to prank, bully, cause Denial of Service (DoS), or even "troll" their targets by constantly forcing the receiver's app to crash. The original message sent had the Italian flag in it and it was using the hashtag: #CaptureTheFlag. 

It is being reported from different sources on social media that the text message other that your iPhone it also may crash your iPad, Apple Watch, and other Apple Gadgets.

The text bomb looks like any of the following group of Sindhi characters with any emoji in between: 
For obvious reasons I had to take a screenshot so not to be held responsible for propagating this. It was tested and it works. 


Text bombs aren’t something new. There have been numerous cases in the past few years where  random strings of text have caused mobile devices to behave in an unexpected way. However, this one is slightly different as it will crash the iPhone to crash if the phone received a message or notification in any social media chat applications. Unfortunately there is nothing much a user can do to avoid this other that wait to install the new update from Apple. The issue seems to be affecting  all Apple's mobile OS version from 13.3 onwards. 

Note: If you receive this type of message use alternative means, e.g. through your Mac laptop or Twitter app under Windows, to delete the received/posted message. This will allow your phone to be able to have access to the affected app without being forced to crash. If you phone hangs completely, you will need to keep pressing the power and volume up keys, until it reboots.

Sunday, 5 April 2020

Ping an IP range from the command line interface (CLI)

If you ever wanted to do host discovery while no specific network scanning tools were available (e.g. nmap), or you wanted to avoid creating a script file (e.g. due to having no write permissions)? Here are a couple of useful commands depending on the OS of your choice:

Windows OS:
for /L %i IN (1,1,254) DO ping -n 1 -w 1 192.168.1.%i| FIND /i "Reply" >> IPs.txt

Note: command prompt has a limitation when asked to return the exact string using regex and returns the whole line. Here is an example of replacing find with findstr in order to use a regular expression (regex). 
findstr /r "[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*"

The regular expression can still be useful in cases such as:
ipconfig | findstr /r "[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*"


Linux OS:
for i in {1..254}; do (ping -c 1 -i 1 192.168.1.$i >/dev/null && echo "192.168.1.$i" &); done

Note: The above command will only list the discovered IP address, without any additional text.

Tip/Trick: Did you know you can use apr to achieve the same results but much faster. This seems to be reliable under Linux. The following command will list the discovered host on your network, including any additional information per IP (including the IPv6 address).
for ip in $(seq 1 254); do arp -n 192.168.1.$ip | grep on; done

The following command however, will list only the IP addresses without any additional text (also avoiding to specify the IP range twice)
for ip in $(seq 1 254); do arp -n 192.168.1.$ip | grep on | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' ; done

Friday, 3 April 2020

Awareness around COVID-19 SMS Phishing (Smishing)

This blog-post discusses an issue known for almost 20years, which is related to the online SMS platforms. Given the recent pandemic and the use of the GSM network for sending SMS notifications to the public, it in an opportunity to raise awareness regarding Smishing (SMS Phishing) attempts, targeting the public which is affected by COVID-19.


In Greece, the number 13033 is being used to send SMS confirmations to people who use this particular service, which is used for registering in advance their daily movements when it comes to get essential goods (such as, going to the supermarket, the pharmacy, etc.) before they exit their homes. Due to the COVID-19 pandemic, this process attempts to limit people’s unnecessary movement(s), in an attempt to minimise the risk of getting affected, or contaminating others in case the person is a carrier of the virus.

Given the importance of the pandemic and the necessity of this service, it is mandatory to mention that it is possible to spoof the SEND ID in order to send SMS updates to recipients pretending to be from the original 13033 service number. This action, have the potential to trick the recipients (general public) in clicking on malicious links, or by using Social Engineering (and potentially scare tactics) to ask recipients to pay a fine that has been imposed. 

"Given the current situation, it would be beneficial to everyone if the Ministry in Greece responsible for operating the 13033 service (and other Ministries around the globe that use similar services), could promote a campaign educating all recipients regarding the potential threat of Smishing"

More specifically, the public should be informed that they should under no circumstances visits any URLs received by the 13033 service and that the 13033 service will not send any messages requesting to pay any finesThe public need to be aware that in case they receive such messages, these should be ignored and deleted.  

The proof of concept for the alluded was tested and proven by @DimisMeu and we decided to publish this blog post in order to be able to raise the necessary awareness.