dreadylein

kanet32 he tried to convert to float i guess well so we can choose now i guess, heavly messing around with the upk , including readjusting the tables or trying to get the binarie to cook us proper things, right ?

nice work as every time :)

mhh maybe we have some version problems here ? :D 1214 m_bInited 1219 InitMgr Which looks more promising Edit: Mh there nearly must be some kind of lengh for the objects, even if only indirect through the name to offset thing in the upk

Hexediting for the moment

mhm did you tryed 0x0b ? maybe you can just fill it with nops depends how the engine handle this token

huh ? of course, thats because the invalide code is nerver reached :D Or do i missunderstood you ?

anyone tried 0x0b token yet ? Seems like a nop :D

just change the bytecode in the decompressed upk if unpacking and repacking makes a problem it will have the same result at the end :)

na, but it would be easier for you open up a cmd and try it there

try decompress -lzo upkfilename.upk

nice :) This will make everything a good bit easier

as far as i know he changed the delay after overwatch just yesterday :)

Well, after a quick peek on ue explorer and some chattering with kanet32 we came up with the following Informations about the NTL files. Every entry in the table seems to have the following format: [operator name] [operator precedence] [format] [bytecode] Format can be: 01 for functions 02 for operators 03 pre increment operator 04 post increment operator Example done by Kanet32 02 3D 3D 18 02 9A The size of the operator name is 02 bytes, then the operator name is 3D 3D ("=="), then the precedence is 0x18, the format is 0x02, and the bytecode is 0x9A. The operator precedence seems to be used to make a workorder where a lower value means a higher precedence (we arent realy sure about this yet) A last little note, kanet32 stumble over something pretty hilarious, there seems to be like 8 different bytecode for the same operator , we dont know why, atm we just think its for backwards compatibility.

isnt ue explorer written in c# ? :o Then we could peek to see how it use the the other bytes

would use tables from the september 2011 sdk, this is what there engine is based of The tables are in the UE Explorer directory under Native Tables

Grats :) hate my weak english :o , kanet32 pretty much explained whats missing to understand nearly all of the bytecode :) A tool which helps us out a bit would be awesome :o Shouldnt be terrrible complicatet i guess Mh a simple list about the bytecodes we searched in the table or source would help big times :o Having it at one look would be nice i guess

Yup, i mostly do it this way: make an unpack of a upk Search the right Functionfile Open it in a Hexeditor Open a Commandline Alter something, make a repack as x.upk Put it into ueviewer and look at the changes Repeat So i can see the original function and all the changes And yes, as i said only saw conditional jumps, no compares yet Edit: Could you pm me the bytecode ?

Im at work so dont relay to heavy on it, could be mistakes in it look at the bytecode take a look at the tokencodes If condtionals seems to be done through a if not equal token, didnt saw other things yet after the jump tokens the next thing is the offset for the leave altering the 0x07 for conditional jump to 0x06 for an uncondtional jump will give you the control what to do next Edit: well this list seems familar :D The Case Switch under it is important too

@mbel atm we are able to mod the upks, but it involves "jumping through loops" as daemonjax would say :D goal of this tool would be an easy way to do all the manual steps automated

@daemonjax you are absolutly right :D overlook it :o Nontheless, changeing the conditional jump to unconditional should work

hexeditor would be the first choice, calc the hex values for your decimal values, search for them should be easy but as far as im aware, there is some kind of crc check in it, thats the important thing you have to find

Required would be Decompressing Patching the bytecode Filehandling of the little uncompressedfilesize files Sha1 hash Patching Nice would be Backuphandling Version checks Would love to help you but my experince with java are near to none, so my code would look like a complet mess i guess, dont know if this would lead to more work for you then help :P

How much you are able to change only depends on the time you inviest tbh ;) IF conditions are done with a Jumpifnotequal loop Guess changing the Jumpifnotequal to a unconditional jump would do the trick here as the next token after the jump is the leaving point So in Theory the script would skip this step undconditional

agree, for corruption they would have other ways think its more like standart function of the engine and they used it to protect the gamelogic and netcode Edit: Thanks god i'm not the only one who thinks this :D Maybe its just because i didnt see ue bytecode before but its quite confusing Edit2: Grats, its an awesome feeling seeing a change after so much work, isnt it ? :D

didnt see the homecall do other things then updating inis, but i didnt search for it also :P Hadnt seen any anti cheat at all yet, well ok, they put the mp vars not in plain sight but that it is, in theory it could be the couse for putting the inis into the binary