Normalement, c'est pour ne pas avoir à echapper les parentheses que j'ai mis l'option -r (extended regex). ça ne marche effectivement pas si on les echappe.
Merci d'avoir testé.
ça ne marche toujours pas chez moi (.com)
J'ai essayé sur deux machines différentes, toutes deux mandriva.
A noter : ça marche avec les range posix [:upper:] et [:lower:]. En guise de sparadrap ...
Il faudrait surement demander l'avis d'un expert, mais il est probable que les relevé bancaires aient une certaine valeur "légale". Ca ne m'etonnerais donc pas qu'une législation où une directive oblige à placer des verrous pour qu'ils ne puissent etre modifiés dans leur format numérique.
Quant à l'éfficacité de ces DRM ....
Par contre, comme il a été dit plus haut, la banque postale permet depuis un moment de télécharger un relevé pour les n derniers mois, et ce dans plusieurs formats, dont du simple CSV. Quand meme plus facile que d'aller extraire du texte depuis un pdf ...
Oui, pour faire tourner le script directement sur votre machine, avec le mecanisme .foward, il faut un serveur mail sur cette machine. Tous les serveur SMTP ne gerent pas le .forward, mais il me semble que les principaux le font. C'est le cas de Postfix, si mes souvenirs sont bons.
Alternativement, si la contrainte de temps réel n'est pas trop forte, une autre solution peut etre envisageable. Sur votre machine, vous pouvez, avec Cron, lancer un script qui va recuperer vos mails par IMAP ou POP toutes les x minutes (en se comportant comme le courrielleur).
Un tel script est facile a ecrire en Perl, Python, Ruby, ou PHP, qui possedent tous une bibliotheque IMAP ou POP. Il me semble que l'outil fetchmail peut aussi faire l'affaire.
Une fois les emails recupérés, le script peut lancer un autre script si un "mail adequat" est present.
A mon avis, cette solution est moins lourde à mettre en place, mais par contre, il y aura un délai de x minutes au maximum entre la reception du mail et le lancement du script.
Les fichiers .forward se situent normalement au niveau du serveur mail. Je parle ici du serveur SMTP, c'est à dire du serveur qui reçoit les e-mails en amont du "courrielleur". Un serveur SMTP populaire dans le monde Unix est sendmail.
Pour mieux comprendre, voici à quoi ressemble le parcours d'un email :
Quelqu'un envoie, avec son courrielleur (j'aime bien le terme), disons Thunderbird, un courriel à destination de Auberon@plouf.fr.
Ce qui se passe en fait, c'est que Thunderbird établit une connexion avec le serveur SMTP dont le nom figure dans la configuration du compte mail, pour lui demander d'envoyer le courriel (Thunderbird lui meme ne sait pas envoyer le mail). Le serveur SMTP, souvent celui du fournisseur Internet dans le cas de particulier, est donc le serveur expediteur. Disons pour faire simple que la personne envoyant le mail est chez Free.
Le serveur mail.free.fr se retrouve donc avec un message à envoyer à Auberon@plouf.fr. Grace au DNS, le serveur de Free trouve l'adresse du serveur mail s'occupant du domaine plouf.fr. Il etablit une connexion avec lui, et par le biais du protocole SMTP, lui donne le message (non sans avoir ajouté quelques en-tete indiquant notamment qui est l'expediteur). Le serveur mail.plouf.fr, serveur destinataire, se retrouve donc avec un message sur les bras, destiné à Auberon.
Imaginons que ce serveur utilise le logiciel sendmail pour traiter les courriel. Une fois le message reçu, il va regarder si il existe un compte sur le systeme du nom d'auberon. Si c'est le cas, s'il est configuré pour le faire et si le fichier existe, il va ensuite lire le fichier .forward present dans le repertoire personnel associé au compte. Au depart, ce fichier sert surtout à "forwarder" les mails vers une autre adresse. Mais la syntaxe permet également d'envoyer les mails à un programme (c'est le cas ici).
Selon la presence ou pas du .forward, et selon ce que contient le fichier, le courriel atterit in fine dans un sous répertoire du compte auberon, par exemple le repertoire Mail.
Ce que faut votre courrielleur , c'est qu'il se connecte aussi à mail.plouf.fr, mais non pas ppar le protocole SMTP. Suivant sa configuration, il va utiliser le protocole IMAP ou POP pour acceder au contenu de ce repertoire ~auberon/Mail, et ainsi recuperer les email. On le voit bien : les directive contenues dans le .forward ont a ce stade deja été executées.
Pour pouvoir utiliser ces fonctionnalités, nul besoin d'avoir un serveur mail personnel faisant tourner sendmail. Il faut par contre un compte mail aupres d'un fournisseur qui laisse à ses clients le loisir de configurer un .forward (ou d'autre filtres pàlus sophistiqués, tels maildrop et procmail). Ce n'est pas le cas chez gmail, hotmail ou autres.
Une solution serait de trier les mails en amont du webmail. Par exemple, avec des regles procmail ou maildrop, qui mettraient les mails dans differents dossiers IMAP en fonction du sujet, de l'envoyeur, ou de tout autre motif present dans le mail.
PS: coincidence, ça me fait un peu penser à ce post : http://linux-attitude.fr/post/Editer .
Il semblerait que ça soit justement un cas où un "sed -i" ne suffit pas trop, ou alors de façon assez "sale".
Il y a une façon assez facile de faire, en utilisant un fichier temporaire. Ainsi, soit le fichier "license", et le fichier "code.c". On fait :
cat license code.c > temp && mv temp code.c.
Ensuite, il y a une façon sans fichier temporaire, avec ed :
L'auteur de rubyscript2exe l'explique bien. A un moment donné, il faut bien utiliser un executable en langage machine, qui se lance tout seul. Il a utilisé Pascal pour ecrire cet executable (EEE), surement par préférence personnelle. Il aurait aussi pu utiliser le langage C, par exemple.
Le but de rubyscript2exe est de pouvoir faire tourner un script Ruby directement sur une machine où il n'y a pas d'interpreteur Ruby. Il n'est donc pas possible d'utiliser Ruby pour ecrire le packer.
En l'occurrence, un compilateur de Ruby lirait le code source Ruby, et le "convertirait" en code machine, voire en assembleur. C'est ce qui se passe, par exemple, avec le C, qui est compilé.
Un compilateur est en fait un traducteur d'un langage vers un autre langage, généralement de plus bas niveau (exemple, langage C vers language machine, ou langage Java vers bytecode). Au passage, notons que cette traduction s'accompagne souvent de nombreuses optimisations.
Ce que fait rubyscript2exe n'est pas du tout une "traduction". Le script Ruby initial est laissé en l'état, mais il est emballé ("packé"), avec l'interpreteur Ruby et des bibliotheques, dans un executable, EEE.
D'apres ce que j'ai compris, lorsqu'on lance le fichier exe crée par rubyscript2exe, on lance en fait EEE. EEE se rend compte qu'il est accompagné d'une archive, crée un répertoire temporaire où il la decompresse, et lance l'interpreteur Ruby contenu dans l'archive sur le script (contenu lui aussi dans l'archive).
Il semblerait que eee ne fasse pas son travail de nettoyage des fichiers temporaires, ce qui expliquerait l'accumulation de dossiers "eee" dont tu parles.
Je repete que je ne connais pas de livre sur les "packers" tels que rubyscript2exe. Par contre, si tu veux modifier ce programme, pourquoi ne pas apprendre Pascal (pour le coup il existe plein de bouquins sur ce langage). Sinon, un mail à l'auteur de rubyscript2exe pourrait permettre de mettre les choses au clair, et eventuellement de corriger le bug, si bug il y a.
En lisant le titre, j'étais pret à repondre avec des titres de bouquins classiques sur les compilos, genre "dragon book" et companie. Et puis cette histoire de "compilateur" Ruby m'a semblé bizarre, donc j'ai lu : http://www.erikveen.dds.nl/rubyscript2exe/
D'apres ce que j'ai compris, il ne s'agit PAS DU TOUT d'un compilateur. L'auteur le précise lui meme. En fait, voila ce que fait rubyscript2exe (si j'ai bien tout pigé) :
1) Il lance le script ruby en mode supervisé, pour determiner les dependances, librairies, autres fichiers ruby, etc.
2) Il crée une archive comprenant le script initial, l'interpreteur Ruby, et ces dépendances.
3) Il enrobe le tout dans un programme Pascal, EEE.Exe.
EEE fonctionne de la maniere suivante : il extrait l'archive qui lui est attaché dans un repertoire temporaire, lance Ruby dessus, attend la terminaison puis fait le menage.
Plus dinfos ici : http://www.erikveen.dds.nl/eee/index.html
Donc en fait, il s'agit plutot d'un "packer", et je n'ai pas d'idée de bouquin qui traite de la question. Reste donc a lire les sites web ci-dessus, et surtout le code de ces outils.
Est-ce que les compilateurs et les débuggeurs sont liés ?
Il existe des formats de debug differents, utilisés par les compilos et les debuggers.
Par exemple, avec la directive -g, gcc peut generer divers format de debug (dwarf, xcoff, ...)
Le probleme, c'est justement que si tu t'es fait piraté,
tu ne peux faire aucune confiance en netstat et autre.
Tu ne peux meme plus avoir confiance en ton noyau.
Le seul moyen de savoir quelle connexion existe est
donc d'utiliser un autre ordinateur et de sniffer le reseau.
Et pourquoi pas "externaliser" completement la sauvegarde ?
En louant un serveur ou juste de l'espace de stockage, ce ne sont pas les offres qui manquent ...
Vu que j'ai deja pas mal bossé sur Android, je me suis dit qu'il pourrait etre sympa de partager. J'ai donc redigé quelques notes basées sur mes "bidouilles". Le but n'est pas d'ecrire des applis Java (ce qui est par ailleurs tres bien documenté par Google), mais de bricoler sur le machin : installer un shell, programmer en C ...
Ce travail date d'avant la release en Open Source, mais est toujours d'actualité. Si y'en a que ça interesse (en anglais, sorry) :
Il est deja possible de compiler (enfin cross compiler) du C/C++ pour Android.
Pour l'instant, le vrai probleme etait que la libc etait "fermée", ce qui imposait des contorsions pour linker, ou alors avoir des executables static.
Pas encore essayé avec cette nouvelle version opensource, mais ça devrait resoudre le probleme.
Les headers sont en effet nombreux, et, c'est leur fonctions principale en C, contiennent des constantes, des structures, des prototypes de fonctions.
Les choses ne changent pas si souvent (bien que les dev noyaux se reservent le droit de modifier ces constantes, prototypes, structures ...). Par contre, il y a des ajouts (cf les depeches de patrick_g), plus frequents.
Il faut savoir egalement que le moindre changement peut avoir des consequences assez graves : un module inséré dans le noyau, et qui "planterait" à cause d'une mauvaise constante, d'un prototype de fonction mal defini, etc, c'est un kernel panic.
Apres, un module a lui seul ne va pas tout utiliser (de meme qu'un programme C n'utilise pas tous les .h de ton /usr/include !). Par contre, un module est susceptible d'utiliser au choix (en fait, selon pourquoi il est ecrit) chacun de ces en-tete.
Pour ce qui est des symboles, c'est une fonctionnalité de la programmation C, qui permet de "lier" des objets entre eux. Cela permet à un programme d'utiliser des fonctions ou des variables définies dans un autre programme. C'est le cas lorqu'on compile plusieurs fichiers .o en un seul fichier binaire, ou dans une autre mesure, lorqu'on utilise les fonctions d'une bibliotheque (par exemple, printf, dans la libC). Sous Linux, le programme qui s'occupe de faire le "lien" entre les symboles est ld, le "linker". La plupart du temps il est appelé par gcc à la fin de la compilation. On peut utilisr le programme nm pour avoir la liste des symboles presents dans un binaire.
L'idée derriere les symboles est la suivante. Lorsqu'on ecrit un programme en C, on utilise des noms pour faciliter la programmation. Par exemple, on va definir un fonction et l'appeler toto. Ces noms, bien sur, n'ont de sens que pour le programmeur. Une fois compilé vers le langage machine, notre fonction toto n'est plus qu'une serie d'octets située à une certaine adresse memoire. Pour "appeler" la fonction toto, il suffit de "sauter" à cette adresse memoire. Or pour appeler cette fonction toto depuis un autre programme, il est pratique d'utiliser le nom toto, plutot que de devoir ecrire l'adresse (que de toute façon on ne connait pas, et qui peut changer à la prochaine compilation). Quelque part dans notre programme, on stocke donc une table des symbole, qui associe à chaque nom son adresse. Lorsqu'un autre programme appele la fonction toto, le linker lit notre table des symbole, recupere l'adresse associée à toto, et remplace cet appel par un saut vers cette adresse.
Dans le noyau, les choses sont un peu differente puisqu'on se branche "à chaud". A savoir, lorsqu'on insere notre module, le noyau est deja en train de tourner. La phase de resolution des symbole ne se fait donc pas en statique (comme evoqu' plus haut), mais en "dynamique". Il n'empeche, le mecanisme est similaire. Chaque partie du noyau, chaque module est en droit de remplir la table des symboles du noyau avec les symboles de ses propres fonctions ou variables, grace à la macro EXPORT_SYMBOL .
Par exemple, la fonction printk, utilisée par tout les modules ou presque, est definie dans linux/kernel.h . Le code correspondant est ecrit dans kernel/printk.c . On remarque dans ce fichier la ligne EXPORT_SYMBOL(printk). Il y a donc dans la table des symboles du noyau une entrée contenant printk et son adresse. Lorsqu'on insere un module faisant des appels à printk, la phase de link dynamique associe ces appels à cette adresse.
si je me souviens bien, l'exploit vm_splice (recent, avec un exploit qui traine partout sur le net), presente un overflow. Il doit y avoir d'abord un int overflow qui permet de faire un overflow ensuite.
Par contre, ce n'est pas un buffer overflow a la aleph1, avec pourrissage de l'eip sauvé sur la pile, mais plutot une exploitation genre heap overflow.
[^] # Re: problème lié au shell?
Posté par castorpilot . En réponse au message question regex. Évalué à 2.
[^] # Re: COINcoin
Posté par castorpilot . En réponse au message question regex. Évalué à 1.
ça ne marche toujours pas chez moi (.com)
J'ai essayé sur deux machines différentes, toutes deux mandriva.
A noter : ça marche avec les range posix [:upper:] et [:lower:]. En guise de sparadrap ...
# T1
Posté par castorpilot . En réponse au message imaginons .. Évalué à 1.
# quelques doutes
Posté par castorpilot . En réponse au journal La banque postale et les DRM. Évalué à 1.
Quant à l'éfficacité de ces DRM ....
Par contre, comme il a été dit plus haut, la banque postale permet depuis un moment de télécharger un relevé pour les n derniers mois, et ce dans plusieurs formats, dont du simple CSV. Quand meme plus facile que d'aller extraire du texte depuis un pdf ...
# xset
Posté par castorpilot . En réponse au message Synergy et repetition de touche. Évalué à 1.
Peut etre faudrait-il faire remonter le bug aux devs de synergy.
Sinon, la repetition de touche se parametre avec la ligne de commande :
xset r rate 250 50
( a modifier selon la frequence voulue).
[^] # Re: Tentative de réponse
Posté par castorpilot . En réponse au message Les mystères du .forward. Évalué à 3.
Alternativement, si la contrainte de temps réel n'est pas trop forte, une autre solution peut etre envisageable. Sur votre machine, vous pouvez, avec Cron, lancer un script qui va recuperer vos mails par IMAP ou POP toutes les x minutes (en se comportant comme le courrielleur).
Un tel script est facile a ecrire en Perl, Python, Ruby, ou PHP, qui possedent tous une bibliotheque IMAP ou POP. Il me semble que l'outil fetchmail peut aussi faire l'affaire.
Une fois les emails recupérés, le script peut lancer un autre script si un "mail adequat" est present.
A mon avis, cette solution est moins lourde à mettre en place, mais par contre, il y aura un délai de x minutes au maximum entre la reception du mail et le lancement du script.
# Tentative de réponse
Posté par castorpilot . En réponse au message Les mystères du .forward. Évalué à 7.
Les fichiers .forward se situent normalement au niveau du serveur mail. Je parle ici du serveur SMTP, c'est à dire du serveur qui reçoit les e-mails en amont du "courrielleur". Un serveur SMTP populaire dans le monde Unix est sendmail.
Pour mieux comprendre, voici à quoi ressemble le parcours d'un email :
Quelqu'un envoie, avec son courrielleur (j'aime bien le terme), disons Thunderbird, un courriel à destination de Auberon@plouf.fr.
Ce qui se passe en fait, c'est que Thunderbird établit une connexion avec le serveur SMTP dont le nom figure dans la configuration du compte mail, pour lui demander d'envoyer le courriel (Thunderbird lui meme ne sait pas envoyer le mail). Le serveur SMTP, souvent celui du fournisseur Internet dans le cas de particulier, est donc le serveur expediteur. Disons pour faire simple que la personne envoyant le mail est chez Free.
Le serveur mail.free.fr se retrouve donc avec un message à envoyer à Auberon@plouf.fr. Grace au DNS, le serveur de Free trouve l'adresse du serveur mail s'occupant du domaine plouf.fr. Il etablit une connexion avec lui, et par le biais du protocole SMTP, lui donne le message (non sans avoir ajouté quelques en-tete indiquant notamment qui est l'expediteur). Le serveur mail.plouf.fr, serveur destinataire, se retrouve donc avec un message sur les bras, destiné à Auberon.
Imaginons que ce serveur utilise le logiciel sendmail pour traiter les courriel. Une fois le message reçu, il va regarder si il existe un compte sur le systeme du nom d'auberon. Si c'est le cas, s'il est configuré pour le faire et si le fichier existe, il va ensuite lire le fichier .forward present dans le repertoire personnel associé au compte. Au depart, ce fichier sert surtout à "forwarder" les mails vers une autre adresse. Mais la syntaxe permet également d'envoyer les mails à un programme (c'est le cas ici).
Selon la presence ou pas du .forward, et selon ce que contient le fichier, le courriel atterit in fine dans un sous répertoire du compte auberon, par exemple le repertoire Mail.
Ce que faut votre courrielleur , c'est qu'il se connecte aussi à mail.plouf.fr, mais non pas ppar le protocole SMTP. Suivant sa configuration, il va utiliser le protocole IMAP ou POP pour acceder au contenu de ce repertoire ~auberon/Mail, et ainsi recuperer les email. On le voit bien : les directive contenues dans le .forward ont a ce stade deja été executées.
Pour pouvoir utiliser ces fonctionnalités, nul besoin d'avoir un serveur mail personnel faisant tourner sendmail. Il faut par contre un compte mail aupres d'un fournisseur qui laisse à ses clients le loisir de configurer un .forward (ou d'autre filtres pàlus sophistiqués, tels maildrop et procmail). Ce n'est pas le cas chez gmail, hotmail ou autres.
[^] # Re: Commande "pgrep"
Posté par castorpilot . En réponse au message pid d'un processus. Évalué à 3.
pkill !
pkill nom_processus
# le nouveau langage à la mode
Posté par castorpilot . En réponse au journal Quel langage pour un non informaticien?. Évalué à 8.
# procmail ou maildrop
Posté par castorpilot . En réponse au message Webmail spécial. Évalué à 2.
Une solution serait de trier les mails en amont du webmail. Par exemple, avec des regles procmail ou maildrop, qui mettraient les mails dans differents dossiers IMAP en fonction du sujet, de l'envoyeur, ou de tout autre motif present dans le mail.
[^] # Re: ed, the one true editor !
Posté par castorpilot . En réponse au message Ajouter une entête de licence. Évalué à 2.
Il semblerait que ça soit justement un cas où un "sed -i" ne suffit pas trop, ou alors de façon assez "sale".
# ed, the one true editor !
Posté par castorpilot . En réponse au message Ajouter une entête de licence. Évalué à 2.
Il y a une façon assez facile de faire, en utilisant un fichier temporaire. Ainsi, soit le fichier "license", et le fichier "code.c". On fait :
cat license code.c > temp && mv temp code.c.
Ensuite, il y a une façon sans fichier temporaire, avec ed :
(echo '0a'; cat license; echo "."; echo "wq") | ed -s code.c
Et pour tous les fichiers, un truc du style :
for file in *.{c,h};do
(echo '0a'; cat license; echo "."; echo "wq") | ed -s "$file"
done
# select()
Posté par castorpilot . En réponse au message Thread : comment fonctionne Apache ? comment bien faire ?. Évalué à 2.
[^] # Re: une autre expérience, relatée dans la Washington Post
Posté par castorpilot . En réponse au message Cherche vieux journal sur expérience "philosophique". Évalué à 1.
Merci pour le lien !
[^] # Re: ce n'est pas du tout un compilateur
Posté par castorpilot . En réponse au message compileur. Évalué à 2.
Le but de rubyscript2exe est de pouvoir faire tourner un script Ruby directement sur une machine où il n'y a pas d'interpreteur Ruby. Il n'est donc pas possible d'utiliser Ruby pour ecrire le packer.
[^] # Re: ce n'est pas du tout un compilateur
Posté par castorpilot . En réponse au message compileur. Évalué à 2.
Tout à fait d'accord avec les réponses de Jean B.
En l'occurrence, un compilateur de Ruby lirait le code source Ruby, et le "convertirait" en code machine, voire en assembleur. C'est ce qui se passe, par exemple, avec le C, qui est compilé.
Un compilateur est en fait un traducteur d'un langage vers un autre langage, généralement de plus bas niveau (exemple, langage C vers language machine, ou langage Java vers bytecode). Au passage, notons que cette traduction s'accompagne souvent de nombreuses optimisations.
Ce que fait rubyscript2exe n'est pas du tout une "traduction". Le script Ruby initial est laissé en l'état, mais il est emballé ("packé"), avec l'interpreteur Ruby et des bibliotheques, dans un executable, EEE.
D'apres ce que j'ai compris, lorsqu'on lance le fichier exe crée par rubyscript2exe, on lance en fait EEE. EEE se rend compte qu'il est accompagné d'une archive, crée un répertoire temporaire où il la decompresse, et lance l'interpreteur Ruby contenu dans l'archive sur le script (contenu lui aussi dans l'archive).
Il semblerait que eee ne fasse pas son travail de nettoyage des fichiers temporaires, ce qui expliquerait l'accumulation de dossiers "eee" dont tu parles.
Je repete que je ne connais pas de livre sur les "packers" tels que rubyscript2exe. Par contre, si tu veux modifier ce programme, pourquoi ne pas apprendre Pascal (pour le coup il existe plein de bouquins sur ce langage). Sinon, un mail à l'auteur de rubyscript2exe pourrait permettre de mettre les choses au clair, et eventuellement de corriger le bug, si bug il y a.
# ce n'est pas du tout un compilateur
Posté par castorpilot . En réponse au message compileur. Évalué à 6.
En lisant le titre, j'étais pret à repondre avec des titres de bouquins classiques sur les compilos, genre "dragon book" et companie. Et puis cette histoire de "compilateur" Ruby m'a semblé bizarre, donc j'ai lu :
http://www.erikveen.dds.nl/rubyscript2exe/
D'apres ce que j'ai compris, il ne s'agit PAS DU TOUT d'un compilateur. L'auteur le précise lui meme. En fait, voila ce que fait rubyscript2exe (si j'ai bien tout pigé) :
1) Il lance le script ruby en mode supervisé, pour determiner les dependances, librairies, autres fichiers ruby, etc.
2) Il crée une archive comprenant le script initial, l'interpreteur Ruby, et ces dépendances.
3) Il enrobe le tout dans un programme Pascal, EEE.Exe.
EEE fonctionne de la maniere suivante : il extrait l'archive qui lui est attaché dans un repertoire temporaire, lance Ruby dessus, attend la terminaison puis fait le menage.
Plus dinfos ici : http://www.erikveen.dds.nl/eee/index.html
Donc en fait, il s'agit plutot d'un "packer", et je n'ai pas d'idée de bouquin qui traite de la question. Reste donc a lire les sites web ci-dessus, et surtout le code de ces outils.
[^] # Re: Exécutables
Posté par castorpilot . En réponse au message calcul scientifique : choix OS, compilateur, debuggeur. Évalué à 1.
Il existe des formats de debug differents, utilisés par les compilos et les debuggers.
Par exemple, avec la directive -g, gcc peut generer divers format de debug (dwarf, xcoff, ...)
[^] # aucune confiance
Posté par castorpilot . En réponse au message IRC sur le port 22. Évalué à 2.
tu ne peux faire aucune confiance en netstat et autre.
Tu ne peux meme plus avoir confiance en ton noyau.
Le seul moyen de savoir quelle connexion existe est
donc d'utiliser un autre ordinateur et de sniffer le reseau.
# rsync.net
Posté par castorpilot . En réponse au message Disque dur réseau pour faire du rsync. Évalué à 2.
En louant un serveur ou juste de l'espace de stockage, ce ne sont pas les offres qui manquent ...
# un "tutorial"
Posté par castorpilot . En réponse à la dépêche Android désormais disponible et libre. Évalué à 5.
Vu que j'ai deja pas mal bossé sur Android, je me suis dit qu'il pourrait etre sympa de partager. J'ai donc redigé quelques notes basées sur mes "bidouilles". Le but n'est pas d'ecrire des applis Java (ce qui est par ailleurs tres bien documenté par Google), mais de bricoler sur le machin : installer un shell, programmer en C ...
Ce travail date d'avant la release en Open Source, mais est toujours d'actualité. Si y'en a que ça interesse (en anglais, sorry) :
http://upche.org
# voila
Posté par castorpilot . En réponse au message aide script awk. Évalué à 7.
En gros : separer l'ip en fonction des ".", ignorer le premier numero (le 10), et utiliser printf, avec les options habituelles.
[^] # Re: Impressionnant
Posté par castorpilot . En réponse à la dépêche Android désormais disponible et libre. Évalué à 3.
Pour l'instant, le vrai probleme etait que la libc etait "fermée", ce qui imposait des contorsions pour linker, ou alors avoir des executables static.
Pas encore essayé avec cette nouvelle version opensource, mais ça devrait resoudre le probleme.
# comprendre le lien entre les headers du noyau et les modules
Posté par castorpilot . En réponse au message comprendre le lien entre les headers du noyau et les modules. Évalué à 6.
Les headers sont en effet nombreux, et, c'est leur fonctions principale en C, contiennent des constantes, des structures, des prototypes de fonctions.
Les choses ne changent pas si souvent (bien que les dev noyaux se reservent le droit de modifier ces constantes, prototypes, structures ...). Par contre, il y a des ajouts (cf les depeches de patrick_g), plus frequents.
Il faut savoir egalement que le moindre changement peut avoir des consequences assez graves : un module inséré dans le noyau, et qui "planterait" à cause d'une mauvaise constante, d'un prototype de fonction mal defini, etc, c'est un kernel panic.
Apres, un module a lui seul ne va pas tout utiliser (de meme qu'un programme C n'utilise pas tous les .h de ton /usr/include !). Par contre, un module est susceptible d'utiliser au choix (en fait, selon pourquoi il est ecrit) chacun de ces en-tete.
Pour ce qui est des symboles, c'est une fonctionnalité de la programmation C, qui permet de "lier" des objets entre eux. Cela permet à un programme d'utiliser des fonctions ou des variables définies dans un autre programme. C'est le cas lorqu'on compile plusieurs fichiers .o en un seul fichier binaire, ou dans une autre mesure, lorqu'on utilise les fonctions d'une bibliotheque (par exemple, printf, dans la libC). Sous Linux, le programme qui s'occupe de faire le "lien" entre les symboles est ld, le "linker". La plupart du temps il est appelé par gcc à la fin de la compilation. On peut utilisr le programme nm pour avoir la liste des symboles presents dans un binaire.
L'idée derriere les symboles est la suivante. Lorsqu'on ecrit un programme en C, on utilise des noms pour faciliter la programmation. Par exemple, on va definir un fonction et l'appeler toto. Ces noms, bien sur, n'ont de sens que pour le programmeur. Une fois compilé vers le langage machine, notre fonction toto n'est plus qu'une serie d'octets située à une certaine adresse memoire. Pour "appeler" la fonction toto, il suffit de "sauter" à cette adresse memoire. Or pour appeler cette fonction toto depuis un autre programme, il est pratique d'utiliser le nom toto, plutot que de devoir ecrire l'adresse (que de toute façon on ne connait pas, et qui peut changer à la prochaine compilation). Quelque part dans notre programme, on stocke donc une table des symbole, qui associe à chaque nom son adresse. Lorsqu'un autre programme appele la fonction toto, le linker lit notre table des symbole, recupere l'adresse associée à toto, et remplace cet appel par un saut vers cette adresse.
Dans le noyau, les choses sont un peu differente puisqu'on se branche "à chaud". A savoir, lorsqu'on insere notre module, le noyau est deja en train de tourner. La phase de resolution des symbole ne se fait donc pas en statique (comme evoqu' plus haut), mais en "dynamique". Il n'empeche, le mecanisme est similaire. Chaque partie du noyau, chaque module est en droit de remplir la table des symboles du noyau avec les symboles de ses propres fonctions ou variables, grace à la macro EXPORT_SYMBOL .
Par exemple, la fonction printk, utilisée par tout les modules ou presque, est definie dans linux/kernel.h . Le code correspondant est ecrit dans kernel/printk.c . On remarque dans ce fichier la ligne EXPORT_SYMBOL(printk). Il y a donc dans la table des symboles du noyau une entrée contenant printk et son adresse. Lorsqu'on insere un module faisant des appels à printk, la phase de link dynamique associe ces appels à cette adresse.
Pour plus d'infos (mieux structurée !) sur la programmation noyau :
http://lwn.net/Kernel/LDD3/
# vm_splice
Posté par castorpilot . En réponse au message Buffer Overflow exploit. Évalué à 4.
Par contre, ce n'est pas un buffer overflow a la aleph1, avec pourrissage de l'eip sauvé sur la pile, mais plutot une exploitation genre heap overflow.