Forum Programmation.shell grep sur du binaire ???

Posté par PyroTokyo le 31 janvier 2011 à 04:37.

Étiquettes : aucune

jan.

2011

bonjour a tous !

j'aurais bien une petite question pour les pros du grep...
j'ai un fichier zImage dont je cherche a extraire l'initramfs pour voir un peu ce qu'il y a dedans
je sais a peu pres ou je dois couper mon fichier, et je cherchais a faire ca avec grep plutot qu'un editeur hexa

apres avoir bien lu la page de man, je me suis dit que
grep -abo $'\x1f\x8b\x08\x00' < zImage aurait du faire l'affaire (j'ai verifie, la chaine hexa est bien presente), mais dans ma fenetre bash, aucun match

est-ce que j'aurais loupe quelque chose ???
j'ai egalement essaye sans le <, juste au cas ou, mais meme resultat :(

# Vite fait

Posté par Axioplase ıɥs∀ (site web personnel) le 31 janvier 2011 à 07:07. Évalué à 3.

1/ c'est quoi ton "$" là ?
2/ Si tu mets des guillemets simples, je pense que ça ne va *pas* évaluer tes échappements.
3/ Si tu mets un "<" à ton grep, c'est que tu n'as vraiment pas compris comment marche grep.
4/ man split
- [^] # Re: Vite fait
  
  Posté par PyroTokyo le 31 janvier 2011 à 10:44. Évalué à 2.
  
  1) si mes souvenirs bash sont bons, $'\xHH' retourne le caractere qui a pour code hexa HH. En tout cas, ca marche avec la commande echo
  
  3) vu que grep fonctionne egalement avec l'entree standard, en quoi ca gene d'avoir un < ?
  Au pire, il ne sert a rien ou ralentit le traitement
  
  4) l'idee etant de recuperer un offset avec le grep, je ne vois pas trop ou intervient split la dedans. J'aurais plutot utilise dd -skip personnellement ?
  - [^] # Re: Vite fait
    
    Posté par Axioplase ıɥs∀ (site web personnel) le 31 janvier 2011 à 11:11. Évalué à 3.
    
    1/ Je connaissais pas.
    3/ C'est aussi joli que cat fichier | grep foo je trouve.
    4/ split -p pattern permet de couper un fichier, mais je pensais pas qu'il coupait à la *ligne* qui matche.
    
    De toute façon, ton grep aussi va te retourner une ligne (c'est-à-dire qu'il va remonter au précédent "\n" et te retourner l'offset de l'octet suivant, pas celui de ta chaîne.)
    
    Tu peux alors sans doute hacker en faisant :
    sed -e $'s/\xde\xad/\\\n\&/' toto.tex | grep -ab $'\xde\xad'
    
    Enfin, si ta chaîne n'apparaît pas, ben, c'est qu'elle n'y est pas !
    Pas un souci d'endianness ?
    - [^] # Re: Vite fait
      
      Posté par barmic le 31 janvier 2011 à 12:01. Évalué à 2.
      
      Tiens puisque tu parle de UUOC, tu peut aussi lire la page man de sed et sur ta commande :
      sed -ne $'s/\xde\xad/\&/p' toto.tex
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Vite fait
        
        Posté par Axioplase ıɥs∀ (site web personnel) le 01 février 2011 à 04:00. Évalué à 4.
        
        Ta commande ne fait *pas* ce qu'il faut.
        La mienne insère un retour à la ligne juste avant le match, afin de placer le dit match en début de ligne et d'avoir l'offset exact indiqué ensuite par grep.
    - [^] # Re: Vite fait
      
      Posté par PyroTokyo le 01 février 2011 à 03:44. Évalué à 1.
      
      la chaine y est, pour sur (c'est Okteta qui le dit ^^)
      par contre, si je reduis le grep au caractere \x1f, j'ai bien une occurrence ou il faut. si je cherche \x8b grep ne retourne rien... je me demande s'il n'y a pas une histoire d'evaluation quelque part
- [^] # Re: Vite fait
  
  Posté par Grégory Landais (site web personnel) le 31 janvier 2011 à 10:55. Évalué à 1.
  
  1/ c'est quoi ton "$" là ?
  2/ Si tu mets des guillemets simples, je pense que ça ne va *pas* évaluer tes échappements.
  
  Moi je suis d'accord avec le $ et les guillemets. Cf section Quoting du man bash :
  
  Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard. Backslash escape sequences, if present, are decoded as follows: ...
  
  Sinon ton problème est étrange car chez moi ça fonctionne. Petite solution de secours : peut-être qu'en utilisant grep sur la sortie de xxd tu pourrais faire ce que tu veux.
  - [^] # Re: Vite fait
    
    Posté par PyroTokyo le 31 janvier 2011 à 11:04. Évalué à 1.
    
    oui, en effet c'est bizarre... un copain me dit que la commande marche chez lui avec les memes fichiers
    par contre, sur ma debian, nada ~
    effectivement je passerai par un dump, mais j'avoue que ca me laisse perplexe :(
    - [^] # Re: Vite fait
      
      Posté par fyah le 31 janvier 2011 à 11:39. Évalué à 1.
      
      une petite idée a deux balles: sur ta debian ca serait un pas dash au lieu d'un bash ?
      - [^] # Re: Vite fait
        
        Posté par PyroTokyo le 31 janvier 2011 à 14:39. Évalué à 1.
        
        en fait c'est pareil sur mon Arch a la maison, donc ca ne doit pas venir de la :(
  - [^] # Re: Vite fait
    
    Posté par Axioplase ıɥs∀ (site web personnel) le 31 janvier 2011 à 11:15. Évalué à 1.
    
    $' n'apparaît pas dans mon man sh
    $ echo $'\x41' $\x41
    
    Je persiste.
    (Oui, il a écrit "dans ma fenêtre bash". Mais quand on veux utiliser le shell plutôt qu'un éditeur ou un autre outil, c'est que la portabilité du code est de mise.)
# Avec hexdump ...

Posté par Skami_18 le 02 février 2011 à 13:47. Évalué à 1.

... c'est pas mieux ?

$ hexdump /tmp/file | grep '8b1f 0008' 0000000 6c62 6261 616c 8b1f 0008 6f63 6e69 6f63
- [^] # Re: Avec hexdump ...
  
  Posté par Frédéric Perrin (site web personnel) le 02 février 2011 à 18:24. Évalué à 1.
  
  Qu'est-ce qui se passe si on n'a pas de chance et qu'il y a un saut de ligne juste entre la première moitié et la seconde ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.