Ir a contenido


Foto
- - - - -

Frozen-layer C2 Brute Force


  • Tema Cerrado Este tema está cerrado
61 replies to this topic

#43 takasagi_k

takasagi_k

    Leecher

  • Hentais
  • 18 Mensajes:

Escrito 23 February 2004 - 02:56 PM

Hola.

A lot of people here will try again even if this first attack fails.

I have respect for people in Frozen-Layer's foro. :abrazo:
***
We have a good news.
A buen guy translated the diary!
Bueno,jajaja.

http://www.geocities...ry/db2003_a.htm
The human translations are on 3 Oct,19 Oct,26 Oct,27 Oct.

Wed.,Octber 29 and after translations are translation by software(not altavista babelfish).

http://www.geocities...ry/db2003_b.htm
All translations are translation by software(not babelfish).

http://www.geocities...ry/db2004_2.htm
The human translations are on 2 Feb,3 Feb.(already I translated.)

http://www.geocities.jp/rank_graph/
I call him "carp".He is making graphs about Frozen-Layer vs Team2ch.

I do not know that translation by software is helpful for you.
Better than babelfish?

****
And another translator wrote,
http://pc3.2ch.net/t...6555307/131-132
This is the diary on Feb. 13 Fri(already I translated.)

####
I enjoy Frozen-Layer's foro with babelfish.
Nobrain babelfish neglects his work.

What does xD(or xDDDDD) mean?
####

Arigato.
Muchas gracias.

Este tema ha sido editado por takasagi_k: 23 February 2004 - 03:00 PM


#44 meruelo

meruelo

    Advanced Member

  • Hentais
  • PipPip
  • 446 Mensajes:

Escrito 23 February 2004 - 03:11 PM

"xD" or "xDDDD" are ... big smiles, like if you were laughing at the momento you wrote that.
Imagen enviada

#45 Guest_Guest_*

Guest_Guest_*
  • Guests

Escrito 24 February 2004 - 02:44 AM

re: 2004.Feb.23 (AVHDD crack [50])

Corrections are welcome. Comments in [] are mine and not C2BF author's. Format is machine translation first then my translation. Computer translations used: excite.co.jp (sentence) & goo.co.jp (words). Rest is human translation.


[Computer translation:]
It is key [n] when all the bits of code stand. Finally = c2_dec (code and key [n-1]) falls to a loop, and since like, it becomes the minimum value within a loop. Although were planned to have discriminated the loop by key and to say that a random number sequence will be distinguished on a unification point with a loop and many things were tried on "do-nichi".

[Computer translation + human:]
While all bits of the code are running ["standing"(?)], key[n] = c2_dec(code, key[n-1]) will ultimately fall into a loop. Within the loop, the key is the minimum value, the loop will be used as identification [basis of comparison(?)]; at the merge point of the loop, random numbers will be used to differentiate. I plan on doing various tests this weekend.

[My interpretation of above, as I am having difficulty understanding the programming problem(?): Sounds like there is a looping problem(?) with key[n] = c2_dec(code, key[n-1]); C2BF author is going to try debugging the problem(?) this weekend by using random numbers to differentiate from good key values from bad]


[Computer translation:]
Acquisition of a unification point has not moved correctly yet. Truly, by millionaire-programming, although it can be made to operate correctly, it was going to cut down the amount of the memory used and has rushed into the nest of a bug. I will think that a bug can be crushed, if it probably investigates to a slight degree.

[Computer translation + human:]
[Data] acquisition at the merge point is not functioning properly. Although a luxuriously built program will function properly, while attempting to reduce the memory load, I encountered a major bug. With a little more investigatation, I should be able to resolve the bug.

[not sure if the "luxuriously built program" was refering to MOGI's program or comparing to a hypothetical one] [original comment was more figurative -- "broke into the bug's nest"; "to crush the bug"]

<><><>

[not really AVHDD related]

[Computer translation:]
"Fate/stay night" Reading through. It applies to 2/14 - 2/22. 50 time is consumed and complete five sorts of ending, and 40 Tiger stamps. Evaluation 75 points. It was tired of being uncanny. An eye still hurts.

[Computer translation + human:]
Finished playing [Type-Moon's] "Fate/stay night". Between Feb.14 and Feb.22, it took me about 50 hours of play time to finish 5 different endings and completed 40 Tiger Stamps. I rate this game a 75 [out of 100]. I'm tired. My eyes still hurt.

<><><>

[Computer translation:]
Although it is going to be over "mu-" 70%, unless a key is found yet, don't become quite uneasy. Although there is an escape way called the domain still investigated before error check introduction .... Even if next week will come, it is still found, and if it seems that there is nothing, the point is likely to become healthily bad uncanny days.

[Computer translation + human:]
[troubled "sound"] Status is about to past the 70% mark and the key has not yet been found. This is making me quite uneasy. Although I could say the [data] area prior to introduction of error checking mechanism can be used as an excuse.... Even after next week, if the key is not found by then, I have a feeling that it [tasks that awaits me(?)] will not be good for my health.

#46 takasagi_k

takasagi_k

    Leecher

  • Hentais
  • 18 Mensajes:

Escrito 24 February 2004 - 01:07 PM

Hola.

"xD" or "xDDDD" are ... big smiles

I see! :idea:
****
Dear guest,(Posted on 24 Feb 2004, 03:44 AM)
Thank you very much! :P
****
Today I introduce Marumo's work.

First,I give notice I have never seen him and exchanged e-mails.
****
He is a programmer in real world.
working about "H.264"(a kind of MPEG cordec in next generation).

At college student age,He already knew movie compression very well.
He has written on books about movie compression and picture technology.

He is a programmer on internet society,also.
He made his dedut as "free software programmer" at college student.
A lot of movie edittng software were released then.

His idea is valued highly at abroad that he took "Lanczos resize"
to make software of movie edittng.

I guess the most popular software in his works is "MPEG-2 VIDEO VFAPI Plug-In".
Simply,It is a MPEG decorder.

MPEG standard is too much flexible.
Programming decoreder software is difficult compare of making encoder.

Everything softwares can read in MPEG files by using Marumo's "MPEG-2 VIDEO VFAPI Plug-In" and "VFAPIConv.".

That has high ability same as DVD2AVI.
Any market softwares are worse than Marumo's "MPEG-2 VIDEO VFAPI Plug-In" and DVD2AVI.
***

Arigato.
Muchas gracias!

Este tema ha sido editado por takasagi_k: 24 February 2004 - 04:46 PM


#47 Guest_Guest_*

Guest_Guest_*
  • Guests

Escrito 26 February 2004 - 08:46 AM

re: takasagi_k's homepage (Feb.24 20:55 entry)

takasagi_k: "39uuuu"
Me: De nada.

re: 2004.Feb.24 (Tue) AVHDD crack [51]

Corrections are welcome.

Comments in [] are mine and not C2BF author's nor the machine translation (parts that the machine failed to translate). Some comments are used to fill-in words that are implied, while others are my personal comments. First the machine translation of C2BF author's comments, then my translation. Computer translations used: excite.co.jp (sentence) / goo.ne.jp & WWWJDIC (words). Rest is human translation.

[Computer translation (excite.co.jp only):]
Table size reduction of Time/Memory Trade Off is under examination succeedingly. The juncture with a loop can be once acquired now correctly. When passed overnight yesterday, juncture acquisition with the minimum key in a loop and a loop was made of the start key of 691 ["ko"]. already -- it is necessary to move for 2 and three days and to increase a sample -- although kicked -- for the time being -- analysis in the present condition

The unique last loop It is 5 ["ko"] and is a juncture with a unique loop. 40 ["ko"]. Start key which arrives at the juncture chosen suitably for the time being It is .... although it investigated whether there would be any nothing that is contained in the same random number sequence by 72 ["ko"]. It turns out that this is not realistic. Total combination It is 2628 passages and checks. 3 time consumption is carried out and it is proved that he has no full duplication. Load is too high even though it assigns a client side. keys increase in number -- alike -- following -- O (n^2) -- out of the question at the time

that it can ask by the client independent set the upper ["akamaru"] (start key) and the upper ["aomaru"] (juncture) in a picture -- a portion (minimum value within a loop) -- under the illusion with whether it will be made to record only the connection relation and distance between nodes by the server side by divided and coming out and asking for the juncture (["haimaru"] portion) of the two start keys, if it seems that there is a start key which arrives at the same juncture

Although the problem is whether to be able to perform reduction of table size in it sure enough .... Mind that table size becomes small [ the direction which records only a start key, a juncture, and distance simply somehow ] how much will come out comparatively and the random number sequence which can investigate the inclusive relation of a random number sequence and can also call only a big thing record and which is primarily included completely although kicked will appear, if it is the form which records the connection relation of a node (Probably it should become equal to the rate of a key discovery success in Time/Memory Trade Off)

It is table size when it is the form which records a starting point and a juncture simply. (since the 2nd block of CBC or subsequent ones is targeted) At least 40G 2G entry is a rate of a success, although it is the translation which can be saved. 46% since a block key is not known if it does not succeed continuously, even if it squares 20% is securable. it aims at 46% -- if securable, it is not necessary to consider anything

<><><>

It is if it is PowerPC. AltiVec ["kedo"] which will become quick extremely if it uses and rewrites .... since there is no real wealthy person ["tte, shi"] it cannot test -- primarily -- assembler ["kaita"] other than x86 -- things -- or .


[Computer translation (goo.ne.jp & WWWJDIC) + human:]
Reducing the table size for Time/Memory Trade Off is still under investigation. For now, [the program is] acquiring merge points within the loop correctly. Yesterday, after test driving [the program] overnight, [the program] created merge points, using 691 start keys within the loop and minimum keys. Although it is necessary to run [the program for] 2-3 more days to increase the sample [base], but for now, [I am] analyzing [the data] under present condition.

Unique terminating loop = 5. Unique loop with merging points = 40. For the time being, a suitable start keys (72) were selected to reach the merge point; did some checking too see if the same thing can be found in the random number sequence.... It turns out that this [test(?)] is not realistic. To check the total combination of 2628 took 3 hours and was confirmed that there were no complete duplication. Even if the load was distributed to the client-side, the load is still too high. It is out of the question, as soon as the key [count] increases to the point of O(n^2).

In order to achieve client independence, in the diagram above [*1], this would be the part (minimum value within the loop) within red dot (start key) and blue dot (merge point). If there are start keys thatmeets at the same merge points, using those 2 start keys at the merge point (gray dot), [I am] brainstorming to record only the [data] relating to the junction and distance/range on the server-side node.

[*1: diagram looks similar to Tokyo's train line -- Yama no Te Line intersecting with other lines / subways / monorail] [original is one sentence...]

The problem is whether or not if this will reduce the table size... Somehow, [I] have a feeling that if [the program] simply records only the start key, merge points, and distance/range, the table size will be smaller. If [I am] going to [program the software] to record the [data] relating to the junction of the node, it [can be programmed to] examine just the random number sequence [data] and record only the large section of that [data], but [I] wonder at what percentage the random number sequence will appear in the first place. (this probably should balance the Time/Memory Trade Off and the success rate for discovering the key)

If [I] simply record the start points and merge points, table size of 40G and entry [data size(?)] 2G can be preserved; if that [results in] the assurance of a 46% success rate, then I don't have to think about it. (since [I am] targeting [data] after 2nd block within CBC, but because block key won't be known unless [what must be(?)] successful consecutively, [what value(?)] to the Nth power [of what value(?)] of 20% to reach the 46% [success rate] target)

<><><>

If [the C2BF code] was re-writen for PowerPC with AltiVec, the program will run much faster.... Because [I] do not own it, [I] cannot test it, furthermore, [I] have never written [code=auto:0] in assembly language other than x86.

#48 Guest_The Carp_*

Guest_The Carp_*
  • Guests

Escrito 28 February 2004 - 07:10 AM

Hello,I come from Team2ch
Mr.takasagi always thank you very much.
maybe this diary importance for "c2-users".


Sat/February 28 - AVHDD crack [52]

A little character display of the present situation was moved downward.
That is, it is such a thing.
I think that such a domain is reinvestigated when the key is not found, even if it investigates of 100%.
On a concrete target "0x11dseven from 0x000000" f2 Domain (about 7%) It will reinvestigate.
I will lose completely, when this is not found.
The hit which considers the part of a failure report is very sad, thinking that a key should just be found.

How is my English? Can you know?

#49 takasagi_k

takasagi_k

    Leecher

  • Hentais
  • 18 Mensajes:

Escrito 28 February 2004 - 04:20 PM

Hola.

Mr.takasagi always thank you very much.

Not at all.

How is my English? Can you know?

I thought nameless guy is you.That is not correct?

Thanks for your translation.
I suposse your English is good.hum...good......same as me.

By the way,
The part 0X000000 to 0x11d7f2 were analysysed by the clients
those have no "check routine".

"check routine"
Check up myself against cracked "c2bf.exe".

Arigato.
Muchas gracias.

Este tema ha sido editado por takasagi_k: 01 March 2004 - 05:46 PM


#50 Guest_Guest_*

Guest_Guest_*
  • Guests

Escrito 29 February 2004 - 01:03 PM

Thank you "The Carp". Since I've already prepared my translatation, here's another (independently) translated version.

re: 2004.Feb.28 (Sat) AVHDD crack [52]

Corrections are welcome.

Comments in [] are mine and not C2BF author's. Some comments are used to fill-in words that are implied, while others are my personal comments. First the machine translation of C2BF author's comments, then my translation. Computer translations used: excite.co.jp (sentence) / goo.ne.jp & WWWJDIC (words). Rest is human translation.

[Computer translation (excite.co.jp only):]
Some character display columns of the present situation were shifted downward. That is, it is such a thing. I hear that such a domain is reinvestigated when the key is not found, even if it investigates 100%.

On a concrete target Domain of 0x000000 ~ 0x11d7f2 (abbreviation 7%) It will reinvestigate. When not finding this, either, a public concession of defeat will be carried out completely.

Is [ feel consciousness of useless human being the hit which considers the purport of a letter of a public concession of defeat, and it is sufficient for and does it, praying that a key is found and ] it sad?


[Computer translation (goo.ne.jp & WWWJDIC) + human:]
[I] have lowered the column of the current status graphics. That's it. [phrase means more like "you determine what I mean" -- if C2BF author had implied something, then I don't know what that might be] If even after searching 100% [of the data] and no key is found, then it will require re-checking that region by that much [quantity(?) -- see next paragraph].

Basically, [data in] region 0x000000 ~ 0x11d7f2 (approximately 7% [of total data]) will need re-checking. In the event that even [re-checking the data and the key still] cannot be found, then [our C2BF efforts will] completely [result in] declaration of defeat.

[Continuing to] pray that the key will be found, it is sad that having to think about declaration of defeat [could lead to] one having [to realize] the feeling of one's self-consciousness [for being] a good-for-nothing person [isn't it?].

#51 Guest_Guest_*

Guest_Guest_*
  • Guests

Escrito 29 February 2004 - 01:03 PM

Thank you "The Carp". Since I've already prepared my translatation, here's another (independently) translated version.

re: 2004.Feb.28 (Sat) AVHDD crack [52]

Corrections are welcome.

Comments in [] are mine and not C2BF author's. Some comments are used to fill-in words that are implied, while others are my personal comments. First the machine translation of C2BF author's comments, then my translation. Computer translations used: excite.co.jp (sentence) / goo.ne.jp & WWWJDIC (words). Rest is human translation.

[Computer translation (excite.co.jp only):]
Some character display columns of the present situation were shifted downward. That is, it is such a thing. I hear that such a domain is reinvestigated when the key is not found, even if it investigates 100%.

On a concrete target Domain of 0x000000 ~ 0x11d7f2 (abbreviation 7%) It will reinvestigate. When not finding this, either, a public concession of defeat will be carried out completely.

Is [ feel consciousness of useless human being the hit which considers the purport of a letter of a public concession of defeat, and it is sufficient for and does it, praying that a key is found and ] it sad?


[Computer translation (goo.ne.jp & WWWJDIC) + human:]
[I] have lowered the column of the current status graphics. That's it. [phrase means more like "you determine what I mean" -- if C2BF author had implied something, then I don't know what that might be] If even after searching 100% [of the data] and no key is found, then it will require re-checking that region by that much [quantity(?) -- see next paragraph].

Basically, [data in] region 0x000000 ~ 0x11d7f2 (approximately 7% [of total data]) will need re-checking. In the event that even [re-checking the data and the key still] cannot be found, then [our C2BF efforts will] completely [result in] declaration of defeat.

[Continuing to] pray that the key will be found, it is sad that having to think about declaration of defeat [could lead to] one having [to realize] the feeling of one's self-consciousness [for being] a good-for-nothing person [isn't it?].

#52 Guest_Guest_*

Guest_Guest_*
  • Guests

Escrito 01 March 2004 - 10:35 AM

re: 2004.Mar.01 (Mon) AVHDD crack [53]

Corrections are welcome.

Comments in [] are mine and not C2BF author's nor the machine translation (parts that the machine failed to translate). Some comments are used to fill-in words that are implied, while others are my personal comments. First the machine translation of C2BF author's comments, then my translation. Computer translations used: worldlingo.com (sentence) / goo.ne.jp & WWWJDIC (words). Rest is human translation.

[Computer translation (worldlingo.com only):]
Exceeding 90%, still, the key is not found. Still most significant 4 bit the part of F being untouched, remains with says...... just preparedness will have decided to do.

<><><>

As an actual escape the table size analysis of TMTO. Because the result of the random number sequence generating function which is being moved from last week accumulated, the number v. of start keysS. That plotting the number of unique keys probably will be written, program creation.

Temporarily the node detecting vis-a-vis 10000 start keys, writing the tree, thinking, however it is to be, because it seems that time is already required a little in the ["so re"], the analysis result vis-a-vis 1000 start keys. When the unique key which increases endlessly optimistically up to 800 - 1000 (distance between the node) with those where in the same ratio the unique key keeps increasing to linear you suppose, the 2^31 the start key (table size approximately 40G) with how much key space can be possessed?

The result with 19.7%, does not reach at all in 46% where it has made target. Because the actual key spatial pulse duty factor collar ["tt"] it probably becomes the low digit, it may become the conclusion that at table size 40G it is unreasonable.

<><><>

Closes with super 3/7 of neighborhood. It becomes inconvenient -.


[Computer (goo.ne.jp & WWWJDIC) + human translations:]
[Checked data is] over 90%, but still no key found. Even though there's still high-end of 4 bit of part F remain untouched.... [But I'll] have to be prepared [that no keys will be found].

<><><>

To escape from reality, [I] analyzed TMTO table size. Because results from random number sequence generating function [program] that had been running since last week had accumulated [enough data], [I have] written a program that will plot 'start key count' vs. 'unique key count'.

[The program] that will detect the node and writing the tree [data] using 10,000 start keys will take some more time, so for the time being [I am] analyzing the results for 1,000 start keys. [I am] endlessly optimistic that assuming if the [start keys] increase in same proportion as unique keys (within node range) to the 800 - 1,000 [key range], how much key space 2^31 start keys (table size approximately 40G) will occupy.

[Because success rate] result was 19.7%, [I did not] reach the goal of 46% [success rate]. Because realistic key space share will probably be a much smaller size/share, [I] conclude table size of 40G will likely be impossible.

<><><>

[not really AVHDD related]

The supermarket nearby will close on 2004.Mar.07. [This] will be inconvenient [for me...].

#53 takasagi_k

takasagi_k

    Leecher

  • Hentais
  • 18 Mensajes:

Escrito 02 March 2004 - 04:46 PM

Hola.
14 hours later,We will finish cracking.
Still the key can NOT be found,we try to re-analysys part of blocks.
They are about 7 percent of whole blocks.
Re-analysys is wanted 3 days at current situation.
Arigato.
Muchas gracias.

#54 Guest_Guest_*

Guest_Guest_*
  • Guests

Escrito 03 March 2004 - 04:13 PM

re: 2004.Mar.03 (Wed) AVHDD crack [54]

Corrections are welcome.

Comments in [] are mine and not C2BF author's nor the machine translation (parts that the machine failed to translate). Some comments are used to fill-in words that are implied, while others are my personal comments. First the machine translation of C2BF author's comments, then my translation. Computer translations used: brother.co.jp (sentence) / dictionary used: goo.ne.jp & WWWJDIC (words). Rest is human translation.

[Online computer translation (TransLand/EJ.JE v4.0):]
With a key not discovered though 100% seeming to reach it with a rear 2, 3 hours. When it isn't found just like this, the territory before introducing an error check automatically will be made un-management handling, and re-allotment will start.

It seems to be completed by the end of this week if it seems that a present speed can be maintained after initial investigation territory resetting as well.

<><><>

The following which has it, possibility.

1. S-Box was changed.
2. The number of ["raundo"] was changed.
3. As a matter of fact, it used another code with a lie to say that a C2 code was being used.

Until the territory investigation before introducing an error check tentatively is finished, it can be said that perfect defeat isn't decided, and a feeling has already been a state of defeat management.


[Dictionary (goo.ne.jp & WWWJDIC) + human translation:]
Within 2-3 hours, [Data region will] reach 100% [completion], but the key has yet to be found. In the event that [the key] isn't found, [I am] going to treat the [block] region, [that was checked prior to] implementing the automatic error check [mechanism], as being unchecked and plan to start re-assigning it [for C2BF].

If [we] can maintain the current speed [of C2BF usage] even after resetting to the original block region, [we should] be able to finish by this weekend.

<><><>

Below are possible [scenerios]:

1. [I] changed the S-Box.
2. [I] changed the ["]round count["][(?)]
3. Actually, [I] lied about C2 code and was using [C2BF] for a different code.

For the time being, until the block region prior to implementing error check [C2BF check] is completed, [I] won't declare complete defeat, but already, [I] feel as though [I'm] already in post defeat mode.

#55 Guest_Guest_*

Guest_Guest_*
  • Guests

Escrito 05 March 2004 - 07:01 AM

re: 2004.Mar.05 (Fri) AVHDD crack [55]

Corrections are welcome. Comments in [] are mine and not C2BF author's.

Having to think that complete defeat will be decided by today.... Frankly, [I] want to runaway.

#56 takasagi_k

takasagi_k

    Leecher

  • Hentais
  • 18 Mensajes:

Escrito 05 March 2004 - 03:11 PM

Hola.
Muchas gracias for all Hispano people!
But we could not find the key......

I'm sorry about Team Rank's Memos.

****
With contributions from our Spanish friends, we have achieved a
miraculous work. However, some ill-minded people in 2ch BBS
have given your team trouble and inconvenience. We deeply
apologize for it as a team of 2ch.

Espanol,
Con contribuciones de nuestros amigos espanoles,
hemos conseguido un trabajo milagroso. Sin embargo,
algunas personas mal dispuestas
en 2ch BBS han dado su problema de equipo y molestia.
Profundamente pedimos perdon por ello como un equipo de 2ch.
****
Please quit your "c2bf.exe".
Analysys was finished.

Arigato.
Muchas gracias.

#57 lordks

lordks

    Advanced Member

  • Hentais
  • PipPip
  • 887 Mensajes:

Escrito 05 March 2004 - 03:57 PM

So what next?

#58 takasagi_k

takasagi_k

    Leecher

  • Hentais
  • 18 Mensajes:

Escrito 05 March 2004 - 04:41 PM

Hola.

So what next?


I don't know.
Marumo keeps quiet.....

I guess he was so shocked about that failure.
We must cheer him up! :beer:

Gracias.

#59 Maeghith

Maeghith

    Zidane

  • FL Vintage
  • 4997 Mensajes:

Escrito 05 March 2004 - 11:28 PM

I guess he was so shocked about that failure.
We must cheer him up! :beer:

Gracias.

Well, we are just one of the teams collaborating, the hard work has been done by Marumo:  有難う, and don't be sad, man, as far as I know nobody else has tried to break that code, and you had tried to do your best here, take a rest :zzz:, relax a while :pc:, or have some fun :heavy:, you really deserve it.

And 有難う to all the other teams, and to everyone who has participated.

#60 Breogan

Breogan

    Leecher

  • Hentais
  • 17 Mensajes:

Escrito 06 March 2004 - 09:38 PM

Well, it's sad we couldn't attain the goals of the project, but it was great to see so many people work together for this. Also, it was fun to see the rivalry between Team2CH and Frozen Layer (a bit of rivalry is always good as long as it's fun and keeps healthy :)).

Lots of thanks to Marumo for all the work he has done for the project (the server, the coding, etc)... you rock ;)

Thanks to Takasagi_k for the updates and spanish translations for the english-impaired :)
Imagen enviada

#61 takasagi_k

takasagi_k

    Leecher

  • Hentais
  • 18 Mensajes:

Escrito 07 March 2004 - 07:34 PM

Hola.
Lately,I can sleep well with silent PCs. :vaca:

Maeghith @ 6 Mar 2004, 12:28 AM

the hard work has been done by Marumo:  有難う, and don't be sad, man, as far as I know nobody else has tried to break that code, and you had tried to do your best here, take a rest , relax a while , or have some fun , you really deserve it.

I translated and quoted a part of your speakings.
http://pc3.2ch.net/t...u/1078547719/31

Saludos.

Breogan @ 6 Mar 2004, 10:38 PM

it was fun to see the rivalry between Team2CH and Frozen Layer

I enjoyed that greatly.
I feel Team2ch was different Frozen-Layer in starting to crack.
The speed was better than ours.

**

**
It is sad Marumo doesn't mention about oversea friends' cooperation.
I think he is thankful to you so much.

Because the first plan needs 304 years to crack encrypt by him personally.

(I have never seen him,but I know his personalyty which is delicate and shy.
Poor translation works brought to me that feelings.)

He declared the end of ceacking.....

See you again at next action!

By the way,
The "Guest" translates Marumo's Diary,(I do'nt know his E-mail address.)
Till when he continues to do?

Again,Muchas gracias.

Este tema ha sido editado por takasagi_k: 07 March 2004 - 07:43 PM


#62 Guest_Guest_*

Guest_Guest_*
  • Guests

Escrito 09 March 2004 - 07:39 AM

This will likely be my last post regarding this subject until "AVHDD part 2" or similar appears in the future.

"Me nah sun, oh two car aye sum ah"

re: 2004.Mar.06 (Sat) AVHDD crack [56] Verdict: Failure

Corrections are welcome.

Comments in [] are mine and not C2BF author's nor the machine translation (parts that the machine failed to translate). Some comments are used to fill-in words that are implied, while others are my personal comments. First the machine translation of C2BF author's comments, then my translation. Computer translation (sentence) used: t-mail.com / dictionaries (words) used: goo.ne.jp & WWWJDIC. Rest is human translation.

[Online computer translation (T-Sail: Full & Magic):]
Failure decision of AVHDD crack. It probably cannot go something. But as for possibility being highest when with C2 code S-Box has been modified CPPM or CPRM or AVHDD or classified by use... DVD the DVD recorder of Audio/CPRM DVD-RAM both correspondence will such a difficult thing probably as expected be executed to being?

Well, DVD Video being encoded with CSS, from the ["ru"], must correspond to which being full plural codes, because, already 1 type increasing, however perhaps it is not many problem. After, in case of AVHDD when is, because encoding and decoding are completed inside the tip/chip, there is also a possibility C2 cryptographic standard even with mounting which is different without of becoming problem, but it is certainly it is, but it is with will Matsushita which is shipping the DVD Audio corresponding prayer or the CPRM DVD-RAM recorder as the product specially do such a thing? (You use normally there and don't turn? If company internal communication is bad, discord between the division is difference but

<><><>

Obtaining - with, it included to S-Box, entire it hits and is not popular. [start *1] in the past, [end *1] but when it is combination of 256, as for probability of correct answer 1 (256! ) Being to become. Being not to be able to read the age of the participant, when you write once! With the calculation sign, factorial, mathematics of high school (probability statistics) with you are taught. 256! The 256~255~254~...... it becomes the calculation, ~1, but when it tries calculating in trial, you are disgusted and that it is the ["ya"] useless, you think that anyone can be agreed upon.

[*1: URL link to AVHDD crack [3] entry]

Furthermore considering to possibility of modification of Matsushita mounting in addition to S-Box, when it is the story which you say because possibility furthermore it spreads explosively, the hand you will acquire, but it becomes without.

<><><>

The algorithm of S-Box or C2 which are used for the latest entire hitting does not think if in the sense, agreement with DVD Audio, being something which can have self-confidence in that appearance, because it did, was completely ["gase"] with. The basis of judgement being not to be able to reveal, it does, but.


[Computer (goo.ne.jp & WWWJDIC) + human translations:]
The verdict is in -- AVHDD crack has failed. [I wonder] what went wrong[?]. The highest probable cause [for the failure] is that there were modifications in the S-Box for CPPM / CPRM / AVHDD in the C2 code.... [I wonder if encryption specs(?)] would go ahead and implement such combersome [methodology], considering [there are units like] DVD recorders supporting both DVD Audio / CPRM DVD-RAM[?].

[One could argue] that DVD Video already uses CSS code, adding 1 more code [type] shouldn't be a problem, because [such units] must support multiple code [types].

Futhermore, in AVHDD's case, [the unit] is doing the coding & decoding within the [built-in] chip [set]. There is a possibility, really, that won't be a problem even if C2 code standard has a different implementation [from AVHDD]. Would [companies like] Matsushita [a.k.a.: Panasonic, JVC, Quasar, Technics, etc.] take such trouble [with encyption?] of shipping out [units like] CPRM DVD-RAM recorders and [DVD] players that support DVD Audio[?]. (wouldn't [they] normally share [such technology]? But things would be different if there's communication problems within different [company] divisions)

[another one long sentence with multiple commas...; I hope I understood C2BF author's comments corrrectly]

<><><>

Ummm, [I] will not be doing distributed computing that includes S-Box. As [I] have written [*1 start] previously [*1 end], the possibily [for finding] the correct 256 [bit key] is 1/(256!). [odds are "one in 256 factorial" -- rest is untranslated; read summary for basic problem]

[*1: URL link to AVHDD crack [3] entry]

[summary: odds for finding a 256 bit key is "1 in 10^420" (1 with 400+ zeros); put in another way, while C2BF'ing a 56 bit was done in a few months, 256 bit will take roughly a few months multiplied by "1 with about 80 zeros"]

Furthermore, should there be a possibility of having to take into account that Matsushita will implement modification to S-Box, the possibility [of what?] will increase exponentially, which would be [well] beyond [my] reach.

<><><>

If it means the algorithm used on this round of distributed computing on S-Box and C2 conforms to DVD Audio [format], [this] was a confidence building [experience] in itself, [so I] didn't consider [what?] was a complete lie/fake. [However], I cannot reveal the basis for my decision.




1 usuarios están leyendo este tema

0 miembros, 1 invitados, 0 usuarios anónimos