(suite du flashchat) tetris sur votre carte bleue - Page 1

(se lit de bas en haut )

20:08 Flanker: vince >
17:15 vince: ça vaudrait bien un topic, le sujet a l'air bien intéressant
17:14 vince: oui enfin y'a beaucoup de processeur qui incluent leur jvm de nos jours...
17:00 Orion_: y'a bien des 68030 coder en C dans les routeurs cisco ou tgv actuel ...
16:16 Ximoon: l'ancienneté des terminaux CB ça veut rien dire, il y a des nouveaux modèles comme des anciens
16:14 Nue: De toutes façons, le terminal a été modifié pour pouvoir faire tourner ça : http://www.lightbluetouchpaper.org/?p=185
16:11 Orion_: j'ai comme un doute quand même ... quand on vois certain truc pro embarqué ... et vu l'ancienneté des terminaux CB je pense pas que ça soit ça
16:06 Rintintin: et oue java ca peut etre partout
16:04 Ximoon: orion, professionnel de l'embarqué
15:57 Orion_: en java ouais ta raison en C# .net aussi non ? avec 50mo de framework, si c un bidouillage amateur je doute que ça soit en language de haut niveau
15:56 Orion_: loooooooool ...
15:34 Godzil: En meme temps, tu sais ce qu'il y a dans un terminal de CB ? ça pourrais tres bien etre en java, ou meme en C que sa m'étonnerais pas
14:15 Orion_: ça doit pas etre codé en C
14:08 Rintintin: c'est que c'est fluide en plus Oo
14:06 Orion_: http://www.dailymotion.com/video/xzmqz_tetris-sur-un-terminal-a-carte-bleu !!

bon perso je vais pas rentrer dans le troll java/c (mais vous pouvez très bien en parler, hein), juste une remarque sur la sécurité :

http://www.lightbluetouchpaper.org/?p=185 :Many discussions over the security of Chip & PIN have focused on the tamper-resistance of terminals (for example in the aftermath of the Shell Chip & PIN fraud). It is important to remember, however, that even perfect tamper resistance only ensures that the terminal will no longer be able to communicate with the bank once opened. It does not prevent anyone from replacing most of the terminal’s hardware and presenting it to customers as legitimate, so freely collecting card details and PINs.

Ce qui est idiot c'est que même si le terminal est "no longer be able to communicate with the bank once opened", on peut très bien avoir un robot qui tape manuellement le code de la carte bleue sur un vrai terminal qui a une fausse carte bleue avec des fils qui ressortent, et qui reçoit ses ordres à distance de la fausse machine Le seul point qui pourrait poser pb, c'est qu'il faut faire croire au vrai terminal qu'il a affaire à la vraie carte, mais je suppose qu'on a facilement accès aux spécifications électriques de la puce qui permettraient ça, non ? ou alors le protocole est suffisamment bien foutu pour exiger que la latence de la puce soit inférieure à la nanoseconde, mais j'en doute étant donné l'âge des cartes bleues :/

(menfin de toute façon ce serait sûrement plus simple de filmer les gens en train de taper leur code, ou de voir où sont leurs empreintes digitales, etc -- mais c'est moins discret qu'un faux terminal qui, lui, n'éveillerait pas les soupçons, et surtout permettrait de collecter absolument tous les codes avec un effort minime)

((et surtout pourquoi le clavier n'est pas intégré dans la carte bleue ??))

vark > mti-ste

Pollux > Ou recouvrir le clavier d'un film transparent qui marque encore mieux, en utilisant - pourquoi pas - la méthode dite marseillaise : un faux clavier au-dessus du vrai (qui répercute les ordre à celui d'en dessous) qui enregistre exactement les pressions des touches et leur ordre.

ouais mais là c'est plus risqué parce que ça peut se remarquer, et si un seul client s'en rend compte tu dois être méchamment dans la merde ^^ (enfin ça doit pas poser pb pour piquer juste 2-3 numéros, mais y a sûrement des moyens plus simples/moins risqués de faire ça )

bof, ça ne devrait pas être compliqué de filmer le code (tu mets une caméra à 10-15m, genre sur l'immeuble d'en face cachée par un pot de fleur), mais pour récupérer la carte, c'est moins pratique

Zephyr (./2) :
vark > mti-ste

euh ?

16:06 Rintintin: et oue java ca peut etre partout

(et ta spé a changé de nom cette année il me semble ^^)

mma -> mti? (mti == ?)

"Multimedia et Technologies de l'Information" je crois, ou un truc proche

Zephyr (./7) :

16:06 Rintintin: et oue java ca peut etre partout

(et ta spé a changé de nom cette année il me semble ^^)

oue mais je vois pas le rapport entre ce que j'ai ecrit et ta remarque
(en plus y'avait un qui a saute lors du copier coller du log du fc)

Tant que c'est pas un hack c'est des petits joueurs (tant que tu te ramènes pas à champion avec ta fausse carte à lancer tetris sur leurs trucs).

ben c'est exactement un hack au sens propre du terme. et un joli hack, même

Ba non puisqu'ils ont remplacé des composants.

17:00 Orion_: y'a bien des 68030 coder en C dans les routeurs cisco ou tgv actuel ...

Forcement si tu en es resté la...

16:16 Ximoon: l'ancienneté des terminaux CB ça veut rien dire, il y a des nouveaux modèles comme des anciens 16:11 Orion_: j'ai comme un doute quand même ... quand on vois certain truc pro embarqué ... et vu l'ancienneté des terminaux CB je pense pas que ça soit ça

Comme le dit ximoon, c'est pas parce que la techno de base est ancienne que tout date de l'époque, pour preuve, j'ai vu pas plus tard que samedi un terminal qui communiquais en bluetooth avec sa base, je pense que ça doit pas trop être un terminal qui a 20 ans.. Et rien n'empêcherais de faire un terminal avec les dernières technos a la mode

En plus les terminaux sont régulièrement changé et les commerçant doivent passer a la caisse pour en racheter...

En plus le terminal de la video, de part les formes & co ne semble pas être du vieux matos

15:57 Orion_: en java ouais ta raison en C# .net aussi non ? avec 50mo de framework, si c un bidouillage amateur je doute que ça soit en language de haut niveau 15:56 Orion_: loooooooool ...

Et oui, il y a des version de java faite pour l'embarqué (meme si je le déplore) et pour ta gouverne Java est capable de tourner sur un 68HC11
Et il en est de meme pour .Net, cf (par exemple) le kit "robotique" de microsoft qui utilise une VM .net et le tout pouvant tourner sur des µC relativement peu puissant
Et tiens aussi, certaines télévision Hitachi en version europe (et pas la version japon) leur programmation est fait 100% en java/SWT et oui...

Edited_3392

Ceci dit, le 680x0 est encore très à la mode, j'en ai vu récemment dans des équipements militaires de pointe et des calculateurs d'avions récents. Mais plus pour longtemps vu que le fabriquant (Freescale) lâche l'affaire d'ici 3 ans (avis d'obsolescence).
Ensuite, de nombreux équipements embarqués utilisent de "vieux" (au sens technologique) processeurs, tout simplement parcequ'ils sont moins cher et mieux maîtrisés (ex: 68HC12 pour des avions en développement...), rien de bien surprenant là-dedans, ni rien de bien inquiétant d'ailleurs. On n'a pas attendu d'avoir des Cell pour envoyer des gens sur la Lune...

Bien sur, et heureusement ^^

Ce que je voulais dire pour Orion, c'est que si il s'en est arrêté a la programmation C sur 68030.. il a 20ans de retard..

Ce qui ne veut pas forcément dire que plus personne ne programme en C ou en assembleur, précisons-le quand même
Mais typiquement un terminal de CB n'est pas un équipement pour lequel la vitesse et la performance sont critiques, et y mettre du Java pour simplifier le développement et améliorer la portabilité (et donc réduire les coûts lors d'un changement de matériel) est tout sauf aberrant. Après je ne sais pas s'il y en a effectivement dedans, mais je ne vois pas en quoi ça serait gênant.

Edited_3393

euh le c en general c'est carrement plus lourd a coder que de l'objet ...

Orion_> tu raisonnes comme un démo-codeur, et non pas comme un industriel
Ceci dit en ce moment je développe en C sur un ppc555, ça aurait été 10000 fois plus rapide en C++ mais... moins traçable (source codée-> objet généré, aéronautique oblige), bien que plus sécurisé, etc.
Le choix d'un language sur un autre n'est pas qu'une question de préférences du programmeur.

Edited_3394

c'est pas une question de fénéantise, simplement avec des langages plus évolués on peut par exemple coder 2 fois plus pendant le même temps (voire bien plus, ce n'est qu'un facteur au pif), donc question rendement c'est plus qu'interessant, même si les perfs sont 10% ou 20% moins bonnes (dans le cas du C++, pour Java effectivement c'est une autre histoire). à moins de vraiment être au taquet sur les perf, donc à part pour du demo making comme disait Ximoon, ça n'a plus tellement d'interêt de coder en C quand on peut faire du C++, c'est plus une perte de temps qu'autre chose...

Oui suffit de voir l'évolution des OSs, le C se cantonne de plus en plus uniquement qu'a endroits vraiment critiques ou le C++ n'est pas possible, et la ou l'ASM serait trop complexe

Edited_3395

Orion_ (./22) :
c'est clair que les languages évolué sont la pour faciliter la tache au codeur toujours plus fénéant, mais alors bonjour la lourdeur du code une fois executé sur la machine

Comme le dit Bob, c'est grossièrement faux, en effet un code généré avec un language de plus haut niveau n'est pas seulement plus facile à écrire, mais aussi à comprendre et à maintenir. Sans compter que réduire le nombre de lignes de code réduit d'autant la probabilité de faire des erreurs.
Un code de démo ne pourra être relu par personne et encore moins maintenu et débogué. Je ne parle même pas des évolutions.
Quant au dimensionnement des systèmes, c'est une autre histoire, mais à part dans des applications très contraignantes et spécifiques (temps réel dur: asservissement de moteurs, codecs, modems, etc), et à plus forte raison pour le décodeur CB qui nous intéresse, le matériel sera souvent largement sous exploité par le logiciel. Tout simplement parcequ'il faut garder une marge suffisante a priori pour être sûr que le code rentre, et que les évolutions et corrections seront toujour spossibles après.

ah bah forcément en contrepartie c'est plus complexe, et puis il faut reflechir un peu à la modélisation avant de se lancer sous peine de faire n'importe quoi, mais bon c'est comme tout : ça s'apprend ^^
(et pr les "3 pages d'erreur", y'a pas que gcc ds la vie )

[cross] ms post quand même, na.

Edited_3396

Orion_ (./25) :
trop complexe le C pour moi, je perd plus de temps a trouver comment faire un truc en C++ ou trouver pourquoi le compilo me sort 3 pages d'erreur

Ca, c'est juste parceque tu ne connais pas assez bien le language
[cross avec Bob] Effectivement, la spécification haut niveau et bas niveau, la modélisation etc c'est pas pour les chiens, mais forcément quand on est amateur on fait rarement ça

Orion_ (./25) :
ensuite dans l'embarqué ou les consoles portable on utilise encore le C pour des raisons de perf.

Et justement c'est ce qu'on dit depuis le début, le monde dit "embarqué" est tellement vaste qu'on ne peut pas généraliser. Oui parfois on code en C, parfois en assembleur, parfois en Java, ça dépend des contraintes.
J'ai déjà programmé pour un projet en C++ sur un DSP par exemple, et en ce moment je fais du C. La prochaine fois je ne sais pas quelles seront les contraintes, on verra bien.
Typiquement un jeu sur console portable a besoin de vitesse, et les contraintes de temps de développement ne sont pas les mêmes que pour un industriel.

Orion_ (./28) :
ahh uml
cela dit, vaux mieux reflechir a un code avant de ce lancer dedans ça y'a pas de soucis ... mais bon toute ces normalisations de schema uml et compagni .... ou comment prendre la tête a un codeur ... (par contre c sur qu'au niveau industriel ça claque )

UML c'est pour l'orienté objet, pour le temps réel embarqué tu peux aller voir SA/RT, c'est plus vieux mais extrêmement pratique