Posté le 26/08/2021 16:31
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 54 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 27/08/2021 12:16 | #
(Je réalise que j'ai un été un peu sec hier, je m'en excuse.)
Tu peux voir quelques variations déjà en regardant les extraits de Redcmd. Regarde cette section :
0000004E EB07 MOV #7,R11
00000050 E100 MOV #0,R1
00000052 E704 MOV #4,R7
00000054 6013 MOV R1,R0
00000056 L649:
Monochrome 45 {
Monochrome 46 *LCD_register_selector = 4;
Monochrome 47 *LCD_data_register = i | 192;
00000056 E2C0 MOV #-64,R2
00000058 2570 MOV.B R7,@R5
Note que le (mov r1, r0) de code 0x6013 est suivi immédiatement du (mov #-64, r2) de code 0xe2c0 et ensuite seulement du (mov.b r7, @r5) de code 0x2570.
Tandis que dans Gravity Duck:
L'ordre est inversé, le (mov.b r7, @r5) précède le (mov #-64, r2). Les deux versions du code sont correctes ; je crois que celle de Gravity Duck gagne un cycle sur SH3. Dans tous les cas, c'est à ce genre de différences que je faisais allusion.
(Je ne saurais pas quoi ajouter à ton post ci-dssus parce que je ne vois pas quel octets tu références.)
Citer : Posté le 27/08/2021 18:38 | #
comment le 4 s'est transformé en -64! ça fais 1h que je bloque dessus
Citer : Posté le 27/08/2021 18:41 | #
Tu peux préciser la question ?
Dans l'instruction e2c0, le e signifie mov d'une valeur constante vers un registre, le 2 est le numéro du registre, et le c0 est la valeur. L'instruction fonctionne avec des valeurs signées sur 8 bits, et donc c0 représente -64. La valeur subit une extension de signes sur 32 bits et devient 0xffffffc0 une fois dans le registre, c'est pour ça que le désassembleur affiche ça dans le code de Gravity Duck.
Citer : Posté le 27/08/2021 20:44 | #
premiers résultats concluants:
fread result: 1
filesize: 52600
find!
e7 04 d5 21 e6 00 d4 21 ec 07
find!
e7 04 60 13 e2 c0 25 70 66 a3
Ajouté le 28/08/2021 à 10:36 :
mon programme ne trouve pas l'instruction de la constante
if(filedata[i] == 0xd5 & filedata[i+1] == 0x2b){
printf("find! \n");
for(int c=0; c<20; c++){
printf("%02x ",filedata[i+c]);
}
printf("\n\n");
addr = i;
}
}
if(addr == 0){
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("no valid file or no data to edit\n");
return -1;
}
fread result: 1
filesize: 52600
error: no valid file or no data to edit
Citer : Posté le 28/08/2021 10:43 | #
Tu as utilisé l'opérateur & au lieu de &&. (-Wall te prévient de ce genre d'erreurs).
Sauf erreur de ma part, le résultat est lu comme ça :
Ce qui n'est jamais vrai puisque l'opérande de gauche est un booléen (0 ou 1) et celui de droite est 0x2b.
Citer : Posté le 28/08/2021 10:53 | #
même en mettant && ça ne change rien
Citer : Posté le 28/08/2021 11:02 | #
Ah mais je vois ce que tu essaies de faire, il te manque quelques notions d'assembleur SuperH.
Comme tu peux le voir, les instructions font deux octets. Ce format fixe fait partie du design du processeur. Par conséquent, une instruction qui copie une constante dans un registre comme (mov #2, r5) a très peu de place pour écrire la valeur de la constante (en l'occurrence 8 bits) et donc la valeur est limitée (à -128 ... 127).
Pour charger des valeurs plus grandes, un mode d'adressage spécial est utilisé. On l'écrit (mov.[wl] @(<disp>,pc), rn) où le .w/.l indique la taille du chargement (2 ou 4 octets) et le disp est une distance entre la position courante et la position de la valeur à charger.
En bref, quand tu vois ça :
Ce qui se passe c'est que le 0xb4000000 est stocké plus loin dans le code, et 0xd52b signifie "copie-moi la valeur qui est située à 176 octets d'ici".
D'un code à l'autre, la valeur ne sera pas toujours au même endroit, donc chercher exactement 0xd52b n'a pas vraiment d'intérêt. Tu peux plutôt chercher ton code comme avant mais ensuite vérifier qu'il y a un 0xb4000000 ou un 0xb4010000 aligné sur une adresse multiple de 4 dans les 200-250 octets suivants.
Citer : Posté le 28/08/2021 14:11 | #
voila la table d'octets a changer!
j'ai un doute sur le mov R1,R0 mais je vais déjà essayer ça
//origin converted
0xeb,0x07, 0xeb,0x10,
0xe1,0x00, 0xe1,0x04,
0xe7,0x04, 0xe7,0x08,
0xe2,0xc0, 0xe2,0x80,
}
Ajouté le 28/08/2021 à 14:39 :
//origin converted
0xeb,0x07, 0xeb,0x10,
0xe1,0x00, 0xe1,0x04,
0xe7,0x04, 0xe7,0x08,
0xe2,0xc0, 0xe2,0x80,
};
...
for(int a=0; a<sizeof(convert_table); a=a+4){
for(int i=0; i<filesize-80; i++){
if(filedata[i] == convert_table[a] && filedata[i+1] == convert_table[a+1]){
printf("find! \n");
for(int c=0; c<20; c++){
printf("%02x ",filedata[i+c]);
}
printf("\n\n");
addr = i;
}
}
}
fread result: 1
filesize: 52600
find!
eb 07 e1 00 e7 04 60 13 e2 c0 25 70 66 a3 22 0b 24 20 25 70
find!
e1 00 98 06 2c 12 9a 05 69 83 dd 08 de 09 a0 57 79 05 75 42
find!
e1 00 90 17 22 12 02 fe 22 e2 90 14 02 fe a0 9a 22 e2 2f e2
find!
e1 00 e7 04 60 13 e2 c0 25 70 66 a3 22 0b 24 20 25 70 24 10
find!
e1 00 09 00 ff 35 e0 89 1e 60 d3 30 5c 01 6c 37 a8 63 9b 62
find!
e1 00 00 00 00 ff 00 7f ff ff 00 00 07 ff 7f f0 00 00 00 00
find!
e7 04 d5 21 e6 00 d4 21 ec 07 2f b6 61 63 2f a6 eb 10 ea 40
find!
e7 04 60 13 e2 c0 25 70 66 a3 22 0b 24 20 25 70 24 10 25 b0
find!
e2 c0 25 70 66 a3 22 0b 24 20 25 70 24 10 25 b0 46 10 63 c4
quelque faux positifs a supprimer et c'est fini
Ajouté le 28/08/2021 à 22:00 :
voila!
fread result: 1
filesize: 52600
00002532 eb07 -> 00002532 eb10
00002534 e100 -> 00002534 e104
00002536 e704 -> 00002536 e708
0000253a e2c0 -> 0000253a e280
j'ai testé gravity guy, je peux voir globalement la scène de jeux avec un écran très beuggé, mais je vois très bien le menu de pause
le dernier bug graphique doit être dut a une instruction ou j'ai pas compris l’intérêt
la, je sous bloqué
#include <stdlib.h>
#include <unistd.h>
unsigned char convert_table[] = {
//origin converted
0xeb,0x07, 0xeb,0x10, //first address to find!
0xe1,0x00, 0xe1,0x04,
0xe7,0x04, 0xe7,0x08,
0xe2,0xc0, 0xe2,0x80,
};
int main(int argc, char **argv){
if(argc == 1){
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("no input and output file!\n");
return -1;
}
if(argc == 2){
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("no output file!\n");
return -1;
}
if(access(argv[1], F_OK ) == 0) {
//none
} else {
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("cannot open file!\n");
return -1;
}
printf("\033[0;37m"); //white text
FILE * file; //file pointer
file = fopen(argv[1], "rb"); //open file
fseek(file, 0L, SEEK_END); //seek file size
int filesize = ftell(file); //get file size
unsigned char* filedata = NULL; //make file data table
filedata = malloc(filesize);
for(int i=0; i<filesize; i++){
filedata[i] = 0x00;
}
fseek(file, 0, SEEK_SET);
int fread_result = fread(filedata, filesize, 1, file); //set file data in filedata table
printf("fread result: %d\n",fread_result);
fclose(file); //close input file
int addr = 0; //address of data to change
printf("filesize: %d\n\n",filesize);
//////////////////////FIND SEQUENCE TO CHANGE/////
for(int i=0; i<filesize-80; i++){
if(filedata[i] == convert_table[0] && filedata[i+1] == convert_table[1]){
//for(int c=0; c<20;c++){printf("%02x ",filedata[i+c]);}
printf("%08x %02x%02x -> %08x %02x%02x\n",i,convert_table[0],convert_table[1], i,convert_table[2],convert_table[3]);
filedata[i] = convert_table[2];
filedata[i+1] = convert_table[3];
addr = i;
break;
}
}
for(int a=4; a<(4*4); a=a+4){
for(int i=addr; i<addr+100;i++){
if(filedata[i] == convert_table[a+0] && filedata[i+1] == convert_table[a+1]){
printf("%08x %02x%02x -> %08x %02x%02x\n",i,convert_table[a+0],convert_table[a+1], i,convert_table[a+2],convert_table[a+3]);
filedata[i] = convert_table[a+2];
filedata[i+1] = convert_table[a+3];
break;
}
}
}
if(addr == 0){
printf("\033[1;31m"); //red
printf("error: ");
printf("\033[0;37m"); //white
printf("no valid file or no data to edit\n");
return -1;
}
file = fopen(argv[2], "wb"); //open output file
//write final data in output file
fwrite(filedata , sizeof(char) , filesize , file);
fclose(file); //close output file
free(filedata);
return 1;
}
Citer : Posté le 28/08/2021 23:13 | #
can you send your fixed GravityDuck.G1A please?
0xeb,0x07, 0xeb,0x10
eb10 should be eb0a
the numbers are in hexidecimal, not decimal
6013 must be changed to e000
this is because it currently copies r1 to r0, with r1 being set to 0
but after changing e100 to e104, r1 now gets set to 4, which will cause the offset by 4 bug
also bear in mind that register numbers, order and location will be different between different programs
so instead of checking for eb07, you should be checking for e-07
Citer : Posté le 29/08/2021 13:35 | # |
Fichier joint
fread result: 1
filesize: 52600
00002532 eb07 -> 00002532 eb0a
00002534 e100 -> 00002534 e104
00002536 e704 -> 00002536 e708
0000253a e2c0 -> 0000253a e280
00002538 6013 -> 00002538 e000
voila une version fonctionnelle de GravityGuy sur graph 35+E II
il y a encore des trucs a faire comme le dit redcmd et Lephénixnoir, mais je vais déjà commiter ça
Citer : Posté le 23/02/2024 04:49 | #
Quand tu partages un outil bas-niveau comme ça les gens te font confiance pour savoir ce que tu fais.
Citer : Posté le 23/02/2024 08:04 | #
Quand tu partages un outil bas-niveau comme ça les gens te font confiance pour savoir ce que tu fais.