Brute Force versus Fuzzer :

#1

All the apps that are available for flipper and named as fuzzers like the RFID/Ibutton fuzzer are in fact either brute force apps and/or apps that test generic/standard master keys.

It would be nice to have a real fuzzer option that would send data to the rader that it would not expect in order to attempt to crash it.

Example, while for example the existing fuzzers would send for example key 00 00 00 00 to FF FF FF FF to a RFID reader it would be niceto send stuff like ÇÇ %% && HH, ETC - non hex data or stuff that would probably not be accepted by the controller to see if it crashes. That would be more close to a “fuzzer” as the ida would be to send “junk” data to the controller in order to attenpt to crash it.

2 Likes
#2

You make a great point. It would be awesome if those apps had a simple toggle to go between real fuzzing and brute force.

#3

I did a BIG MISTAKE …

Now that i think better …

On software you have codepages and ascii, etc … so if you write software that expects an input of 0-9 or A-Z and you send an input of ç or % you might crash the software so the notion of fuzzer … BUT …

On flipper RFID, Sub-Ghz, iR, etc … you are not sending characters … you are sending binary numbers of 0 and 1 encoded on the format/protocol of application, etc …

So if you send 0F on a “code” for an rfid “key” for example you are sending “1111” encoded on a radio wave, etc …

So no way to send ç or @ or hatever because you don’t have a notion of characters but only numbers encoded on AM or FM as binary …

To simplify you can use calculator to convert hex to binary because they are numbers but not characters of codepage …

So to really “fuzz” you would need to somehow send something that the reader/controller would not be expecting but that would more or less be like sending data/protocol that is different from the ones that the controller accept, like using an ioprox card on an indala reader so … no use for a “real” fuzzer so the only possible thing to do here is either master key/brute force as already exist …
maybe the apps should simply be reenamed to brute force instead of fuzzer but that’s it …

My mistake.

#4

I bet it is a normal thing already tested, because it occurs too easily even without malicious intent. Speaking of fuzzing methods, I’d start with varying length of data sent.
Fuzzing is also hard in absence of feedback channel, and RFID has none.

#5

This is an insightful thread. I never considered whether an IR code could be fuzzed until @Spildit brought it up.

1 Like
#6

Yes, if we could somehow use flipper to send data to the devices like a IR reciever in a way that it would not expect there would be chances for it to crash or be broken…

Imagine someone managing to brick a TV set or a digital sign or freeze the device just by sending “craffeted” signals using flipper … It would be … coooollll !

1 Like
#7

Is it any better than turning it off?
It is only useful for vandals, whom I shall not approve.

#8

Might be of use to find problems with the systems or even to find “secret stuff” … Imagine for example that instead of briking a TV it goes to service menu by sending crafted packets or a IR blast that the set doesn’t properly parse/expect…