Jeremy Prater schrieb: > > The 240byte position split in the various versions in the aupd verify > the block size is 16byte (128-bit). It is odd that the aupd and osos > filesizes are multiples of 2048 also, I thought it could be just a > coincidence in osos, but both files is odd. To use decrypting > functions in winhex goto edit | convert (ctrl + r) and it brings a box > up, also hackman hexeditor can do decryption. I use them both for > testing stuff. I don’t really know where to go from here, aes-cbc is > difficult to get the plain-text from the cipher-text, I was looking at > 1g nano firmware to see about strings and stuff, but I doubt any of > that data made it into the 2g firmware. Later -- Jeremy > I guess these files are just padded to fill the 2K blocksize of the flash. Well, there are definitely a lot of strings and stuff we know must be in there, but we don't know where they are. I would have also guessed that there would be at least some zero padding, but I couldn't find any repetitive ciphertext blocks, no matter how hard I search. If I understood the workings of a CBC cipher correctly, repetitive blocks of plaintext must yield repetitive blocks of ciphertext, right? What ways are there to crack the key if you know plaintext AND ciphertext? Does that need a brute force attack?
Thanks for your good and hard work ;) > > ------------------------------------------------------------------------ > > _______________________________________________ > Linux4nano-dev mailing list > [email protected] > https://mail.gna.org/listinfo/linux4nano-dev > http://www.linux4nano.org _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
