This post is not about telling you whether or not to buy one, but to simply debunk some claims that they have made. This is an open response to their thread on iPod touch Fans, so that others will know what is going on as well, and if you don’t believe me about something that they said, look in the post in the above link and you will see that everything I am replying to is something that they have said.
They Claim:
Our software patches the signature checks in the ibec, ibss’s and the iboot221. This is one line of assembly which nop’s out the negate of the return value at the end of the signature check routine. This is an extremely trivial patch and enables unsigned code execution in subsequent stages.
RAM:0FF1A132 01 20 MOVS R0, #1
RAM:0FF1A134 40 42 NEGS R0, R0
changes to
RAM:0FF1A132 01 20 MOVS R0, #1
RAM:0FF1A134 00 00 NOP
The Truth:
I won’t deny that the RSA / signature check patch for an iBoot / iBEC / iBSS / etc. is pretty trivial, but even here they prove their ignorance, and the fact that they just used the standard Pwnage patch without looking too much into it. They said they have a NOP at 0×0FF1A134, but that would mean that the RSA check would be returning 1, and since anything but returning 0 means it failed, then this would fail. Interestingly, they paste this later in the post:
13 SigCheck:
14 0018 E59F2014 LDR R2, =0×0FF1A000
15 001c E3A03A02 LDR R3, =0×00002000
16 0020 E5823134 STR R3, [R2, #0x134]
Note the =0×000020000. This shows that first off, they don’t know how to use STRH, and secondly, it would equate to 00 20, or MOVS R0, #0, which is the Pwnage patch and correct patch for the RSA check routine. Again, I am not saying that the Pwnage patch is that complicated, but simply pointing out their ignorance, as they blindly copied the Pwnage RSA check patch and simply failed quite hard at trying to explain it.
They Claim:
The initial code for the routines to talk to the iPod/iPhone in dfu mode came from the openmoko community. The code from there was developed into a utility called dfu-util. This was later revised into utilities like ibooter and iRecovery.
We are FULLY aware of the original source of this code, and who developed it. We are also aware how it was used to make the subsequent programs.
To use that code, modify it and put it into a program which you then copyright, and then have the audacity to say that we copied your code, when we simply used the same source to develop it is quite amazing. Well done, you really have set a new low.
The Truth:
This claim is probably based off the fact that in July planetbeing had a hacked up dfu-util that he initially used to communicate with DFU. With iRecovery though, it hinges upon the 2.x recovery protocol, just like the DFU mode does, and it was written from scratch. There was no “dfu-util” used in the making of iRecovery. We are not “setting a new low”, because tom3q and westbaer wrote it from scratch, on their own. Aside from that, iBooter never even implemented the old DFU protocol, it only did the old Recovery Mode. The only things off the top of my head that use the DFU protocol at all are iTunes (obviously), iRan, and planetbeing’s modified version of dfu-util made to work with the iPhone / iPod DFU protocol. That may also be where NitroKey’s very misguided view on this is from, in which they think that iBooter and iRecovery are somehow just rip-offs of dfu-util.
They Claim:
- 24/02/09 09:59 GMT Musclenerd uploads an SHA1 hash of his solution to paste bin over 7 hours after his attempts to order our product.
This raises the question, what was he doing in the interim?
The Truth:
He did that so NitroKey can’t say he copied them for the dongle tutorial, as the zip was already sha1′d and pastebined, so there was no way he could have made a tutorial based off of the NitroKey dongle. The reason that he held back a few days on posting the tutorial was because nobody had yet actually received a dongle, and did not put it below NitroKey to just copy the tutorial that he released.
They Claim:
arm7 or more specifically arm7_go and arm7_stop are left over iboot commands left in iboot211. They have been known about ever since the release of firmware 2.1.1. Executing code with arm7 is EXTREMELY trivial. You simply write the raw assembly into 0×9000000 using mw and execute it by typing arm7_go. We were able to execute code with arm7 almost immediately.
The Truth:
I have no proof that they weren’t the first to discover arm7_go and were able to execute code “almost immediately”, but one cannot help but wonder why it took them so long to release it, let alone the fact that redsn0w was already released which utilized the exploit, and 0wnboot along with iPhone Wiki articles I wrote were up weeks earlier than that too. So they would have had plenty of time to spend five minutes reading the article on the iPhone Wiki, and implement their “solution”.
They Claim:
There is a specific reason for every element of the NitroKey design, the patches we use and the way in which they are used. These depart completely from the public information at the time.
The Truth:
Whether spoken about often or not, everything they used is based on public information. The bdev command was not widely publicized, but you could just type “bdev” and have the usage list come up for it, so there is no real skillz.app needed to use the command at all.
They Claim:
The byte by byte assign and write is simply an old script reused from another project where it was essential to do it that way. More discerning coders among your may be able to hazard a guess as to what that may be
The Truth:
An array would do fine, but they do this for both the NitroKey setup application AND in the NitroKey firmware updater, they opt to “reconstruct”, byte by byte, the encrypted firmware in memory, before they send it to the NitroKey via serial. This would have taken extra effort that they would not have put forth if their intentions were good.
We hope this can clear up some of the mist that has been surrounding the whole NitroKey issue.
what's the dif between customize and winterboard?
ok did anybody figure out the customize problem where it tells you that you do not have the necessary files to run offline