I really need some reverse engineering help, and I didn't know where to turn except here as I really admire many people's skills here. However it is unrelated to the NES, and for this I appologize (Memblers, I do not plan to make this a habit and hope this one thread is an okay exception to have here).
The story:
I love to reverse engineer stuff, and most of my hobby time goes to such activities. For some reason one simple device has really gotten stuck in the back of my mind. I'm almost ashamed to say I've spent hundreds of dollars at this point trying to figure out this device, which even when solved would have no real practical value. It is, and I assume some here will understand completely, the challenge itself that makes it fun. But like any puzzle that gets stuck in the back of your mind, this one is starting to gnaw at me and I really just want to "flip to the back of the book" and see the answer now.
Due to the nature of this (the information can easily be abused), I would prefer to not release all details here. So I will just word it this way, I saw an encrypted data storage device that I was pretty sure the company was lying about their security. I found some flaws almost immediately. Talking to the company raised all kinds of trouble, and asking even simple questions like "does your device have any security besides obscurity" led to them threatenning me. Yeah, these guys know they are hiding something.
It is this project which was always drifting in the back of my mind that actually led to me learning new techniques (for example reading ROM and circuitry directly from IC chips, learning about the code and operations being ran by carefully watching the current a chip takes, etc.) which has undoubtedly helped in other "real" projects. (Yeah, this has been going on for years.)
In fact I've had so much fun with some of these techniques that I got side tracked with them. A couple months ago I returned to this project to finish up some more routine reverse engineering work on it (which I should have done in the first place) and figured out how to _completely_ bypass the security. So in a sense I finally won. But not really... the fun was trying to crack it, and that just side stepped the real question.
Here is the question:
At one point, the device asks a 32bit challenge, and the other side must authenticate by responding with a correct 32bit response. Due to figuring out how to bypass all this, I can get as many challenge->response pairs as I want (well, it takes on the order of a second to do... so I can't just crank out all 4 billion, and also the EEPROM starts to fail after getting about 100k responses). But I am getting these by tricking the device into giving me the answer, and I do not know the actual algorithm. The question is then: What is the algorithm? And the more fun rewording is How can I figure out this algorithm?
It is the classic black box challenge!
Something goes in, something else comes out ... can you craft the attempts well enough to learn what is going on in the box?
There are only a couple little bits of extra information. In addition to the 32bit challenge there are, let's just call them "channel IDs". With a different channel ID, the response to the challenge changes. So this algorithm must also be easily modified with some extra information. I cannot freely change these "channel IDs", which has a 16bit "main ID", and 4bit "sub ID". The very fact that the algorithm must be able to easily change is useful information.
And finally, the device runs at 1MHz, and doesn't take all that much time to process stuff (I can try to give some numbers if you really want) and therefore this algorithm isn't anything heavy duty. I do not know if the device CPU has a hardware multiplier or not. This company seems to have done everything very "homebrew", as if they just asked an undergrad engineer to make up something. So while they may have grabbed some known random number generators, or borrowed some code, they definitely didn't use the latest and greatest of any security protocal or followed any standards.
The public challenge / reward:
If anyone finds a classic black box challenge interesting, I'd love to work with people on this.
Give me inputs (challenges) and I'll give you the outputs (the correct response from the algorithm). Any ideas for strategy here would be helpful.
Since I really just want to find the answer at this point, I'll gladly give a couple hundred dollar reward or buy someone a Wii or something as a prize for solving the black box if you wish (would a NES flash cart be a more appropriate prize for this board? ). Feel free to pass this on to other places where hardware/software knowledgeable people gather.
The story:
I love to reverse engineer stuff, and most of my hobby time goes to such activities. For some reason one simple device has really gotten stuck in the back of my mind. I'm almost ashamed to say I've spent hundreds of dollars at this point trying to figure out this device, which even when solved would have no real practical value. It is, and I assume some here will understand completely, the challenge itself that makes it fun. But like any puzzle that gets stuck in the back of your mind, this one is starting to gnaw at me and I really just want to "flip to the back of the book" and see the answer now.
Due to the nature of this (the information can easily be abused), I would prefer to not release all details here. So I will just word it this way, I saw an encrypted data storage device that I was pretty sure the company was lying about their security. I found some flaws almost immediately. Talking to the company raised all kinds of trouble, and asking even simple questions like "does your device have any security besides obscurity" led to them threatenning me. Yeah, these guys know they are hiding something.
It is this project which was always drifting in the back of my mind that actually led to me learning new techniques (for example reading ROM and circuitry directly from IC chips, learning about the code and operations being ran by carefully watching the current a chip takes, etc.) which has undoubtedly helped in other "real" projects. (Yeah, this has been going on for years.)
In fact I've had so much fun with some of these techniques that I got side tracked with them. A couple months ago I returned to this project to finish up some more routine reverse engineering work on it (which I should have done in the first place) and figured out how to _completely_ bypass the security. So in a sense I finally won. But not really... the fun was trying to crack it, and that just side stepped the real question.
Here is the question:
At one point, the device asks a 32bit challenge, and the other side must authenticate by responding with a correct 32bit response. Due to figuring out how to bypass all this, I can get as many challenge->response pairs as I want (well, it takes on the order of a second to do... so I can't just crank out all 4 billion, and also the EEPROM starts to fail after getting about 100k responses). But I am getting these by tricking the device into giving me the answer, and I do not know the actual algorithm. The question is then: What is the algorithm? And the more fun rewording is How can I figure out this algorithm?
It is the classic black box challenge!
Something goes in, something else comes out ... can you craft the attempts well enough to learn what is going on in the box?
There are only a couple little bits of extra information. In addition to the 32bit challenge there are, let's just call them "channel IDs". With a different channel ID, the response to the challenge changes. So this algorithm must also be easily modified with some extra information. I cannot freely change these "channel IDs", which has a 16bit "main ID", and 4bit "sub ID". The very fact that the algorithm must be able to easily change is useful information.
And finally, the device runs at 1MHz, and doesn't take all that much time to process stuff (I can try to give some numbers if you really want) and therefore this algorithm isn't anything heavy duty. I do not know if the device CPU has a hardware multiplier or not. This company seems to have done everything very "homebrew", as if they just asked an undergrad engineer to make up something. So while they may have grabbed some known random number generators, or borrowed some code, they definitely didn't use the latest and greatest of any security protocal or followed any standards.
The public challenge / reward:
If anyone finds a classic black box challenge interesting, I'd love to work with people on this.
Give me inputs (challenges) and I'll give you the outputs (the correct response from the algorithm). Any ideas for strategy here would be helpful.
Since I really just want to find the answer at this point, I'll gladly give a couple hundred dollar reward or buy someone a Wii or something as a prize for solving the black box if you wish (would a NES flash cart be a more appropriate prize for this board? ). Feel free to pass this on to other places where hardware/software knowledgeable people gather.