Suggestions about DOS attack

[charlescao460]

Hi,

I found that the DOS attack would be more efficient if the IDs and answers were gotten from serial port rather than generating locally. I noticed that the random() function was invoked 3 times in iClickerEmulator::randomId(). Thus, the arduino's implements of random() function seems to slow down the attack process.

Maybe it could be better if we only invoke random() once and use bit operations to its result to generate IDs?

I was testing this on my own-designed device with Atmega328p and CH340E, so I am not so sure that it is the problem of randomId() function.

By the way, I am now working on integration of the iSkipper. I am trying to put Atmega328p, CH340E, RFM69HW and a patch antenna on one small PCB. I hope you like this idea:)

(You could see my design in my fork: https://github.com/charlescao460/iSkipper/tree/dev/emulator/iSkipper/iSkipper-in-one-package)

[wizard97]

You could definitely optimize the use of random a ton...

However, I would not imagine that random() would be slower than sending over a serial port. If this is the case though, you could instead use a fast xorshift RNG since the quality of the randomness does not matter. If your only goal is to overload the base station, you could also just submit the same answer under the same ID over and over again and never have to use any random numbers.

If your only goal is to stop other remotes from being able to submit, probably the best approach is by putting the radio in what is called Continuous mode (instead of the packet mode), this will let the radio transmit continuously, and if you transmit garbage nobody else will be able to submit!

Also, very cool project, it looks great! I was meaning myself to design a PCB that one could use to built a much cheaper remote replacement. Also, it is hard to tell from the pictures, but it does not look like you have a copper GND pour adjacent to the antenna on the same layer. Adding this might potentially improve your RF performance since you are using a single ended antenna.

[charlescao460]

Thank you for your response~

Actually, I am developing "replacing" attack, which is collecting other's IDs and use their IDs to replace their answers. (This is soooo evil). As for the DOS attack, I've tried to use the same ID and answer to overload the base station, but this would only stop other remotes receiving response form the base, the base still got their answers. But this could really make another iSkipper overload. I guess it may be the problem of hardware.

As for the antenna, well...The design of this antenna was actually from internet. I am not majoring in any subject that relates to antenna, so I have totally no idea about antenna design (Forgive me).
But I tried use HFSS, and the simulation of this antenna in free space looks great. But I don't know what would happen if it was placed near those electronic components.

I do have the GND polygon on both sides of PCB, but I heard that putting the GND polygon near antenna would influence its impendence and generate high-frequency interference to the circuit , and I found that patch antennas were usually placed far away from GND in many hardware designs. So I put them separately as much as I can . The current design seems to work well, it can receive iClicker answers from 30 meters away, but I have never used it in the real class.

[wizard97]

We actually have a working example of that exact atack: https://github.com/wizard97/iSkipper/blob/master/emulator/iSkipper/examples/attacks/attacks.ino

Take a look at the answer_resubmit method.

As for the DOS attack, I've tried to use the same ID and answer to overload the base station, but this would only stop other remotes receiving response form the base, the base still got their answers.

Interesting, I would not expect that, as the remote transmit is a complete different frequency than the base stations response. Perhaps the base station just stops sending acks if it detects it is getting overloaded. I actually know of someone from UConn who used this library for a reverse engineering class and was able to crash the host computer with a ddos atrack.

I do have the GND polygon on both sides of PCB, but I heard that putting the GND polygon near antenna would influence its impendence and generate high-frequency interference to the circuit , and I found that patch antennas were usually placed far away from GND in many hardware designs.

Sorry I should have clarified what I met. You are absolutely correct about the distance to the GND pour affecting the impedance of the antenna. However, the goal is not to make this pour as far away as possible. Rather, the antenna design you found should have specified the exact distance to this ground plane to make the antenna have a 50ohm impedance. If you are familiar with the dipole antenna, the GND plane effectively forms one side of the dipole. Without properly spacing it there will be an impedance mismatch and whenever you transmit, the wave will be reflected back into the transceiver, which at best will cause it to heat up more and have a lower ERP, and at worst destroy the chip.

Once you finish your design, what are the chances I can have one of your boards :)?

[charlescao460]

oh I didn't notice that function before. The answer_resubmit method works perfectly well.

This DOS attack does have the ability to crash host computer. I have an iClicker1 base station ($15 from ebay). With the iClicker 6.4.2 Windows software, the attack did sometimes make the software stop responding. However, it seems that the iClicker 2 base station (which I don't have but my university is using it) is more powerful and the newest iClicker software is well-designed to prevent crashing. So maybe we need multiple iSkipper to attack in the same time to ensure the DOS attack is effective. The current design with RFM69 maybe not capable for crashing that system. (Or it is because ATmega328p is too slow? Maybe trying STM32...)

The antenna was originally designed as an external antenna. (See the picture below)

There is only a small GND square pour in this original design, and its impendence is 50ohm. It is an external antenna, which means, I guess, it was designed to be placed away from the circuit.

The Ver.2.0.1 PCB is now in production in factory. I hope this could be the version that works perfectly.
I am happy to give some boards to you. I will ask your address through email once I go back to U.S :)

And then maybe you could help to improve design, since I don't have oscilloscope to check its electrical performance.

[wizard97]

There are definitely a ton of performance improvement that can be done in the underlying radio driver (RFM69.cpp) -- I'm not the one who wrote it, and if I had the time I would rewrite the whole thing...

To name a few issues:

• You could try speeding up the SPI speed look on line 399 of RFM69.cpp: SPI.setClockDivider(SPI_CLOCK_DIV4); According to the datasheet the clock can be up to 10 MHz.
• You can get rid of the canSend() thing on line 228
• There is just a ton of redundant register reading and stuff everywhere

Also, very important that when you call submitAnser(), you tell it not to listen for the ACK (withAck=false), otherwise will slow it down a ton.

There is very little processing going on the host side, so I doubt upgrading to a fast 32-bit ARM will give that much more performance.

There is only a small GND square pour in this original design, and its impendence is 50ohm. It is an external antenna, which means, I guess, it was designed to be placed away from the circuit.

Yeah, keeping the antenna far away from sensitive components is a good idea. However, that distance to the GND plane is very important.

The Ver.2.0.1 PCB is now in production in factory. I hope this could be the version that works perfectly.
I am happy to give some boards to you. I will ask your address through email once I go back to U.S :)
Ok cool, keep me updated!

And then maybe you could help to improve design, since I don't have oscilloscope to check its electrical performance.

To really test the RF stuff well you need a really expensive piece of equipment called a network analyzer.