Discussion :

[Darz4]

Bonjour,

Je développe en ce moment (à titre de projet perso) un petit soft qui utilise l'API windows afin de lire un fichier en streaming à mesure qu'il est rempli par un programme tiers.

Je fais donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

HANDLE file = CreateFile(path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL) ;

Problème : CreateFile échoue si l'autre programme a déjà commencé à écrire dans le fichier.
L'autre programme n'écrit pas dans le fichier si cette ligne de code a déjà été exécutée.

Il y a comme qui dirait un genre d'inter-exclusion. Je suppose que l'appel à CreateFile du programme tiers se fait avec un paramètre dwShareMode à 0.

Ma question est donc : existe-t-il un moyen d'accéder tout de même à ce fichier en lecture, malgré l'accès exclusif imposé par le programme tiers ?
(Autrement qu'en modifiant le binaire dudit programme évidemment )

Merci

[bacelar]

Je ne pense pas qu'il y est de solutions élégantes et documentées à votre problème.
Vous voulez contrevenir directement aux systèmes de protection et de synchronisation mis en place par le système.
Je vous deux méthodes de contournement, mais aucune n'est facile à mettre en place.
- Développement d'un driver de système de fichier qui interceptera les requêtes de programme espionné
- Utilisation des mécanisme de shadow copy de l'OS pour copié le fichier en sous-main avec tout les problèmes que cela implique si le programme espionné ne gère pas correctement cette fonctionnalité.

Franchement, si le programme espionné n'est pas protégé contre le reverse-engineering, il sera plus simple de modifier le fichier espionné que de mettre en place les deux autres solutions.
Une modification dans le code assembleur au bon endroit et le tour est jouer.

Mais il faut que le fait que programme espionné est pris le mode exclusif sur le fichier par erreur et qu'il en n'est vraiment besoin.

Vérifiez que le programme source n'est pas une option pour modifier le type du canal de sortie.
Prenez la peine de lire très attentivement sa documentation.

[Darz4]

Avant tout, merci d'avoir pris le temps de me répondre.

Il s'agit de diffuser en streaming un fichier de replay qui est construit par l'exécutable d'un jeu tout au long d'une partie. Ainsi, si quelqu'un récupère le streaming du fichier, il peut assister à la partie en direct.

(Je précise qu'il ne s'agit en aucun cas de créer un programme de triche, le soft sera distribué à la communauté via les forums officiels)

Je n'ai donc malheureusement pas accès au code source de l'exécutable qui crée le fichier. La documentation technique est inexistante, et il est probablement protégé contre le reverse-engineering. Je l'ai désassemblé avec Win32DASM, mais impossible de trouver la moindre référence au nom du fichier en question dans les String Refs.

Par ailleurs le binaire faisant 13 Mo, autant dire qu'une fois désassemblé c'est absolument énorme. J'ai bien tenté de faire une recherche sur les appels à CreateFile, mais il y en a beaucoup trop.
Cela dit, mes connaissances en ASM se résumant à la base, peut-être me manque-t-il la méthode adéquate.

Comment procéder pour trouver dans le code ASM du programme l'endroit où il crée et commence à écrire dans ce fichier ?

[bacelar]

Ne pouvez-vous pas rediriger le streaming vers une socket ou un autre type de sortie ?

[Darz4]

L'exécutable du jeu n'a pas été conçu pour permettre à l'utilisateur de choisir le type de sortie où est écrit le fichier de replay

[Médinoc]

Pour commencer, as-tu testé en ajoutant FILE_SHARE_WRITE dans ton appel à CreateFile() ?

[Mat.M]

Salut,

Ma question est donc : existe-t-il un moyen d'accéder tout de même à ce fichier en lecture, malgré l'accès exclusif imposé par le programme tiers ?

si CreateFile échoue c'est parce que comme tu t'en doutes le fichier est verrouillé sur disque de manière exclusive...
donc tu ne pourras pas y accéder.
Il y a peut-être un possibilité c'est de créer un "pipe" ou appeler éventuellement CreateFileMapping.
Chercher dans le MSDN la section Interprocess Communications..

http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx

Problème : CreateFile échoue si l'autre programme a déjà commencé à écrire dans le fichier.
L'autre programme n'écrit pas dans le fichier si cette ligne de code a déjà été exécutée.

la problèmatique c'est que tu ne sais pas forcément avec précision quand le programme tiers ( le jeu ) ouvre des fichiers...
et si le jeu écrit des données dans des threads de manière asynchrone ?