Jump to content
IGNORED

The new Atari 2600+ Hacked?


WhyLee commotari.club

Recommended Posts

18 minutes ago, WhyLee commotari.club said:

it could be a linux serial console

Actually there is a serial linux console all the way to the USB-C port. It nicely asks for login credentials.

 

It is also accepting firmwares using Rockchip Batch Tool or Rockchip Factory Tool. I don't know if it is capable to update the firmwares of the 2 MCU chips on the I/O board. My guess is that you can update everything.

  • Like 1
Link to comment
Share on other sites

2 hours ago, karri said:

Actually there is a serial linux console all the way to the USB-C port. It nicely asks for login credentials.

 

It is also accepting firmwares using Rockchip Batch Tool or Rockchip Factory Tool. I don't know if it is capable to update the firmwares of the 2 MCU chips on the I/O board. My guess is that you can update everything.

admin/admin?  atari/atari?  plaion/plaion? 😀

Link to comment
Share on other sites

15 minutes ago, Zap1982 said:

Password123 or the month of the year has been the password on all the confidential stuff wherever I have ever worked.

Naah. My guess would  be something easier to remember and written on the box like:

login: root (as it is linux)

pw: 2600+

 

Link to comment
Share on other sites

1 minute ago, Zap1982 said:

Is there any programme (not Codebreaker on the 2600! 😂) that could be used to decipher it? 

The easiest way might be to ask for it. But this may be difficult as the credentials are the same for all units. You do not want hackers to install their own stuff on machines. I would not share it.

 

The chip has a mask rom booting capability. You can just write your own firmware from scratch and install it :) . Or wait until they have a good enough firmware that allows us to run homebrews on the 2600+.

Link to comment
Share on other sites

4 hours ago, WhyLee commotari.club said:

something is already soldered on this UART pins.

It's a resistor soldered between the 5V and GND pads. I'm pretty sure It's a fix for a design change (or flaw) otherwise they wouldn't use a through hole resistor. Haven't checked it yet but I'm thinking it may just be a current limiting resistor for the logo / power led.

 

4 hours ago, WhyLee commotari.club said:

two different JTAG connectors - U1 and U2.

There are two MCUs on the I/O board. each header is probably used in the factory to program the firmware and/or bootloader to those MCUs

 

Those UART Rx and Tx pins are most likely used for the dumper to communicate with the main board. When sniffed we will probably see the rom dump and controller states pass by.

 

Link to comment
Share on other sites

On 11/23/2023 at 9:29 PM, Blinky said:

It's a resistor soldered between the 5V and GND pads. I'm pretty sure It's a fix for a design change (or flaw) otherwise they wouldn't use a through hole resistor. Haven't checked it yet but I'm thinking it may just be a current limiting resistor for the logo / power led.

 

There are two MCUs on the I/O board. each header is probably used in the factory to program the firmware and/or bootloader to those MCUs

 

Those UART Rx and Tx pins are most likely used for the dumper to communicate with the main board. When sniffed we will probably see the rom dump and controller states pass by.

 

no the kernal is on the nand and should be called nanda and the firmware should be in nandb in dev folder, it uses the same nand from THEC64 Mini/THEA500 Mini, it looks like old stock to me, the company that made the nand is not called TOSHIBA any more its called KIOXA... https://thec64community.online/thread/426/rgl-thec64

Edited by Spanner
Link to comment
Share on other sites

On 11/29/2023 at 7:47 PM, Spanner said:

no the kernal is on the nand and should be called nanda and the firmware should be in nandb in dev folder

sligtly confused as I wasn't talking about the kernal but about the Micro Controllers of which one handles the (joystick) controller ports and the other the cart dumper. Their programs are stored in internal flash memory and not in the mainboards nand chip.

Link to comment
Share on other sites

Just a small discovery. The TX and RX pins are doubled on the connector. Good engineering. So you need to cut a pin in both rows if you want to inhibit transmission.

 

There is some fast cart removal mechanism that informs the CPU that the cart has been removed. It does not wait for a signal over the TX lines.

 

Link to comment
Share on other sites

1 hour ago, karri said:

you need to cut a pin in both rows

Alternatively you can heat up the solder joints of the two Tx pins on the header and push down those pins on the side of a table or something. That way if you ever want to restore the header pins, you can heat them up again and push them back.

  • Like 1
Link to comment
Share on other sites

3 hours ago, karri said:

I just tested if record/playback is enough to load a cart. There may be some handshaking required as it did not react.

I just figured this out too. It uses the CAR_TEST signal to tell the mainboard a cart is inserted (high for cart) if this pin is not high it chokes on the streamed ROM. So this pin needs to be disconnected as well. It can probably be controlled by the RTS pin of the USB serial cable.

Edited by Blinky
corrected DTR > RTS
Link to comment
Share on other sites

18 minutes ago, Blinky said:

It uses the CAR_TEST signal to tell the mainboard a cart is inserted (high for cart) if this pin is not high it chokes on the streamed ROM.

Even with a cart inserted the streamed ROM is not accepted. Could it be that the loading of the cart requires some RX/TX communication?

Link to comment
Share on other sites

39 minutes ago, karri said:

Even with a cart inserted the streamed ROM is not accepted

there's a crc byte in the end of rom dump:

 

0x55, 0xAA, crc, romtype MSB, romtype LSB

 

When the crc byte hasn't the correct value, the rom dump is ignored. It's not a simple checksum. Not sure what the algorithm is.

 

BTW: I was able to stream a dumped rom back to the 2600+ with cart inserted (and dumper Tx disconnected)

 

Edited by Blinky
added BTW
  • Thanks 1
Link to comment
Share on other sites

13 minutes ago, Blinky said:

It's not a simple checksum. Not sure what the algorithm is.

What makes you think so?

 

The dumper will most likely return random values anyway, because the hotspots return random values. Except if the hotspot or the hotspot area is skipped here.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...