Forums d'entraide informatique - Astuces - Conseils

Cet article présente une étude concernant le système Windows CE sur terminal mobile. Il présentera les nouveaux risques associés à l'utilisation d'un système ouvert sur un téléphone mobile. Le modèle de sécurité de Windows CE sera ici évalué et des méthodes permettant d'exploiter ses faiblesses seront présentées. Il est à noter que les autres systèmes que Windows CE ont également leurs faiblesses (Symbian OS par exemple) et qu'actuellement aucune solution satisfaisante sur le plan de la sécurité n'est disponible.
Introduction du contexte
Deux systèmes dominent actuellement le marché des terminaux mobiles de dernière génération : Symbian et Windows Mobile, ce dernier faisant l'objet de cet article. Bien évidemment, à l'idée d'évolution technologique des téléphones portables, il faut penser aussi à celle des technologies associées. En effet, l'introduction de systèmes ouverts autorisant l'installation et le développement d'applications a fondamentalement changé la donne de la sécurité sur les terminaux mobiles. Les premières menaces, relativement anodines ([0], [i]), sont apparues très précisément avec l'introduction de ces nouveaux systèmes offrant des poss;bilités importantes et en parallèle introduisant de nouveaux risques.
L'étude présentée ici se concentre plus particulièrement sur les SmartPhone et PocketPC qui utilisent Windows Mobile, un dérivé de Windows CE. Deux versions majeures de ce système existent Windows Mobile 2002 (SPV E100, M1000) qui est construit sur Windows CE 3.0 et Windows Mobile 2003 (SPV E200, M2000) reposant lui sur Windows CE 4.2 (.NET). Un très récent article [2] détaille les différences essentielles de la gestion de la mémoire sur ces environnements. Il est par ailleurs à noter qu'il existe depuis peu Windows Mobile 2005 (Magneto) que nous ne traiterons pas, faute de tests appropriés. Dans la suite de l'article, nous nous intéresserons aux différentes techniques pouvant être employées sur ces environnements pour la réalisation de backdoors. Après un rapide rappel de l'architecture mémoire de Windows CE, nous parlerons de la création de backdoors user/and et expliquerons leurs limites. Nous introduirons alors les backdoors noyau et verrons dans quelle mesure elles sont réalisables. Enfin, nous conclurons notre étude par l'inventaire des moyens mis à disposition des utilisateurs pour se prémunir de tels dangers.
Protection de ta mémoire virtuelle et notion de certification de module
Windows CE possède une organisation de la mémoire virtuelle relativement atypique. La bonne documentation ne manquant pas ([3], [4] et plus récemment [5]), dans le cadre de cet article, nous nous contenterons d'en rappeler les principes majeurs.
Ce qu'il est important de retenir se résume en quelques points
Z. La mémoire virtuelle (VM) est adressée sur 32 bits, 2 Go de cette mémoire étant réservée au noyau (0x80Z00000 - OxFFFFFFFi--).
IM L'espace d'adressage virtuel réservé aux applications est divisé en un nombre limité de slots de 32 Mo (64 Mo pour Windows CE .NET), chacun d'eux étant occupé par un processus bien précis. Ceci implique que le nombre de processus soit limité sous Windows CE contrairement au nombre de threads (en théorie du moins). Le slot 0 est quant à lui réservé au processus courant, c'est-à-dire au processus auquel l'ordonnanceur a donné la main.
MM Une application ne peut pas accéder à l'espace d'adressage, donc au slot, d'un autre processus. Toute tentative d'accès à cette mémoire déclenche en effet une exception.
▪    La plupart des API système ainsi que quelques routines clefs
du kernel fonctionnent en accédant directement aux champs de la structure KDat.Struct dont on peut bien évidemment trouver la définition dans les sources du noyau de VVindow CE mais également sur Internet [5]. Un point intéressant est que sur architecture ARM, cet objet se situe à l'adresse statique OxFFFRC802`.
Alors que les autres versions de Windows fondent la restriction d'utilisation d'API sensibles sur les droits des utilisateurs, Windows CE, lui, fonctionne complètement différemment. À chaque module (exécutable, bibliothèque, driver), est en effet associé un niveau de privilège qui peut être CEM CERTIFY_TRUST pour un module certifié possédant tous les privilèges (le module est signé par l'intégrateur). OEM_CERTIFY_RUN pour un module à accès restreint (l'utilisation des Trusted API, qui est une gamme d'API sensible lui est interdite) ou OEM_CERTIFY FALSE pour un module interdit de chargement.
Deux fonctions sont utilisées par le noyau pour gérer la certification des applications OEMCertifyhloduleInit() qui est appelée lors de l'initialisation de tout module non issu de la ROM et OEMCertifyModule() qui s'occupe de la vérification proprement dite à l'aide de la clef publique de l'intégrateur stockée dans la mémoire même du noyau.
Ce mécanisme est intéressant dans la mesure où il permet d'interdire l'utilisation des Trusted API, dont on trouvera une liste exhaustive sur [6],


à toute application non référencée par l'intégrateur donc potentiellement dangereuse. En effet, lorsqu'une application non signée par l'intégrateur est exécutée via Shel 1 ExecuteEx0 ou (Ce) C reateProce ss 0 sur un Smartphone, alors l'utilisateur reçoit un avertissement lui demandant s'il autorise l'exécution du code. Si oui, le code en question passe en niveau OFM_CERTIFY_RUN. Dans le cas contraire le code est rejeté. Raisonnablement, on peut considérer que le niveau de sécurité global du mobile est alors très correct, à l'exploitation de bugs de sécurité près, tant au niveau du mécanisme de vérification de la signature que du noyau [7], si les niveaux de privilèges sont bien définis.
Il est cependant essentiel de rappeler que le marché visé par Microsoft avec Windows CE est celui de l'embarqué. De ce fait, Microsoft fournit, moyennant finance, un kit complet de développement appelé « Platform Builder » [8] qui permet de recompiler Windows CE pour une plate-forme donnée. Ce kit comprend un IDE (Integrated Development Environment), une abondante documentation ainsi qu'une très grosse partie des sources de Windows CE ce qui a permis aux intégrateurs de fournir des produits à base de Windows CE plus ou moins différents d'un équipement à un autre.
Ce qu'il est important de noter est que le mécanisme noyau de certification des modules est activé en initialisant les variables globales pOEMCerti fyModule et pOEMLoadModul e de la fonction OEMInit() de l'OAL (OEM Adaptation Layer) respectivement avec les adresses de CEMCerti fyModul eIni t 0 et OEMCerti fyModul e ( ). Les intégrateurs, devant la pression des utilisateurs, ont alors fait le choix de désactiver à la compilation cette protection sur la gamme des Pockets PC, ainsi que de fournir un utilitaire (SecurityOff) pour la désactiver sur les SmartPhones, ceci afin de favoriser le développement et l'installation d'applications tierces telles que des jeux.
Malheureusement, ce choix contestable donne l'accès aux Trusted API à tout code non signé présent sur le mobile. Un code malicieux pourra alors, par exemple, appeler quelques API au nom relativement évocateur :
▪    DebugActi vePr ocess 0 qui permet de se déclarer parent
debugger d'un processus;
▪    LoadDri ver( ) qui permet le chargement d'un driver dans l'instance du programme;
▪    Load Kernel Li brary 0 qui permet le chargement d'une DLL dans l'espace du noyau;
{ Read,Write}ProcessMemory 0 qui permettent respectivement de lire et écrire dans la mémoire d'un autre processus;
▪    SetKMode{) qui permet de passer un processus en kernel mode;
Avec de telles API, on peut envisager d'injecter du code dans certains processus et de détourner alors certaines de leurs fonctions clefs. Ce type d'infection est relativement commun
dans le monde Windows et les techniques employées sont similaires, aussi verrons-nous comment adapter ces techniques au monde des plates-formes mobiles. On peut également se poser la question de la création de backdoors kernel, ce qui sera l'objet d'une réflexion à part. On pourrait croire à tort qu'un code malicieux nécessite obligatoirement le niveau d'exécution OEM CERTI FY TRUST, mais il n'en est rien car les contraintes liées à un réseau de télécommunication mobile sont bien différentes de celles d'un réseau informatique classique. Il est en effet essentiel pour l'opérateur :
De garantir la sécurité des informations de l'usager, que ce soit celles contenues dans sa carte SIM ou celles contenues dans la Flash du mobile ;
ffll De protéger l'usager de toute utilisation abusive du mobile qui entraînerait une surfacturation ;
ffl Que l'intégrateur fournisse un mobile résistant aux attaques. Le mobile ne doit en effet pas être détérioré et son fonctionnement global ne doit pas être altéré (impossibilité de passer des appels ou d'envoyer des SMS, carte SIM bloquée, etc.).
Or le problème posé avec les API fournies par Microsoft pour un niveau de privilège au moins égal à OEM_CERTIFY_RUN est qu'il permet l'utilisation :
De technologies de type GPRS ou Bluetooth qui sont susceptibles de devenir des vecteurs de propagation virale;
IM D'API liées à la téléphonie et aux SMS, ce qui peut permettre d'engendrer une surfacturation de la consommation de l'usager;
MI D'API de manipulation de la SIM ainsi que d'accès aux fichiers ce qui implique une mauvaise protection des données de l'usager;
Infection de processus, mode d'emploi
Dans la mesure où les dangers liés au niveau d'exécution OEM_ CERTIFY RUN ne nécessitent pas vraiment d'autre connaissance que celle de l'utilisation d'API en langage C, il n'est pas utile de les détailler plus. En ce qui concerne les infections de processus sous Windows (2k,XP), il existe principalement trois techniques que nous ne détaillerons pas, l'excellent article de Kdm [13] le couvrant de façon bien plus détaillée que nous ne pourrions le faire en quelques lignes :
L'utilisation de CreateRenoteThread 0 permet de démarrer un nouveau thread dans un processus, ce qui permet naturellement l'exécution de code malicieux.
1M En définissant un hook par l'utilisation de SetWindowshookExi) qui permet l'exécution de code arbitraire pour un type de message donné, pour une application donnée
local) comme pour l'ensemble des applications de l'espace utilisateur aux problèmes de droits près (hook global).
On peut également se déclarer parent debugger du processus cible, manipuler le contexte d'un thread particulier (tout processus a toujours au minimum un thread principal) et ainsi rediriger le flux d'exécution.
Alors que la première technique est irréalisable sous Windows Mobile puisque l'API CreateRemoteThread 0 est indisponible sur ce type de plate-forme, la seconde devrait a priori, elle, l'être. En effet, bien que non documentée par Microsoft, la fonction SetWindowsi-lookEx0 existe bel et bien dans la bibliothèque corecil 1. dil partagée par tous les processus.
En revanche, elle est clairement incomplète et ne permet de hooker que les messages de type WH_KEYBOARO_LL ce qui est néanmoins sensible dans la mesure où cela permet de réaliser potentiellement un keylogger très simplement.
En ce qui concerne la troisième méthode, il faut savoir qu'elle possède un certain nombre de contraintes
IM Elle repose sur un très grand nombre de Trusted API, ce qui implique un niveau d'exécution ClEM_CERTIFY TRUST. Elle n'est donc pas applicable sur un SmartPhone pour lequel le mécanisme de signature n'a pas été désactivé via SecurityOff, mais l'est nativement sur un PocketPC.
IM Certains processus ne peuvent pas être déboges sous Windows Mobile. Si par exemple un code malicieux tente de déboger NK.exe, qui est le processus correspondant au noyau, ou GWES.exe, qui est celui responsable de la gestion des drivers, alors le système plante et un reset est nécessaire.
La portabilité ne peut pas toujours être garantie d'un mobile à un autre, puisque les intégrateurs sont dotés des sources et les recompilent à leur guise. En particulier, certains champs dans certaines structures clefs sont susceptibles d'être supprimés. A contrario, certains pourraient tout à fait être ajoutés même si cela reste moins vraisemblable puisque la tendance est à l'économie de la mémoire dans l'embarqué.
La portion de code suivante illustre le fonctionnement de l'attaque
1-1
hSnapshot = CreateToo1lielp32Snapshot(I1132(S_SNAPMODULEl TH32CS_SNAPPROCESSIT1132CS_SHAPTHREAO, 0);
if(!hSnapshot)
GetLastError(); retorn -1;
ifiProcess32First(hSnapshot, &lppel)
do{
1.-.1
if(!strcep(TARGET_PROCESS, szExeFileAnsi))
flyld    lppe.th32Process10;
break;
whi1e(Pretess32tlextaSnapshot, lippe));
CloseToolhelp32Snapshot(hSnapshot);
pAddr = VirtualAlloc(MVOID)Ox4FC0000O, 8x2(l0g, MEM_COMMIT, PAGE_EXECUTE3EAOWRITE);
eielicpy(pAddr, ShellCode, ShellCodeLen);
1* Lets debug the taret process *1 if) DebugActiveProcess(Myld))
goto end;
while(1)
1,..]
if(WaitForDebugEvent)&DehogEvent, 10011 1...1
if((suspend = SuspendThread(hThread) >= 01 fprintf(logit, "Thread OFF\n");
raemet(Picontext, 0, sizeof(CONTEXT)); cohtext,ContextFlags    CONTEXT_FULL;
iffetTbreadContext(hThread, kontextl) if(!shellcode_patched)
memcpy(pAddr, &context.Pc, 41; shellcode_patched++;
[...]
Context,Pc r (DWORDWDWORD)pAddr + 4); SetThreadContext(hThread, &tontext);
1...1
if(ResuraeThread(hThread) >. 0) fprintf(logit, "Thread ON\ n");
VirtualFree(pAddr, (42000, )IE11 JECOMT);
Le processus malicieux alloue une zone de mémoire via VirtualAlloc() de quelques pages avec des droits de lecture, écriture et exécution dans laquelle il copie un sheilcode. Il se déclare alors parent debugger du processus cible via DebugActiveProcess() puis redirige le flux d'exécution de l'un des threads du processus en question vers la zone mémoire allouée via SetThreadContext(). Cette façon de procéder est possible, car le premier paramètre passé à la fonction Virtua1Alloc() est une adresse mémoire, ici f1x4FC09 A(10, accessible à n'importe quel processus.
Infecter un processus peut être réalisé dans deux buts distincts exécuter du code malicieux dans l'instance d'un programme dont on sait qu'il ne sera pas contrôlé par un anti-virus ou détourner certaines fonctionnalités de ce programme. L'exemple le plus classique du premier cas est l'infection d'Internet Explorer sous Windows qui permet d'envoyer des informations via les sockets en toute furtivité puisque l'utilisation des API correspondantes est légitime de la part de Internet Explorer.
Le second cas correspond à la modification de l'IAT (Import Address Table) afin de réaliser des détournements (hook) de fonctions. Nos tests indiquent que sous Windows Mobile un processus même en tant que parent debugger ne semble pas pouvoir modifier la mémoire d'un autre processus par WriteProcessilemory() et ce, contrairement à la

En revanche, il peut s'automodifier, l'astuce présentée précédemment est donc la seule solution pour modifier l'IAT d'un processus donné. Nous ne détaillerons pas par la suite pas cette technique supposée bien connue du lecteur tant elle est classique. Intéressons-nous cependant un peu à la création de shellcodes.
Quoi qu'on en dise, la création de shellcodes, qui intervient à de multiples niveaux en sécurité, n'est pas toujours un exercice évident suivant l'architecture considérée. Toutefois, nous nous concentrons ici sur l'infection de processus, évitant de ce fait la très contraignante problématique des octets nuls.
Les articles [5], [IO], [I I] et très récemment [2], constituent d'excellentes références en la matière. Il en ressort un certain nombre d'idées clefs :
MO Pour construire du code position indépendant, la pseudo instruction adr permet d'adresser des chaînes ou des blocs de code sans avoir recours à une astuce particulière pour déterminer la position de l'objet en question.
ffl Pour appeler une API, on peut le faire de deux façons : en déterminant l'adresse de ces API dans la bibliothèque concernée par l'utilisation des informations fournies dans KDataStruct ou en appelant directement les appels système concernés. Chacune des méthodes a ses avantages et ses inconvénients. Le principal avantage de la première est sa plus grande portabilité alors que la seconde permettra d'obtenir des shellcodes de taille réduite.
Quelle fonctionnalité intelligente pouvons-nous donner à notre shellcode ? Puisqu'un bon sheilcode est un petit shellcode, alors il est souhaitable de n'appeler que le plus petit nombre d'API possible. Dans le cas d'une infection de processus, appeler la fonction Loadlibrary 0, qui chargera une bibliothèque malicieuse est judicieux. C'est en effet extrêmement pratique et ce pour deux raisons :
▪    Le code dans cette bibliothèque sera écrit en C donc portable et pouvant être relativement complexe sans que cela gène l'attaquant outre mesure.
▪    Les bibliothèques de Windows ont la possibilité d'exporter
un entry point, et du code sera donc automatiquement exécuté au chargement de la bibliothèque ce qui évite d'avoir à appeler ses fonctions à partir du shellcode.
Les [imites du détournement d'API
La méthode précédente repose sur le détournement d'API, en conséquence une application peut détecter son emploi en opérant à un plus bas niveau, celui du noyau. On a vu précédemment que l'objet KDataStruct était employé par certaines API système et autres routines du noyau.
Or cet objet est accessible à une adresse fixe en lecture/écriture à tout processus en kernel mode, c'est-à-dire dans le mode processeur pour lequel les 5 premiers bits du registre Psr sont mis à SYSTEM_MODE. Un processus malicieux dans un tel mode peut alors s'affranchir complètement de l'utilisation de certaines API en manipulant judicieusement certains champs de cet objet.
Aussi surprenant que cela puisse paraître, un processus démarre en kernel mode sur la gamme des Pocket PC
La raison qui justifie ce choix est celle de l'abandon de l'encombrant contexte utilisateur, ce qui permet d'accroître les performances. En contrepartie, outre une réduction de la stabilité de l'OS, tout processus peut accéder librement à la mémoire de donnée du noyau, ce qui constitue une faille de sécurité énorme. Ratter a vraisemblablement été, avec DUST, le premier à exploiter pleinement cet état de fait.
Sur la gamme des SmartPhones, le passage provoqué d'un processus en kernel mode ne peut se faire qu'en utilisant la Trusted API SetiOlocle 0, ce qui limite considérablement les risques puisque seul un module certifié aura alors accès à KDataStruct. À titre d'exemple, la portion de code suivante permet de lister les processus tournant sur le système. Puisqu'il ne repose pas sur l'API CreateTool h el p32Smapshat ( 1, il n'est pas possible de Je hooker avec la technique précédente. De ce fait, un processus caché de l'Explorer par exemple serait alors révélé.
1=include "stdafx.h"
I/ contient la definition de certaines structures non puhiiques
Pinclude "pswithout_api.r
FILE *logit reL;
/1 Trusted APIs
extern ''C" DWORD SetProcPermissiors(DWORD deerms);
extern '1C" NORD SetCode(BOOL toto);
/*
* Or suppose que les tailles des structures sont alignées sur 4 octets.
* Or se donne 10% de marge sur la taille de la structure. */
NORD GimmeOffset(struct KDataStruct *k)
DWGRO BigOffset = 0, Offset = 0;
DWORD Min = 0, Max = 0;
NORD die = 0;
DWORD i = 0;
/* Les deux champs de K utilisés sont critiques
/* et les champs d'avant aussi.
* Or peut donc postuler que ces pointeurs sont valides. */ BigOffset    ((0M0RD)k->pCurPrc - k->aInfoEKIN)LPROCARRAY1;
Min = (OWORD)10.9 * (sizeof(PROCESSI - sizeof(PROCESS) % 411;
Min -= Mir;%4;
Max = (DMORD)(1.1* (sizeof(PROCESS) - sizeof(PROCESS)    4)1;
Max -= Max%4;
for(i = Min; i <= Max; i+.4)
div = (DWORD)(BigDffset/i);
if( BigOff set == (div *
return i;
return 0;
* Fonction d'affichage de la liste des processus
*/
void DumpKernelInfo()
struct KDataStruct *k= (struct KDataStruct ifixffffc800; PPROCESS prou = MIL;
DWORD offset = 0;
int j = 0;
fprintf(logit, "sizeof(PROCESS) = %d Oytesln", GimmeOffset(k)1; for(j=0; jalnto[KIRX_PROCARRAY] + offset11;
else
return;
if(j==ti [I proc->procnum)

WideCharToMultiByte(CP_ACP, 0, proc->lpszProcNavie,
-1, buffer, sizeoftbuffer), NULL, NULL); fprintf    proie %p [%siln",j++, proc, buffer);
rets ro;
int WINAPI WinMain(HINSTANCE hinstance, HINSTANCE erevInstance, tPTSTR 1pCivitine,
int nCmdShow)
BOOL bMcde    SetKMode(TRUE);
BORD dwPerm = SetProcPermissions(OxFFFEFFFF); logit    fopen("Kernel-Map.txt", Y);
Ilumgernellnfo();
l* Restauration des privilèges *I SetProcPermissions(dwPerm);
SetKMode(bMode);
/* Bye */ fcloselogit);
return 0;
1
Le champ a-Info de KDataStruct est un tableau de pointeurs dont
l'un est l'adresse du tableau d'objets PROCESS, chacun d'entre eux pouvant décrire un processus donné. Le code précédent accède
donc à ce tableau et écrit dans le fichier Kerne] -tlap.txt le nom
des différents processus du système.
Toutefois, ainsi que nous l'avons évoqué précédemment, un problème susceptible de survenir est la modification de champs dans certains objets clefs du noyau (ici dans la structure PROCESS) par les intégrateurs.
Dans ces conditions, lors du parcours du tableau de PROCESS, il est risqué d'employer des raccourcis usuels du langage C de type proc++. Cette manipulation repose en effet sur le calcul implicite par le compilateur de la taille de l'objet et, puisque les sources de celui-ci ont peu de chance de correspondre exactement à la réalité, le calcul sera erroné. Le code précédent emploie donc une petite astuce qui permet d'accroître sensiblement la portabilité.
L'idée de départ est que KOataStruct fournit deux adresses d'objets PROCESS différents : le pointeur sur l'objet PROCESS du début de tableau et celui correspondant au processus courant. De ce fait, on en déduit un multiple de si zeof (PROCESS).
La détermination de la bonne taille se fait en supposant que celle- ci sera proche de la taille de la structure PROCESS dont on possède les sources à une erreur de 10% près. Ce code a été testé avec succès sur Pocket PC M1000 et M2000, ainsi que sur HP IPAQ RX 3715.
Aller plus loin, s'attaquer au noyau
Plus un code malicieux intervient à un niveau bas et plus il sera difficile pour le programme chargé de le détecter de mener à bien sa tâche. Cependant, bien qu'il soit souvent possible d'aller encore plus bas, le noyau a souvent été et vraisemblablement restera encore longtemps l'un des points clefs les plus étudiés par les attaquants.
Sur les Windows modernes classiques tels que 2000 ou XP, la corruption du kernel peut se faire de plusieurs façons, que ce soit par le chargement d'un driver comme par l'accès en lecture/
écriture à certaines interfaces type Device PhysicalMemory [14]. Quelle que soit la méthode employée, l'idée est toujours de détourner certaines fonctions clefs du kernel.
Dans le cas des SmartPhones et des Pocket PC, créer une backdoor kernel est plus compliqué et cela s'explique d'au moins deux façons
MM Le code du kernel est situé en ROM et exécuté depuis cet emplacement, ce qui signifie que toute technique liée à une modification directe de ce code, telle que celle décrite dans [15], est a priori impraticable.
IM L'ajout d'un driver sur le système correspond au chargement d'une dll via LoadDri ver ( ) dans l'instance du processus adéquat (Fi I eSy s exe, GWE S. ex e ou De v i ce .exe) et ce, suivant le type de driver. Il se s'agit donc pas de code kernel à proprement parler, mais cela ne signifie pas pour autant qu'il ne soit pas possible d'en tirer parti.
En dépit de ces limitations, force est de constater que l'architecture de Windows CE est néanmoins permissive puisque l'utilisation de la Trusted API LoadKernelLibrary() permet le chargement d'une DLL ayant les mêmes droits d'exécution que le noyau. Le seul inconvénient est que celle-ci ne peut pas importer de symboles, la DLL ne sera en effet pas chargée si elle possède une import table.
De ce fait, appeler une fonction du kernel revient à être capable de la localiser dans la mémoire, un problème bien connu... Pour réaliser un hook au niveau noyau, la solution est donc de remplacer certains pointeurs présents dans la mémoire de donnée du noyau par les adresses de fonctions présentes dans la DLL.
On peut envisager d'autres scénarios, mais celui-ci reste l'un des plus simples. À noter que cette méthode possède quelques inconvénients.
D'une part, la DLL ainsi chargée est visible comme DLL chargée par le processus NK.exe et, d'autre part, il est impossible de la décharger sans un reset, ce qui n'a pas que des inconvénients mais peut, dans certains cas précis, compromettre la furtivité.
Protéger son Pocket PC
On peut envisager deux voies de sécurisation des terminaux Lors de l'intégration de l'OS sur le terminal
Après l'achat du terminal par l'utilisateur.
En ce qui concerne la première étape, elle peut être réalisée par l'intégrateur comme par le concepteur de l'OS embarqué (ici Microsoft), puisqu'il s'agit d'une étape précédant la compilation. Bien évidemment, sécuriser un OS alors que ce n'était pas une contrainte initiale de développement coûte énormément d'argent en R&D.
Ce n'est donc a priori pas le concepteur qui effectuera une telle démarche de son propre chef sauf si cela lui semble absolument nécessaire. Ce travail de sécurisation passe essentiellement par un audit approfondi de l'API, du noyau ainsi que des services exécutés sur le mobile. Il consiste également en une éventuelle redéfinition de l'architecture de sécurité.

Dans le cas de Windows Mobile, il est clair que l'architecture n'est pas initialement problématique si l'on suppose le mécanisme de signature actif (donc compilé). Il pourrait être cependant judicieux de définir un certain nombre de niveaux d'exécution intermédiaires pour restreindre l'utilisation des API de communication GSM/GPRS ou les accès SIM. Un mécanisme alternatif tel que celui des capabilities proposé par Symbian OS pourrait en outre être tout à fait profitable. Bien que différentes solutions à base de VM (Virtual Machine) puissent être envisagées, les seules disponibles à ce jour sur le marché pour l'utilisateur sont le firevvall personnel et l'anti-virus.
Malheureusement, ceux-ci ne constituent absolument pas un rempart suffisant et ce pour plusieurs raisons
Le processus défensif ne dispose pas d'un niveau de privilège supérieur à celui des autres processus ce qui signifie qu'il peut être tué par une application malicieuse (donc non signée) via un simple appel à l'API TeraiteProcessO.
IM Le moteur de signature des antivirus est absolument insuffisant et apparaît comme relativement trivial à contourner, ce qui implique l'impossibilité de détection de variantes de codes malicieux connus.
Le lecteur l'aura compris, les logiciels de protection actuels pour mobiles sont relativement rudimentaires. Le problème ne vient pas forcément d'un manque d'implication des sociétés concernées, mais aussi de l'environnement cible. Dans le domaine de la téléphonie mobile, les équipements sont très peu puissants. En particulier, les OS type Windows Mobile ou Symbian occupent une grande partie des ressources. Il est donc impossible de réaliser des moteurs de détection comportementale, de lutter contre le polymorphisme, etc.
Plus critique, il est difficile de gérer un mécanisme de signature complexe faute de moyen processeur suffisant. N'oublions par ailleurs pas que toute exécution d'un code un peu lourd modifie sensiblement le temps de réaction du système, ce qui est perceptible par l'utilisateur, voire éventuellement altère certaines fonctionnalités essentielles du portable.
Conclusion
Plus d'un an après la publication du code source de DUST par Ratter, il est clair que le nombre de virus ou de worms apparus sur les terminaux Windows Mobile est plus que réduit, pour ne pas dire ridicule. Il serait cependant dangereux de s'en féliciter... Nous avons en effet vu que les moyens de défense des utilisateurs étaient encore extrêmement réduits or l'absence d'activité virale n'incite pas véritablement à un développement de la sécurité. Pourtant, les menaces sur ce type de plates- formes sont bel et bien réelles et si pour le moment la grande hétérogénéité du parc nous protège, il n'en sera pas toujours ainsi.