I think I read something about that but I do not know the details.

It fhat is true, that would be good news. Thanks for the info. 👍

There was an example of an ethical hacker that bought up old email-domain names of police offices, city councils (name of city changed due to Mercer) and so on. He received quit a few mails with quite sensitive data.

Well, let's look at this high-level. Let's look at how (say) FSK decoding is done. Let's concider a audio signal of 1200 and 2200 Hz.

From what I've seen of oldl RTTY machines, how it was done in the beginning was simply by filtering: you take the audio, create two audio filters, one at the low frequency and one at the high frequency. Then, on both outputs you do signal detection (AM demodulation) and you get two voltages. Compair them (or subtract one from the other) and you get your data.

Another option, if the two frequencies are sufficient close together and you can filter the signal that you only have that signal and no other stuff, if simply do FM demodulation. After all, FM modulation is that you take in a voltage and output a sinewave of a certain frequency. The higher the input voltage, the higher the frequency. So, invert that, if you input a signal of either 1200 or 2200 Hz into a FM demodulator, you will a voltage that is (say) 1 volt for the 1200 Hz tone and 1.5 volt for the 2200 Hz. Then set a threshhold at 1.25 volt (which you can determine by taking the average of all the voltages of -say- the last 10 seconds), and you can determine if you have received a "0" or a "1" tone.

Another option, if you work with an SDR and you have IQ data, if to first downconvert the audio. The middle between 1200 and 2200 Hz is 1700 Hz. Create a sinewave of -1700 Hz (yes, minus 1700 Hz, negative frequencies!) and mix it with the received signal. As a result, you will get a signal of either -500 Hz or +500 Hz. (*) FM demodulate that, and you get a negative or a positive voltage.

(*) 1200 - 1700 = -500, 2200 -1500 = +500

Now, in this case, the signal is quite far apart (7 KHz) and there are kind of other signals inbetween these two carriers. If you have a SDR, you can just take in the complete signal (say, sample at 20 Ksps), filtering out all the unwanted signals and then process it like any other FSK signal (as described above). Another option I guess would be to use two receivers (two sessions to a websdr), set one at 7.061 (500 Hz below the lowest) and the other at 7.067 (1500 Hz below the highest tone). Apply filtering that you remove all other signals. Your computer should then play out two tones: a 500 Hz for the lowest carrier and a 1500 Hz tone for the highest carrier. Mix and record the audio, and then then process it like a normal FSK signal.

Yes, .. signal-processing can be fun.

Ah. Concerning the signal itself and the meaning of the bits. I heared your latest podcast episode after I wrote my previous post. I agree. Perhaps it simply do not mean anything. We live in strange times, so it can be anything, .. or nothing :-)

Concerning this particular article, perhaps the vulnerability here are not a mallicious software packages, but the management of these software repo's.

Should it be possible to upload a package on a repo with 99% of the same name as one that already exists without some additional checks?

I run a small setup on a seperate server segment (2nd router behind my main router) so it is on the internet. I run nextcloud, an dendrite and conduit instance (matrix chat-server servers), a mastodon and go-to-social instance (fediverse), bitwarden (password manager), and others.

If there is a service that you do not want to be publically accessable by everybody but you do want to access from everywhere on the internet yourself, check out client-side TLS (https) certificates. The server does is accessable from the internet put only people who have a TLS certificate on their client signed by you can access it. For services that do not require incoming connections from other machines (e.g. nextcloud, bitwarden, ... but no federated services like matrix-chat or the fediverse) that is a very good option to protect your servers.

011111001101110001011101001100101010100100100010100001001101000111110101101001010011111100000001101101010001001011110010110001000110011000111000011000001110110000101011001001110011101010111111110110110011110001101011100100001111011101111010000010000001011 0111110011011100010111010011001010101001001000101000010011010001111101011010010100111111000000011011010100010010

Hi Otto,

First of all, it is just me or is the wav-file on your github repo actually empty (just 2 byes)?

Concerning the data you receive. Nice capture finding out it is a repetative pattern.

As said, I am not at all a SIGINT expert, but let's see how far we can go with this/

So, what next? Question 1: OK, we've got a repetative pattern, so it is probably a data packet that is repeated continuesly (or multiple data-frames that happen to be all the same) But where does the packet actually start?

One important thing about digitale communication to keep in mind when dealing with digital communication: synchronisation, synchronisation and even more synchronisation!

Although the transmission has a fixed bitrate (and hence, timing), the receiver will mever have exactly the same frequency as the transmitter, so it must continuously adapt it own timingf to that of the transmitter. It does that by looking for bit-transistions and correct any error of its onw timing to that. So what you really want to avoid is large number of all-zero and all-one patterns, or at least, in actual data of the frame.

If you look at the bitstreaming, you see that '0000000 ... 1101101010' pattern.

The 7 consecutive 0 bits probably are a no-data indication.

The following bits are -I guess- the 'start of frame' pattern that indicates .. well, the start of the frame. Note that there are a lot of 0-1 alternations in that pattern. That helps the receiver synchronise itself to the received bitstream. The slight variation on it (i.e. the additional ´1' in front of it) might be there to avoid 'false positive' start-of-frame detections.

Now, as for the rest of the packet. As you have only one single packet, it is very difficult to determine its exact meaning. For that, you need to have multiple packets with different data in it.

Hope this helps a bit

edit: Hum .. just noticed there is actually a 8 all-1 bit pattern in the fransmission. A 2nd marker pattern ? strange!

Kristoff (ON1ARF)

I used inspectrum mainly with raw IQ-files from gqrx, so the c16 format is indeed correct.

For me, the great thing about the tool is that it is very visual. (*)

It allows you to get an idea what kind of signal you are looking at (on-off, FSK, PSK, ...) and get a rought idea about timing. That then gives you information to better apply the proper filtering in urh and work from there on. It also allows you to see any "abnormallities" .. e.g. I once came across a signal that sounded to be two-tone FSK, but after closer investigation, you could see that the two tones overlapped (in the time domain).

Concerning the bitstream you demodulated, I am not at all an expert in SIGINT, but I guess we can do some basic research like search forrepeating pattern (that could indicated a start-of-frame indicator), maximum number of consecutive all-0 or all-1 (that can indicate bit-stuffing) etc. The problem with unknown digital signals is that the number of variations of different processing-techniques is almost infinite: scrambling (not encryption, but scrambling) , FEC, ...

(*) The visual element of inspectrum is the reason why I use it in a workshop I give. The workshop I do is similar to the one done by Mike Walters that is on youtube: https://www.youtube.com/watch?v=tGff31uGXQU

I find urh a great tool ... except when you absolutely have no idea what kind of signal it is. I usually use inspectrum as a first tool to have a basic idea what the signal looks like. Based on that, I decide how to go further.

Inspectrum is an older tool and has less features then urh, but sometimes simplicity works better.

Kristoff ON1ARF

interesting advice. Thanks!

I do not see that as phone-usage, I'm doing an experiment to see how easy / difficult it is to revert the "i need to know the time, so I grab my phone" reflex back to "I need to know the time, so I look at my wrist".

I'm currently reading some books on how easy it is to manipulate peoples behaviour using 'nudging', this to better understand the social engineering tricks used by hackers.

An chapter in one of these books in how social media use tricks to manupale our behaviour that resemble the tricks used by the gambling industry.

One of the things I find intriging is the size of a smartphones today. If you look at it objectively, they are actually so large that most people would consider it to be annoyting: you have to carry it in a bag, in a pocket of your pants -but you have to take your phone out when you want sit-, or ..you carry it in your hands. Have you noticed how many people have their smartphone in their hand when they walk around? But, of course, if you have something in your hand, it is very easy to open it quickly check your notifications; which reinforces the addiction.

So, that's the thing. People do not find it annoying.

So .. as an experiment, I am trying out how easy / difficult it is to break the habbit.

A small sidenote when (or if) I manage to get my garmin vivosmart HR charges, it does rapport activity per week, number of steps and number of floors I went up on foot per day, even without a smartphone app. So that's at least something :-)

One of the reasons I am looking for a new sportswatch is because I try to reduce my smartphone use and I noticed that I actually took out my smartphone just to check the time.

I have an old garmin vivosmart HR but I do have a problem with the charging cable. Plus I am not able to download the healthstats with my linux 'daily driver' laptop.

Perhaps I should just get a cheap regular watch somewhere? 🤔

I don't. I thought the emoji would have made that clear.

I have been doing cybersecurity awareness lately. We are starting to get over the furst hurdle: make people see the signatures of phishing message. But now we are starting with the 2nd hurdle: make people understand that when they write a genuine post, they should avoid these signatures of phishing, in this case, the "time pressure" argument.

The problem is that the more genuine messages have phising signatures, to more difficult it becomes for people to distinguish a genuine posts from phishing. There is also the risk that you genuine posts will get noted as fake (although that is clearly not the case here :-) )

ah .. currently not available :-/

ah. That looks very interesting. And they have a show here in the EU, and it seems to work with gadgetbridge (thx Lambda RX :-))

Thanks!

my daily driver is a ubuntu laptop so I was first thinking about that, but now that you mention a mobile app, ..yes. that would be nice too.

thanks for the food for thought :-)

A URL 'Free up to some-end-date'. ???

Phishing link? 🤔

Hum , interesting point. If you where a hacker, would you not prefer software to be spread out everywhere so people would be even more confused what is the real source for some application?

I guess people would then just depend on their search engine

Well, in principe I do not see that much different between 'curl | bash', 'sudo apt-get install' or installing an app on your phone. In the end, it all depends on trust.

Considering how complex software has become and on how many libraries from all over the internet any application that does more then 'hello world' depend, I do not see how you can do if you are not prepared to put blind trust into some things.

Concerning CrowdStrike, I am just reading an book on human behaviour (very interesting for everybody who is interested in cybersecurity), and I am just on the chapter about the fear of deciding with unknown parameters vs. the fear of not deciding at all. Any piece of software will brake at some point, so will you wait forever to find something that will not have any vulnerabilities?

Obtainium seems to have a very interesting take on this. Thanks for the link! I will check it out 👍