Date: Mon, 26 Jan 2009 12:08:06 -0500 From: Chuck Robey <chuckr@telenix.org> To: Alex Karpovic <alekar2009@gmail.com> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: hex editors, disk info Message-ID: <497DEDF6.7040102@telenix.org> In-Reply-To: <700ff07a0901260633n2b09d056n64cf6b1def013f04@mail.gmail.com> References: <700ff07a0901251351t629b9606g260447b4cbaef00b@mail.gmail.com> <20090126001710.688b53eb@gluon> <497D1201.6060503@telenix.org> <700ff07a0901260633n2b09d056n64cf6b1def013f04@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Karpovic wrote: >> That in mind, what's wrong with bpatch? I've used it for binary patching, it >> works just fine that that (if my first assumption is totally off-base). You >> download from the device, change any required data, and (if the device allows >> writes) write it back to the device. Of course, not all devices allow writes. > > It's a bit uncomfortable. Just for example: I need to search some > signatures, which could be anywhere in 640Gb disk, and make some > changes around them. And I don't have spare 640+ Gb to copy whole disk > to. And even if I would have enough space, it is painfully slow to > move 640Gb twice just to make ten minutes editing. That's an unusual requirement, but folks ought to listen here, because optimizing such a problem, it's an interesting challenge. There is NO established tool which will do such an outre' task well, just because it's so unusual) I won't probe into your reasons, although a request so very odd usually means that there's some misunderstanding at the back of it. Anyhow, if I were given this task, I really think that the problem is in localizing the area you need to change, not in changing it. I'd use whatever language you feel comfortable with, then using that language (either directly, or by piping dd or nc to help out) so that you could do a global search for your target. Your search could trivially do extra things, like uniquely identifiying the target area, even dumping surrounding blocks into work file, so you could follow up with bpatch to actually change things. Don't expect such a thing to go quickly ... however, this is one of those tasks that can be made to operate significantly quicker, if you choose an efficient language and (easily as important) choose a good search/comparison algorithm. Actually, this sort of thing mgiht well have been given as homework to an undergrad, a very good learning opportunity indeed. Lot's of room for optimization of all kinds, and that task is big enough to really show obvious results. Done wrong, with tools bent into shape, this task is really too large to be reasonably contemplated. Unless you have a few extra months to use waiting for results, and you'd have to keep your mitts off the disk in the meanwhile. Just not a good idea to take that approach. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl97fYACgkQz62J6PPcoOmJzgCePrJCKxJc6y92RNJPa+Nr76GY dDoAniq7ay6Bb72eVUFVOeyxWo5IPehc =r9vi -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497DEDF6.7040102>