PureBasic

Bonjour a tous,

Je bataille depuis quelques heures sur une chose un peu particulière.

J'ai 4 applications qui comportent le terme update dans leur nom, genre xxx-update-yyyyy.exe

Je compile chaque application en 32 et 64-bit et bizarrement, les applications en 32-bit passent en mode admin. Je précise qu'elles sont compilées sans l'option élévation.
Après de veines recherches, j'ai renommé les applications sans le terme update et là tout est OK, sauf que si je renomme l'application en incluant le terme update n'importe ou dans le nom, le symbole admin apparait au niveau de l'icône de l'exe.

J'ai fais la même chose avec des exe non PB, idem.

Avez vous la même chose chez vous, sous Windows 10 / 64-bit

cage

Mdr on a pas fini d'en voir de belles avec Cro$oft ^^

Bonjour,

Je confirme, je viens de faire la même chose avec un de mes codes et si je met update dans le nom, il passe en admin. Bizard ^^

GallyHC

Bonjour,

Merci GallyHC, cela me rassure car j'avais la crainte que se ne soit autre chose.

cage

Non rien de bizarre à ça.
En fait j'ai perdu un temps de dingue avant de comprendre que ça venait de windows ou au pire de l'antivirus (norton ici)
Je me bat contre ce phénomène de merde depuis les nombreuses années ou je l'ai découvert,je crois même en avoir parlé sur ce forum..

Tu devrais peut-être avoir comme moi le même comportement avec le mot "instal" ou "setup". Etc...
Enfin tout ce qui pourrait modifier la machine...tu enlèves une seule lettre et d'un coup ton giciel n'est plus dangereux
Donc depuis ce temps j'ai renommé mes programmes "VirtualSetu" "InstaFacile" ... ça fait vraiment pro, le mec qui fait déjà une faute d'orthographe dans le titre... ça donne envie pour la suite

Au début j'ai pensé aux faux positifs et aux api irritantes, donc j'ai viré les api, puis les hook, les callback...et à la fin, j'ai pris les couilles à l'envers et j'ai compilé avec zéro lignes puisque même un msgbox demandait un droit admin.

Putain ya quand même des trous de balles d'intellectuels qui feraient mieux de changer de métier avant d'inventer des conneries comme ça, qui pourrissent la vie des mecs qui payent leur travail de débile

J'ai abandonné quand je me suis aperçu que même un txt renommé en setup.exe demandait les mêmes droits
Alors ça si c'est pas de la protection à 2 balles...

Pour ici le parc informatique est géré par un active directory et aucun employé n'a de droits...
Je suppose qu'ils ont bridé les restrictions entre l'active directory et l'antivirus, encore plus serré qu'un cul de nonne... alors ici plus rien ne m'étonne à ce sujet, bientôt on pourra plus qu'allumer le pc (avec trois mots de passe) pour bronzer avec l'écran
Mais pour une machine de particulier... j'ai jamais eu ce phénomène dans aucune de mes nombreuses machines sur presque tous les os Windows..

T'as peut être bidouillé un truc qui fallait pas

Si tu trouves, "dizileunouleu" ça pourra sûrement nous dépanner..

Bon courage mr felps...

Dans Innosetup, on déconseille de nommer le fichier final setup.exe, donc "*update*.exe" est peut-être aussi "bloqué" ?

http://www.jrsoftware.org/ishelp/
Setting this to setup is not recommended: all executables named "setup.exe" are shimmed by Windows application compatibility to load additional DLLs, such as version.dll. These DLLs are loaded unsafely by Windows and can be hijacke

Ça ne le fait pas chez moi (exe avec update dans le nom). Ça ressemble à une "protection" par un antivirus ?

PS. Je teste NOD32 car Windows Defender n'a rien vu à l'infection de CCleaner (5.33)
(non seulement il est léger, mais il ne considère pas les programmes PB comme suspect)

Bonjour,

Je penche plutôt pour des mots clef de Windows (setup, update, ect....) sont surement dans une liste qui demande une élévation des droits. Par contre maintenant que je le sais je mettrais par exemple "upd@te" comme nom pour un fichier ^^.

Cordialement,
GallyHC

Je viens de tester sur un autre poste en utilisateur lambda sans AV
Compilation en 32 bits -> demande privilège admin mais pas en 64 (?)
(pareil avec setup ou update dans le nom de fichier)

Cela doit remonter a l'époque de Windows 16-bit et 32-bit avant l'avènement des processeurs 64-bit
Ce comportement perdure pour les versions 32-bit (compatibilité) mais a été corrigé en 64-bit
SGDG

Gérard/cage

Note: SGDG Sans Garantie De Gérard

Marc56 a écrit :PS. Je teste NOD32 car Windows Defender n'a rien vu à l'infection de CCleaner (5.33)
(non seulement il est léger, mais il ne considère pas les programmes PB comme suspect)

Ccleaner a comuniqué sur ce probleme, ils ont dis avoir bloqué tres rapidement l'infection
que seul la version 32 bits etait touché ..(ouf j'utilise la 64 )

maintenant ont est a la version 5.34.6207
mise a jour automatique par le soft ...

d'autre part a propos des antivir, de toutes façons, un antivir, ne peut bloquer que les "Anciens" virus
voir ceux qui sont calqués sur les anciens , mais ne peut pas bloquer des virus ou autre malwares
qui seraient de forme nouvelle , puisque ceux ci, n'apparaitraient pas dans la base de données de l'antivirus ...

j'ai perso Panda Antivir Free , il ne m'a rien detecté non plus a propos de Ccleaner (que je n'utilise pas tout les jours non plus )

mais peut etre que ton Windows Defender n'as rien capté, simplement parceque tu n'avais pas été infecté non plus ...

vu que chez piriform Ccleaner , ils ont bloqués rapidement , il est possible que comme moi, tu n'es jamais été infecté

Pour parler de CCleaner, je viens de faire la mise à jour en 5.35.6210 (version Pro avec licence)

Voir : CCleaner v.35

J'ai aussi téléchargé la version portable gratuite pour mes outils portables (disque externe au cas ou)

Une fois l'archive décompressée, je déplace les 2 exe chacun dans leur répertoire.
J'ai un répertoire TOOLS32 et un autre TOOLS64
Je vous laisse deviner a quoi ils servent.

Et bien, avec cette version, impossible de copier la version 32-bit, je peux juste créer un lien dans TOOLS32
Pour pouvoir la copier, il faut que je renomme d’abord l'exe puis que je le copie et enfin que je le renomme.

C'est ma journée on dirait.

cage