Hardware Wallet Hack: Ledger Nano S - f00dbabe
Vložit
- čas přidán 27. 12. 2018
- It was found that the Ledger Nano S bootloader can be tricked into flashing and executing untrusted firmware.
Research Site: wallet.fail/
Twitter: / walletfail
Thomas Roth: / stacksmashing
original wallet.fail talk: • 35C3 - wallet.fail
The bootloader is used to update the firmware of the 'non-secure' processor in the Ledger Nano S and has full control over the display, USB and the buttons. Time might tell how critical this issue actually is, a strong proof-of-concept still requires a lot of work and maybe the guys from wallet.fail will publish more in the future. Or join the security research and play around with it yourself!
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Website: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
=[ 📄 P.S. ]=
All links with "*" are affiliate links.
LiveOverflow / Security Flag GmbH is part of the Amazon Affiliate Partner Programm.
#HardwareSecurity #SecurityResearch
Most epic liveoverflow intro ever
Yeah, I was thinking that he must've put some time in Photoshop animating that, but then I realized it was the actual display
Yeah what the fuck that was soooo sick
reply button : 0:26
This channel is underrated. Awesome video.
This is beautiful bb
Michael Reeves nice to see you here!
Yes
You know what else is beautiful?
_drones_
Meet your maker, I see.
Ha nice to see you here :D
12:22 I remembered the Google logo a bit different
Hahahaha
The UML of that it's only in his mind. 🤓😇
I enjoyed that... some nice work by Thomas, and well presented as always. :-)
I saw the Talk from CCC, very great work! And they even told that there is something coming on your Channel so I expected this vid to come ;)
Keep up the great work!
I should never take a break from watching your videos. They inspire me to take the initiative to stop playing video games and get hacking again. You're awesome!
Really nice video ! (as always)
But, about the extraction of the private key from the secure element I would like to mention that it's not as easy as using some DPA (or other side-channels), or using some powerful microscope.
This kind of chip is designed to avoid side-channels, it includes power fault detection circuits (like the Rambus DPA countermeasures).
And to avoid microscopic analysis, you can use a metal layer of the integrated circuit to hide the memory on the chip (it's called a "sheld"). That way, you need acid to destroy the metal layer and reveal the memory. This process is very complex because you can destroy the memory with acid (that's why only organizations like the NSA can do that kind of attack).
And even if you're the NSA, if the memory are encrypted with a true secret key your attack is dead. We can use PUF (Physical Unclonable Function) to make a true secret key (generally known as root-of-trust).
Also, from my point of view, the real architectural error is not to connect screen and button to the non-secure chip. Real error is not checking the boot loader at each boot (but it's time consuming). Or at least put the "f00dbabe" in an other memory (a secure one).
These little microcontroller chips don't really have any permanent storage other than flash memory. There is also no MMU or MPU to protect memory areas and has no privileged execution modes (The bigger ARMs meant to run Linux have all this).
Yes running the check every time on boot would be more sensible but wouldn't protect you against this particular silly exploit. This exploit allows you to write to 0x00000000 and this is the reset vector. With that you can just insert a jump instruction into whatever code you want (And could have loaded earlier), bypassing the bootloader completely. But none of this would happen if the bootloader simply would refuse to write to this memory area too.
@@berni8k "These little microcontroller chips don't really have any permanent storage other than flash memory"
Are you sure about that ? I'm currently working with a crypto accelerator IP to implement a secure boot and it embeds a small ROM for the boot ROM and a OTP (One Time Programmable memory) made of fuse for secret datas.
I don't know the ST chip, but it would be surprising if it didn't have any memory on it. (like a secrete unique key, a certificat, or a boot rom)
Yes obviously that device is a bad example of secure device x), it's so stupid to allow writing on memory used for the secure boot process.
Watching this after the 35c3 talk. Very interesting!
This pixelated boot intro simply blew my mind! AMAZING!!
Followed by remark that he didn't do anything important. Like putting your logo onto a device that's sole purpose is to be secure is not impressive
@@evennot Well it demonstrates code execution on something that is supposed to be secure (executing non verified code is a big no no)
@@berni8k did he actually change the code? i think it was just a visual edit thing
@@jamiebury1807 This visually demonstrates that the code is executing, but the code does have full control over the MCU inside. Yes the secure element chip is still safe, but the MCU is the interface between the secure element and the user/usb port. This allows it to trick the user into approving a transaction shown on the display while actually sending a malicious coin stealing transaction to the secure element for signing.
This is still a pretty difficult coin stealing attack to execute, but it is possible.
@@berni8k thanks berni8k i thought as much. what about when you enter a 24 word phrase how does the the secure element never get seen by a potential hacker who tried to mess with the device? What makes the secure chip so special?
Drink every time he says "zero"
The joys of low level embedded programming.
You tend to learn to subconsciously count to 8 when writing 32bit values in hex.
I feel booze
Have Vodka shots. 😂
Was looking forward to this since i saw the talk! :D
Why aren't they just patching it? Usually they cannot patch the bootloader, but this vulnerability includes the ability to write to the bootloader's section. Therefore they can use the vulnerability to patch the vulnerability.
Well you can't use this vulnerability to directly overwrite the bootloader because the bootloader is executing directly from flash. So the bootloader would end up running in a mix of the old and new code until it trips over itself and crashes, leaving a broken bootloader in flash and bricking the device.
However what you can do is use the bootloader to update the main code, this code would then run and overwrite the bootloader and show something on the display to signal its done. At that point you can then reboot it into the new bootloader and load the genuine application back in. This can be done with the exploit or without it (If you have that magical private key)
Oh and i just realised. As part of the exploit you could update the bootloader yourself and lock it down.
So then when the user tries to update to the new secure firmware with a patch for this vulnerability it pretends like it is flashing it but actually does not write anything. So your code stays in there.
@@berni8k I'm not certain if you could use the same technique to update the bootloader from main code. Mainly because the vulnerability involved changing this during bootloader code, and altering it during main code may not be trivial, as chips can have hardware protection features to protect the bootloader during main code. I haven't researched this chip in particular, but remember reading something along those lines in a datasheet for another chip
@@jackaw1197 These STM32F04 series are just simple little microcontrollers. There is likely some sort of register based lock to prevent accidental writes to flash, but since there is no such thing as privileged execution any code can do it and start writing to flash. All of the flash memory is the same. The only reason why its placed where it is placed is because the reset vector is at the beginning of flash memory. So the bootloader is placed there so that its the first thing it executes on startup. No special boot region. The things are just faster 32bit versions of classical 8 bit microcontrolers used to run simple tasks with no OS or even RTOS.
Its the bigger ARMs built to run a OS that have the usual security features you would expect in a modern computer because the OS pretty much needs them.
@@berni8k OK, I looked up the application notes, and you appear to be correct (AN5156, section 6). Some STM32 series do have 'Secure User Memory', but the F0 series do not.
The datasheet I had read was for an ATMEGA32u2, which has lock bits to prevent writes to bootloader memory from application memory. I assumed a 32 bit arm chip would have this since an 8 bit avr does, but I was wrong.
Having written a few supposedly-secure bootloaders, the check at 5:35 should always be a whitelisting. Most microcontrollers have mirrors of the flash area, especially when they sell them fused-off to a smaller size for cheaper. You can also write evil bootloaders.
Yes, this is slightly iffy. Once the evil code is loaded (by bootloader or swd), nothing prevents it from responding with the good hash, and since key load/generation-and-backup is visible to the mcu and not just the SE, see yesterday's CCC talk about leaking the private key through signatures:-)
Hello! It's the first time I'm watching one of your videos and I'm impressed, I watched all the videos on the Ledger series and I liked them a lot, it's great work and I'd like to thank you.
Now, in this video you make it sound like Ledger brushed off the hack you discovered. I found it strange that they would do that and if that was the case I would certainly stop using their product just out of principle and and so I looked up their release notes to see what could come up and I'd like to point out my findings.
On the release notes for 1.5.5, (01/16/2019) they say:
"The so-called f00dbabe vulnerability has been independently discovered by Juliano Rizzo from Coinspect and T. Roth a few months later. We evaluated it as not exploitable, thus we did not urge for a new update. To our knowledge, no exploitation has been proven since then.""
I thought, yeah it checks out! Despite of that, a few lines below they wrote:
"Improved MCU genuine check to prevent the installation of rogue MCU firmware by software."
Nevertheless, they've might actually fixed it just in case.
Then later for version 1.6 (11/13/2019) Ledger wrote:
"Starting from firmware version 1.6.0, the microcontroller (MCU) will be updated by the Secure Element, further increasing the security of the update process and improving the user experience."
I can't tell for sure but I believe they actually implemented countermeasures for the hack you described. I think the key is that they said "we did not urge for a new update". Now it's clear what they meant.
I hope you can find the time to test it.
All the best!
Great work balancing the statements, instead of tooting your own horn, you carefully explain both the vulnerability, and Ledger's response to this criticism
So many LiveOverflow videos... Am I in heaven?
another quality video from liveoverflow!
The video gives a great insight on how one of the most popular hardware wallets works and what are its weak points. This will make up for a great series! For the next one, would you consider talking about using Python scripts on Android and iOS (through Pythonista for example) to build basic tools that help pentest networks? (or serve other hacking purposes)
Can’t wait for this video series
Always quality content here 👌 💯
It's so clear when you explain it. But the question afterwards is, HOW you found the bug, how you got attention to it and how long Thomas needed to find it..
Excellent video with moderated claims. Keep on the good work :)
I am definitely interested in upcoming videos!
Great work! I wonder why the secure element does not check if the firmware is signed, like it happens with drivers on operating systems like Windows? Is it because they are not able to update/revoke the key if it ever gets compromised and the devise would be useless?
7:56 look at the videos on the side xd
Yes. CZcams was not trained on his taste as he uses a private tab in chrome and is not logged in into CZcams.
@@finntegeler That's not what I meant.. Look at the channel names of the videos.
@@melluh Damn, nice catch!
I didn't even notice that heh
@@melluh That last one is so ironic.
If you put on a custom boot-loader, can you bypass the three login attempts before the private-key is deleted? Not sure it the secure chip self deletes or relies on commands from the un-trusted chip to order the deletion. If this would be the case this would provide a vulnerability if someone has physical access. Wondering what your thoughts are on this is.
This Nano Ledgers are being sold as security model, and I never felt safe about this configuration. Is also sold as open source hardware but the secret chip is not, just the board designs and software.
Hardware related security issues is my favourite. Thanks!
As you said the new firmware can control the screen (@2:47) it was enough for me to have a scenario to abuse the owner of a borrowed key. So, for the users of this dongle, don't enter boot-loader mode and update the code.
Is there a link to the document/research notes shown in the video? Didn't find anything in the description links...
7:10 By the way, the fact that the two locations are maped to the same physical memory on STM32 chips is basic knowledge. I hope the company took actions against those who made such a mistake
Amazing video. Thank you!
Only 35 seconds in, and I'm gonna bet you're going to spend the next 15 minutes explaining how you made the past ten seconds happen.
In other words, *best intro ever*.
Interesting, just got one yesterday. Think I'll transfer back and have some fun
This was a great explanation.
Why do they use different adresses for the same part of memory ? 6:31
Thank you for your video!
How does the code for your Firmware look like? Im really interested in that. Especially if you have no 'imaginary structure' of the firmware, how tf you can implement sth. like this?
I'm wondering, at 5:39 can we bypass the protection by passing destination_address = 0x7FFFFFF, and buffer_size = 0x304 ? Or will it segfault for writing to a non-mapped memory ?
Great content as always, thanks :)
Yes these ARMs throw a "Hard Fault" exception when you try to use memory that is not there or use it in the wrong way (Some things must be 32bit aligned)
A boot loader as attack vector? We haven't seen this in a while :)
Liveoverflow is love
simple question - is there anything more secure on the market now then Ledger or Trezor?
Paper wallets in a big trusty safe. At the end of the day a hardware wallet is 100x more safe compared to leaving crypto on an exchange.
@@ShawnBuckingham I would argue that paper wallet is less secure, once you have access to the paper wallet you got funds, once you have access to the physical hardware wallet, you dont have access.
i can use a used wallet if i delete the previous one before use ?
wonderful explanation.
Here's a video idea I want to see covered by you, and I have pretty high hopes that you're probably going to do it anyways.
I want to see a video about GDB and defeating anti-debugging techniques, I have a crackme I've been working on and I get for the most part how it works, but I can't get too far into it because there's a trigger that once hit, force closes the program. And I am not sure what causes that.
hey can u tell me how can i download any and every book every written from textbooks to self help to fiction from normal web and deep web??????
As a fairly ok hardware engineer, I feel like I could just unsolder the STM32 and solder one in with my custom bootloader/flash content, or? Maybe even one with a bigger flash size/same package , so I could be able to handle all the communication on the untrusted side, bypassing the crypto element completely? (The latter sounds way too optimistic to work)
Where did you find all the firmware info for the ledger?
The best intro I've ever seen. Thug lyf
Doesn't the bootloader require physically pushing a button?
If so wouldn't that greatly reduce any attack surface other than physical access?
@UXXELDUXXEL I assume that there is an option for a passcode that you have to enter on the device. Two buttons are enough for code entry and the hardware can lock itself to deter guessing.
@@henke37 But the passcode is useless if you can simply replace the firmware to do anything you want on the passcode screen.
But yeah its a pretty wild scenario to get physical access to the crypto wallet and get malware on the PC in order to make an actual attack. Maybe if they knew someone is keeping >100k USD in there wallet.
You could tamper with the Ledger before it even reaches the end-user, that's the issue here. There's no way to tell if your Ledger was previously compromised.
@@berni8k It's not useless if the secure element stores and verifies the passcode (I'd certainly hope that's the case). If so, the correct value still needs to be entered at least once after a malicious firmware is loaded on an already-initialised device.
this is a nice vid, keep it up
Very interesting!
Is this also possible on the Nano X? Just ordered one and I saw this video
The moment you said "let's look at the memory map" I facepalmed so hard because I knew what you were going to say and I didn't want to believe they messed that up
Also, at 11:11, the NSA doesn't need anything to obtain documents from ST micro or any other US based company, not even a please.
The only way that chip is secure is if it has a phisically unclonable funtion inside.
Security through obscurity is never the answer, just a fake layer of lull.
Well the NSA can legaly do almost anything anyway, for us mortals its illegal to use malware but not for them its business as usual.
Security trough obscurity does help. But only if there is some actual legit security underneath. Piling up layers of obscurity on top can really slow down the attacker. For example when they have no documentation means they have to reverse engineer everything first. Each layer is an annoying time waster so that a lot of attackers will get fed up and give up.Only the most persistent ones actually get to your real security to have a go at cracking it (And this is the important bit).
So obscurity in itself it certainly not a security measure but it does help the actual real security measure under it resist attacks a bit better. Modern PC games make heavy use of this. For example now famous Denuvo protection is used to unscramble machine code in real time as its executing. This Denuvo protection is not doing any security jobs, but it makes analyzing or tampering with the code running inside of it really painful and difficult. Its used to obscure actual security code under it so that you can't mess with it as easily. This can take a game from being cracked in
@Fluffy_tail xD ! Same reaction for me : "what ? There is an alias o.o that so stupid !"
PUFs are a great solution but you also need a good architecture
ST micro is not US based
@@berni8k I think you're overstating the value of Denuvo a little. When it was first released in 2014, it secured 2 titles for 12 months, followed by titles for 6 months or less. By 2015 it looks like 2-3 months was common. In early 2016, Denuvo was calling almost 4 months for doom "impressive" . In 2017, games were frequently cracked within hours of release (e.g. Middle-earth: Shadow of War and Total War: Warhammer 2). Final Fantasy XV was cracked 3 days before release. I haven't bothered to do a full head count but it seems like between no real effect and 12 months is a much more reasonable estimate to the value that Denuvo gives but with the time spent at 12 months being a lot shorter than the time spent at no real effect.
There are a few "not cracked" titles in the list but the ones that stand out to me are Valkyria Chronicles 4 and the Adventures of Captain Spirit/Life is Strange 2 as they are big name titles that are primarily single player. Can't explain why those survived where everything around them was in flames, but i doubt it's purely the quality of the security of Denuvo.
Ultimately this is an arms race where the ones doing the protecting have limited time and resources where as the ones doing the penetrating have (effectively) unlimited time and resources. Denuvo found a method that protected against a common cracking vector so the cracking community developed a new general purpose approach.
@@dantenotavailable Well yes Denuvo does get cracked much faster as crackers develop tools to help them work with it.
But still before Denuvo and similar mechanisms under other names it was rare that something didn't get cracked within a day of release. So extending it even to a month is actually pretty impressive. But Denuvo does not help at all if the security code it is protecting is itself flawed. Its Denuvo put on top of already strong copy protection that keeps the game from being cracked for long. For example using Denuvo to protect the Steam DRM is essentially useless, the hackers have such good understanding of Steams DRM system that they can crack it without modifying the actual game executable rendering denuvo useless. Using denuvo to protect a sophisticated DRM that is spread trough all the games code and performs secret checks that make the game act weird or mysteriously crash on purpose is a whole different story.
In any case Denuvo does significantly slow down cracking when used on top of a good strong DRM. This is security by obsurity and it does work. If the game developers implement it wrong then its there own fault. Denuvo is not a magic never crack pill, just helps reasonably secure DRM be even more secure
You must have been talking to someone, down the hall, behind me...that went right by me.!
Has the nano x the same vulnerability?
wow nice new intro
I saw you wrote code to the chip. Can you dump original code from the chip?
My two cents on this are even if it the address was spoofed, it would just be the display, displaying the wrong value. To be able to change data, it would have to access the secure non-volatile storage (or flash) to be able to actually modify the data that was already stored on the device.
If it was a new "hacked" one to the consumer, then it still wouldn't match as the verification using the ledger app would be incorrect, as it wouldn't match.
Theoretically, the user would (or moreover should) notice this, and not execute transactions.
It's like changing the Windows boot animation on Windows, it's not doing anything fancy, it's not bypassing bitlocker or anything, it's just in essence a change of files, no real code changes.
With a hacked firmware theoretically it could trick the secure element into believing the firmware is legit and then authorize a transaction to a different address than what the hacked firmware is displaying on the screen.
This would require an additional exploit that no one has demonstrated to exist yet, but it might exist.
does this only about S model or is applyable to the X model ?
Is this patched in the newer versions?
Thats a kickass intro
Surely we will see you at the 36C3 ?! 😂
Well presented!
By the time someone steal your ledger and try hack it, you have enough time to use seed phrase and move funds with another wallet. To extract data key from chip with advanced micro engineering and using your idea how NSA can break into it if they have access to the company that build chip, it takes a lot of time. Plus, one mistake can erase chip's memory. It is really hard to hack the device itself, but yes you can trick public key to be changed on the computer that you use it with ledger. So, if you are not visually confirm address on the screen of ledger, you might send funds to a wrong spoofed address public key.
I have no idea what any of this means but yet I'm still watching this at 2am
What's with the weird clicking in your voice?
Are you getting wire-tapped? Am I getting wire-tapped?
I didn't notice this until I read this comment, and now I can't not hear it again. Shit.
Someone please answer to this
#saliva #goodmic
He's speaking a mix of a language in Africa and English
Him making mouse clicks while recording?
Is it a good idea to make a manual for other people who are not good in hacking to make 8t easy to hack such parts....
Amazing video...you are boss :)
Incredible! I wonder how long it will take to reverse engineer original code and add exception, which will automatically accept payments to certain addresses.
Likely not that hard since they have machine code running inside this chip. The whole thing can be thrown into disassembler, perhaps look for the string that shows when it asks you to confirm. Check what part of the code accesses that string and just add one jump instruction to skip the button check (Or jump into your own code that checks for a specific pattern in the payment address if wanted).
I'm just waiting for people to stop calling it SSL when all modern secure connections use TLS. Pedantic I know =P.
Ah, I wasn't the only one who though that.
@@tripplefives1402 lol wow, are you trolling or do people still actually do stuff with gopher.
@@tripplefives1402 IPoHAM...is that an RFC yet? IPoAC is a thing so I have to imagine IPoHAM is. Also while I know what gopher is I've never actually used it. I guess the advantage to not having images or any of the bloat of the web is it's super light weight.
@@tripplefives1402 But does it have IPv6 lol? Also I have no idea what AX.25 and x.25 are so I'll probably go look those up
@@tripplefives1402 very interesting. I am familiar with the OSI model just not many of the layer 2 protocols. I actually would have thought that most fiber connections would use ethernet but guess not. I know fiber in a LAN usually is just ethernet but I guess it shouldn't be surprising something else is used on the scale of an ISP.
I don't see how reverse engineering the secure chip client protocol, , malware on the PC and malware on the unsecured chip is ever not enough to steal the wallet funds, the secure chip cannot know it does not speak with the real client and the confirmation button can be pressed by the evil firmware. Without the firmware vulnerability there is still the confirmation mechanism to defend the wallet. Therefore the code execution is definitely a major issue.
Also, if it's not an issue like Ledger says than why go into the trouble of protecting the bootchain? Obviously they are improvising at this point
Has this vulnerability been fixed?
So why can't you just create a piece of malware that will update the firmware on the device to sign anything without confirmation and create a fraudulent transaction? Yes, you can't extract the keys, but why does it matter if you can just still all the coins?
I don't quite understand at 6:55, the sentence: "You might have SRAM, system memory, Flash mapped from 0x000000 to 0x00008000". Why is it being mapped?
Just a feature of the chip
Foodbabe was my nickname at hooters
I bought a Nano X and Nano S just a few days ago... then CZcams recommended me this video...
Oh lord... let's see what it's about...
Do you think hardware wallet is not secure like nano x?i already ordered nano x.that is on the way?reply me
@@digitalworld5407 That comment made no sense (I recommend using Grammarly btw, it can help you figure out grammatical mistakes and fix typos, I'm not affiliated with them) but I guess you meant to ask whether the Nano X is more secure than the Nano S?
If that's your question, then no.
The Nano X uses the same design as the Nano S with some "ease of use differences".
These differences include (but are not limited to):
- allowing more "apps" (basically wallets) on the device
- bigger buttons
- bigger display
- USB-C (instead of micro-B)
- Bluetooth
Fundamentally, they are the same, though, due to the increased storage space on the Nano X, along with the Bluetooth component, I think the Nano X *might* (in theory) actually be less secure.
Do you have to worry? realistically speaking: no.
Unless you are being targeted individually (like someone actively targeting YOU), there is no real problem.
If they are actively targeting you, then your cryptos might be the least of your concerns...
Creating an attack and sending it out in mass and blablabla might prove too difficult to be worth the effort over creating malware that just phishes the user or something.
I mean, do note that one thing @LiveOverflow didn't mention is that you need to approve a connection between your ledger and the manager... so it can't do it sneakily (atleast, that we currently know off).
Having a hardware wallet is marginally better than having a software wallet so you'd be fine nonetheless.
I own both a Nano S and X btw.
The Nano X is on me while the Nano S is in my safe (seeded and good to go), the recovery phrase is stamped and put in another safe, pretty far away from me.
If I ever lose the Nano X, I buy a new one, initialize it then send my funds from my S to the new X then re-seed my S with the recovery seed from my X.
This way, by the time the finder might have broken into the thing... the funds are gone.
@@FinlayDaG33k oh my god tnx for the very big reply.really i have to say that i havent good inglish to understand what you said exactly..i mean some words anyway i Trying to understand your reply words to words.thnx bro
@@digitalworld5407 Use Google translate :)
While it *might* not be 100% accurate, it could help you understand it all a bit better since now you can see it in your native language (albeit with some funkyness here and there).
Also, just keep trying to write English (especially with the aforementioned Grammarly extension) so you can practice!
Good luck!
@@FinlayDaG33k yes thnx bro.i ll
Awesome video
Well couldn't you just send the requests by the secure chip to the pc to handle them and then send the calculated results back to the untrusted chip to use as a response for the secure chip? That way you could avoid the firmware checks of the secure chip
Hahah the intro is excellent, made me laugh out loud
What if I have have mining software on my PC, can they steel my keys?
That's why in modern consoles the boot process is handled by a bootrom... You can't read it "easily" and certainly you can't modify it...
But you said that the SecureChip checks the “proxy” memory and refuses to work when the firmware is not valid... so that means the “screen” and “button” are just unusable to make a automatic decision or show invalid data on the screen since there is no communication with the secure chip.
Well the only way the SecureChip can read memory of the microcontroller is to ask it via the serial link "Could you give me your data at 0x574 in flash? Thanks" What is stopping you from giving it back data that would be at that location in the real firmware? You don't need to keep a copy of the whole original firmware, just the small part you changed.
Trezor safety than Ledger?
was this updated in december 2020 i just got a ledger
Good video. As idea for new video - bay a cheap Chinese drone (like Eachine e58). They all make open wifi network and have camera, so interesting here is what can be done with this open wifi networks>
Hello, I need help, I put another security word in my ledger apart from the 24 words and I don't pay attention that it generates 4 digits and I don't write them I want to enter and it asks me for those 4 digits that I do not write down, I lost all the funds I had? Can somebody help me?
What's their excuse for not checking the signature of the firmware on each boot?
Perhaps its so slow it takes a few seconds?
uhh so like funds are totally not safu....where can i put my erc20s that is safe?
funds are 100 safe, if you gave this youtuber a ledger he would not be able to take the funds off the ledger. No one has been able to do this yet.
Top 10 Hackermen.
It's amazing that you can actually put your money on a USB
What if you added the extra security of the 25th word passphrase in addition to the general recovery phrase? If a hacker got past the bootloader etc they would still need the 25th word.
how would u add a 25th word?
Can you do a video on blueborne poc?
Great video man, hope you keep your spirit up
you would still need physical access the device in order to start the Bootloader mode in the first place.
Thing is, since the private key is in that "secure chip" which verifies the "proxy chip" even beeing possible to show stuff on the display and handle the buttons the "secure chip" would not handle the key (the the result of some signature) if the code on the proxy is not right. Of course that if the protocol between the secure chip and the proxy is just "hey, the secret word is gimmedasignature" "That's right here u have the signature" then a *simple* scoping would tell the secret word and then a real MITM attack would be possible
I think the PC needs malware in any case to let you steal funds from the wallet.
With a lot of work you probably pretend you are the security chip as the PC is talking to you, modify the request and then pretend you are the PC as you talk to the security chip to make it sign you a huge transaction of bitcoin to your own address. But if you send this forged signature back to the PC it will notice. What happen is that the PC pins this signature to a bitcoin transaction header that the PC generated and the transaction will fail because the signature is wrong. Or the PC will check what it got from the wallet and note that the bitcoin wallet address or amount does not match.
Oh wait... i just remembered about the BadUSB exploit... yeah that could be used to get some small program to execute on the PC that received the forged signature and sends it out.
I liked that intro
I confused is it safe to use ledger Nano s or not?!!!
FUCK YEA, half a day after i watched the talk
So the question is: Did Ledger patch this vulnerability in their recent hardware / firmware releases? This vid is 3 years old.