The first three Limit Breaks on our list have the same number of frames set aside: 2700 frames (0xA8C in hexadecimal). That's 45 seconds.

The Chaos Vincent LB is the outlier, having only 600 frames (0x258) reserved. That's 10 seconds.

Animations when initializing LB state will eat away at these times, especially so in Galian Beast form, but we'll put that aside for now.

Once a limit break has been activated we can find the instructions for these LB durations by searching for the correct array of bytes.

2700-frame LB: C7 05 ?? ?? ?? ?? 8C 0A 00 00

600-frame LB: C7 05 ?? ?? ?? ?? 58 02 00 00

The set of question marks represent the address of a container which may be different between occurrences of Limit Break activation. Cheat Engine accepts "?" as a wildcard to represent an unknown value. I could technically shorten the array of bytes down to "

C7 5 ? ? ? ? 8C A 0 0", removing superfluous digits, but for reasons of symmetry I prefer any byte-hex to be written with two digits.

Are we in the clear now to easily replace 2700 with some much, much higher value and extend the LB? Not so!

Two operations are performed on the retrieved 4-byte value before it is actually used to start up a Limit Break. First the value is shifted left 16 times. This can also be expressed as "multiply by 2, 16 times".

**shl** = shift logical left

The result of the above operation is then shifted shifted right 16 times, but under arithmetic logic. This can be written as "signed divide by 2, 16 times". What does basically means is that if you attained a negative number from the shift-left, the result of this next shift-right operation will also be negative.

**sar** = shift arithmetic right

For small values like 2700 or 600 this is not a problem. You end up with the same value you started with.

00000A8C * (2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2) = 0A8C0000

0A8C0000 / (2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2) = 00000A8C

But with high values we run into issues. The shift-left could leave us with only zeroes. Let's say we took the hex number 0x77770000 (2004287488 in decimal) and shifted it left 16 times.

77770000 << 10 = 00000000

The shifted bits do not loop back around to the beginning, so we are now left with a Limit Break duration of 0 frames.

There is also a second trap. Let's say we replaced 2700 (0xA8C) with 32768 (0x8000). What will happen?

00008000 * (2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2) = 80000000

80000000 / (2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2) = FFFF8000

The shift-left created a 4-byte number where the most significant bit (the bit to the furthest left) was set to 1.

Hexadecimal: 80000000

Binary: 10000000000000000000000000000000

That means it can be interpreted as a negative number, which is precisely what the

**sar** operation does in its arithmetic logic. When a negative number is divided with a positive number, we still end up with a negative number. In most cases, the game will not like this and choose to end the Limit Break either immediately or 1 second after it has begun.

I say "in most cases" because while writing this post I discovered that the code is way more complex than expected. When editing the values for the shift-operations, there are situations where the game will accept negative values for the Limit Break duration and other times when it will not.

There can even occur a "counter-glitch" with the 1-second delay that's intended to mark when your LB state should end. This 1 second is a value of 60 (3C) and also goes through the shift-left and shift-right operations. So when the game shifts this value left 16 times (

3C << 10 = 3C0000) , but I have edited the code to not shift right, you end up with a long-lasting Limit Break regardless.

Why are these logical- and arithmetic shifts happening to begin with? Maybe they are obfuscations, meant to make it more difficult for hackers to tap into the power of Limit Breaks. Due to Dirge of Cerberus once having had an online component, I often speculate that the game was programmed with higher security in mind so to prevent cheating in an online multiplayer environment.

It's also entirely possible that the LB code is unintentionally wrapped up in other functions, where the shift-operations have an actual intended purpose.