This is going to have a turnaround time of one or two *minutes* per key. Trying to decrypt the data and using some heuristics to detect a correct decryption would be *way* faster. And still, it would need thousands of years. In the average case, we would have to do roughly 1.7e+38 tries. Even if we could try a billion keys per second (which is far more than we could actually do) on a million machines in parallel, that would take roughly 5.000.000.000.000.000 years. Bruteforcing AES128 just can't work out.
So we need to think about a different approach: - Either find a way to execute code on the device itself, and analyze it from the inside, trying to find some hole in their security system. (Succeeded on 2G, and we can execute code but haven't found a flaw yet on 4G, there's still much analysis to be done on that platform) - Find another way to steal their key. Some nice folks at 25C3 showed that it may actually be possible to do that by opening up and analyzing the chip itself, even though they were dealing with way older, lower-density chips. - Analyze it once again from the outside and find another vulnerability earlier in the boot process, that allows us to execute code at a stage where the crypto unit is still accessible. Keanen Shaw schrieb: > To clarify, I was saying that you replace data in the first location of > writable memory, and if the code executes (is valid), success, if not, try > the next encryption key. > > On Sat, Jan 16, 2010 at 10:28 PM, Cory Walker <cwalke...@gmail.com> wrote: > >> Brief summary of the current situation: (as far as we know) >> >> 1. We can't replace the first code run because it is ROM (not accessible >> from the outside) stored in the Samsung processor. >> 2. We can't replace code on writable memory because it has to be encrypted >> with a key we don't know. >> 3. For the same reason, we can't do anything with the code we can read >> since >> it's encrypted. >> >> On Sat, Jan 16, 2010 at 9:05 PM, mat h <mat...@gmail.com> wrote: >> >>> Sorry I thought it did use a linux subsystem. >>> >>> On Sun, Jan 17, 2010 at 12:36 PM, The Seven <these...@gmx.net> wrote: >>> >>>> Rockbox and uclinux don't have anything in common. Rockbox uses some >>>> tiny bits of cherrypicked linux code here and there, but it is >> certainly >>>> not based on linux, as it has its own operating system core. >>>> And Rockbox can successfully load and play music at least on most 2Gs. >>>> We know about one flash chip type out of about 30 of them that at least >>>> sometimes refuses to work properly in Rockbox, but for the vast >> majority >>>> of devices, Rockbox is next to fully functional, only some small things >>>> still lacking... >>>> My iPod Nano 2G is Rockbox-only since several months now, I completely >>>> removed the Apple firmware, and it's working just fine for everyday >> use. >>>> mat h schrieb: >>>>> Well rockbox is uclinux, it boots although it doesnt work 100% (cant >>> load >>>>> music) >>>>> >>>>> On Sun, Jan 17, 2010 at 12:26 PM, The Seven <these...@gmx.net> >> wrote: >>>>>> Well, actually, I released that thing, and I don't know anything >> about >>> a >>>>>> 2G linux port... That linux boot option is just "reserved for future >>>>>> use" ;-) >>>>>> >>>>>> mat h schrieb: >>>>>>> Take a look in the archives, you will see the bootloader that they >>>>>> released >>>>>>> for the 2G, no idea about the other generations, I went to an ipod >>>> touch >>>>>>> recently :P >>>>>>> >>>>>>> On Sun, Jan 17, 2010 at 12:19 PM, The Seven <these...@gmx.net> >>> wrote: >>>>>>>> So have we got somewhere on the 2G/4G? >>>>>>>> Actually I'm very interested about your ideas, even though I think >> I >>>>>>>> have got quite a comprehensive overview about those things and the >>>> only >>>>>>>> plan that I could think of that doesn't run into a dead end >>> somewhere >>>> is >>>>>>>> figuring out that return address and making our exploit work. >>>>>>>> Nevertheless, I would be very pleased to discuss your ideas here. >>>>>>>> I may have missed something, and even if I didn't, I would at >> least >>>> like >>>>>>>> to clarify *why* a certain plan can't work in the end. >>>>>>>> So please just explain your ideas... >>>>>>>> >>>>>>>> Keanen Shaw schrieb: >>>>>>>>> I will do neither of those things. I have a few ideas of what to >> do >>>>>>>> myself, >>>>>>>>> but I'm sure none of you would listen. The guy who emailed me >> about >>>> my >>>>>>>> last >>>>>>>>> message didn't even email me back after my response, so I have no >>>>>> reason >>>>>>>> to >>>>>>>>> believe that you guys are getting anywhere. >>>>>>>>> >>>>>>>>> On Sat, Jan 16, 2010 at 3:39 PM, The Seven <these...@gmx.net> >>> wrote: >>>>>>>>>> Do you feel like opening it and soldering on the PCB? >>>>>>>>>> Or maybe donate it to stooo, our "hardware wizard"? >>>>>>>>>> We may indeed need another 3G for board-level testing... >>>>>>>>>> >>>>>>>>>> Keanen Shaw schrieb: >>>>>>>>>>> Hey people, since I'm on the mailing list I thought it would be >>>>>>>>>> appropriate >>>>>>>>>>> for me to actually say something without you blokes ignoring >> it. >>>> So, >>>>>>>> for >>>>>>>>>> the >>>>>>>>>>> last time, I have an iPod Nano 3G that I can run any kind of >> test >>>> on >>>>>>>> you >>>>>>>>>>> want. It is pretty much disposable, as I have no way to use it >>> now >>>>>> that >>>>>>>>>> I'm >>>>>>>>>>> running Puppy Linux. Anyone want to say "nice to know" or >> "we'll >>>> keep >>>>>>>> in >>>>>>>>>>> touch"? I'm not going to deal with this bullshit anymore. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Linux4nano-dev mailing list >>>>>>>>>>> Linux4nano-dev@gna.org >>>>>>>>>>> https://mail.gna.org/listinfo/linux4nano-dev >>>>>>>>>>> http://www.linux4nano.org >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Linux4nano-dev mailing list >>>>>>>>>> Linux4nano-dev@gna.org >>>>>>>>>> https://mail.gna.org/listinfo/linux4nano-dev >>>>>>>>>> http://www.linux4nano.org >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Linux4nano-dev mailing list >>>>>>>>> Linux4nano-dev@gna.org >>>>>>>>> https://mail.gna.org/listinfo/linux4nano-dev >>>>>>>>> http://www.linux4nano.org >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Linux4nano-dev mailing list >>>>>>>> Linux4nano-dev@gna.org >>>>>>>> https://mail.gna.org/listinfo/linux4nano-dev >>>>>>>> http://www.linux4nano.org >>>>>>>> >>>>>>> SplitIce >>>>>>> http://thewarezscene.org >>>>>>> _______________________________________________ >>>>>>> Linux4nano-dev mailing list >>>>>>> Linux4nano-dev@gna.org >>>>>>> https://mail.gna.org/listinfo/linux4nano-dev >>>>>>> http://www.linux4nano.org >>>>>>> >>>>>> _______________________________________________ >>>>>> Linux4nano-dev mailing list >>>>>> Linux4nano-dev@gna.org >>>>>> https://mail.gna.org/listinfo/linux4nano-dev >>>>>> http://www.linux4nano.org >>>>>> >>>>> _______________________________________________ >>>>> Linux4nano-dev mailing list >>>>> Linux4nano-dev@gna.org >>>>> https://mail.gna.org/listinfo/linux4nano-dev >>>>> http://www.linux4nano.org >>>>> >>>> >>>> _______________________________________________ >>>> Linux4nano-dev mailing list >>>> Linux4nano-dev@gna.org >>>> https://mail.gna.org/listinfo/linux4nano-dev >>>> http://www.linux4nano.org >>>> >>> _______________________________________________ >>> Linux4nano-dev mailing list >>> Linux4nano-dev@gna.org >>> https://mail.gna.org/listinfo/linux4nano-dev >>> http://www.linux4nano.org >>> >> _______________________________________________ >> Linux4nano-dev mailing list >> Linux4nano-dev@gna.org >> https://mail.gna.org/listinfo/linux4nano-dev >> http://www.linux4nano.org >> > _______________________________________________ > Linux4nano-dev mailing list > Linux4nano-dev@gna.org > https://mail.gna.org/listinfo/linux4nano-dev > http://www.linux4nano.org > _______________________________________________ Linux4nano-dev mailing list Linux4nano-dev@gna.org https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
