I don't fully understand this but it looks like we (someone with knowledge) can mod code

Cool

It's all Greek to me!

I only skimmed over the linked text, so this is absolutely not a full analysis in any way...

But what misentropy appears to be showing is that he was able to get the "spk" package installer to operate in an emulated environment.

He appears to have utilized the fact that Stern made a poor choice in their coding. The error message text was located "near" the code that checked for the appropriate signature from the hardware platform. This made it "easy" to locate the signature code, as it wasn't obfuscated in any manner, and change the code to simply act as if the signature was correct.

At least that's my reading from looking at it for 2 whole minutes. And BTW, when I say "easy" I don't mean it is easy, but it's not like trying to break into a real content protection system or a real DRM.

Start requesting sources of the various GPL licensed libraries, utilities, and applications from Stern!

Heh. No question going with Linux is going to mean there are some interesting opportunities.

So far Stern doesn't seem concerned over Pinball Browser, guess we'll have to see if they play cat and mouse with this stuff or just let it ride since it will be very niche enthusiasts playing with it.

Stern should embrace the homebrew community. Pinball browser was the only reason I picked up TWD & Mustang. Besides, it would probably be too much effort to squash these types of programs. And to what end? It would piss everyone off and make Stern look like the bad guy.

Stern pays their license fees and the game goes out the door. After that, it shouldn't matter.

Not that simple. Part of the license contract means they can't just let people do whatever they like. Lame, but true.

Same for video games

But people hack & patch all kinds of nonsense

Stern can't get in trouble if a guy in Prague puts a BeeGees song on TWD

People write on dollar bills & staple them on walls at bars which isn't legal either

Stained behind
Stained behind

Oh wait, another misheard lyric lol

Not licensed titles though. Sure, there are all kinds of hacks for Grand Theft Auto, but they don't care, it's their original IP. You want to make a gun that shoots whales they're not gonna trip.

With a license you're obligated to protect it. Part of the contract. Let's just say there's a reason why I had to shut down my Helen translites.

As long as there is no profit involved, there is little they can do. Start charging for something, and you will find yourself marked.

That's not true.

I was part of a group that was sued by a very large game studio for emulating their server software. We wrote our version of the server software from scratch too.

server software is a little different than modifying existing software or art work mods. You would have to prove that the things aulrich was doing effected their sales negatively. If anything, he boosted their sales. Legal battles cost money to fight though.

Personally, I think you should have offered to license Helen to a certain manufacturer.

Heh. I mean it's all about the ACDC logo. I cheated a little and broke it up, and you can't trademark a font, so I could fight it if I wanted to. But I don't even want to fight it, not worth it. Had a good run, it's all good, not mad at anyone. It's relevant to the conversation, so I brought it up, but I purposefully didn't throw said company under the bus when I closed the thread, no reason to stir up angst.

We didn't even entertain the notion of fighting them on it. It ended up OK though.

Yeah, it's just not worth it most of the time. These are little passion projects, even if you thought you had a chance to win, why spend the money and time and angst? I'd rather shrug and walk away most times. At least with Helen it was a good run, I feel like the people who really wanted it got it, and after I send out this last batch I'll probably have a few left over if anyone really needs it still. Just won't print anymore, and let the thread die. I can live with that.

wonder if they understand the licensing.

requesting all the gpl stuff wont mean squat, looks like init just run spk, so youd need to prove spk includes gpl'd libs... statically linked not strippped wonder if going forward they suddenly start stripping and upx'ing etc.

Hm...I'd be interested to hear which group that was. I'm playing SWG EMU right now..

ok Axel!

cripes... i thought we had some interesting news on this thread

Nicely done misentropy.

Right

You emulated software & got a C&D or whatever

Aurich you sold shit for Stern games via methods which can be traced with IP that was grey in legal nature. Of course you were contacted but Stern was not sued.

If a fan made alt translite makes it onto the Web there's no one to send a letter to. Stern will not get in trouble for something they didn't make or sell.

That's different than Stern getting sued because an unaffiliated nameless unknown dude or group or community uploads a file onto some Russian based share site without assistance or authorization of Stern.

That's like saying GTA Rockstar could get sued because someone in Iowa uploaded the Vice City soundtrack to LimeWire back in the day.

Its not Rockstars fault a song they licensed for a game was copied & uploaded

If someone printed a giant tit on a piece of paper & stuck it to a WWE machine would Stern get in trouble?

Nope.

Right, I'm not exactly hard to get ahold of. I post under my real name FFS.

I think it's honestly in Stern's best interest to let people tinker, it's just a way to build interest and get games sold. But it has to be in such a way that they can look the other way. Otherwise they're putting themselves at risk, and it's simply not worth it, since it's not actually a part of their business model.

Let's not dissolve this conversation away from the topic, eh? If you want to argue about what's legal and what's not, may I suggest you start another thread.

This is correct, but in future it may well be the case that Stern change their update procedure so things like this can't be done/are harder to do. Considering the first release of the code had no signature support whatsoever, they might just be working on the more important stuff first (ie getting the game working) then working on security later. Maybe they'll move the spk into the onboard filesystem so it's harder to modify, but then we might run into a situation where people are paying over the odds for a "non-upgraded" SPIKE system kind of like the PS3/Wii cat and mouse games.

I had a poke around of the previous release and it almost runs on a Raspberry Pi but obviously it's missing a few devices it needs to run properly.

Also the OP was looking at the PRO update, the LE has some more files which look to be related to the video screen:
http://pastebin.com/j3VE9mJc

(lols at BLANK_FRAME.spv)

I was digging around in the file myself using strings against spk to see what it's looking for, but didn't get any files extracted as I ran out of time.

first part of .spk file is a .tgz , with update scripts in it

spk looks for:

SPK0 = start of a "partition" chunk
SIDX = directory?
STRS = file names - each one separated by a null
FINF = File INFO (guessing size, offset, maybe perms/owners,)
FEND = End of file info field? end of file?

SDAT = start of data - padded by 4 nulls and a byte? - binary files only?
SEND = data file end?

If you look around with a hex editor, you can kinda see how format is.. It starts with STRS, the FINF.. etc.

Not much, hope to have more time to dig into it later.

All of this talk is beyond me.
I thought I was really doing something when I learned how to update a code from Stern

you were part of bnetd?? respect!

So what does this mean for the community? Does it mean we will soon have Pinball Browser like capabilities on the new platform?

If you have a Raspberry Pi (or an appropriate qemu setup) you can extract the files into a chroot, after you've modified the spk binary to ignore the signature check.

Make sure the /etc/fstab in your chroot has something like the following:

/host/games /games none bind

And make sure all those directories exist in your chroot. Bear in mind that the update process will overwrite /etc/fstab the first time it's run, so don't run it outside of a chroot.

Not much right now, just that Stern suck at protection and that they probably need to start complying with the GPL, but they aren't the only guys in pinball who aren't following the license rules properly.

Is Sterns Spike system region coded? Eg 50hz 60hz? Like SAM was?
I wouldn't mind a Kiss pin, but our price here in NZ works out to be 10.4k U.S for an LE

Means it's looking pretty easy to jailbreak your Stern.

I've just been poking around with the SPV files and I've noticed something strange, but I'll get to that in a minute.

The headers are 28bytes long and contain a version string (SPV1), x/y resolution (320x240) and the number of frames, it doesn't look like there's any compression used so it shouldn't be too hard to extract the frame data. The weird bit is this, there seems to be a set of 8 bytes attached to the end of each frame.

To take BLANK_FRAME.spv as an example, it's filesize is 153636 bytes. So that works out as;

28 bytes for the header
153600 bytes for the frame data (320x240x2)
8 seemingly random bytes at the end of each frame.

If you open up BLANK_FRAME.spv in a hexeditor it's quite easy to see the random 8 bytes after 153600 bytes of zeros:
http://pastebin.com/dq6GqnQd

I've checked the other video files and they are all the same, I'm scratching my head as to what these 8bytes might be for. I've dumped them all out and I couldn't see any pattern, so I don't think it's time sync data. Any ideas?

Haven't looked but I'll toss out... hash or checksum of sort to validate contents?

I have no idea what's in the 28 header bytes so apologies if this is already in the header.

Palette information for future color?

Could be some kind of internal signing, like what internal tool version created the frame?

It could also be a bunch of bits that signal different settings/etc.... just packed into two 32 bit integers?

You part of the wowserver group? If so that was a cool project.

Geek

I thought that, but then why would you hash every single frame?

I don't think 8 bytes is large enough to hold a palette, plus again why would you do it for every single frame?

I thought maybe it's timing information, but I couldn't see any pattern.

Agreed!

I would not own either TWD or Mustang if it wasn't for pinball browser. True story.

There's definitely something strange about those extra bits on the end of the frame. I wrote a program to dump the 'extra' 8 bytes of each frame and found some interesting things.

First thing I've noticed is that those extracted bits are nearly identical between the following files:
US_CHAMPIONS.spv and WORLD_HEAVYWEIGHT.spv, only 8 extracted bytes differ
The first 57 bytes of the 'extra' data of AJ.spv is identical to above two files.

Also, in some files, the first byte of those 8 bytes is exactly 8 different, so looking at the extra bytes on the first frames of two files:
07 6B 2D 52 EF A1 19 5A (BELLA_TWINS.spv)
0F 29 25 10 E7 E3 11 18 (MAIN_EVENT.spv)
This carries on the same for the rest of the frames, so:
(frame 2 of BELLA_TWINS and MAIN_EVENT)
10 59 0E A6 86 92 AB 38
18 1B 06 E4 8E D0 A3 7A

(frame 3)
B3 FC 5C C7 76 6C 94 02
BB BE 54 85 7E 2E 9C 40

etc etc.

Another bizarre thing is that the 4th byte of the extra data is always identical to the 4th byte of the frame data, but I've only checked the first frames so far:
38 E2 03 10 46 34 4E 42 (1st 8 bytes of MAINEVENT 1st frame)
0F 29 25 10 E7 E3 11 18 ('extra' 8bytes of main event 1st frame)

This is true for all the 1st frames I've checked so far.

EDIT: So I started checking other frames, it appears that the above rule holds true for frames:
1, 39, 188, 257, 295, 444, 513, 551, 700, 769, 807, 956, 1025, 1063 and 1212
What's so special about the numbers 38, 69 and 149?

Jared with another coded message?

Total size of frames? (i.e. Frames 1-38, then so on..) Or playback speed?

WTF is someone hacking a Gibson in here?

Actually I made a mistake in my code, I forgot to account for the extra 8 bytes in the size of the frames, whoopsy daisy. I noticed after checking the output by hand that a few things didn't add up properly.

So, the 4th byte of the frame matches the 4th byte of the extra data on frames:
1, 133, 280, 494, 613, 696, 722, 794, 950.

Like I said before, it's weird this is true for most of the video files (I've found one exception so far), so it's not a random coincidence. What's even trippier is that the values at those offsets is the same for different video files.

I'm posting here in the hope that someone might notice some chksum/encryption style pattern in the numbers.

To be honest I have no f*ckin' idea why I'm fooling around with this. At first I thought it would be relatively simple to convert the data into an image format that can be read after looking at the BLANK_FRAME.spv file, but I've ended up staring at seemingly random hexdumps for too long and it's making my head go funny.

It's pretty obvious to me now that the files don't hold raw image data, as I'd expect to see repeating patterns of values in areas where the video is solid colour (ie black background). But seeing as the filesizes add up exactly based on the amount of frames they have, it doesn't point to compression being used. I'm thinking now that the 8 bytes of extra data per frame are used with a colour lookup table that's present somewhere else, purely to thwart attempts like mine to try and extract the images.

If you are following along at home, you can get the code I'm using from my github here:
https://github.com/SonnyJim/spvtool

There's a copy of the output it generates here:
http://pastebin.com/Jr8k3uC8

These frames are 320x240? Are they for the little LCD screen? If so they might be RGB 565 data.

You'd think that, wouldn't you? But this is what you get when you try decoding the data as an RGB stream:
http://i.imgur.com/rzYaEGG.png

Why is it greyscale? I'd think if it was random or even any kind of image data you'd be getting colored snow at least.

Even if it was colored, you would expect to see adjacent regions with the same value. On the other hand, maybe the videos are of confetti? Jim's just guessing, which is pretty much what you do.

That's not some kind of seed to decrypt the frame is it?

Have you gotten any kind of usable frame data yet where you can actually make out an object?