433Mhz You can't hack this !!

[@AndyHullMcPenguin]

You don't necessarily need to *store* many codes for your sequence. You can use a seed for a pseudo random number generator. If both Rx and Tx use the same pseudo random number generator and the same seed/salt then they can programmatically follow the same sequence without needing to store a large lookup table. Also look in to shared secrets, HMAC and Rolljam vulnerability. Also, multiple failed codes should cause a progressively longer timed lockout. This makes it much more difficult for a brute force attack to succeed within a time frame acceptable to the attacker.

[@TheBionicbone]

Thanks for commenting. The idea of storing the random numbers is to remove the predictability of the next code and eliminate any reverse engineering by capturing a few codes. Although for the next loop I do intend to reseed the numbers so they don’t repeat, but again the hacker would be unaware of when that happens since it will not be after every transmission. I like to think of it as using spare memory, while adding security and challengeing the current methods. I like the time out idea I may use that as well as lock out after 10 unsuccessful attempts. RollJam is also on the hit list but this need/may need different Tx/Rx device, if possible I'd really like to make a vibrating Tx Fob in the event RollJamming is detected, but lets see how far I get based on end user interest.

[@xhivo97]

@@TheBionicbone That is a non issue if you use encryption. The common vulnerability to fix is guarding against rolljam attacks which can only be done with embedding a timestamp. Any other rolling code is going to be susceptible to rolljams and replay attacks too triggered when not in range.

[@deterdamel7380]

You don't have to store the rolling codes in flash. Most implementations of a rolling key will create a sequence by a function. TX and RX will share the init-value of this function and a current (rolling) value. For example init-value: 5, rolling value 4, function will add init-value + rolling value. => 9. This will be the rolling value for the next function call and stored on both devices. Next rolling value will be: init-value + last rolling: 5 + 9 = 14. Of course you have to use a more complex one-way-hash function for calculation instead of a simple add-function, to get none-predictable values.

[@TheBionicbone]

Thanks for taking the time to watch and comment, it is really appreciated. I agree fully with your comment, but we are seeing good reverse engineering now, and using AI like ChatGPT it is making this very easy (and thats not even a dedicated maths AI). OK, ignore the hash to keep it simple. Ask ChatGPT to solve your example, 1st number is 9, 2nd is 14, 3rd is 19, it will work out the next number adn detail how. OK, again this is a really simple example, but try more complex you maybe supprised. The future is coming, if it can be calculated and even hashed (unless you can give an example of otherwise) it can be reverse engineered, yesterday by some clever guys, tomorrow by AI. It is for this reason I want it to be totally impossible to scan and calculate the next range of numbers in the sequence.

[@deterdamel7380]

@@TheBionicbone Not AI is the issue in this case. It's the quantum computing. So you have to chose a function that can not be solved by the quantum computer in a short time.

[@oeq57]

I agree on the need for hashing. I suggest the HOTP algorithm. I left a more detailed reply in the main thread. en.wikipedia.org/wiki/HMAC-based_one-time_password_algorithm

[@TheBionicbone]

Thank you. I am also looking at detecting RollJam attacks.

[@TheBionicbone]

@deterdamel7380 @omareq5724 So I can give full clarity I will make another video on why when using my methodology encryption and hashing methodologies do not add value whilst saving the memory does. If you study my method well, you will see why.

[@AllanSavolainen]

By sending the captured code and then two random sets of codes, you should hit the original code in 600 tries. As in it would loop through the numbers 3 times and on each round it will be offset by 1 and on fourth round it would hit the original code. Not sure how long that would take.

[@TheBionicbone]

Well done, yes I have been looking at this problem. I’m thinking after each loop I need to change the list of numbers, either so the loop itself is offset by an odd number or the numbers themselves change which is similar to how sequence coding works today but it would still be more difficult as the sequence would only alter once after many codes. I may need to use a ESP32 though, more code means less numbers stored lol

[@AllanSavolainen]

@@TheBionicbone And then there is always the out-of-sync -problem so you need some sort of way to reset the list, which gives replay possibility, or master key, that can also be copied. A better solution would be to store a master key on both devices, and use current timestamp as integer minutes, hash them together and use that as the key. That way the numbers don't ever loop, you cannot advance the counter by sending codes. The reciever just needs to check +- couple minutes and after that not to allow any earlier keys.

[@TheBionicbone]

@AllanSavolainen, yes I like the date and time bit. However, the latency of these cheap 433MHz devices is slow, and I have this nibble (4 bits) binary issue with them. If I transmit any more than about 10 nibbles then I risk the user thinking its not worked and pressing again :(. I have other devices that are much faster, they could easily handle date and time hashed so maybe one for the future.

[@AllanSavolainen]

@@TheBionicbone you could hash it to just couple bytes or 7 codes like you now have

[@TheBionicbone]

@AllanSavolainen the 600 tries issue has been resolved, I would love you to take another look at the latest imporvements.

[@jamesharding7536]

Super interesting video, thanks! Might need to have a gander at the git later

[@TheBionicbone]

Thanks for watching. I'd really appreciate you taking a look, see if you find any vulnerabilities that I may have missed. I'll try and add the buttons back in later cos I'm convinced it can't be hacked.

[@TheBionicbone]

@jamesharding7536 lots of new improvements have been added, I'd love to know your thoughts.

[@arva1kes]

I made implementation where i have aes encryption and decryption. I would send random IV unencrypted and send encrypted counter from remote to receiver (with also the command - button click/longpress/dual press etc.). AFAIK sending IV plaintext would not be bad practice. I would always allow higher counter number than the one already sent, so it would never go out of sync and would not allow lower number so it can't be replay attacked. On the remote and receiver side I save counters to eeprom and use rolling location for wear leveling and very high endurance (20+ years having multiple transmissions per day). Only problem I have is that it eats up majority of typical arduinos rom and ram. Your implementation seems far lighter and time will tell if it's secure if more people test and look into it. Thanks for great work.

[@TheBionicbone]

Thanks for your positive comments, I too intend to use eeprom too, it’s a good point to use rolling location for this.

[@milo2karel]

Thanks for describing this solution. I truly believe the rolling key mechanism is obsolete and not secure. The standard encryption & decryption mechanism from the computer world is a secure solution. Of course, RAM and storage are an issue, but there are dedicated security chips or controllers with hardware assisted encryption modules (many of them out there). The AVR is an old platform now (from 90's). There is nice example of the implementation here ww1.microchip.com/downloads/en/appnotes/atmel-42784-software-library-for-aes-128-encryption-and-decryption-on-megaavr_applicationnote_avr284.pdf

[@Rob_III]

Rule #1 in cryptography: Don't roll your own! Don't get me wrong, I appreciated and liked the video, but as a demonstration of the basic idea. But for anyone thinking of implementing this: Don't! Use an existing, proven, algorithm!

[@TheBionicbone]

@Rob_III with the greatest of respect I have to disagree. Let me pose a scenario. If I purchased a Land Rover Discovery today (if I could afford one:) ) then it would be very easy to use a relay attack and steal it, crime stats and LR insurance increase demonstrate how many are being stolen. If I somehow disabled LR protection and used mine own method in a different way to unlock the car, how long would thieves hang around trying a relay attack before moving on to an easier target? My point is, the uniqueness of my design and allowing each to be different in list of codes, init-value (which is only apply once the list is used not every time), the number of codes to make a full sequence, all mean end users can make their system unique and this in itself (in my opinion) is the best security of all.

[@Rob_III]

Hi@@TheBionicbone, thanks for your reply in the first place! I disagree though. What you're describing (look it up on Wikipedia) is "Security through obscurity". The best cryptographic algorithms are open and reviewed by cryptanalysts. I wish I could post a bunch of links, but I highly recommend you also google "cryptography don't roll your own". Ofcourse, if you implement your idea as a "one off" then most likely thieves won't hang around for long to try and figure it out; however, if your method is being used more and more widely you can bet that someone is going to figure out some (maybe sidechannel-)attack on your algorithm and break it wide open.

[@robertbruce7686]

Like Microchip did (Keeloq), 😆?

[@newmonengineering]

I have written my own algorithm and no one knows what it is. Without me telling someone the method it's even less likely someone can hack it. I generate my own unique key and use no ones algorithm, only my very own and I'd love to see someone hack it without looking at my code because I personally doubt looking at the encrypted text anyone could make any s3nse of it. I tried to hack it with a few known methods and those all fail because those are known methods. Just my 2c.

[@Rob_III]

@@newmonengineeringAgain: This is "Security through obscurity". Are you using a CSRNG or a PRNG? Are you using constant-time comparison or are you vulnerable to side-channel attacks like a timing attack? Are you a cryptography expert or are you just "making things very complicated so someone will never be able to hack my system"? Again, and this has been proven time-and-again: When it comes to security the adage is, for good reason: Don't roll your own. If you think you can do better than proven algorithms then you **should** be able to tell someone how yours works and **still** be safe. Because, at one point or another, a determined attacker, **will** get a hold of your code (maybe not in source code form but in binary form) and **will** be able to reverse engineer it. You are going to have to assume that and if not, and your code relies on someone not having access to the code you've already lost. Now, an attacker may not be interested in hacking a one-off, it may not be worth the time or effort, but if your algorithm is going to be used at scale, you can bet your behind your algorithm is going to fail unless reviewed by cryptanalysts at the very least.

[@IzzyIkigai]

nothing is unhackable and this has a few of the usual attacks. like there's being able to clone the key with nothing more than physical access and then using the cloned key - that way you don't just have a clone but can actually run denial of service by using the clone first. One could also denial of service your sender by just using it 10 times while not being in range of the receiver. there's also actual RF attacks on rolling keys that don't require physical access to the sender. samy kamkar held a decent talk highlighting current research for stuff like this at last year's defcon. great talk on the basics of these things.

[@TheBionicbone]

I have to agree, human makes and human breaks, it will always be the same if someone really wants to gain access they will even with risks of getting caught. Lets face it, if someone puts a jig under the door and lifts it no rolling codes stopping that :). But if I can detect lots of unsuccessful codes / RollJam and warn the user (vibration fob / text message etc.) then it could be as sucure as we can get today

[@IzzyIkigai]

​@@TheBionicbone The thing is, these big rolling code windows actually make it safer b/c of how the human psyche handles repeated false positives. It's also always important to remind people that a DIY solution, no matter how great it is, might risk an insurance company rejecting claims in case something gets stolen.

[@TheBionicbone]

@@IzzyIkigai the insurance issue is a good disclaimer I should add. I'm not sure where you are in the world but here in the UK insurers tend to ask if it alarmed and if it is then is it xxx approved and is it service at least once a year. Nothing DIY is xxx approved and therefore you'll never get an insurance discount. Thanks for you input.

[@artursmihelsons415]

Nice! 👍 For dealing with interference, just add at the packet end CRC. If received CRC doesn't match calculated value from received packet, receiver just ignores packet all together as faulty and don't even check compatibility with rolling code.. 😉 And waits for new packet.. For remote part - before CRC add in packet button press counter in coded manner (XOR, bit swap etc). Remote will update counter after every button press and send that data in packet. Receiver, after CRC check, first decodes received button press counter data in packet, then according to that data, goes looking in rolling code table. To prevent hacking, button press counter can't be smaller than stored last counter value in receiver, that's mean's - there is no way to reuse old or precisely captured rolling code data, because counting can only go forward until looping.. If button press counter data is smaller than expected, packet will be simply dropped.. For extra safety, button counter data can be added, even in middle of data packet between rolling code data. From theoretical point of view, even if hacker will decode button press data, it can't replicate next parcel, because he don't have rolling code data table, but this add will ensure good remote and receiver synchronization..

[@TheBionicbone]

@artursmihelsons415 what can I say, great minds think alike. Have a look at the update I have just released :) kzbin.info/www/bejne/eZewdZSXf7atosU. I have added multiple Rx option, and I've added the Rx number in the exact way you have mentioned for the button (I may do this for the button later). Failed transmissions are a thing of the past, even in high interferance areas. Thanks so much for your great comment and for watching and taking part, it really is appreciated.

[@bennymegidish]

Instead of a backdoor you can reserve a special key the resets the rolling code position pointer for both the transmitter and the receiver.

[@TheBionicbone]

I like this, perfect, the hacker would not know that internally the code was reset

[@threeMetreJim]

This is how i'd try, just from your description (not looked at the code). Capture 1, then send random guess to move along, send captured and repeat. If the random guess is right, door opens otherwise you'll only need to send as many attempts as you have in the numbers list. Trying to roll your own rolling code without knowledge of cryptography is usually a disaster. You should see how complex the original keeloq was, but it still was broken after the method used was leaked.

[@jonathan-._.-]

idea 1: lets say you have a recorder at the door - that pciks up the signals whenever you leave and come back , it would always send open signal and then close signal meaning around 4 requests per day i think you could get the whole code relatively quickly (depending on sizeof rollingCode and sizeofSendingRollingCode ) 🤔 im not a security expert but i think there should be some public/private key involved and some encryption

[@TheBionicbone]

Thanks for your comment. Can I ask you to check initValue, it applies when sizeOfRollingCode is reached. There is also an update video kzbin.info/www/bejne/jJrLhWlnbc5-hqM which explains the encryption situation

[@dougaltolan3017]

If an incorrect code is repeated, Rx wont progress.. Hacker records 2 valid sequences and plays them back alternately. Rx progresses and looks ahead so it only takes once round the sequence and I'm in.

[@TheBionicbone]

After x (set by user) incorrect receives the rx starts a lock down, again set by user, ever increasing time outs. Its not perfect and can create a long lock out. But at least the criminal is also locked out.

[@dougaltolan3017]

@@TheBionicbone there is a solution... Use encryption... Encrypted information is salt (key word that must be present) and a counter. Tx encrypts a sentence comprised of salt, count and RSA signature(that's overkill, but hey..) then increments count. Because count is never the same, RSA signature will never be the same. Encrypted, doubly so. Rx only has to decode a valid packet (correct encryption was used), check salt and RSA signature (double protection), and check that count is greater than any recieved so far (pre recorded packets won't work).

[@TheBionicbone]

It's true and the normal way, but I like to find different things and while what you mention and RSA is industry standard the industry is already preparing for the future. Search quantum resistant algorithms, and look for US government or banking

[@8x13b]

You could add an RTC to the electronics and have the code be dependent on the time it receives the message. It solves the problem of desync.

[@TheBionicbone]

Thanks for watching. Desync has been resolved on the latest updates. Check the channel for the latest videos or github which also links to the videos.

[@zachbrown7272]

rolljam.

[@TheBionicbone]

This is something I need to investigate more and see if I can detect it

[@NicksStuff]

What happens when you sync the Tx and Rx? Have you looked at the raw frames? Couldn't you use them to know where the code starts from?

[@TheBionicbone]

I can not see any vulnerability here. Since it is driven from a list of random numbers set by the user rather than a generated next number then the next set of numbers is impossible to reverse engineer and therefore impossible to tell where we are in the list. Also, if it was possible to workout say "in the middle of the list", it still would not help because what comes next is only known by the list in both the Tx and Rx, it can not be calculated.

[@NicksStuff]

@@TheBionicbone When you resync them, you don't change the list, right? So it wouldn't be hard to put a receiver near your garage door, register frames passively for a month, then flood it with wrong guesses and force you to resync them. You'll start somewhere in the list and I'll know the next frame from my previous recording.

[@TheBionicbone]

@@NicksStuff ok I see what you are getting at. At the moment no battery back up, thus power down Rx and we'd have to start again, reset Tx too. Also if you reflashed with "your settings" and did not change your settings or base numbers then it would repeat from the start. If someone had been recording your codes then technically they could start replaying them. With the latest code on each 10 incorrect then it would lock up for 60 seconds, then 120, 240, 480 seconds etc. any codes sent during this time are totally ignored. For clarity a normal code resync moves forward never backwards, so the Rx catches up with the Tx which can only go forward. Eventually, once I start on the text messages part I'll add eeprom, I hope then I'll be able to store how many times the list has been played, then I'll be able to roll the numbers forward and reset back to the correct position and be at the next new numbers. I hope all that makes sense, it does in my head 😁

[@frankjrgenjrgensen5179]

Im just passing by. I havent studied this algorithm. But a it is a testcase perhaps, to consider 20 neighbours having the same locking mechanism - it should not leave the neighbour that happens to be on holiday for some weeks with a locket door.

[@TheBionicbone]

Thanks for looking. This won’t happen because the qiachip devices have to be paired, Tx to Rx, thus signals from a non paired Tx are ignored. I appreciate your comment though and you having a look.

[@nicoladellino8124]

Nice video an project, THX.

[@TheBionicbone]

Thank you for a great comment

[@aquahoodjd]

So you jam one of the signals and you store the rolling code which remains valid cuz it hasn't been used and then you're in....

[@TheBionicbone]

They call this Rolljam, see latest videos for Rolljam I'm working on.

[@thebagmasters]

This could be brute forced right? 256^7 is big but you could get lucky?

[@TheBionicbone]

Technically yes, but you’d have to keep changing your numbers and then system would keep changing its numbers, it’s a bit like playing the lottery. I have thoughts though, if it receives say 10 signals without a pass it could just lock up as we’d know a brute force was being tried

[@thebagmasters]

This would absolutely work; but whatever system you use to reset it would be vulnerable as well. A hardware key maybe?@@TheBionicbone

[@TheBionicbone]

@@thebagmasters have a spare fob that has a reset code, if pressed it resets the numbers loop back to the beginning. If a hacker sent these codes by chance, the numbers loop would reset but they would not realise this had happened unless you were using it all the time, followed by the initial entry code for some reason

[@TheBionicbone]

@thebagmasters I have added a delay, if 10 unsuccessful codes are received then it locks up for 60 seconds, after if 10 more are received, locks for 120 seconds etc. This timer is reset once it gets a correct code (obvs only after its finished the lock out). Thanks for the idea.

[@thebagmasters]

@@TheBionicbone Sounds good, and with all rolling code, if it is brute forced too much it just locks out; which is a good indicator in itself.

[@drewlarson65]

"dumps the flash and cackles* ez hack