sfrazor

Thank you everyone for taking the time to work through this with me. I read here often but haven't been in a position to ask for help until this stumped me. Until some pre-process or pre-pass substitution is supported by Delphi the answer was to take the the long names and replace them with coded alternatives and comment the heck out of the code for future developers to follow. Hand-jamming that was a chore even with the help of refactoring. Not very "Delphi" ie pretty, but it works and provides the obfuscation I needed for this mandate. I picked up some other tidbits here as well. If, for example if the decoupling would omit the long names and only embed the alternate names in the RTTI that would have been a perfect solution. Cheers!

This is the path I'm headed down. Its a tremendous amount of code, but hey, job security. I thought before I took on that task I'd ask here. I saw where Jedi has a pre-parser but its a bit vague on how to use it and it doesn't seem to exactly fit what I'm wanting to do. Uwe, I've looked at UPX. I don't see where it will handle DLL's unless I missed something. I konw Delphi doesn't NEED a pre parser but man it sure would be nice.

I know... I have asked this question almost exactly. Obviously I'm using simple field names that have no value. But in some of the code (In some of the DLL's) there are class names and members that identify proprietary information and they would prefer it to not be there as it paints a target on that binary to be investigated. Yes the information is sensitive which has created a push for obfuscation. Unfortunately I don't get a choice. Obfuscation is something they have adopted and I have to try and figure out. Like I said, strings and data are easy but if a specific name paints a target on one of the DLL's to be investigated it makes it that much quicker for someone to target. I know you've seen these question before but if a person snooping around sees 'kowsscud' instead of 'FPriorityAlgorythm' it makes it less obvious to 'start here' and not just handing it to some malicious person without trying. That seems to be all they want. In the past I've written python scripts that have a blacklist of strings it will search/replace in the CI/CD pipeline. Before I go down that road, I want to make sure I can't handle via native coding. Like I said, I've gotten the same response asking my peers. They respond with Why? What are they thinking, makes no sense, waste of time etc..... The answer may be that Delphi simply can't do it.

OK I threw together this example. The attributes decoupling mentioned above works fine for the production of the JSON. However the Fieldnames in the binaries is present. unit Unit4; //{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, REST.Json, REST.Json.Types; type TPPI = class public [JSONName('abcd')] FName: string; //client name [JSONName('efgh')] FAddress: string; //client address [JSONName('ijkl')] FCity: string; //client city end; type TForm4 = class(TForm) Memo1: TMemo; Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form4: TForm4; implementation {$R *.dfm} procedure TForm4.Button1Click(Sender: TObject); var MyPPI: TPPI; PPIJSON: string; begin MyPPI:= TPPI.Create; MyPPI.FName:= 'First Name'; MyPPI.FAddress:= 'Main Street'; MyPPI.FCity:= 'New York'; PPIJSON := TJSON.ObjectToJsonString(MyPPI, [joIndentCaseCamel]); // now that we have our JSON lets make if pretty //PrettyJson := TJsonObject.ParseJSONValue(TMJSON); //TMJSON := TJSON.Format(PrettyJson); Memo1.Lines.Add('////////////// JSON DATA //////////////'); Memo1.Lines.Add(PPIJSON); MyPPI.Free; end; That gets my JSON looking like this: ////////////// JSON DATA ////////////// {"abcd":"First Name","efgh":"Main Street","ijkl":"New York"} However these are still in the binary when I do a strings. Which is what started all of this when the binaries were reviewed. ... FName abcd FAddress efgh FCity ijkl TPPI, TPPI ... Scott

No, no debug. The Identifiers are all there in Release. Gonna throw together a very small sample. I'll add the decoupling example Uwe mentioned as well.

Custom attributes is a good read. It solves another request they made. Thanks! To answer your question, ultimately both would be best. Class and member names within the compiled binary are what caught my employers eye when reviewing the compiled binaries. I feel like if I obfuscate the class field names (not their values as I can post process and obfuscate those) , by default the associated JSON names will be obfuscated when they are processed to JSON which I'd then encrypt the JSON string as a whole. and decrypt it on the receiving end when its consumed. So in the above example I don't want FNAME showing in the binary when I run a simple 'strings' on it, I want 'abcd' to show and not 'FNAME'. When looking at the source, I want the programmer friendly FNAME to be in the source. Not real code here but it would be something like this: cons FNAME = 'abcd' type TPPI = classs public <$FNAME>: string; .... end; at compile time <$FNAME> converts to 'abcd' and when a strings is run on the binary, you only see 'abcd'. Of coarse in Delphi this could create all sorts of problems when referencing that class member later on. Does this help?

Thanks François , Yes I can pre/post process the JSON text itself, but the class member names still exist in the binary in their original form. ie 'FNAME' instead of 'abcd'. That's where I'm having difficulty. In 'C' this is easy but in Delphi I can't think of a way to ach ive that level of substitution.