I commented a few days ago about looking at the data that is downloaded into the speedtouch. Not a lot to report yes, but a few observations.
If you execute: objcopy -O binary -j .rodata mgmt.o speedtouch.microcode replacing the filenames as appropriate, the output file should be almost exactly what needs to be downloaded. Would people with various versions of mgmt.o and the whatever.sys file care to try using the file transformed thus and report what offsets the upload procedure tells them. This should be a more robust way of making sure we can find the right stuff to upload. Also, the .data section of mgmt.o seems to contain an 8 byte value that is the offset of the start of the end match data within the .rodata section. This *should* mean that if we link against libbdf (for manipulating the elf), we should be able to do away with having to match anything - we can simply discard the first eight bytes of the section and we can read where to stop. I don't have the time, or the familiarity with libbdf to code this up myself, but I don't imagine it is all that hard. Can someone with the Windows driver establish if it is ELF, and if so, if the sections in it are the same? None of the other sections contain much of use, except .comment, which announces that it was built by: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). In my case, the mgmt.o thus transformed has the eight bytes of the match before the start of what is obviously some little-endian ARM code. At the tail of the file there are about 734 bytes after the end pattern, which are mostly sets of text padded with zeroes to make them align on 32-byte boundries (which corresponds with the alignment data provided by objdump -h mgmt.o). The text appears to be format strings for error/status messages as the strings are: .1.3.4 bulk_write: %s bulk_read: %s Preceding (timeout) error messages are normal. /tmp/.udsl_client%d Modem initialised at %d kbit/s downstream and %d kbit/s upstream. Modem initialisation lost. Directory %s does not exits. 0123456789 %s/%s Usage: %s etc.... The ".1.3.4" looks suspiciously like a version number and the offset of that is *immediately* after the 8 bytes of termination match data. This may or may not be useful, depending on whether it is always in the same place relative to the termination match. If you have done the objcopy thing, and know how to, could you report what is immediately after the end match data, so we can see if it is there in the versions of the driver that are in the field. I am not sure why they are in the same elf segment, but they are read-only data so I suppose it is not unreasonable. They would appear to be RO data for the i386 part of the system. A little more looking around and I noticed that the hard-coded stuff in modem_run.c is *also* little-endian ARM code. Obvious now I think about it - it will be the other end of the download process. Except now I look again, the code supports the idea of not using that first set - when do we not? I shall be trying to work out what is going on in that first. I was hoping we would find it was nestling in some corner of the ELF somewhere, but I can't find it. Where did it come from originally? Hope that has been of some interest to someone. This is my first real attempt at trying to reverse engineer something like this, so if anyone has and gotchas that I should avoid, speak up. Peter -- Peter Riocreux, Amulet Group, Dept. Computer Science, Manchester University, Oxford Road, MANCHESTER, M13 9PL, UK. <http://www.cs.man.ac.uk/amulet/> Voice: +44 161-2753547 Mobile: +44 7970-611366 Fax: +44 161-2756236 Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
