On 28.08.2007 17:41, ron minnich wrote:
On 8/28/07, ron minnich rminnich@gmail.com wrote:
On 8/28/07, Uwe Hermann uwe@hermann-uwe.de wrote:
Yes, good idea IMO.
Maybe 'LAR Magic 0.01' or something similar?
Again, given current brute force search, this won't help, since that string will appear in the data segment. The most reliable fix is the one I posted; the most proper fix is stefan's "let's stop being stupid" which I will try to implement now.
OOOPS. We are being smart, it turns out:
lib/lar.c and util/lar/example.c differ in subtle ways in find_file. Inverted logic in one file, bogus calculations in the other one. We might want to make sure they behave the same way.
header = (struct lar_header *)walk; fullname = walk + sizeof(struct lar_header); printk(BIOS_SPEW, "LAR: current filename is %s\n", fullname); // FIXME: check checksum if (strcmp(fullname, filename) == 0) { printk(BIOS_SPEW, "LAR: it matches %s @ %p\n",fullname, header); result->start = walk + ntohl(header->offset); result->len = ntohl(header->len); result->reallen = ntohl(header->reallen); result->compression = ntohl(header->compression); result->entry = (void *)ntohl(header->entry); result->loadaddress = (void *)ntohl(header->loadaddress); printk(BIOS_SPEW, "start %p len %d reallen %d compression %x entry %p loadaddress %p\n", result->start, result->len, result->reallen, result->compression, result->entry, result->loadaddress); return 0; } // skip file walk += (ntohl(header->len) + ntohl(header->offset) - 1) & 0xfffffff0;
ARGH! Shouldn't that be
walk += (ntohl(header->len) + ntohl(header->offset) + 15) & 0xfffffff0;
Carl-Daniel