Firmware herunterladen (EZUSB, FX2)

NTSTATUS DownloadIicMem(IN PDEVICE_OBJECT Dev, IN PBYTE p, LONG len) {
// Firmware von IIC-Speicherabzug laden - len zur Vermeidung von UAEs
// Die IIC-Datei enthält erfreulicherweise am Ende den Kode zum
// Start der Firmware auf dem µC
 PURB U;
 WORD Len,Adr;
 BYTE e;
 NTSTATUS ret=STATUS_INVALID_PARAMETER;
 if (!p) return ret;
 if (len<12) return ret;
 switch (p[0]) {
  case 0xB2: p+=7; len-=7; break; // EZUSB-Kennung, Daten beginnen nach 7 Bytes
  case 0xC2: p+=8; len-=8; break; // FX2-Kennung, Daten beginnen nach 8 Bytes
  default: return ret;
 }
#define USIZE sizeof(struct _URB_CONTROL_VENDOR_OR_CLASS_REQUEST)
 U=ExAllocatePoolWithTag(NonPagedPool,USIZE,'ls#h');
 if (!U) return STATUS_NO_MEMORY;
 do{
  ret=STATUS_DATA_ERROR;	// hier: ungültiger Aufbau der IIC-Daten
  len-=4; if (len<0) break;
  e=p[0];			// Bit7: Ende
  Len=MAKEWORD(p[1],e&0x7F);	// Len und Adr...
  Adr=MAKEWORD(p[3],p[2]);	//...liegen big-endian vor
  p+=4;
  len-=Len; if (len<0) break;
  RtlZeroMemory(U,USIZE);	// Muss immer wieder gelöscht werden!
  U->UrbHeader.Length	=USIZE;
  U->UrbHeader.Function	=URB_FUNCTION_VENDOR_DEVICE;
  U->UrbControlVendorClassRequest.Request=0xA0;
  U->UrbControlVendorClassRequest.TransferBufferLength=Len;
  U->UrbControlVendorClassRequest.TransferBuffer=p;
  U->UrbControlVendorClassRequest.Value=Adr;	// Zieladresse im µC
  ret=CallUSBD(Dev,U); if (!NT_SUCCESS(ret)) break;
  p+=Len;
 }while (!(e&0x80));			// Solange bis Endekennung
 ExFreePool(U);
#undef USIZE
 return ret;
}

Einige Dinge wurden in den Kernel-Headern schlichtweg „vergessen“:

typedef USHORT WORD,*PWORD;
typedef UCHAR BYTE,*PBYTE;
#define LOWORD(x) ((WORD)(x))
#define HIWORD(x) ((WORD)((x)>>16))
#define MAKEWORD(lo,hi) ((WORD)((hi)<<8|(lo)))

Weil es im Kernel-Mode keine Funktionen zum Zugriff auf (irgend)eine Ressource gibt, muss man zu Fuß die Ressource laden. Einfach wäre das mit eingeblendeten Dateibereichen (memory mapped executable file), aber – falls es überhaupt geht – ich weiß nicht wie. Außerdem will man vielleicht auch mal eine externe Datei öffnen.

So wie hier dargestellt beschränkt sich die Funktionalität auf Windows 2000 und Windows XP!

NTSTATUS OpenFileForRead(OUT PHANDLE hFile, IN PUNICODE_STRING FName) {
 NTSTATUS ret=STATUS_SUCCESS;
 IO_STATUS_BLOCK ios;
 OBJECT_ATTRIBUTES oa;
 InitializeObjectAttributes(&oa,FName,OBJ_CASE_INSENSITIVE,NULL,NULL);
 ret=ZwCreateFile(hFile,GENERIC_READ,&oa,&ios,NULL,0,FILE_SHARE_READ, 
   FILE_OPEN,FILE_SYNCHRONOUS_IO_NONALERT,NULL,0);
// Zweckmäßig ist an dieser Stelle eine Fehlerausgabe, weil hier
// erfahrungsgemäß öfter etwas schief geht.
 return ret;
}

static NTSTATUS ReadAt(IN HANDLE hFile, ULONG pos, OUT PVOID ptr, ULONG len) {
// Lesen aus einer (binären, <4GB) Datei ab einer bestimmten Position
 NTSTATUS ret;
 IO_STATUS_BLOCK ios;
 LARGE_INTEGER start;
 start.LowPart=pos;
 start.HighPart=0;
 ret=ZwReadFile(hFile,NULL,NULL,NULL,&ios,ptr,len,&start,NULL);
 if (!NT_SUCCESS(ret)) return ret;
 if (ioStatus.Information!=len) return STATUS_END_OF_FILE;
 return ret;
}

Die Suche nach dem String ".rsrc" löst dieses Problem – nicht ohne Nebenwirkung: Die Echse (oder Treiber) muss mit VisualC erstellt werden! Dass der gleiche Sektions-Name in Borland-Produkten verwendet wird, wäre Zufall. Über eine DEF-Datei ließen sich diese Bezeichner auch einstellen, aber wer kennt die heute noch? (Aber: es gibt sie noch!) Linker-Optionen tun ein übriges.

NTSTATUS LoadRCData(IN HANDLE h, WORD id, OUT PBYTE* ptr, OUT PULONG len) {
// Lädt RCDATA-Ressource aus Datei im Kernel-Mode - NUR numerische IDs
 WORD w,w1,w2;
 ULONG l,p,p0,i;
 NTSTATUS ret;
#define READ(pos,p,l) {ret=ReadAt(h,pos,p,l); if (!NT_SUCCESS(ret)) return ret;}
 READ(0,&w,2);
 if (w!='ZM') return STATUS_DATA_ERROR;
 READ(0x3C,&p,4);
 READ(p,&l,4);
 if (l!='EP') return STATUS_DATA_ERROR;
 READ(p+6,&w1,2);		// NumberOfSections
 READ(p+0x14,&w2,2);		// SizeOfOptionalHeader
 p+=0x18+w2;
 for (i=w1; i; i--) {		// Suche Verweis auf Ressourcen (per Name)
  char buf[6];
  READ(p,buf,6);
  if (*(PULONG)buf=='rsr.' && ((PUSHORT)buf)[2]=='c') goto f0;	// * s.u.
  p+=0x28;			// sizeof(IMAGE_SECTION_HEADER)
 }
 return STATUS_RESOURCE_DATA_NOT_FOUND;
f0:
 READ(p+0x0C,&l,4);		// VirtualAddress
 READ(p+0x14,&p,4);		// PointerToRawData
 l-=p0=p;			// Differenz (wichtig!!)
 READ(p+0x0C,&i,4);		// NumberOfEntries
 w1=LOWORD(i); w2=HIWORD(i);
 p+=0x10+8*w1;			// NumberOfNamedEntries übergehen
 for (i=w2; i; i--) {		// Suche RCDATA-Ressourcen
  READ(p,&w,2);
  if (w==(WORD)/*RT_RCDATA*/10) goto f1;
  p+=8;				// sizeof(IMAGE_RESOURCE_DIRECTORY_ENTRY)
 }
 return STATUS_RESOURCE_TYPE_NOT_FOUND;
f1:
 READ(p+4,&i,4);
 p=p0+(i&0x7FFFFFFF);
 READ(p+0x0C,&i,4);		// nochmal dasselbe
 w1=LOWORD(i); w2=HIWORD(i);
 p+=0x10+8*w1;
 for (i=w2; i; i--) {		// Suche Ressource mit passender ID
  READ(p,&w,2);
  if (w==id) goto f2;
  p+=8;
 }
 return STATUS_RESOURCE_NAME_NOT_FOUND;
f2:
 READ(p+4,&i,4);
 p=p0+(i&0x7FFFFFFF);
 READ(p+0x14,&i,4);		// erster (einziger) Eintrag
 p=p0+i;
 READ(p,&p0,4);
 p0-=l;
 READ(p+4,&l,4);
 if (ptr) {
  *ptr=ExAllocatePoolWithTag(PagedPool,l,'ls#h');
  if (!*ptr) return STATUS_NO_MEMORY;
  ret=ReadAt(h,p0,*ptr,l); if (!NT_SUCCESS(ret)) ExFreePool(*ptr);
 }
 if (len) *len=l;
 return ret;			// müsste hier STATUS_SUCCESS sein
#undef READ
}

Ressourcen sind in Win32 stets in drei „Verzeichnisse“ gegliedert:

1. Typ (also DIALOG, STRING, VERSIONINFO, RCDATA usw.)
2. Nummer oder Name (mehrere Dialoge usw.)
3. Sprache (gleicher Dialog in mehreren Sprachen möglich – man glaubt es kaum!)

Das lokale Makro READ erspart viel Tippaufwand – und erzeugt dennoch kugelsicheren Kode.

Diese recht simpel zu verwendete Routine liefert im Erfolgsfall einen Speicherzeiger und die Länge des Speicherblocks. Der Aufrufer muss den gelieferten Speicherzeiger freigeben, mit ExFreePool().

Die Beschränkung auf RCDATA und numerische IDs sollte in der Praxis unwesentlich sein. Ein Treiber wird sich wohl nie für Dialog-Ressourcen interessieren.

String-Ressourcen erscheinen wohl noch interessant, aber dafür (dagegen?) hat Microsoft schon längst MessageTables ersonnen.

NTSTATUS DownloadFileFW(IN PDEVICE_OBJECT Dev, IN PUNICODE_STRING FName, WORD id) {
// Lädt Firmware aus RCDATA-Ressource einer (beliebigen) EXE/DLL/SYS-Datei
 NTSTATUS ret;
 HANDLE h;				// Datei-Griff
 PBYTE ptr;
 ULONG len;
 ret=OpenFileForRead(&h,FName);		// (Ausführbare) Datei öffnen
 if (NT_SUCCESS(ret)) {
  ret=LoadRCData(h,id,&ptr,&len);	// IIC-Ressource laden
  if (NT_SUCCESS(ret)) {
   ret=DownloadIicMem(Dev,ptr,len);	// Speicher-Abbild downloaden
   ExFreePool(ptr);
  }
  ZwClose(h);
 }
 return ret;
}

Man muss ihn aus der Registry lesen. Er steht unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\<Treibername>:ImagePath. Den Schlüssel-Namen (bis zum Doppelpunkt) bekommt man bei DriverEntry() zugestellt; den muss man sicherstellen. Einziger Speicherort (für den Anker) ist eine globale Variable. Den String-Speicher müssen wir bei DriverUnload() wieder freigeben.

UNICODE_STRING gRegPath;

NTSTATUS DriverEntry(IN	PDRIVER_OBJECT drv, IN PUNICODE_STRING RegPath) {
 NTSTATUS ret;
 
 ret=AllocUnicodeString(&gRegPath,RegPath.Length+2);
 if (!NT_SUCCESS(ret)) return ret;	// Fatal!
 RtlCopyUnicodeString(&gRegPath,RegPath);
 //... usw. ...
}

VOID DriverUnload(IN PDRIVER_OBJECT drv) {
 FreeUnicodeString(&gRegPath);
}

Ja, die Funktionen AllocUnicodeString und FreeUnicodeString hat Microsoft mal wieder vergessen mitzugeben. Deshalb hier ihre Implementierung:

// Vermisste RtlXxx-Routinen - buflen in BYTES, nicht in ZEICHEN (wie in Win32)
NTSTATUS AllocUnicodeString(OUT PUNICODE_STRING u, ULONG buflen) {
 RtlInitUnicodeString(u,NULL);
 u->Buffer=ExAllocatePoolWithTag(NonPagedPool,buflen,'1s#h');
 if (!u->Buffer) return STATUS_NO_MEMORY;
 u->MaximumLength=(WORD)buflen;
 return STATUS_SUCCESS;
}
// Leider weiß ich nicht, ob RtlFreeUnicodeString() das gleiche tut.
VOID FreeUnicodeString(IN PUNICODE_STRING u) {
 if (u->Buffer) ExFreePool(u->Buffer);
}

• C:\WINNT\System32\drivers\<sysname>.sys
• %SystemRoot%\System32\drivers\<sysname>.sys
• \??\C:\WINNT\System32\drivers\<sysname>.sys
• \SystemRoot\System32\drivers\<sysname>.sys
• System32\drivers\<sysname>.sys

Die ersten beiden Punkte zeigen gewöhnliche Pfade. Ein Zeichen für User-Mode-Sachen (DOS und Win32, um genau zu sein.)

Aber haben Sie auf Ihrer Festplatte schon mal das Verzeichnis "\??" gefunden? Ich auch nicht. "\SystemRoot" auch nicht. Dies ist das Kernel-Mode-Verzeichnis-System! Hierin ist "\SystemRoot" sovielwie C:\WINNT (wo auch immer es auf Ihrer Festplatte liegt) und "\??\" ein Präfix, um auf DOS- und Win32-Pfade zugreifen zu können.

Wichtig zu wissen ist, dass "\SystemRoot" früh beim Bootvorgang festliegt, "\??" erst wenn das Win32-Subsystem initialisiert ist.

USB-Treiber habe ich nur in der letzten Form vorgefunden. Daraus folgt, dass USB-Treiber nur unterhalb von C:\WINNT liegen dürfen. Schließlich könnten die Treiber sehr früh geladen werden, wenn das Gerät bereits dran steckt und bspw. vor dem Einloggen notwendig sind (da denke ich an Tastaturen und Mäuse – und Fingerkuppenscanner).

Man muss zu Fuß "\SystemRoot\" davorsetzen. Die soeben implementierten Unicode-String-Funktionen vereinfachen diesen Vorgang erheblich.

#define SYSTEMROOT L"\\SystemRoot\\"

NTSTATUS DownloadInternalFW(IN PDEVICE_OBJECT Dev, WORD id) {
// Lädt Firmware aus RCDATA-Ressource der eigenen .SYS-Datei
 NTSTATUS ret;
 UNICODE_STRING IName,FName;
 RTL_QUERY_REGISTRY_TABLE Query[2];	// Stack == NonPagedPool

 RtlInitUnicodeString(&IName,NULL);
 RtlZeroMemory(Query,sizeof(Query));
 Query->Flags=RTL_QUERY_REGISTRY_DIRECT;
 Query->Name=L"ImagePath";
 Query->EntryContext=&IName;
 Query->DefaultType=REG_SZ;
 Query->DefaultData=L"";
 ret=RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE,gRegPath.Buffer,Query,NULL,NULL);
 if (!NT_SUCCESS(ret)) return ret;
 ret=AllocUnicodeString(&FName,IName.Length+sizeof(SYSTEMROOT));
 if (!NT_SUCCESS(ret)) return ret;
 RtlAppendUnicodeToString(&FName,SYSTEMROOT);
 RtlAppendUnicodeStringToString(&FName,&IName);
 FreeUnicodeString(&IName);
 ret=DownloadFileFW(Dev,&FName,id);
 FreeUnicodeString(&FName);
 return ret;
}