Sommaire
- Contexte
- Un problème de signature
- La solution détournée, mais peu élégante
- Conclusion : les formats ouverts et les formats ouverts
Dans ce journal, qui se veut un peu long mais clairement divisé en parties relativement
indépendantes, j'aimerai expliquer les expérimentations que j'ai faite pour pouvoir ajouter de la
musique sur un iPod (Apple, donc) de 7ème génération, qui n'est pas supporté par les outils actuels
sous GNU/Linux.
Et ça ne se finit pas élégamment, mais ça se finit quand même : j'écris ce journal en écoutant la
musique de cet iPod, musique transférée depuis GNU/Linux !
Le résultat en tant que tel n'a pas grand intérêt : ma solution n'est utilisable que pour ce type
d'iPod là, et empêche l'utilisation d'iTunes, n'est pas graphique, etc… Mais comme c'est la première
fois que je fais ce genre de chose, beaucoup d'éléments m'ont semblé intéressants, et j'espère aussi
récupérer des avis et des conseils sur ces méthodes.
Contexte
Pour faire court, j'ai reçu un iPod 7g à Noël il y a deux ans (oui, c'est une excuse courante pour
les linuxiens), et j'aurai quand même aimé l'utiliser. Sauf qu'il n'est pas possible de transférer
des morceaux depuis les lecteurs de musique libres qu'on peut trouver sur GNU/Linux.
Après quelques recherches, il s'avère que libgpod ne le supporte pas, et il n'y donc aucune raison
pour que ça puisse marcher avec un quelconque lecteur. On trouve vaguement une procédure sur
Internet, mais c'est à base de .so dont on n'a pas les sources, et de toute façon ça ne marche pas
chez moi (il semble que j'ai un firmware trop récent).
Je laisse donc tomber dans un premier temps. Mais cet été, je retombe dessus, et ayant un peu avancé
dans mes études, j'ai un peu plus d'idées qu'avant. Je me décide donc à essayer de faire un peu de
reverse engineering là dessus. Il va de soi que je ne me suis pas devenu un expert dans ce domaine
en un an et demi.
Un problème de signature
Une approche large
On a un peu de chance, tous les fichiers qu'écrit iTunes (en dehors du système lui même) sont
lisibles normalement, comme si l'iPod était une vulgaire clé usb. Oui, ce n'était pas gagné.
Déjà, je redémarre sous windows, j'installe iTunes, je réinitialise l'iPod. Je redémarre sur Arch, copie
l'intégralité des dossier de l'iPod sur mon ordinateur, je rédemarre, j'ajoute un morceau, et je
fais un diff pour voir les fichiers qui ont changé.
Évidemment il n'y a pas qu'un, mais ça reste raisonnable, je les remplace un par un jusqu'à
trouver ceux qui sont vraiment responsables du changement.
3 fichiers ressortent du lot : Locations.itdb, Library.itdb, Locations.itdb.cbk.
Là, agréable surprise, les deux premiers sont des bases de données SQLite. Victoire, je commence à bidouiller un peu, je peux changer le titre des morceaux en modifiantLibrary.itdb, ça marche bien. J'exulte. Sauf qu'ensuite, j'essaye d'ajouter un nouveau morceau. Pour
ça, j'ajoute une entrée dans une table de Locations.itdb, et une autre dans Library.itdb. Et là, le
drame, l'iPod me dit qu'il n'y a aucun morceau sur l'iPod. Donc non seulement ça a échoué, mais en
plus, on a perdu les morceaux qui y étaient déjà.
Je remets les bases de données dans un état antérieur qui fonctionne. Je commence à comprendre que
le .cbk est une signature des autres fichiers. Je change un octet dans ce fichier avec ghex, et
l'iPod déclare qu'il n'y a aucun morceau sur l'appareil. Maintenant on est certain qu'il s'agit
d'une signature, et probablement seulement de Locations.itdb (déjà par son nom, et ensuite parce que
les changements dans Library.itdb n'ont pas l'air de déranger l'iPod).
Les grands moyens, le désassemblage
Alors là, on examine un peu le fichier .cbk : 177 octets, ce qui ne correspond pas un standard
largement répandu (i.e. je ne trouve pas ce que ça peut être), j'essaye quand même des trucs au
hasard, mais bon, même en supposant que ça soit un sha quelconque, il suffit qu'il y ait simplement
un masque appliqué sur Locations.itdb pour que je n'ai aucune chance de trouver. Donc ça,
j'abandonne.
Je me lance donc dans la décompilation d'iTunes, ou plutôt dans le désassemblage, puisque j'apprends
au passage qu'il n'y a pas de logiciel accessible pour décompiler un truc de cette taille là et
avoir un résultat un peu intéressant (oui, ça existe mais ça ne marche pas bien du tout).
Là surprise, les outils classiques fonctionnent bien, même si c'est un binaire Windows
et qu'on désassemble sous Linux.
Là, la seule chose que je peux chercher c'est "cbk". Gros coup de chance, il y a 2 occurences. L'une
me mène dans le segment de data, je récupère l'adresse, je cherche dans l'assembleur où elle est
utilisée, et pareil un nombre très réduit d'occurrences.
Je tente de lire l'assembleur et de le décompiler à la main les morceaux qui semblent prometteurs :
autant dire qu'au bout de quelques heures j'abandonne, c'est incompréhensible.
Je fais quand même quelques expérimentations, j'écris un programme qui sépare l'asm en fonctions, et
qui leur donne des noms d'animaux aléatoires à la demande. C'est rigolo, mais ça ne m'avance pas
beaucoup.
Une petite victoire, des maths, et le désespoir
Pour poursuivre un peu dans cette voie, j'ai besoin de voir comment le code s'exécute. Je fais des
recherche, je trouve un débugguer pour Windows, je redémarre, je mets des breakpoints sur les
adresses que j'ai remarquées à l'étape précédente. Je lance iTunes avec le débugguer, ça crash. Je
recommence, pareil. Finalement je lance iTunes, et
j'attache le débugguer ensuite (ça revient en gros au même). Ce n'est pas super stable (c'est le
moins qu'on puisse dire), mais ça marche à peu près.
J'ajoute un morceau à l'iPod, et le débugguer s'arrête sur un breakpoint. Ouf, je n'avais plus
d'idées sinon.
Alors là, j'y passe des heures, je fais marcher le débugguer pas à pas, entre les crash, j'essaye de
faire une carte du code voir par où on va, si je comprends quelque chose. J'utilise mon programme
qui sépare l'asm en même temps, pour donner des noms aux fonctions que je rencontre. Quand elles
sont appelées à d'autres endroits, je ne les étudie pas, etc…
Au bout d'un moment, j'arrive à comprendre à peu près dans quel ordre les bases de données et la
signature sont écrites. Mais bon…
Et à un moment, je tombe sur le code de chargement de 4 constantes, ça ressemble à l'initialisation
d'un code de crypto. Je les mets dans mon moteur de recherche favori, et là, boum, c'est du sha1. Je
passe encore quelques heures à étudier ça, et finalement, j'arrive à déterminer que sha1 est appelé
sur les 1024 premiers octets de Locations.itdb, puis les 1024 suivant, et cela 4 fois.
Hop, je split le fichier, je calcule le sha1, et je les retrouve dans le .cbk. Jubilation.
Mais ça ne fait pas tout le fichier ça, il manque encore pas mal d'octets du cbk. Je réétudie
l'assembleur, je me rends compte que les 4 hash calculés sont accolés et qu'ensuite on recalcule
encore une fois le sha1 là dessus. Hop, ça ne laisse plus que 55 octets dans le .cbk.
Et là… je continue de regarder l'asm et le débuggueur, je ne trouve plus rien. Pire, l'assembleur
change d'un coup, il devient encore plus difficile à lire. Je ne suis pas arrivé à décider si c'est
le débugguer qui bugguait ou si c'était fait exprès mais il semblerait que certains endroits du code
incrémentent %pc de seulement quelques octets, ce qui décale le cadre de lecture de l'asm. En plus,
les instructions qui font ça le font après avoir fait tout un tas de calculs absurdes (genre mutiplier
par 0x452FE45 puis soustraction de 0x786798, puis on remultiplie… tout ça pour faire moralement %pc = %pc + %rax,
avec %rax = 2). Alors je commence à me dire que c'est peut-être de l'obfuscation et que c'est juste
fait exprès pour ne pas qu'on puisse continuer.
Ça fait donc 55 octets, qui sont probablement calculés à partir de 122 premiers. Mes maigres
connaissances en crypto me disent que je n'ai absolument aucune chance d'inverser ça par force
brute, et que ce n'est absolument pas standard. Bref, c'est désespérant.
C'est dommage, j'ai la majorité des octets, mais il en suffit d'un de faux… J'abandonne pour le
moment.
La solution détournée, mais peu élégante
Hop, ce sont les vacances de Noël, je retombe sur l'iPod que je n'ai toujours pas utilisé, et je n'y
remets. Après quelques égarements dans l'asm et le débuggueur (qui avance un peu, j'ai trouvé un peu
plus dans l'asm quelles étaient les fonctions qui généraient la signature), je commence à relaisser
tomber.
Mais en fait, on a pas besoin de générer la signature à chaque fois. Le contenu de Locations.itdb
est assez inutile. Grossièrement, cette base de données ne sert qu'à associer un id à un fichier.
Donc quand on ajoute un morceau, il faut rajouter une ligne. Oui mais en fait, je fais un test, et
on peut avoir plus de ligne dans Locations.itdb que de morceaux dans Library.itdb.
On va donc faire générer à iTunes une signature pour une bases qui contient des centaines de
morceaux, puis les supprimer de Library.itdb, et on aura un certain nombre d'emplacements disponibles
pour mettre nos morceaux. Quand on en ajoutera un, il suffira de prendre une ligne qui n'est pas
encore associée à un vrai fichier dans Locations.itdb, et la rajouter dans Library.itdb, avec toutes
les informations sur ce morceau (titre, artiste, album, etc).
L'intérêt de la méthode c'est qu'on a besoin une seule fois d'iTunes, et ensuite ça marche (très
probablement) pour tous les iPod du même modèle (enfin ça c'est à vérifier, mais j'y crois).
Et ça marche ! Je sépare un mp3 en 10000 morceaux, j'importe ça dans iTunes, je les copie sur l'iPod
(enfin là je suis passé à 3000, 10000 ça faisait tout planter), et ça génère bien un Locations.itdb
avec 30000 entrées.
Reste à coder de quoi ajouter automatiquement toutes les données aux bases de données de l'iPod,
gérer les "emplacements" disponibles à chaque fois, etc…
Après 2 petites journées à coder en Vala, je transfère la majorité de ma bibliothèque depuis Linux,
sans avoir besoin d'utiliser Windows. Le code est ici, mais ça risque probablement de détruire toute
la bibliothèque de votre iPod si vous l'utilisez…
Conclusion : les formats ouverts et les formats ouverts
Ces expérimentations m'ont donc permis d'écrire un programme qui transfère bien des morceaux depuis
Linux vers un iPod.
La conclusion reste quand même qu'il faut acheter des produits qui ont des spécifications un minimum
ouvertes, à défaut de matériel et de logiciel libre.
Cependant, dans cette histoire qui peut sembler noire de logiciels propriétaires, on voit quand même
les bienfaits des logiciels open source. Parce que oui, on s'aperçoit qu'Apple utilise des
technologies largement répandues ou des spécifications standards : SQLite, sha1, etc… Sans cela, il
est certain que ce travail aurait été très laborieux, voir impossible.
L'autre aspect, c'est qu'il semble évident que les ingénieurs d'Apple ne cherchent pas à empêcher
l'utilisation de leur matériel sur d'autres systèmes, ils ne l'encouragent pas, c'est vrai, mais il
n'y a pas particulièrement de protection là dessus : les coups de chance que j'ai eu ne seraient pas
possibles si les ingénieurs s'étaient sérieusement dit qu'il fallait l'empêcher (ou sinon c'est qu'il
sont assez incompétents et négligents, mais je ne le crois honnêtement pas).
Enfin, quelques mots sur le côté légal de la chose : désassembler le code d'iTunes comme je l'ai fait est probablement formellement interdit par la licence d'utilisation. Cela dit, on peut aussi voir cette démarche comme nécessaire pour faciliter l'interopérabilité, comme le fait VideoLAN. C'est étonnamment clair dans le code de la propriété intellectuelle :
La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1° ou du 2° de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels
# Ouah!
Posté par ʭ ☯ . Évalué à 10.
Bravo pour la persévérance, pour ma part j'ai juste assez répété qu'Apple c'est l'Étoile Noire pour que personne ne joue à m'offrir un iPod ;-P
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# StackExchange Reverse Engineering
Posté par antoyo . Évalué à 10.
Salut !
J’ai effectué un travail similaire pour comprendre le fonctionnement du format d’archive de ChessBase, le format propriétaire .cbv.
Tout comme toi, je m’étais rendu assez loin, mais il me restait un algorithme inconnu à comprendre.
J’ai donc posté un message sur le site Reverse Engineering de StackExchange et j’ai eu droit à une superbe réponse qui m’a permi de terminer le travail.
Je te recommande de faire la même chose si tu souhaites aller plus loin.
Bonne chance.
P.S.: Pour les intéressés, le code de mon outil est disponible sur Github.
# merci
Posté par bobble bubble . Évalué à 7.
un très bon journal, sur le fond et sur la forme, ça me donnerait presque envie de m'offrir un iChose pour mettre en pratique.
j'espère que d'autres lecteurs pourront profiter de ton code et peut-être avancer sur ce fichier .cbk
le dernier point que tu soulèves est tout aussi intéressant, surtout l'exemple de vlc (ici ou là)
# autres outils ou autres contournements?
Posté par freem . Évalué à 5.
Super intéressant ton journal, mais je me permet une question bête, comme je n'ai pas d'iTruc ni de machinPod…
Et au passage, je vais indiquer d'autres outils pour le RE, pas forcément installables sous Linux (sans Wine) mais… très honnêtement, je n'arrive déjà pas à trouver une interface potable de debugger sous linux, alors un désassembleur, je n'ose essayer.
Quel est le but exactement, à la base? Nourrir la bibliothèque de l'iPod pour laisser le logiciel interne s'occuper de lire les données, ou juste écouter de la musique?
Dans le 2nd cas, n'y a-t-il pas moyen de changer le player? J'imagine que non, mais on se sait jamais :)
Pour les outils, de mon côté quand j'ai besoin/envie de bidouiller un exécutable windows, je me tourne vers des choses telles que:
IDA.
Dés-assembleur avec une version gratuite, qui est bien sûr limitée. Je ne me rappelle pas exactement des limites, mais il est possible que radare(http://radare.today/posts/radare-0-9-9) puisse être un remplaçant potentiel (pas encore testé, je le reconnais) si elles sont trop gênantes. Où si tu n'as pas envie de travailler sous windows j'imagine :)
L'avantage par rapport à objdump, c'est que ça t'aurait au moins évité pas mal de bricolage manuel, puisque IDA te montre une représentation du code "éclatée", en fonction des sauts et des calls. Les noms données aux destinations ne sont bien entendu pas parlant, mais ils peuvent se changer. De même pour les noms données aux chaînes de caractères.
Il me semble même qu'il est possible de déboguer le programme cible depuis IDA. Par contre, je n'ai pas souvenir d'avoir pu modifier le binaire depuis IDA: une des limitations de la version d'essai je suppose, mais bon travailler avec un compilateur et un éditeur hexadécimal à côté ne me choquait pas quand je faisais joujou avec ce type d'outils.
OllyDBG… zut, on dirait qu'il ne supporte pas le 64 bits… c'est un débogueur.
Ça fait vraiment longtemps que j'ai joué avec des binaires moi :) mais en tout cas il est stable et plutôt bien branlé (je préfère son IHM à celle du mode debug de IDA). Je doute qu'iTunes n'ai pas de version 32 bits, sous windows le 64 bits n'est pas encore la règle après tout… loin de là même il me semble.
En tout cas, encore une fois merci pour le journal et chapeau pour ta réussite.
[^] # Re: autres outils ou autres contournements?
Posté par Victor STINNER (site web personnel) . Évalué à 8. Dernière modification le 03 janvier 2016 à 12:43.
Tu décris la base de l'obfuscation du code machine, un classique pour ralentir le travail de l'ingénierie inverse. objdump est vraiment le desassembleur le plus rudimentaire qui existe, ce n'est pas étonnant qu'il butte sur ces bidouilles. Il existe des outils pour "simplifier" le code machine (supprimer les calculs absurdes que tu décris) automatiquement. J'en ai entendu parlé, mais je ne pourrai t'en conseiller. Ca ne m'étonnerait pas que radare2 sache faire ce genre de chose.
Ca me rappelle quand j'ai migré à Linux. Ayant passé pas mal de temps dans un débogueur en ring 0 (SoftICE) et IDA, j'étais un peu frustré de ne plus avoir de logiciels à déplomber. Tout le code source était disponible très facilement, et il était trivial de modifier un logiciel depuis le code source.
[^] # Re: autres outils ou autres contournements?
Posté par freem . Évalué à 2.
À un moment j'ai cru que c'était à moi que tu répondais… il m'a bien fallu 20s pour comprendre :)
Ce sentiment ne m'est pas inconnu. Dommage par contre qu'il n'y ait pas de débogueurs (enfin, d'interface à GDB) correct sous Linux, parce que ça sert aussi dans des cas plus légitimes de programmation. Au moins sous windows, pas besoin d'installer un mastodonte genre Visual Studio pour déboguer un truc écrit sur un coin de notepad++ et compilé à la main (genre un programme de moins de 200 lignes pondu en 15min quoi).
Si SoftIce te manque, par contre, il y avait RR0D qui existait. Jamais testé, ceci dit.
[^] # Re: autres outils ou autres contournements?
Posté par liberforce (site web personnel) . Évalué à 3.
Bin Nemiver, c'est pas bien ?
[^] # Re: autres outils ou autres contournements?
Posté par imalpha . Évalué à 1.
Hum je vois, donc je n'avais effectivement aucune chance… Je vais vraiment regarder radare2 !
[^] # Re: autres outils ou autres contournements?
Posté par Antoine . Évalué à 10.
Tu as toujours la possibilité de déplomber des logiciels écrits en Perl ou en Haskell.
[^] # Re: autres outils ou autres contournements?
Posté par imalpha . Évalué à 2.
Pour l'iPod, il n'y a pas moyen de changer le player. Un temps, il y avait le projet ipodlinux (leur site semble être down maintenant), mais à ma connaissance ça ne marchait que pour le nano première génération (il y a un petit moment, donc). Donc oui, il s'agit d'écrire une base de donnée que le player d'origine puisse utiliser.
J'avais rapidement vu quand j'avais fait chercher des outils, mais je n'avais pas vu qu'il y avait une version gratuite (bizarrement je croyais que c'était la même chose qu'hexrails). Mais bon, c'est vrai que tant qu'à faire, je préfère utiliser des outils libres, je vais regarder radare, ça a l'air intéressant !
Pour OllyDBG, je ne connaissais pas non plus, je regarderai à l'occasion.
Merci pour les informations !
[^] # Re: autres outils ou autres contournements?
Posté par freem . Évalué à 3.
Si tu testes radare, je suis preneur d'un retour d'expérience, ce type d'outils est toujours intéressant à avoir dans sa trousse.
[^] # Re: autres outils ou autres contournements?
Posté par Grégory Soutadé (site web personnel) . Évalué à 2.
Pour Linux et OS X (sa cible de base), il y existe le désassembleur et décompilateur Hopper qui est plutôt sympa .
Sinon, en natif sous Windows, le fameux WinDBG de Microsoft. L'interface est spartiate, mais au final on peut tout faire !
# Expérience similaire
Posté par plietar . Évalué à 9.
Merci pour ce journal très intéressant.
Je suis moi-même en train de faire de la rétro-ingénierie du protocole d'un grand service de streaming audio Suédois.
Ce sont de longues séances de lecture d'assembleur, avec quelques maux de tête à la clé, mais la satisfaction quand mon implémentation se comporte comme la référence n'a pas de prix.
Je devrais faire un journal là dessus un jour.
Par contre je ne sais pas vraiment ce qu'il en est du coté légal.
[^] # Re: Expérience similaire
Posté par Yth (Mastodon) . Évalué à 4.
Pour autant que je sache (je ne suis pas autorité en la matière), tu as le droit de le faire en France si ce n'est en Europe.
La situation complète est peut-être un brin tordue, mais je suppose que tu as le droit de désassembler en France, et donc d'en extraire des informations concernant le protocole, de faire un papier qui explique comment ça marche.
Quelqu'un peut ensuite tout à fait prendre ton papier et écrire un outil qui utilise ces informations.
Il n'est cependant pas impossible qu'il y ait des restrictions à faire les deux à la fois, puisque là tu contournes, toi tout seul, une éventuelle sécurité. C'est peut-être uniquement vrai dans le cas de DRM ou assimilés, c'est à dire si le programme est conçu pour protéger du contenu.
Ce qui n'est pas a priori le cas du lecteur de l'iPod, puisque le fichier ne semble contenir qu'une somme de contrôle un brin complexe dont les deux seuls intérêts sont de détecter une corruption des méta-données, et d'emmerder les gens qui veulent ajouter de la musique sur leur iPod sans utiliser iTunes. Ça ne protège pas le contenu (la musique), et tu as le droit de faire ce que tu veux d'un matériel que tu possèdes, y compris en changer le logiciel, le contenu etc.
Dans tout les cas, en France au moins, tu peux faire ce que tu veux à titre personnel.
Le problème est toujours dans la publication…
Bref, faudrait un expert pour avoir les tenants et les aboutissants précis.
Ce qui est sûr c'est que rien dans la loi française ne t'empêche de bricoler ton matériel et de le hacker dans tout les sens, au moins à titre personnel.
Et si rien ne t'en empêche, c'est que tu as le droit de le faire.
Yth.
[^] # Commentaire supprimé
Posté par freejeff . Évalué à -5. Dernière modification le 05 janvier 2016 à 23:57.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Expérience similaire
Posté par lolop (site web personnel) . Évalué à 3.
Un bug ?
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Expérience similaire
Posté par Victor STINNER (site web personnel) . Évalué à 3.
On dirait une réaction à http://linuxfr.org/news/in-memoriam-ian-murdock-1973-2015
[^] # Re: Expérience similaire
Posté par bobble bubble . Évalué à 2. Dernière modification le 05 janvier 2016 à 20:21.
du spam ?
edit : au début j'ai cru à du spam, mais il devait bien s'agir de la mort d'Ian
[^] # Re: Expérience similaire
Posté par freejeff . Évalué à 1.
Oui c'est ça dsl, si un modérateur veut bien retirer le message, il n'a rien à faire ici …
# Format du fichier .cbk
Posté par Christophe Fergeau . Évalué à 6.
Ce que tu décris correspond effectivement à ce qui est implémenté par la libgpod
http://sourceforge.net/p/gtkpod/libgpod/ci/master/tree/src/itdb_sqlite.c#l2067
Une sha1 est généré pour chaque block de 1024 octets, et ensuite au début du fichier, il faut ajouter une signature magique. Pour cette signature magique, on tombe effectivement sur du code qu'Apple a apparemment délibéremment rendu difficile à désassembler, à ma connaissance le seul moyen de générer cette signature, c'est de passer par le blob libhashab.so.
[^] # Re: Format du fichier .cbk
Posté par imalpha . Évalué à 1.
Pour le hashab, c'est ce que je voulais dire avec :
Par contre, d'après mes tests, le .cbk n'est pas généré tout à fait pareil : même les derniers octets sont faux avec ce que fait libgpod. Donc ce n'est probablement pas la même chose qui est hashé. Cela dit, pour être tout à fait honnête, j'ai essayé avec libgpod standard, puis en rajoutant libhashab, mais je pensais que libhashab s'occupait de tout le .cbk (et donc qu'il n'y avait pas de code récent sur le sujet). Je ne pensais pas que libgpod générait déjà une partie correcte de la signature pour d'autres modèles.
Merci !
[^] # Re: Format du fichier .cbk
Posté par Christophe Fergeau . Évalué à 2.
Si les derniers octets, c'est des SHA1, c'est un peu surprenant que ça soit légèrement différent entre ce dont tu as besoin et ce que fait la libgpod, vu que globalement les 2 font la même chose, c'est bizarre de juste légèrement changer les derniers octets. Après y a peut être juste un bug ;) Il faut peut être que la libgpod soit capable d'identifier l'ipod (touch je suppose ?) correctement pour que les choses se passent comme elles doivent.
Dans mon souvenir, la libhashab génère juste une signature de 20 octets (la partie sur laquelle tu t'es pour l'instant cassé les dents justement).
[^] # Re: Format du fichier .cbk
Posté par groumly . Évalué à 3.
Probablement un classic ou nano plutot, vu qu'il explique l'impossibilite de changer le lecteur mp3, ce qui est clairement possible avec un touch (jailbreaké ou pas, t'as une palanquee de lecteur tiers sur ios).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.