There are dumps in MAME but these are the DVD images. Which need some adjustment before they can be read.
What would be beneficial is a dump of the contents of the CF card.
- Thread starter Darksoft
- Start date
What would be beneficial is a dump of the contents of the CF card.
Very ineresting if it's possible to port Linbergh multi to RingEdge, so could perhaps use JVS mor easily (and I don't want Taito hardxware to run my Sega games 
).
About this multi, it needs some improvments: lacks servers (ID), some games have different versions (I have 3 version of Virtua Tennis 3), don't know exactly which one is in the multi, and some other things.
).About this multi, it needs some improvments: lacks servers (ID), some games have different versions (I have 3 version of Virtua Tennis 3), don't know exactly which one is in the multi, and some other things.
theoddtech
Enthusiast
switching from NVIDIA GeForce 6 Series (in Lindburgh) to GeForce 8800GS (in Ringedge) seems unlikely as that uses a different driver, at least the Taito X3 supports Nvidia GeForce GTX560Ti which is on the same Nvidia driver
Oh, I wasn't aware the images are in mame. I can do a glance at it later. I'm not Linus level expert but I have been working with Linux for over a decade now so should be able to write some stuff out.
Sorry, my bad. CF images are not in MAME.
Yeah I just started looking into it, appears it's a dvd image from mame has to be installed to the CF. Probably not even worth looking at honestly, the install dvds for megatouch were pretty tough to navigate into what would be expected to be the actual running system due to portions of the userland being compressed inside the mounted images within the install dvd. It's easy enough to check though that I'll take a look later today.
Yup, the ISOs appear to have some form of encryption on the resulting init script so they're useless for what I mentioned. Even decrypting them it seems the data contained within the dvd is in no real shape to have an idea of how the existing system is setup.
WITH THAT SAID reading over the mame source file the system uses MontaVista linux which is an embedded version of Linux as well as a custom NVidia GPU. Looking at the versioning history of MontaVista it's likely written against 4.0 which is a 2.6 kernel. I hate to say it but due to the age of the platform and how the distribution is made you might have an extremely hard time getting the games to work outside of MontaVista. Even then 4.0 was announced April of 2005 so it's more likely they use 3.0 which is based on the 2.4 kernel. I can tell you getting anything to work from that era is a work in extreme frustration and tears.
WITH THAT SAID reading over the mame source file the system uses MontaVista linux which is an embedded version of Linux as well as a custom NVidia GPU. Looking at the versioning history of MontaVista it's likely written against 4.0 which is a 2.6 kernel. I hate to say it but due to the age of the platform and how the distribution is made you might have an extremely hard time getting the games to work outside of MontaVista. Even then 4.0 was announced April of 2005 so it's more likely they use 3.0 which is based on the 2.4 kernel. I can tell you getting anything to work from that era is a work in extreme frustration and tears.
@sammargh can you be more precise on what are the implications of those frustation and tears. I mean from a more technical point of view.
I know for sure that most games run on kernel 2.4 and 3-4 games like OR2 run on Kernel 2.6.
AFAIK, the problem is not really the kernel, but the libs used by the game, which depend on the kernel. so you need an old kernel + old libs. Theoretically it would work on newer linux too, if all libs support it (which is highly unlikely).
What needs to be done here is basically code to emulate only those portions of the software which would touch lindbergh specific hardware .
Each game uses a different set of kernel version, software libraries, sega internal libs (which access the hw and have to be rewritten), nvidia driver (exposing different features). As emulating hw is not feasible, emulating sw has to be done for each version of said libs / sw
I know for sure that most games run on kernel 2.4 and 3-4 games like OR2 run on Kernel 2.6.
AFAIK, the problem is not really the kernel, but the libs used by the game, which depend on the kernel. so you need an old kernel + old libs. Theoretically it would work on newer linux too, if all libs support it (which is highly unlikely).
What needs to be done here is basically code to emulate only those portions of the software which would touch lindbergh specific hardware .
Each game uses a different set of kernel version, software libraries, sega internal libs (which access the hw and have to be rewritten), nvidia driver (exposing different features). As emulating hw is not feasible, emulating sw has to be done for each version of said libs / sw
Yeah, I was able to find a set of decrypted cf images so I'm poking at them. It seems these were built against MontaVista 3.4.3. They are using kernel 2.6.10 on them and there is a kernel module for the lindberg baseboard named basbd.ko.
Everything appears to have been built against GCC 3.4
Uses OpenAL for Sound via ALSA
Like most linux games the entire thing is a window manager replacement for X11 and is launched via X11R6 xinit (xorg hates this)
This appears to be some weird workaround done by older X11 scripts as it is a binary being fed and xorg does not like trying to run it.
While you cannot verify exactly which libraries they're built against it appears this is mostly standard stuff.. GLU,GL, glut, Xmu, Xi, Xext,X11, etc.
There are two libraries custom-loaded libcri_soundoutput_lindbergh_jr.so and librnalindbergh_jr.so which seem to interact with ALSA in some fasion via OpenAL.
I can't go much deeper into this because time constraints and real world... crap But I'll poke at more dumps later and see what else there is.
Everything appears to have been built against GCC 3.4
Uses OpenAL for Sound via ALSA
Like most linux games the entire thing is a window manager replacement for X11 and is launched via X11R6 xinit (xorg hates this)
This appears to be some weird workaround done by older X11 scripts as it is a binary being fed and xorg does not like trying to run it.
While you cannot verify exactly which libraries they're built against it appears this is mostly standard stuff.. GLU,GL, glut, Xmu, Xi, Xext,X11, etc.
There are two libraries custom-loaded libcri_soundoutput_lindbergh_jr.so and librnalindbergh_jr.so which seem to interact with ALSA in some fasion via OpenAL.
I can't go much deeper into this because time constraints and real world... crap But I'll poke at more dumps later and see what else there is.
If you need help to get into a running system (i.e. root it) , shellshock (dhcp exploit) gets us into most older linux-based devices these days. I'm not sure if the lindbergh has any protection against detecting sudden/strange system modifications (on the file system for example) so you could be better off staying in /tmp or having a way to recover from dvd once you kill the CF by accident with this hack. 
Here's a decent one in python to run on your attack machine, it needs tailoring for your specific lan/network needs/ip range/target. (I don't know if we have NC or /bin/bash is there etc.)
I guess if you have a decrypted cf you can tell us more about the target and specific dhclient version on the montavista distribution etc..
https://www.exploit-db.com/exploits/36933/
Also, tools for unlocking the cf. Bios password for the lindbergh is mssvhy and so on.
See here: New Lindbergh tools
Here's a decent one in python to run on your attack machine, it needs tailoring for your specific lan/network needs/ip range/target. (I don't know if we have NC or /bin/bash is there etc.)
I guess if you have a decrypted cf you can tell us more about the target and specific dhclient version on the montavista distribution etc..
https://www.exploit-db.com/exploits/36933/
Also, tools for unlocking the cf. Bios password for the lindbergh is mssvhy and so on.
See here: New Lindbergh tools
Last edited:
good news. Let us know what else you can find please.
Thanks for the mention on the mda image @stj , I was able to get the actual system to mount to explore.
So the system works by booting into mda which is just a full image of the hard drive, you can mount it using offset options and these decrypted games are mounted to /home. It seems just playing with a few of the games however that there are multiple builds of the OS and they aren't cross compatible due to library differences.
As an example I'm using Primeval Hunt as my base test game along with MDA. While I was able to chroot into an environment that mostly worked the game is expecting entirely different libraries from what is present in mda. Mda was built with gcc 3.3 libraries while Primeval was built with 3.4 and the shared libraries do not exist thus not allowing the game to boot very far at all. I'm guessing I should start with HotD4 due to it being the first game and I'm assuming this mda image is from an early Lindbergh system. Unfortunately I hit my mega download limit grabbing random games to test and that will be a while haha
It should be noted I don't think the custom nvidia driver matters, it's a standard nvidia driver just built specifically for the mvl40 and kernel version within the system.
Continuing with the trend of specific builds Primeval Hunt manages its own X11 initialization while mda calls /usr/bin/segaboot from startup via /etc/X11/bootrc or testrc. Test mode is started via /usr/bin/segaboot -t.
To be honest there's not much point in going very far with this approach, these games look like a complete mess. It also doesn't help that a lot of the decrypted dumps I was using as a test don't appear to be properly dumped and are malformed images.
Edit: that said so long as you are able to work around the baseboard kernel module in game I believe these games should work with the proper shared libraries compiled within a system. There's a few sega-specific shared libraries as well in /usr but they should also be able to be moved if you are able to meet the stdc shared library requirements. The baseboard kernel module based on a glance at strings is just a JVS interface so you should theoretically be able to write your own driver like what is done with idmacdrv32 so long as you match the functions.
So the system works by booting into mda which is just a full image of the hard drive, you can mount it using offset options and these decrypted games are mounted to /home. It seems just playing with a few of the games however that there are multiple builds of the OS and they aren't cross compatible due to library differences.
As an example I'm using Primeval Hunt as my base test game along with MDA. While I was able to chroot into an environment that mostly worked the game is expecting entirely different libraries from what is present in mda. Mda was built with gcc 3.3 libraries while Primeval was built with 3.4 and the shared libraries do not exist thus not allowing the game to boot very far at all. I'm guessing I should start with HotD4 due to it being the first game and I'm assuming this mda image is from an early Lindbergh system. Unfortunately I hit my mega download limit grabbing random games to test and that will be a while haha
It should be noted I don't think the custom nvidia driver matters, it's a standard nvidia driver just built specifically for the mvl40 and kernel version within the system.
Continuing with the trend of specific builds Primeval Hunt manages its own X11 initialization while mda calls /usr/bin/segaboot from startup via /etc/X11/bootrc or testrc. Test mode is started via /usr/bin/segaboot -t.
To be honest there's not much point in going very far with this approach, these games look like a complete mess. It also doesn't help that a lot of the decrypted dumps I was using as a test don't appear to be properly dumped and are malformed images.
Edit: that said so long as you are able to work around the baseboard kernel module in game I believe these games should work with the proper shared libraries compiled within a system. There's a few sega-specific shared libraries as well in /usr but they should also be able to be moved if you are able to meet the stdc shared library requirements. The baseboard kernel module based on a glance at strings is just a JVS interface so you should theoretically be able to write your own driver like what is done with idmacdrv32 so long as you match the functions.
Last edited:
if the MAME set has proper dumps you should be able to get those from archive.org
I'm not sure what decrypted dumps you're using but @Darksoft what are the chances we could hook sammargh up with the decrypted dumps from the darkdawg multi?
There's not much point really, I've looked at the binaries and it's a pretty standard setup. There's just a handful of specific libraries which shouldn't be difficult to move as they were compiled to be shared but your major limitation will be the baseboard kernel module...
The only major hangup really is if those sega-specific libraries differ between each revision of a game.
The only major hangup really is if those sega-specific libraries differ between each revision of a game.
So how does a standard Lindbergh boot up ?
We know there is a PIC chip a BIOS, a CF card and an HDD.
Games came on DVDs.
On powerup the BIOS unlocks the CF-Card.
When the system loads a new game from the DVD-ROM is it written to the CF card and/or hard/disk ?
Anyone have the details ?
We know there is a PIC chip a BIOS, a CF card and an HDD.
Games came on DVDs.
On powerup the BIOS unlocks the CF-Card.
When the system loads a new game from the DVD-ROM is it written to the CF card and/or hard/disk ?
Anyone have the details ?
skate323k137
Enlightened
the DVD has several files that are simply copied into the hdd. That's it. Then the DVD is not needed anymore.
Process is like this.
* Bios unlocks the c.f. and boots from there.
* c.f. loads kernels and drivers and unlocks the hdd
* c.f. boots game from hdd.
* game does several checks to the pic as a security measure.
Process is like this.
* Bios unlocks the c.f. and boots from there.
* c.f. loads kernels and drivers and unlocks the hdd
* c.f. boots game from hdd.
* game does several checks to the pic as a security measure.
