› Foros › Retro y descatalogado › Consolas clásicas
Pararegistros escribió:@jj_0
Great tips.
BTW, they say:yeah
we have some protections in place, but i guess the only fool proof way is digitally signing the binary
i.e. its signed using a key that only we have
Thats a step above what we've done so far
nothing says we can't do that ofc
yea
its hash checked and what not
can't stop anyone creating a http server and doing domain redirection - thats (for example) how steam caches and xbox live etc caches work
the bit we can improve for protection is the binary validation
So until now it is very vulnerable to external attacks (malicious or to hack update server to mod the CHA) as PSVita or Wii with DNS mod method if one could inject signed code.
Pararegistros escribió:@CAMPIRULO
@kikex-box
@Vick21
¿Habéis probado eso con ese método y hay novedades frescas?
Pararegistros escribió:@CAMPIRULO
@kikex-box
@Vick21
¿Habéis probado eso con ese método y hay novedades frescas?
vick21 escribió:Pararegistros escribió:@CAMPIRULO
@kikex-box
@Vick21
¿Habéis probado eso con ese método y hay novedades frescas?
Yo no he podido mirar nada más. Quería mirar lo que ha comentado @jj_0 de arrancar un sistema de orangepi (también intenté en su día con el chroot del sistema, pero no conseguí nada) para investigar alguna cosilla, pero vamos toquitear ya lo que es el sistema de Capcom ahí me pierdo, que yo soy administrador de sistemas, no desarrollador...
Lo de engañar al sistema de actualización del CHA, ya lo había pensado ya que vi el script de arranque (el S21Capcom) y me pareció bastante simple, pero para eso hay que tener una alternativa a esos binarios para inyectárselo...
Pararegistros escribió:@RataWeb
Como se ha dicho, es una placa Orange Pi personalizada (vamos, sin puertos USB ni lector de tarjetas SD ).
De momento la sustitución de las roms con límite de 16 y esperar a ver como avanza la cosa. Y mientras que salga una 1.5 estable porque ahora ejecutando juegos CPS3 a tope de opciones (16:9 + scanlines) no demuestra que se sobrecaliente la CPU y falta pulir detalles. Hay un par de obstáculos pero ya están más cerca.
Pero vamos, con esto y próximamente la PCB BT a la venta, quien no se la haya pillado ya... es porque no la quiere y luego que no llore.
miguelonic escribió:@Pararegistros
Bueno, qué tal? Muy guapo jugar a Black Tiger, uno de los primeros arcades que jugué en salones... hace mucho mucho tiempo...
Estamos en mayo y no hay link para comprar la PCB bluetooth y tampoco está la 1.5... esto les hace quedar mal, simplemente se queda mejor no anunciándolo pero bueno, son las ganas de tenerlo...
Por otro lado todo lo avanzado en la scene se sigue en otro hilo de diferente foro o web en el idioma de Shakespeare dónde esté el amigo jj_0
EDITO: 2 preguntas; cuando le cambiaste la PCB terminaste poniendo las gomas que venían en el kit o re-pegaste las originales?
Tacto jostick, botones, sensaciones, etc con cuál te quedas, estos de sanwa o los que tienes de IL? Gracias!
miguelonic escribió:@kikex-box
Gracias, entiendo que una vez hemos conectado la placa por UART (soldado) mediante USB al pc, este tiene que estar con Linux, la interrupción de uboot y ganar acceso root, no sabría cómo hacerlo sin alguna instrucción previa.
Kei_Dash escribió:Aquí estamos:
Así como resumen:
- Mi CHA es alemana y tiene lector de SD ya instalado
- Hice los pasos para cambiar passwd de root
- Hice una imagen de las particiones a la SD CARD
- He modificado el UBOOT para que arranque desde la SD CARD (también es posible hacerlo desde USB) pero la modificación no se queda permanente, tengo que investigar el porqué, creo que algún proceso en la carga lo vuelve a dejar desde la MMC interna ya que otras modificaciones sí se quedan permanentes. Pendiente de revisar, no es prioritario hasta que se solucione lo siguiente.
- El emulador incluido fba_libretro (v0.2.97.44) está limitado para que sólo acepte las ROMS que vienen incluidas, si lo arrancamos a mano desde Linux con otras ROMS no funciona. He revisado el código con un RA2 y efectivamente no hay referencias a más ROMS de ahí que sólo ocupe 14MB frente a los 60MB de mismo emulador completo (con referencias internas a todas las ROMS).
- Una vez cambiado el emu arranca la rom del dino si problemas desde la shell, si cerramos antes el menú de CAPCOM ya que sino se queda sin RAM (posiblemente por esto se reinicie el menú tras cada juego, simplemente para liberar memoria).
- Desde el menú de CAPCOM no se pueden lanzar otras ROMS distintas a las que vienen incluidas ya que, el emulador necesita que el menú le indique el nombre correcto del juego para que lo inicie y cualquier modificación en el fichero que controla esto "\opt\capcom\assets\games.txt" hace que el menú no arranque (muestra el logo de KOCH y nunca llega al de CAPCOM) <- Este es el punto en el que estoy ahora, revisando como pasar este control.
- Además he encontrado partes de scripts comentadas como la posibilidad de volcar una imagen desde el USB a la partición interna en cada arranque (lo que sería una buena solución una vez comprobado todo ya que se puede liar).
- Y otro punto sería como ganar root e instalar un medio de acceso directo (OpenSSH ¿?) sin UART mediante un DNS Spoofing de http://cha.tbbrds.com pero eso para más adelante...
A ver si alguna noche más me puedo quedar a investigar y os voy comentando.
@CAMPIRULO si tu placa ha muerto pero tienes acceso UART te la puedo intentar recuperar.
Kei_Dash escribió:- Una vez cambiado el emu arranca la rom del dino si problemas desde la shell, si cerramos antes el menú de CAPCOM ya que sino se queda sin RAM (posiblemente por esto se reinicie el menú tras cada juego, simplemente para liberar memoria).
Pararegistros escribió:@gynion Todavía hay problemas con la 1.5. Hay cosas que están y otras que hay que solucionar.
Muchas gracias Campirulo, este finde quiero meterle mano, mi placa lleva ranura SD, pregunto; se puede llegar al proceso sin soldar en la placa?CAMPIRULO escribió:
El modo de interrumpir el Uboot es sencillo.
Es mas facil de lo que parece.
Aunque no estemos posteando, no quiere decir que este la cosa parada, a ver que sale
upd
├── e4f0d6df5d62e282c138ecd3af755764
│ ├── asset.zip
│ ├── capcom
│ ├── updater
│ └── version.txt
└── current.txt
# md5sum capcom
e4f0d6df5d62e282c138ecd3af755764 capcom
# echo "PADDING" >>capcom
# md5sum capcom
988080fad1f493d01f0f951c3408c995 capcom
ifconfig eth0:1 77.240.1.20
bootargs=console=ttyS0,115200 root=///dev///mmcblk1p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
bootargs=console=ttyS0,115200 root=//dev///mmcblk0p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
jj_0 escribió:Overall I think the easiest way to make changes to the CHA without having to open it up is to abuse the update mechanism. In fact it took me much longer to type the explanation below than to actually set it up :
- Choose which device you are going to use as a fake update webserver.
- Install a webserver on it. This obviously depends on what OS you are using but there are options for both Windows and Linux
- In the webserver root folder create the directory structure as I described here:
upd
├── 6aba9986b734f32fc7e1a9c5c3907410
│ ├── asset.zip
│ ├── capcom
│ ├── updater
│ └── version.txt
└── current.txt- For the initial files you can download the 'capcom', 'updater' and if you want 'asset.zip' from the official CapCom update server:
- In a browser go to http://cha.tbbrds.com/upd/current.txt
- This will display the md5sum has5 of the latest update (at the time of writing: 'e4f0d6df5d62e282c138ecd3af755764') which is also the name of the folder you need to download the files from:
http://cha.tbbrds.com/upd/http://cha.tbbrds.com/upd/e4f0d6df5d62e282c138ecd3af755764/capcom
http://cha.tbbrds.com/upd/e4f0d6df5d62e282c138ecd3af755764/update
http://cha.tbbrds.com/upd/e4f0d6df5d62e282c138ecd3af755764/asset.zip- 'version.txt' you can create with whatever text you want
- 'current.txt' has the md5sum hash of 'capcom' but al lthat is really required is that it is a different md5sum than what is currently on the CHA. I used '6aba9986b734f32fc7e1a9c5c3907410'
- On the device give it's network connection a second IP address which is the same as 'cha.tbbrds.com' has. Currently that's 77.240.1.20:
- On Linux do something like
ifconfig eth0:1 77.240.1.20
- On Windows you can edit an 'Alternate Configuration' in the IP properties of the network adapter
- Now all that's left to do is to ensure that the CHA will connect to your webserver rather than the official one. To do this set up a route in your router to point to the your webserver. Assuming the real ip-address of your webserver's PC is for example 192.168.178.105 you need to tell your router to send requests to 77.240.1.20 instead to 192.168.178.105. Most routers have an option somewhere to put in a 'static route' to do this. In my example the static route would be network: 77.240.1.0, netmask: 255.255.255.0, gateway 192.168.178.105.
- You can check whether it works by (on a different device go to http://cha.tbbrds.com/upd/current.txt and check if the hash displayed is indeed the one you put in the file 'current.txt.' However ensure that your browser hasn't cached te original page or address. You can also ping cha.tbbrds.com and you should see quite low ping times as ti will be on your own network
- Of course you can also differently, e.g. set up your PC as Wifi hotspot with address range 77.240.1.xx, or set up a separate access point etc etc
Once you have done all the above you can basically keep the 'capcom' and 'updater' binaries as is, only changing them when new versions are released. An then make any change you want by changing 'asset.zip'.
If one doesn't mind opening up the CHA then both UART connection (I just bend the 5V and 3.3V pins of the USB2UART converter out of the way and stick the GND, RX and TX pins through the appropriate holes and squeeze them a bit so thee device is fixed into position) an using FEL mode are easy to use for different purposes.
@Kei_dash Which fba_retrolib.so did you use, the same one I used here or a different one? The one I used doesn't skip the games bootup process does your skip them?
Also, regarding UBOOT changes to boot from SD-card note being permanent, I assume you would change the bootargs variable from:to:bootargs=console=ttyS0,115200 root=///dev///mmcblk1p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
and then do a 'saveenv'? I don't have an SD-card board myself, so i'm wondering whether with an SD_card inserted u-boot + settings is loaded still form the internal eMMC or from the SD-card?bootargs=console=ttyS0,115200 root=//dev///mmcblk0p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
Btw, does anyone else also hate the fact that the forum doesn't allow single //'s?
RataWeb escribió:
Hi @jj_0,
I think that it's better that in the same server that you are configured a fake webserver, configure a domain name server to resolve cha.tbbrds.com domain with your IP webserver. Remember change on your router, the DNS, then it will assign your IP server as a DNS to CHA.
Regards,
jj_0 escribió: @Kei_dash Which fba_retrolib.so did you use, the same one I used here or a different one? The one I used doesn't skip the games bootup process does your skip them?
Also, regarding UBOOT changes to boot from SD-card note being permanent, I assume you would change the bootargs variable from:to:bootargs=console=ttyS0,115200 root=///dev///mmcblk1p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
and then do a 'saveenv'? I don't have an SD-card board myself, so i'm wondering whether with an SD_card inserted u-boot + settings is loaded still form the internal eMMC or from the SD-card?bootargs=console=ttyS0,115200 root=//dev///mmcblk0p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
Btw, does anyone else also hate the fact that the forum doesn't allow single //'s?
setenv fdt_high ffffffff
setenv bootargs console=ttyS0,115200 root=/dev/mmcblk${mmc_bootdev}p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
fatload mmc ${mmc_bootdev} $kernel_addr_r zImage
fatload mmc ${mmc_bootdev} $fdt_addr_r sun8i-h3-orangepi-pc.dtb
bootz $kernel_addr_r - $fdt_addr_r
Kei_Dash escribió:jj_0 escribió: @Kei_dash Which fba_retrolib.so did you use, the same one I used here or a different one? The one I used doesn't skip the games bootup process does your skip them?
Also, regarding UBOOT changes to boot from SD-card note being permanent, I assume you would change the bootargs variable from:to:bootargs=console=ttyS0,115200 root=///dev///mmcblk1p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
and then do a 'saveenv'? I don't have an SD-card board myself, so i'm wondering whether with an SD_card inserted u-boot + settings is loaded still form the internal eMMC or from the SD-card?bootargs=console=ttyS0,115200 root=//dev///mmcblk0p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
Btw, does anyone else also hate the fact that the forum doesn't allow single //'s?
Lo siento pero al ser un foro de habla hispana te respondo en castellano, no tengo inconveniente en hablar por MP en inglés. Intento usar expresiones simples para que se traduzcan correctamente.
Acerca del UBOOT, el cambio que hice fue poner la variable mmc_bootdev a "0", tras esto hacer un saveenv pero esto sólo afecta al boot actual. Aunque haga un saveenv en el siguiente arranque vuelve a arrancar desde la MMC interna.
La modificación que comentas me parece más agresiva ya que los parámetros que tengo en el boot.scr son:setenv fdt_high ffffffff
setenv bootargs console=ttyS0,115200 root=/dev/mmcblk${mmc_bootdev}p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
fatload mmc ${mmc_bootdev} $kernel_addr_r zImage
fatload mmc ${mmc_bootdev} $fdt_addr_r sun8i-h3-orangepi-pc.dtb
bootz $kernel_addr_r - $fdt_addr_r
Y si consiguiéramos poner el mmc_bootdev = 0 de forma permanente, sería todo más rápido y limpio, ¿no lo crees?
=> printenv bootcmd_mmc1
bootcmd_mmc1=setenv devnum 1; run mmc_boot
=> setenv bootcmd_mmc1 "setenv devnum 0; run mmc_boot"
=> printenv bootcmd_mmc1
bootcmd_mmc1=setenv devnum 0; run mmc_boot
=> saveenv
Saving Environment to FAT... writing uboot.env
OK
=>
jj_0 escribió:RataWeb escribió:
Hi @jj_0,
I think that it's better that in the same server that you are configured a fake webserver, configure a domain name server to resolve cha.tbbrds.com domain with your IP webserver. Remember change on your router, the DNS, then it will assign your IP server as a DNS to CHA.
Regards,
Sure you can do it that way as well. But if you don't want to install a DNS server you can do it just by 'using' the IP-address on your own network. On my router that was easy to do so I didn't need to install a DNS server as well. But both ways work.
I'm not sure how long this method is going to work anyway, it seems that in v1.4 they have already changed something, not using 'wget' anymore in the updater. So I guess the best way forward is sitll going to be via UART or FEL mass-storage.
@Pararegistros Regarding manual Wifi, you will still need to 'hijack' the update IP address I think.
jj_0 escribió:Kei_Dash escribió:jj_0 escribió: @Kei_dash Which fba_retrolib.so did you use, the same one I used here or a different one? The one I used doesn't skip the games bootup process does your skip them?
Also, regarding UBOOT changes to boot from SD-card note being permanent, I assume you would change the bootargs variable from:to:bootargs=console=ttyS0,115200 root=///dev///mmcblk1p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
and then do a 'saveenv'? I don't have an SD-card board myself, so i'm wondering whether with an SD_card inserted u-boot + settings is loaded still form the internal eMMC or from the SD-card?bootargs=console=ttyS0,115200 root=//dev///mmcblk0p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
Btw, does anyone else also hate the fact that the forum doesn't allow single //'s?
Lo siento pero al ser un foro de habla hispana te respondo en castellano, no tengo inconveniente en hablar por MP en inglés. Intento usar expresiones simples para que se traduzcan correctamente.
Acerca del UBOOT, el cambio que hice fue poner la variable mmc_bootdev a "0", tras esto hacer un saveenv pero esto sólo afecta al boot actual. Aunque haga un saveenv en el siguiente arranque vuelve a arrancar desde la MMC interna.
La modificación que comentas me parece más agresiva ya que los parámetros que tengo en el boot.scr son:setenv fdt_high ffffffff
setenv bootargs console=ttyS0,115200 root=/dev/mmcblk${mmc_bootdev}p2 rootwait usbhid.quirks=0x1C59:0x0023:0x20000000 quiet vt.global_cursor_default=0
fatload mmc ${mmc_bootdev} $kernel_addr_r zImage
fatload mmc ${mmc_bootdev} $fdt_addr_r sun8i-h3-orangepi-pc.dtb
bootz $kernel_addr_r - $fdt_addr_r
Y si consiguiéramos poner el mmc_bootdev = 0 de forma permanente, sería todo más rápido y limpio, ¿no lo crees?
No problem with you using Spanish, it works quite well with Google Translate. Unfortunately I don't speak Spanish at all so I have to use English.
I agree, my method would be more aggressive and it would be better to make 'mmc_bootdev = 0' permanent. However I think that the 'mmc_boot_dev' variable is set by u-boot during booting. That will overwrite any change you make to it. But another way is to change 'bootcmd_mmc1':=> printenv bootcmd_mmc1
bootcmd_mmc1=setenv devnum 1; run mmc_boot
=> setenv bootcmd_mmc1 "setenv devnum 0; run mmc_boot"
=> printenv bootcmd_mmc1
bootcmd_mmc1=setenv devnum 0; run mmc_boot
=> saveenv
Saving Environment to FAT... writing uboot.env
OK
=>
This is not overly aggressive, and if you want to restore the original settings you can always delete the uboot.env file
I'm still curious, which fba_libretro.so did you use?
env set -f mmc_bootdev_custom 0
env set -f bootcmd_mmc_auto "if test ${mmc_bootdev_custom} -eq 1; then run bootcmd_mmc1; run bootcmd_mmc0; elif test ${mmc_bootdev_custom} -eq 0; then run bootcmd_mmc0; run bootcmd_mmc1; fi"
env set bootcmd_mmc0 "setenv devnum 0; setenv mmc_bootdev 0; run mmc_boot"
env set bootcmd_mmc1 "setenv devnum 1; setenv mmc_bootdev 1; run mmc_boot"
env save
miguelonic escribió:@Kei_Dash
Increíble vaya logro..! Felicitaciones.
Pregunta de profano: ¿Es posible, meter una tarjeta SD (con los datos adecuados) y que arranque con la modificación de ROMs que se pretenda sin hacer previamente nada? Muchas gracias.
Kei_Dash escribió:miguelonic escribió:@Kei_Dash
Increíble vaya logro..! Felicitaciones.
Pregunta de profano: ¿Es posible, meter una tarjeta SD (con los datos adecuados) y que arranque con la modificación de ROMs que se pretenda sin hacer previamente nada? Muchas gracias.
No, eso sería la leche!! desde el fronted de CAPCOM que se arranca, de momento, solo se pueden ejecutar las ROMS que vienen. Cualquier modificación en el archivo que controla esto games.txt hace que no arranque el frontend. Estamos ahora con ello...
Kei_Dash escribió:Hola, finalmente he solucionado el arranque desde la SD permanente con los siguintes cambios en el env del UBOOT:env set -f mmc_bootdev_custom 0
env set -f bootcmd_mmc_auto "if test ${mmc_bootdev_custom} -eq 1; then run bootcmd_mmc1; run bootcmd_mmc0; elif test ${mmc_bootdev_custom} -eq 0; then run bootcmd_mmc0; run bootcmd_mmc1; fi"
env set bootcmd_mmc0 "setenv devnum 0; setenv mmc_bootdev 0; run mmc_boot"
env set bootcmd_mmc1 "setenv devnum 1; setenv mmc_bootdev 1; run mmc_boot"
env save
Además, estos cambios permiten que, si no hay una SD presente (mmc0), el sistema arranque desde la MMC interna (mmc1) directamente. Posteriormente habría que añadir la posibilidad de hacer lo mismo con el puerto para no tener que estar con la SD y para los que no tengáis esta posibilidad, aunque supongo que el puerto USB será algo más lento.
Kei_Dash escribió:El fba_libretro que utilizo es este:
https://www.mediafire.com/file/9fc2lemc5owo8og/fba_libretro.zip/file
Pararegisters escribió:But with manual IP, someone could try to create an alternative update server with its own DNS (such as the case for Henkaku Enso and Wiihack) and it would be even better than having to change router DNS or creating a DNS server with BIND or similar software.
miguelonic escribió:(Translated from Spanish by Google, apologies if this isn't what you meant) So, the situation so far to load another ROM would only be possible connecting by UART to pc
jj_0 escribió:If you load my fake firmware upgrade you should not need an UART, but can connect via ftp or ssh or scp to copy and change things. Or you could use the fake firmware method to create an 'asset.zip' that replaces the //usr//lib//libretro//fba_libretro.so, replaces the //opt//capcom//assets//games.txt and adds a new game and the neccesary pictures and music in //opt//capcom//assets as well.